NEW – Suricata 1.4.6 pkg v0.1 BETA package released
-
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 -
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.pidThanks for the report. I have noticed that sometimes, for an unknown reason, Suricata seems to need two consecutive "stop" commands in order to actually stop. During the initial development I just worked around it by calling "kill" on Suricata twice in succession from the GUI. Might have to incorporate the same thing into the shell script that pfSense uses to start/stop services.
As I have continued working over the weekend on the next 0.2 update of the BETA, I've found some dumb bugs and logic flaws that I am fixing from the v0.1 release. I hope to get out the v0.2 BETA package in the next few days to address all of those problems and some of the ones reported here by users. Blocking in Suricata is still a bit farther out, though. For true inline IPS-mode, some changes to the pfSense kernel code are required and Ermal is looking at those. Since those kinds of changes are sort of major, I don't look for that to happen until at least pfSense 2.2. However, it is possible to patch/hack Suricata to work like Snort on pfSense and use an alias table in the packet filter for blocking. I have that plan in my back pocket as a temp solution for blocking.
Bill
-
@BBcan17:
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?
This is coming soon, and hopefully in the next Snort release. I want to implement the IP Reputation preprocessor in Snort. This uses simple text files with one IP address or network per line. Lists are distributed with the ET-Pro rules and, I believe, some other packages. Read up on the IP reputation preprocessor here: http://manual.snort.org/node17.html#SECTION003219000000000000000. The preprocessor offers high performance because it's a simple SRC or DST IP address compare. No CPU-intensive pcre matching of traffic content, etc.
Bill
-
This is coming soon, and hopefully in the next Snort release. I want to implement the IP Reputation preprocessor in Snort. This uses simple text files with one IP address or network per line. Lists are distributed with the ET-Pro rules and, I believe, some other packages. Read up on the IP reputation preprocessor here: http://manual.snort.org/node17.html#SECTION003219000000000000000. The preprocessor offers high performance because it's a simple SRC or DST IP address compare. No CPU-intensive pcre matching of traffic content, etc.
Bill
Thats Great news.
If pfBlocker could incorporate .CSV, there are several other lists that can be added.
-
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?
Sorry AhnHEL to be so late responding to your question about the "Block Offenders" feature. I am about to release a Suricata v0.2-BETA update that fixes all the bugs reported thus far (and some more I found while fixing the reported ones). Hopefully this 0.2-BETA will be a more or less "done" package in terms of basic functionality with everything working but blocking. After that, my next priority is to update Snort to the 2.9.6.0 version of the binary and make a few feature ports from Suricata over to Snort (like the new Barnyard2 page with its additional output options, for example). When that is done, then I will work on the blocking feature for Suricata. In terms of a date, a guesstimate right now is maybe the end of March or early in April for the blocking feature.
Bill
