NEW – Suricata 1.4.6 pkg v0.1 BETA package released



  • A new Suricata port for pfSense versions 2.1 and higher has now been posted and is available under System…Packages.  This is the initial BETA release of the package and your feedback is welcomed.

    You must be running pfSense version 2.1 or higher in order to see and install the Suricata package.

    KNOWN BUGS:
    The LOGS BROWSER tab for viewing logs is currently broken due to a quick last minute code edit gone bad that was not caught.  A fix will be posted soon, so please be patient.  A self-help fix for this bug is posted here: https://forum.pfsense.org/index.php/topic,72974.msg397988.html#msg397988.  You can perform the file edit described there to repair the bug until the update code is posted.   This fix for this bug has been merged.  If you have a problem with the LOGS BROWSER tab, simply reinstall the package (the version number won't change; it's still v0.1 for this first BETA).

    NOTES:
    This initial BETA release does not offer blocking of offenders.  It operates in IDS (intrusion detection) mode only.  IPS (blocking) mode is planned for later versions of the package.  One more time – this initial package will not block offending traffic, it will just log it.

    The underlying binary version of Suricata in the package is 1.4.6.

    The GUI is borrowed heavily from the Snort package (actually it's almost a complete copy and paste :) ).  This means the general layout of the options and the icons should be familiar to Snort users.

    While Suricata can decode and use the Snort rules, things will work much better with the Emerging Threats rules.  Emerging Threats offers a set of Suricata-optimized rules, and if you enable either the Emerging Threats Open or Pro rules on the GLOBAL SETTINGS tab in the package, the Suricata-optimized rule set will be downloaded and used.  If you still wish to use the Snort VRT rules or the Snort GPLv2 Community rules, be prepared to deal with some flakiness.  Somewhere around a hundred of the Snort VRT rules may fail to validate with Suricata due to unsupported rule options and keywords.  This will not stop Suricata from starting, but the failed rules will of course never fire.  Suricata does a good job of logging its startup progress.  On the LOGS BROWSER tab, open and view the suricata.log file to see which rules passed and which failed validation.

    If you have never experimented with Suricata, then your first stop should be to peruse the documentation available at http://www.suricata-ids.org/.  Even though this initial package offers IDS mode only, Suricata offers several cool features not currently available in the Snort package.  Some examples are full packet capture, capture and storage of downloaded files from HTTP or FTP connections, and fairly extensive logging of HTTP sessions.  There is also a TLS log output available for capturing TLS handshakes.  To get an idea of all the logging features available, look under the INTERFACE tab once the package is installed and initially configured for an interface.  There is a new LOGS BROWSER tab that will let you select an interface and then any of the configured logs for viewing.

    Some additional Barnyard2 output options are included with Suricata including full syslog output to either the local firewall (not really recommended) or to a remote syslog receiver (this is recommended).  The traditional MySQL database output is still available as well.

    Please remember that full packet capture and file downloads logging can eat up a lot of disk space very quickly!!!  Pay attention to how much space you have.  I strongly suggest you make sure the Log Directory Limit feature is enabled on the GLOBAL SETTINGS tab.  This will create a cron job that will clear out Suricata logs when they exceed the configured disk space limit.  All logging is done to the /var volume in a suricata directory tree there.

    FEEDBACK:
    Comments and bug reports are welcome.  The intent of putting out this initial BETA package is to solicit user feedback.  Please post your comments or issues back to this thread.  The idea is for the Snort and Suricata GUIs to pretty much mimic each everywhere possible.  It will take a bit of time to get there, though.

    Have fun testing, and let me know what you think:
    Bill



  • Can Snort and Suricata run concurrently?  (mainly just while we are in the testing phase)

    Bad things going to happen?



  • @priller:

    Can Snort and Suricata run concurrently?  (mainly just while we are in the testing phase)

    Bad things going to happen?

    No, and in fact that could be a good idea.  Run Snort on the WAN and Suricata on the LAN. That way you can see what Snort might miss.  This would be a good way to compare rule sets as well.  Just remember the caveat that Suricata does not recognize all the Snort VRT keywords and options in their rules, so you will get some Snort rules thrown out by Suricata.  All things considered, I recommend folks use Emerging Threats rules with Suricata.

    Suricata can be your IDS and grab a bunch of stuff for logging and later analysis.  For example, you can enable several of the rules in files.rules on the RULES tab. These will sense and capture and store certain downloaded file types Suricata sees in the stream.  By default, all the rules in files.rules are disabled.  But you could try some and see what happens.  You will also need to enable the file logging features under the INTERFACES tab.  I have not tested this personally, so I'm curious how well it works.

    Bill



  • Did as you stated Bill, only using ET rulesets and checked them all off for testing purposes.

    Saw a false positive so I initiated your "new" force-disable feature of a rule and the ruleset did a Live Rule Swap/Reload successfully.  Looking good!

    I have 16GB of RAM on this box and I was noticing that with the Max Pending Packets set to 32768, my memory climbed and maxed out and then started swapping out to failure.  Something is definitely up with that setting.  Only 2 settings not at default were the Max Pending Packets and Detect Engine Profile which I set at High.

    The Logs Browser tab isnt showing anything and Instance to View does not list any interface, WAN is the only interface I've setup.



  • Thanks Bill!! I have both Snort and Suricata running with no issues so far. I have Snort setup on all my interfaces and twice for the WAN (One for Blocking and another for Alerting). I'm running Suricata on the WAN and using the same rules I have for my Snort Blocking setup. For the most part, they are alerting the same but Snort is catching more because of the extra rules its able to read… I'll have to get more familiar with Suricata since I've never used it before...

    P.S I know this if off topic, but if you can; copy the barnyard2 page/code over to the snort package ;-)

    Thanks again for all your work you have done



  • @AhnHEL:

    Did as you stated Bill, only using ET rulesets and checked them all off for testing purposes.

    Saw a false positive so I initiated your "new" force-disable feature of a rule and the ruleset did a Live Rule Swap/Reload successfully.  Looking good!

    I have 16GB of RAM on this box and I was noticing that with the Max Pending Packets set to 32768, my memory climbed and maxed out and then started swapping out to failure.  Something is definitely up with that setting.  Only 2 settings not at default were the Max Pending Packets and Detect Engine Profile which I set at High.

    The Logs Browser tab isnt showing anything and Instance to View does not list any interface, WAN is the only interface I've 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.

    Bill



  • @Cino:

    Thanks Bill!! I have both Snort and Suricata running with no issues so far. I have Snort setup on all my interfaces and twice for the WAN (One for Blocking and another for Alerting). I'm running Suricata on the WAN and using the same rules I have for my Snort Blocking setup. For the most part, they are alerting the same but Snort is catching more because of the extra rules its able to read… I'll have to get more familiar with Suricata since I've never used it before...

    P.S I know this if off topic, but if you can; copy the barnyard2 page/code over to the snort package ;-)

    Thanks again for all your work you have done

    Thank you Cino for the kind words.

    I do indeed intend to copy the Suricata barnyard2 page and capabilities over to the Snort package.  My goal is to do that in the next Snort update when the binary moves to 2.9.6.0.  That should be later in March if my plans hold.

    Bill



  • @AhnHEL:

    I have 16GB of RAM on this box and I was noticing that with the Max Pending Packets set to 32768, my memory climbed and maxed out and then started swapping out to failure.  Something is definitely up with that setting.  Only 2 settings not at default were the Max Pending Packets and Detect Engine Profile which I set at High.

    Just noticed the detail about the Detect Engine Profile being set to "High".  I think I do recall seeing that can just gobble up memory (like it will go right up beyond 64 GB).  I'm not a Suricata expert.  Just started toying with it around this past Christmas.  There are a couple of Suricata sites that you can find via Google.

    One of the primary project leads from the Suricata project volunteered back in late January to help beta test the package and provide some suggested tuning parameters for pfSense.  I sent him an e-mail just after the package was posted, so hopefully he and his team will get some time to do some testing and suggesting.

    Bill



  • @bmeeks:

    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.



  • @AhnHEL:

    @bmeeks:

    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



  • @bmeeks:

    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.



  • @AhnHEL:

    @bmeeks:

    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.


  • Moderator

    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?



  • @priller:

    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



  • @priller:

    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.



  • @priller:

    **  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



  • @bmeeks:

    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.



  • @bmeeks:

    @priller:

    **  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



  • @priller:

    @bmeeks:

    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



  • @priller:

    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



  • @bmeeks:

    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?


  • Moderator

    @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
    
    


  • @Cino:

    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
    
    

    Thanks 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


  • Moderator

    @bmeeks:

    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.



  • @AhnHEL:

    @bmeeks:

    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



  • A feature I always wanted was common block lists in case of a CARP cluster. Is there anyway for the master to sync over the blocked hosts to the slave AND vice versa?



  • @jflsakfja:

    A feature I always wanted was common block lists in case of a CARP cluster. Is there anyway for the master to sync over the blocked hosts to the slave AND vice versa?

    In theory, I believe so.  Now actually implementing this might be a bit tricky.  Probably one of the seasoned pfSense Core Team developers is better suited to answer the question.  I can ask them via e-mail and see what they say.  Since the blocks are really just entries in an existing pf alias table, if the firewall tables are replicated, then the blocks should be going along for the ride.  I don't run a CARP cluster, though, so I'm a bit ignorant of how pfSense does it.  I'm more familiar in my old professional life with VRRP on Nokia and Checkpoint products.

    Bill



  • Thanks for the new Suri package, been looking forward to this for a bit. :)

    Feel free to disregard, but I was wondering how hard it would be to implement an options tab similar to the oldschool Snort IDSControl Center (see example)

    I like the idea of being able to quick select options for a custom starting command line and then being able to save that Suri/Snort profile for later use.



  • @JWTrance:

    Thanks for the new Suri package, been looking forward to this for a bit. :)

    Feel free to disregard, but I was wondering how hard it would be to implement an options tab similar to the oldschool Snort IDSControl Center (see example)

    I like the idea of being able to quick select options for a custom starting command line and then being able to save that Suri/Snort profile for later use.

    Be on the lookout for a substantial update to the Suricata package to be posted sometime over the next few days. I will be submitting the Pull Request shortly.  This will be version v0.2-BETA of the package.  There are lots of bug fixes and some other enhancements (such as an included Dashboard Widget, better rule update management and logging, and a Bro output option for Barnyard2).

    As for some control over command-line options, that is certainly possible.  Right now a fair number of parameters are configurable in the GUI and then provided to the Suricata binary via the suricata.yaml conf file.  Are there some Suricata-specific command-line options you need that are not available in the GUI?  If so, post a list and I will see what I can do.

    Bill