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

    Snort and Interface Enable/Disable

    Scheduled Pinned Locked Moved pfSense Packages
    60 Posts 8 Posters 20.4k 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.
    • D
      dhatz
      last edited by

      bmeeks, thanks for your very promising work.

      Would be good if one could tag Ermal in this topic….

      It seems to me that Snort is a complex piece of software that requires one to have a certain amount hands-on-experience with IDS, in order to create a fully functional pfsense package.

      Apparently a new binary will be nice, because 2.9.2.3 is going EoL soon.

      Snort Version Released EOL
      Snort 2.9.2.3 2012-05-16 2013-02-28
      Snort 2.9.3.1 2012-08-12 TBD**
      Snort 2.9.4.0 2012-11-30 TBD**

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

        Snort is indeed a bit complex and somewhat sensitive to the settings in the snort.conf file (no big surprise there  ;) )

        I am quite close to being finished with my modifications and updates.  Here is a screenshot of some of the new features that are working.  I have corresponded with the Forum admins, and the recommended course of action for posting my code is via Github and then executing a Pull Request for Ermal or others on the pfSense team to evaluate.  So I will not post modified PHP files directly to the forum, but will instead have them available on my fork of the Github pfsense-packages repository.  I will post a link back here when things are posted.

        Are there any particular settings for the HTTP_Inspect or Stream5 preprocessors that anyone would like to have GUI configuration parameters available for?  Below you can see what will be available (if my submissions are accepted by the pfSense team).

        New Preprocessors tab showing additional settings

        ![New Preprocessors tab.jpg_thumb](/public/imported_attachments/1/New Preprocessors tab.jpg_thumb)
        ![New Preprocessors tab.jpg](/public/imported_attachments/1/New Preprocessors tab.jpg)

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

          Here is another screenshot of the new Categories tab showing the features I've added for IPS Policy selection and automatic flowbit resolution for selected rules.

          New Categories tab (partial)

          ![New Categories tab.jpg](/public/imported_attachments/1/New Categories tab.jpg)
          ![New Categories tab.jpg_thumb](/public/imported_attachments/1/New Categories tab.jpg_thumb)

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

            Last post for this evening…

            For those of you that use the enablesid and disablesid feature in the Snort package, I've found some potential big bugs with its implementation in the current code base.  In particular, it can't cope with multi-line rules.  These are rules with a backslash ("") at the end of the line followed by a newline to signal continuation onto the next line.  There are a handful of these multi-line rules in the rule sets from Emerging Threats and the Snort VRT.  The current code just assumes any newline indicates the end of a rule when reading a rules file.  Obviously with multi-line rules this is a mistake.

            This bug, combined with the way the old code physically wrote back to disk a modified version of the rules file when enablesid or disablesid was used, risks writing a corrupt rules file when the original contains any multi-line rules.

            My new procedure for handling enablesid and disablesid will fix this potential bug.  I'm including the capability to "reset to defaults" any rules you may have previously disabled or enabled.  The "reset to defaults" feature will return all the rules in a particular category to their default state, effectively wiping the slate clean of any modifications you previously made.

            Of course I'm also adding the necessary hooks to ensure that any disablesid or enablesid customizations are preserved across rule updates... ;D

            1 Reply Last reply Reply Quote 0
            • S
              Supermule Banned
              last edited by

              Is it possible that this could go into 2.0.3 as well??

              Since current Snort package EOL??

              Pls. push Jim and Ermal for this if you can!

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

                @Supermule:

                Is it possible that this could go into 2.0.3 as well??

                Since current Snort package EOL??

                My changes are entirely contained within the handful of *.PHP files that comprise the GUI piece of the Snort package.  They require no changes to the Snort binary nor to the underlying pfSense code in order to work, so assuming my changes are accepted by the pfSense team, a new Snort package (say v2.5.3) could be posted in the repository.  It would work with 2.0, 2.0.1, 2.0.2 or even a 2.0.3 pfSense installation.

                I don't have a Snort 2.9.4.2 binary (for FreeBSD) to test with, but I'm pretty confident my changes will work fine with the latest Snort binary.  I've reviewed the 2.9.4.2 docs and see nothing that should be a problem in terms of configuration changes.

                1 Reply Last reply Reply Quote 0
                • S
                  Supermule Banned
                  last edited by

                  So basically we need to compile a new package for Pfsense?

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

                    @Supermule:

                    So basically we need to compile a new package for Pfsense?

                    Yeah, that's essentially correct.  Although, for someone with quite moderate "geek" skills, my updated files can be copied to an existing pfSense installation and used without recompiling anything.  The Snort package itself on pfSense consists of essentially three parts:  (1) the Snort binary module, (2) some support libraries for the binary module, and (3) a collection of PHP files that comprise the GUI.  Really all the GUI for Snort does is peform the function of creating the snort.conf file.  The snort.conf file is where all the configuration information lives for the Snort binary.

                    My updates and new features for Snort are really just additions and corrections to the PHP code that runs the GUI and builds the snort.conf file.  So to use my updated files, you just copy them to the two sub-directories where the Snort PHP stuff resides and then everything just works.  No reboot, and no compiling.  Of course a rudimentary level of "geek skill" is required to copy over the files.  This can be as simple as knowing how to use WinSCP, for instance… :)

                    The point of a formal package update would be to make the overall installation simple (just click the icon in the Packages tab).  Now updating to the latest version of the Snort binary will require compiling the underlying package.  However, a new binary is not necessary to start taking advantage of the changes I've made.

                    1 Reply Last reply Reply Quote 0
                    • S
                      Supermule Banned
                      last edited by

                      If the current package is seeing EOL anyway, then I suggest writing to Ermal or Jim to get them to compile it before it goes EOL.

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

                        @Supermule:

                        If the current package is seeing EOL anyway, then I suggest writing to Ermal or Jim to get them to compile it before it goes EOL.

                        Pushing for an update to the latest 2.9.4.x Snort binary is my plan.  I should finish my PHP code tweaks and have everything posted later today or by the end of the weekend to Github.  I will then create the Pull Request to signal Ermal and others on the pfSense team to take a look at my changes.

                        1 Reply Last reply Reply Quote 0
                        • S
                          Supermule Banned
                          last edited by

                          Damn nice mate!! The world would be a fecking nice place to be if populated by folks like you :)

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

                            Here is a link to the Github Pull Request that has the code changes I am proposing for the Snort package.

                            https://github.com/bsdperimeter/pfsense-packages/pull/352

                            The Pull Request has a change log highlighting the major modifications.  It also has the modified files with the changes highlighted.  Should any of you want to test on your own system, contact me via PM and I can provide the files and instructions for using them.  I recommend that any testing be done initially on non-production systems.  I have been running the changes on two different pfSense VMs in VMware with no issues.

                            Bill

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

                              @bmeeks:

                              Here is a link to the Github Pull Request that has the code changes I am proposing for the Snort package.

                              https://github.com/bsdperimeter/pfsense-packages/pull/352

                              This pic says its all  :)

                              Work.jpg

                              AhnHEL (Angel)

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

                                @onhel:

                                This pic says its all  :)

                                Yeah, the Github summary shows each and every changed or deleted line.  Sort of makes it look like more work than it really is.

                                I would like to recruit a few testers willing to give the changes a shake down in a non-production environment.  The changes are super easy to back out if something causes a problem.  To implement the changes, you just copy a few files to two folders after renaming the existing target files (to have as backups).  No reboot necessary.  To back out, just copy the renamed previously existing files (the backups) over top of the new files.

                                Bill

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

                                  PM Sent

                                  AhnHEL (Angel)

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

                                    @onhel:

                                    PM Sent

                                    Replied at 4:20 PM EST.  Thanks for volunteering.

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

                                      Seems to be working with a few caveats.

                                      In testing the memcap setting, the most surefire way I know to trigger the "S5: Pruned 5 sessions from cache for memcap" error was to run a speedtest and max out my bandwidth.  I have a 50/5 connection so your recommendation of a 32MB Stream5 memcap was still setting off that error.  I raised it to 134217728 (128MB) since I have a lot of free memory and that error is now gone. :)

                                      When I go into the Rules tab, instead of getting the Rules page, I seem to be getting the Github webpage for the Rules code but the web address is still showing as 192.168.1.1:443/snort/snort_rules.php?id=0
                                      Did I copy the file wrong?
                                       Redownloaded from GIT and overwrote again and its working now.

                                      I also noticed that when I went to Update Rules, it completed successfully but gave an error at the bottom of the screen complaining of a line 9xx in snort.inc.  I copied the line to post here but in my excitement of trying to see if Stream5 was fixed I copied some text again and it got overwritten.  I've gone back to Update Rules again but I can not reproduce the error that I saw initially, might have to wait for a newer rule update that I can download.

                                      Enabling an interface kicks off this error but System Logs show Initialization Complete and the Interface in fact does Enable.

                                      Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 129 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 130 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 131 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 132 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 133 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 136

                                      AhnHEL (Angel)

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

                                        @onhel:

                                        Enabling an interface kicks off this error but System Logs show Initialization Complete and the Interface in fact does Enable.

                                        Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 129 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 130 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 131 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 132 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 133 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 136

                                        I think I have found and fixed the errors toward the bottom of your post related to "…headers already sent...".  I accidentally moved a section of HTML code into the wrong place in a file.  At least I think that's the cause.  The file package I just sent you via e-mail will hopefully fix the "…headers already sent..." messages.

                                        As for the Rule Update warning, I will check that one out.  I made a last minute change late last night that I might not have thoroughly checked out.

                                        – UPDATE --
                                        I found the problem with the warnings about strings and arrays.  It's an easy fix.  I'm still new to PHP coding, and I made a newbie mistake by not testing the variable type before passing it to some PHP functions.

                                        Bill

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

                                          @onhel:

                                          In testing the memcap setting, the most surefire way I know to trigger the "S5: Pruned 5 sessions from cache for memcap" error was to run a speedtest and max out my bandwidth.  I have a 50/5 connection so your recommendation of a 32MB Stream5 memcap was still setting off that error.  I raised it to 134217728 (128MB) since I have a lot of free memory and that error is now gone. :)

                                          There is a stream5 configuration parameter available called

                                          prune_log_max [bytes]
                                          

                                          Setting this to zero is supposed to suppress the logging of those "pruned session" messages.  However, I could not get it to work, so I did not include it in my changes.  This parameter is designed to set the threshold of logging the pruned messages.

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

                                            Well its definitely gone now that the memcap is above my bandwidth.  I always assumed that the memcap should at least be able to deal with the bandwidth coming in as a buffer so being able to set it now is a plus.

                                            AhnHEL (Angel)

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