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

    Snort 2.9.2.3 pkg v. 2.5.0 Issues

    Scheduled Pinned Locked Moved pfSense Packages
    331 Posts 38 Posters 227.8k 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.
    • J
      judex
      last edited by

      In the new version it is not possible to add IPs to the Whitelist, since the Alias field is missing (and the + sign for adding entries).
      EDIT: ok, we have to define an alias to be used for Whitelists.

      It is still not possible to start snort, when Sensitive Data preproc is disabled.

      FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown rule option: 'sd_pattern'.

      Greets, Judex

      2.1-RELEASE (amd64)
      built on Wed Sep 11 18:17:48 EDT 2013
      FreeBSD 8.3-RELEASE-p11

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

        @judex:

        In the new version it is not possible to add IPs to the Whitelist, since the Alias field is missing (and the + sign for adding entries).
        EDIT: ok, we have to define an alias to be used for Whitelists.

        It is still not possible to start snort, when Sensitive Data preproc is disabled.

        FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown rule option: 'sd_pattern'.

        Greets, Judex

        @Judex The sensitive issue has been fixed.. please reinstall

        1 Reply Last reply Reply Quote 0
        • J
          judex
          last edited by

          I did that 60 min. ago - was it fixed meanwhile

          2.1-RELEASE (amd64)
          built on Wed Sep 11 18:17:48 EDT 2013
          FreeBSD 8.3-RELEASE-p11

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

            @judex:

            I did that 60 min. ago - was it fixed meanwhile

            yes, https://github.com/bsdperimeter/pfsense-packages/commits/master/

            1 Reply Last reply Reply Quote 0
            • F
              fragged
              last edited by

              Loading without sensitive information preproc works.

              So far with 2.5.0 I've only noticed minor UI issues with alert page growing outside the background margins.

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

                @fragged:

                So far with 2.5.0 I've only noticed minor UI issues with alert page growing outside the background margins.

                i've noticed that too, thinking its because of the theme and not the package

                1 Reply Last reply Reply Quote 0
                • J
                  judex
                  last edited by

                  @Cino:

                  @judex:

                  I did that 60 min. ago - was it fixed meanwhile

                  yes, https://github.com/bsdperimeter/pfsense-packages/commits/master/

                  Thx Cino, I had the 60 min gap bad luck! Everything working now!

                  2.1-RELEASE (amd64)
                  built on Wed Sep 11 18:17:48 EDT 2013
                  FreeBSD 8.3-RELEASE-p11

                  1 Reply Last reply Reply Quote 0
                  • M
                    mschiek01
                    last edited by

                    Has anyone that runs an smtp server behind snort been able to get the smtp preproc to work correctly.  If I enable it the preproc, it will start blocking the traffic to the server with bad alerts.

                    1 Reply Last reply Reply Quote 0
                    • F
                      Fesoj
                      last edited by

                      Hi ermal,

                      good job. For my purposes, snort is running smoothly now.

                      I have also solved my problem of the 2nd interface on the LAN side that apparently did not work at all, where I was using the ET p2p rules. These rules worked on the WAN side, but not on the LAN side.

                      There's no need to go int details here, but I'd like to say that it is (probably always was) necessary to look at the definition of the rules and how your environment is defined. If a rule is based on the HOME_NET, the local machines that are being monitored should also be part of the HOME_NET or the rule is essentially not active. In my case I had to augment the default HOME_NET by the client subnet to get the behavior I wanted.

                      1 Reply Last reply Reply Quote 0
                      • E
                        eri--
                        last edited by

                        Fesoj,

                        re-added sub-nets to the HOME_NET list, i had mistaken it with something else.
                        Just re-install and should be good.

                        1 Reply Last reply Reply Quote 0
                        • J
                          judex
                          last edited by

                          Hm, but now we have the WAN subnet back as 24 CIDR in HOME_NET

                          2.1-RELEASE (amd64)
                          built on Wed Sep 11 18:17:48 EDT 2013
                          FreeBSD 8.3-RELEASE-p11

                          1 Reply Last reply Reply Quote 0
                          • E
                            eri--
                            last edited by

                            Yeah its ok judex.

                            1 Reply Last reply Reply Quote 0
                            • B
                              breusshe
                              last edited by

                              @ermal:

                              @Cino:

                              Added some more suggestions/issues to post http://forum.pfsense.org/index.php/topic,51387.msg275159.html#msg275159

                              @breusshe

                              If you dont mind changing commenting out some php code, you can get your 2nd WAN interface back:

                              lines 82 and 83 in /usr/local/www/snort/snort_interfaces_edit.php

                              make them look like this:

                              
                              #		if ($natent['interface'] == $_POST['interface'])
                              #			$input_errors[] = "This interface is already configured for another instance";
                              
                              

                              This allowed me to create another WAN interface, and it has a different ID:

                              
                               ps -aux | grep snort
                              root   61341 23.7    ??  Ss    1:56PM   0:01.29 /usr/pbi/snort-i386/bin/snort -R 36745 -D -q -l /var/log/snort/snort_em336745 --pid-path /var/run --nolock-pidfile -G 36745 -c /usr/
                              root   59209  0.2    ??  Ss    1:54PM   0:01.13 /usr/pbi/snort-i386/bin/snort -R 60770 -D -q -l /var/log/snort/snort_em360770 --pid-path /var/run --nolock-pidfile -G 60770 -c /usr/
                              root    3143  0.0  0.3 13048  8384  ??  Ss    1:54PM   0:00.06 /usr/local/bin/barnyard2 -r 60770 -f snort_60770_em3.u2 --pid-path /var/run --nolock-pidfile -c /usr/local/etc/snort/snort_60770_em3
                              root   35410  0.0  0.0  3536  1256   0  S+    1:56PM   0:00.01 grep snort
                              
                              

                              Use event_filter configurations for this it makes no sense to do this!

                              The above quotes are from the v2.4.2 issues posting, but I see the issue still applies, so I'm bringing the discussion here.

                              @Ermal:  event_filter does not do what I want.  There are categories of rules that I wish to log, but don't want to block if they are seen.  I simply wish to monitor how prolific the event is.  Since there is no way to block some categories/rules while also only alerting for other categories without using two instances of snort on the same interface, it seems necessary to have this feature.

                              Now, let's assume I'm mistaken and there is a way to have only one instance where some things are blocked while some are only noted in the snort logs using some filter command.  I would have to activate all of the categories/rules I want running on my interface and then manually identify all of those gen_id and sig_id numbers that I only wanted alerted, but not blocked.  Since those rule files contain multiple gen_id's I can't so something like "gen_id=xxx, sig_id=0" to change how a whole category is handled.  What you are asking us do to is an administrative nightmare.  Also, having all of this running through one instance means all snort matching will occur on one CPU core (since, last I checked, Snort wasn't very multi-core friendly) while how I run Snort allows multiple cores to be used, thus helping to prevent snort from getting swamped with requests.

                              So, I ask you, even though you don't see the sense in it, please implement the edit that Cino suggests so multiple instances of Snort will run on one interface.  If nothing else, it makes management of Snort easier.

                              1 Reply Last reply Reply Quote 0
                              • B
                                breusshe
                                last edited by

                                I have two other questions.

                                1.)  Why is it that I can only save snort alerts to the system logs now?  Used to be we could choose between unified2 format, tcpdump, or system logs.  What was the reason for the change?

                                2.)  What happened to "Define SSL_IGNORE"?  It's not on the preprocessors page nor does it seem to be anywhere else.

                                1 Reply Last reply Reply Quote 0
                                • E
                                  eri--
                                  last edited by

                                  Reinstall you will be able to configure 2 ifaces.

                                  The logtype was removed because:
                                  barnyard logging will be enabled when you enable barnyard
                                  alerts tab uses alert_csv format

                                  syslog exporting remains the other thing you want to enable disable.

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    breusshe
                                    last edited by

                                    @ermal:

                                    Reinstall you will be able to configure 2 ifaces.

                                    The logtype was removed because:
                                    barnyard logging will be enabled when you enable barnyard
                                    alerts tab uses alert_csv format

                                    syslog exporting remains the other thing you want to enable disable.

                                    Thank you, Ermal.  Is it still true with barnyard2 that the sql server is not installed on pfsense?  I'm a home user, myself, so I don't have extra servers just lying around simply for a sql database.  I know it isn't "recommended" to have sql server running on an Internet facing system, but if it is locked down to only the localhost interface, the risks are acceptable for a home user.  Hmmm.  I wonder if a "mySQL for Barnyard2" package could be built?  You obviously build packages, Ermal.  Do you mind pointing me to the documentation on how one adds a package to the pfSense Package Manager?

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      breusshe
                                      last edited by

                                      @ermal:

                                      Reinstall you will be able to configure 2 ifaces.

                                      The logtype was removed because:
                                      barnyard logging will be enabled when you enable barnyard
                                      alerts tab uses alert_csv format

                                      syslog exporting remains the other thing you want to enable disable.

                                      Just did the reinstall.  I get this error:

                                      FATAL ERROR: Failed to load /usr/local/lib/snort/dynamicrules/bad-traffic.so: /usr/local/lib/snort/dynamicrules/bad-traffic.so: Undefined symbol "freeRuleData"

                                      The funny part is I'm not even using bad-traffic.so.  Not sure why it is even loading.

                                      1 Reply Last reply Reply Quote 0
                                      • E
                                        eri--
                                        last edited by

                                        breusshe because snort is just going to dump/exit if i put only enabled so rules and libs.

                                        1 Reply Last reply Reply Quote 0
                                        • E
                                          eri--
                                          last edited by

                                          @breusshe:

                                          @ermal:

                                          @Cino:

                                          Added some more suggestions/issues to post http://forum.pfsense.org/index.php/topic,51387.msg275159.html#msg275159

                                          @breusshe

                                          If you dont mind changing commenting out some php code, you can get your 2nd WAN interface back:

                                          lines 82 and 83 in /usr/local/www/snort/snort_interfaces_edit.php

                                          make them look like this:

                                          
                                          #		if ($natent['interface'] == $_POST['interface'])
                                          #			$input_errors[] = "This interface is already configured for another instance";
                                          
                                          

                                          This allowed me to create another WAN interface, and it has a different ID:

                                          
                                           ps -aux | grep snort
                                          root   61341 23.7    ??  Ss    1:56PM   0:01.29 /usr/pbi/snort-i386/bin/snort -R 36745 -D -q -l /var/log/snort/snort_em336745 --pid-path /var/run --nolock-pidfile -G 36745 -c /usr/
                                          root   59209  0.2    ??  Ss    1:54PM   0:01.13 /usr/pbi/snort-i386/bin/snort -R 60770 -D -q -l /var/log/snort/snort_em360770 --pid-path /var/run --nolock-pidfile -G 60770 -c /usr/
                                          root    3143  0.0  0.3 13048  8384  ??  Ss    1:54PM   0:00.06 /usr/local/bin/barnyard2 -r 60770 -f snort_60770_em3.u2 --pid-path /var/run --nolock-pidfile -c /usr/local/etc/snort/snort_60770_em3
                                          root   35410  0.0  0.0  3536  1256   0  S+    1:56PM   0:00.01 grep snort
                                          
                                          

                                          Use event_filter configurations for this it makes no sense to do this!

                                          The above quotes are from the v2.4.2 issues posting, but I see the issue still applies, so I'm bringing the discussion here.

                                          @Ermal:  event_filter does not do what I want.  There are categories of rules that I wish to log, but don't want to block if they are seen.  I simply wish to monitor how prolific the event is.  Since there is no way to block some categories/rules while also only alerting for other categories without using two instances of snort on the same interface, it seems necessary to have this feature.

                                          Now, let's assume I'm mistaken and there is a way to have only one instance where some things are blocked while some are only noted in the snort logs using some filter command.  I would have to activate all of the categories/rules I want running on my interface and then manually identify all of those gen_id and sig_id numbers that I only wanted alerted, but not blocked.  Since those rule files contain multiple gen_id's I can't so something like "gen_id=xxx, sig_id=0" to change how a whole category is handled.  What you are asking us do to is an administrative nightmare.  Also, having all of this running through one instance means all snort matching will occur on one CPU core (since, last I checked, Snort wasn't very multi-core friendly) while how I run Snort allows multiple cores to be used, thus helping to prevent snort from getting swamped with requests.

                                          So, I ask you, even though you don't see the sense in it, please implement the edit that Cino suggests so multiple instances of Snort will run on one interface.  If nothing else, it makes management of Snort easier.

                                          My fix to this would be to make alert_pf understand a kind of suppress type list to block also.
                                          This would make your setup usable with one instance.
                                          Though for now i want go into that implementation anyhow.

                                          1 Reply Last reply Reply Quote 0
                                          • E
                                            eri--
                                            last edited by

                                            @breusshe:

                                            @ermal:

                                            Reinstall you will be able to configure 2 ifaces.

                                            The logtype was removed because:
                                            barnyard logging will be enabled when you enable barnyard
                                            alerts tab uses alert_csv format

                                            syslog exporting remains the other thing you want to enable disable.

                                            Thank you, Ermal.  Is it still true with barnyard2 that the sql server is not installed on pfsense?  I'm a home user, myself, so I don't have extra servers just lying around simply for a sql database.  I know it isn't "recommended" to have sql server running on an Internet facing system, but if it is locked down to only the localhost interface, the risks are acceptable for a home user.  Hmmm.  I wonder if a "mySQL for Barnyard2" package could be built?  You obviously build packages, Ermal.  Do you mind pointing me to the documentation on how one adds a package to the pfSense Package Manager?

                                            Just add yourself the mysql-server package.

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