Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NEW – Suricata 1.4.6 pkg v0.1 BETA package released

    Scheduled Pinned Locked Moved pfSense Packages
    36 Posts 7 Posters 7.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • AhnHELA
      AhnHEL
      last edited by

      @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 (Angel)

      1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks
        last edited by

        @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

        1 Reply Last reply Reply Quote 0
        • AhnHELA
          AhnHEL
          last edited by

          Easily fixed and confirmed working properly now  8)

          Many thanks as always.

          AhnHEL (Angel)

          1 Reply Last reply Reply Quote 0
          • BBcan177B
            BBcan177 Moderator
            last edited by

            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.

            "Experience is something you don't get until just after you need it."

            Website: http://pfBlockerNG.com
            Twitter: @BBcan177  #pfBlockerNG
            Reddit: https://www.reddit.com/r/pfBlockerNG/new/

            1 Reply Last reply Reply Quote 0
            • P
              priller
              last edited by

              **  Wishlist Item **

              The ability to click on an object within an alert and have that download the pcap file that contains the data.

              1 Reply Last reply Reply Quote 0
              • P
                priller
                last edited by

                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?

                1 Reply Last reply Reply Quote 0
                • bmeeksB
                  bmeeks
                  last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User
                    last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • bmeeksB
                      bmeeks
                      last edited by

                      @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

                      1 Reply Last reply Reply Quote 0
                      • P
                        priller
                        last edited by

                        @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?

                        snort-ET.jpg
                        snort-ET.jpg_thumb
                        sur-ET.jpg
                        sur-ET.jpg_thumb

                        1 Reply Last reply Reply Quote 0
                        • ?
                          A Former User
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • P
                            priller
                            last edited by

                            @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.

                            1 Reply Last reply Reply Quote 0
                            • bmeeksB
                              bmeeks
                              last edited by

                              @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

                              1 Reply Last reply Reply Quote 0
                              • bmeeksB
                                bmeeks
                                last edited by

                                @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

                                1 Reply Last reply Reply Quote 0
                                • bmeeksB
                                  bmeeks
                                  last edited by

                                  @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

                                  1 Reply Last reply Reply Quote 0
                                  • AhnHELA
                                    AhnHEL
                                    last edited by

                                    @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?

                                    AhnHEL (Angel)

                                    1 Reply Last reply Reply Quote 0
                                    • BBcan177B
                                      BBcan177 Moderator
                                      last edited by

                                      @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?

                                      "Experience is something you don't get until just after you need it."

                                      Website: http://pfBlockerNG.com
                                      Twitter: @BBcan177  #pfBlockerNG
                                      Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                                      1 Reply Last reply Reply Quote 0
                                      • C
                                        Cino
                                        last edited by

                                        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
                                        
                                        
                                        1 Reply Last reply Reply Quote 0
                                        • bmeeksB
                                          bmeeks
                                          last edited by

                                          @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

                                          1 Reply Last reply Reply Quote 0
                                          • bmeeksB
                                            bmeeks
                                            last edited by

                                            @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

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.