NEW – Suricata 1.4.6 pkg v0.1 BETA package released
-
I will check on the Logs Browser problem. It has worked for me fine, but I use Internet Explorer. Have not tested with another browser yet. Are you using IE or something else?
I will also check into the memory use. I did some early following of Suricata bug reports (for the binary) some time back, but have not visited those threads in a while since I've been working on the package.
I use Chrome, but just swapped over to IE to test and I'm still not getting an Interface in the Logs Browser Tab.
I left Detect Engine Profile on High but brought the Max Pending Packets down to default of 1024 and its running fine so its not the Detect Engine Profile but the combination of the two settings on my setup.
-
I will check on the Logs Browser problem. It has worked for me fine, but I use Internet Explorer. Have not tested with another browser yet. Are you using IE or something else?
I will also check into the memory use. I did some early following of Suricata bug reports (for the binary) some time back, but have not visited those threads in a while since I've been working on the package.
I use Chrome, but just swapped over to IE to test and I'm still not getting an Interface in the Logs Browser Tab.
I left Detect Engine Profile on High but brought the Max Pending Packets down to default of 1024 and its running fine so its not the Detect Engine Profile but the combination of the two settings on my setup.
That Logs Browser problem bugs me. I can't for the life of me understand what may be wrong with it. It should show at least the one configured interface in the top drop-down. The Log drop-down is blank initially until you select a log. I never had that crop up during development testing. Is the interface name something common like WAN or LAN? Just wondering if it might have any special characters in it.
Bill
-
That Logs Browser problem bugs me. I can't for the life of me understand what may be wrong with it. It should show at least the one configured interface in the top drop-down. The Log drop-down is blank initially until you select a log. I never had that crop up during development testing. Is the interface name something common like WAN or LAN? Just wondering if it might have any special characters in it.
LAN and WAN are both labeled as such, no fancy names here. Switched over from WAN interface to LAN and still no change. Maybe someone else will comment and say its working for them and its just some strange scenario with what I've setup.
-
That Logs Browser problem bugs me. I can't for the life of me understand what may be wrong with it. It should show at least the one configured interface in the top drop-down. The Log drop-down is blank initially until you select a log. I never had that crop up during development testing. Is the interface name something common like WAN or LAN? Just wondering if it might have any special characters in it.
LAN and WAN are both labeled as such, no fancy names here. Switched over from WAN interface to LAN and still no change. Maybe someone else will comment and say its working for them and its just some strange scenario with what I've setup.
Oops! Egg on face many times over :-[ :-[
Just realized that in a last minute rush yesterday to incorporate some comments from Ermal into the package code that I messed up on the LOGS BROWSER page. My copy from the repository is not showing any interfaces. I will get a fix posted for this, but it may be a day or two before I can get the Core Team devs to merge it. They have been quite busy.
In the meantime, if you are quasi-proficient with the [b]Diagnostics…Edit File feature in pfSense, you can fix it yourself as follows:
Open /usr/local/www/suricata/suricata_logs_browser.php
Scroll down and find this line in the file:echo " <option value="{$id}" {$selected}="">(" . convert_friendly_interface_to_friendly_descre($instance['interface']) . "){$instance['descr']}</option>\n";The problem is an incomplete copy-and-paste that failed to overwrite the "e" on the end of "_descre". It should read as follows:
echo " <option value="{$id}" {$selected}="">(" . convert_friendly_interface_to_friendly_descr($instance['interface']) . "){$instance['descr']}</option>\n";Make that change and save the file to fix the problem until a package update is merged.
Bill
-
Easily fixed and confirmed working properly now 8)
Many thanks as always.
-
If anyone is going to run both Snort and Suricata together at the same time, make sure that the UPDATE Interval is staggered or you will get an update error from Snort and ET as you can't poll twice within a 15-20 mins interval.
-
** Wishlist Item **
The ability to click on an object within an alert and have that download the pcap file that contains the data.
-
All the "emerging-*" ET rules show under the Categories. However, the following are in suricata.yaml but are not there:
- botcc.rules
- ciarmy.rules
- compromised.rules
- drop.rules
- dshield.rules
- rbn-malvertisers.rules
- rbn.rules
- tor.rules
http://rules.emergingthreats.net/open/suricata/rules/
…. should they be?
-
All the "emerging-*" ET rules show under the Categories. However, the following are in suricata.yaml but are not there:
- botcc.rules
- ciarmy.rules
- compromised.rules
- drop.rules
- dshield.rules
- rbn-malvertisers.rules
- rbn.rules
- tor.rules
http://rules.emergingthreats.net/open/suricata/rules/
…. should they be?
To keep the various rule sets separated (since the names duplicate within ET and VRT), each enabled vendor rule set is prefixed with a label to identify the source. So for example, the "drop.rules" in ET-Pro rules would be listed under CATEGORIES as "etpro-drop.rules" while the ET-Open version would be "emerging-drop.rules". You should see them listed that way under the CATEGORIES tab.
Both the Suricata and Snort packages on pfSense gather up all your enabled rules and writes them to a single file on disk called "suricata.rules" (or "snort.rules" on the Snort package). This file is the one actually specified in the suricata.yaml file used by each configured interface.
Bill
-
All the "emerging-*" ET rules show under the Categories. However, the following are in suricata.yaml but are not there:
- botcc.rules
- ciarmy.rules
- compromised.rules
- drop.rules
- dshield.rules
- rbn-malvertisers.rules
- rbn.rules
- tor.rules
http://rules.emergingthreats.net/open/suricata/rules/
…. should they be?
You shouldn't actually be using those rules, that's pfblocker's job. see https://forum.pfsense.org/index.php/topic,64674.0.html
I really like this suggestion:
@priller:** Wishlist Item **
The ability to click on an object within an alert and have that download the pcap file that contains the data.
looks into the crystal ball I foresee spending a lot of time to create a new suricata+pfblocker blueprint :P
Special thanks to Bill for all the work he is doing on pfsense's IDS/IPS functionality. -
** Wishlist Item **
The ability to click on an object within an alert and have that download the pcap file that contains the data.
I agree that would be a cool feature, but I don't know at the moment how to tie the two together. In other words, how to know out of the several of on-disk rotated pcap files which particular one contains a specific alert. If there is some hidden index or key you know about, please share and I will see if I can implement the feature.
Bill
-
To keep the various rule sets separated (since the names duplicate within ET and VRT), each enabled vendor rule set is prefixed with a label to identify the source. So for example, the "drop.rules" in ET-Pro rules would be listed under CATEGORIES as "etpro-drop.rules" while the ET-Open version would be "emerging-drop.rules". You should see them listed that way under the CATEGORIES tab.
They are there in Snort, but not in Suricata. Due to having both running?
-
How about adding the unix epoch timestamp to the alert? Not visible (to reduce clutter), but a clickable button to take you to the file. That should be directly related to the file that is created by the alert. If that's not possible, there should be a direct relation to the alert time and the file creation.Haven't tested the package yet, I'm super busy this weekend, so can't really say how the pcaps are related to the alerts.
-
** Wishlist Item **
The ability to click on an object within an alert and have that download the pcap file that contains the data.
I agree that would be a cool feature, but I don't know at the moment how to tie the two together. In other words, how to know out of the several of on-disk rotated pcap files which particular one contains a specific alert. If there is some hidden index or key you know about, please share and I will see if I can implement the feature.
Bill
Can it be derived from the time stamp of the alert and the pcap file? Look for the pcap that would contain the time range that the alert fired in.
-
@jflsakfja:
How about adding the unix epoch timestamp to the alert? Not visible (to reduce clutter), but a clickable button to take you to the file. That should be directly related to the file that is created by the alert. If that's not possible, there should be a direct relation to the alert time and the file creation.Haven't tested the package yet, I'm super busy this weekend, so can't really say how the pcaps are related to the alerts.
That might work. I will look into it. Thanks for the suggestion.
Bill
-
To keep the various rule sets separated (since the names duplicate within ET and VRT), each enabled vendor rule set is prefixed with a label to identify the source. So for example, the "drop.rules" in ET-Pro rules would be listed under CATEGORIES as "etpro-drop.rules" while the ET-Open version would be "emerging-drop.rules". You should see them listed that way under the CATEGORIES tab.
They are there in Snort, but not in Suricata. Due to having both running?
I have a temporary ET-Pro subscription I was using for testing, and those rules are there for me in Suricata. Let me quickly test an ET-Open VM to see the result. As for Snort and Suricata running together, that should not figure in as each has its own directory for storing stuff and doing rule extractions and such.
Bill
-
They are there in Snort, but not in Suricata. Due to having both running?
I figured out what the problem is. It is a naming convention anomaly. Turns out those files are named slightly differently in the ET-Open tarball as opposed to the ET-Pro tarball I did the majority of my testing with. This one slipped by me during my testing. I will fix it and get it into the next update. I'm working on v0.2 of the Suricata package now.
Bill
-
I'm working on v0.2 of the Suricata package now.
Strict curiosity but any thoughts on when you will complete the "Block Offenders" feature of Suricata?
-
@jflsakfja:
All the "emerging-*" ET rules show under the Categories. However, the following are in suricata.yaml but are not there:
- botcc.rules
- ciarmy.rules
- compromised.rules
- drop.rules
- dshield.rules
- rbn-malvertisers.rules
- rbn.rules
- tor.rules
http://rules.emergingthreats.net/open/suricata/rules/
…. should they be?
You shouldn't actually be using those rules, that's pfblocker's job. see https://forum.pfsense.org/index.php/topic,64674.0.html
The only problem with using pfBlocker for those rules is that they are based on the ET OPEN RuleSet. If you have a paid ET subscription, Snort will still pick up IPs that are not in the OPEN list.
Maybe, Snort/Suricata could create a list of IPs in theses categories above and generate a list for pfBlocker to use?
-
I think I found an issue that is similar to an issue we have had with snort, more then 1 instance of it running… I have a feeling its because of apinger reloading interfaces. I am running Suricata on 2 interfaces, WAN and LAN. I have them stop in suricata_interfaces.php, I tried to stop them in Services but Suricata remains running. I'll have do some more testing but wanted to let you know.
root 16637 5.4 14.9 506440 467016 ?? Ss 9:48AM 5:35.82 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 35615 5.2 6.3 523848 197992 ?? Ss 11:29AM 89:14.46 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 6687 4.9 8.1 523848 252860 ?? SNs 11:29AM 88:19.67 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 39904 4.9 14.8 518724 461212 ?? SNs 12:13AM 40:26.23 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 96654 4.9 2.6 336516 80580 ?? SNs 11:29AM 85:44.73 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_50725_em3/suricata.yaml --pidfile /var/run/suricata_em350725.pid root 6132 0.0 0.2 30972 5536 ?? SN 11:29AM 0:02.12 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 34024 0.0 0.0 3644 0 ?? IWN - 0:00.00 /bin/sh /usr/local/etc/rc.d/suricata.sh start root 38206 0.0 0.2 30972 7780 ?? SN 12:13AM 0:01.06 /usr/pbi/suricata-i386/bin/suricata -i em2 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_40502_em2/suricata.yaml --pidfile /var/run/suricata_em240502.pid root 58340 0.0 0.0 3644 0 ?? IWN - 0:00.00 /bin/sh /usr/local/etc/rc.d/suricata.sh start root 95639 0.0 0.0 3644 0 ?? IWN - 0:00.00 /bin/sh /usr/local/etc/rc.d/suricata.sh start root 96518 0.0 0.2 30972 5496 ?? SN 11:29AM 0:02.07 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_50725_em3/suricata.yaml --pidfile /var/run/suricata_em350725.pid
