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

    Snort 2.9.5.5 pkg. v3.0.0 – Update Released

    Scheduled Pinned Locked Moved pfSense Packages
    67 Posts 14 Posters 25.2k 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
      jasonlitka
      last edited by

      @bmeeks:

      @Jason:

      @marcelloc:

      @Jason:

      I'm also having some issues with the sensitive data feature.  I enabled it for credit card data, set the threshold to 1, and told it to mask the card numbers, but it doesn't seem to be alerting or replacing the text when I email a bunch of test CC numbers to a Gmail account.  Is there something I'm missing?

      If you're sending via ssl, snort will not be able to "decode" it.

      TLS negotiation is enabled in Exchange, so yeah, it might be connecting to other servers with STARTTLS.  That really limits the usefulness.  Damn…

      Should this work on HTTP traffic as well?

      I believe so.  As far as I know, the Sensitive Data preprocessor inspects all traffic regardless of protocol.

      Bill

      Ok, then maybe something else is wrong here too as it's not tripping on PayPal's test card page.

      http://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm

      I've also got another box that I just upgraded and snort refuses to start on this one.

      Unknown rule option: 'stream_size'

      I can break anything.

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

        @Jason:

        Ok, then maybe something else is wrong here too as it's not tripping on PayPal's test card page.

        http://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm

        Make sure that PayPal is not flipping over to a HTTPS connection on you.  Many times they will redirect an HTTP URL to an HTTPS one for security.  My personal opinion on the SDF preprocessor (aka Sensitive Data) is that it is sort of pointless.  I do not enable in my setup.

        One other point – from your other error message about an unknown rule option, it would appear at least one of your firewalls has the Stream5 preprocessor disabled.  Disabling Frag3 and Stream5 really cripples Snort, and can lead to detections not happening because session traffic is not properly reassembled.  Not saying that is necessarily your SDF problem, but it could be if you have Stream5 disabled.  SDF depends on Stream5 being enabled in order to function correctly.

        Attached to this reply is a screenshot I captured from one of my virtual machine test firewalls when browsing to the PayPal link you provided.  Note that it fired on the SDF for me.

        @Jason:

        I've also got another box that I just upgraded and snort refuses to start on this one.

        Unknown rule option: 'stream_size'

        This means you do not have a required preprocessor enabled.  Any time you see an error message about an "unknown rule option", that means Snort is parsing a rule that requires a specific preprocessor be enabled, but that preprocess is disabled.  With the required preprocessor not enabled, then Snort does not know how to interpret the rule option.  This particular rule option requires the Stream5 preprocessor be enabled.  Do you have all the default preprocessors enabled on the Preprocessors tab, or have you disabled some?  There is really never a good reason with today's hardware capability to disable the preprocessors enabled by default in Snort.  Any performance gain will be miniscule at best, and then you open yourself up to the "unknown rule option" errors.  And these can get really aggravating because they will come and go as rules are enabled and disabled in the nightly updates from the rule maintainers.  They frequently enable new rules that expect the preprocessors to be enabled.

        Bill

        SDF_Alerts.jpg
        SDF_Alerts.jpg_thumb

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

          @bmeeks:

          This means you do not have a required preprocessor enabled.  Any time you see an error message about an "unknown rule option", that means Snort is parsing a rule that requires a specific preprocessor be enabled, but that preprocess is disabled.  With the required preprocessor not enabled, then Snort does not know how to interpret the rule option.  This particular rule option requires the Stream5 preprocessor be enabled.  Do you have all the default preprocessors enabled on the Preprocessors tab, or have you disabled some?  There is really never a good reason with today's hardware capability to disable the preprocessors enabled by default in Snort.  Any performance gain will be miniscule at best, and then you open yourself up to the "unknown rule option" errors.  And these can get really aggravating because they will come and go as rules are enabled and disabled in the nightly updates from the rule maintainers.  They frequently enable new rules that expect the preprocessors to be enabled.

          Bill

          All the preprocessors are enabled on the two interfaces.  I uninstalled and reinstalled the package, then setup the interfaces again and now it's fine.  Must have been something in the upgrade process.  Thanks.

          I can break anything.

          1 Reply Last reply Reply Quote 0
          • I
            iFloris
            last edited by

            @bmeeks:

            I am working on my next pfSense package.  I have a very early Beta of Suricata working in IDS mode at the moment.

            This would be an amazing addition.

            one layer of information
            removed

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

              Thanks Bill!  Installing now :)

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

                @bmeeks:

                Thank you for the positive feedback, and that is a good idea.  Supermule also suggested some time back a sort of "template" system for Snort where you could create a set of configuration templates and then assign one to a specific pfSense box or group of boxes.  The template would have all the settings preset.  I have that idea in my list of future enhancements.  I could probably incorporate your disablesid.conf idea into the same template design.  I'm thinking maybe this would be an add-on package for Snort much like the Snort Dashboard Widget is today.

                Bill

                Hi Bill,

                I have been going thru the Snort rules and disabling/Enabling the ones to suit my network and I came across a few ideas.

                1. Ability to create Multiple Snort Interfaces. Only one Interface per NIC would be online, the others could be offline.  It could also allow testing of Rulesets without compromising the Primary Interface settings.

                2. The ability to Copy the "Snort Interface" to another pfSense Box. This would allow managing rulesets for several boxes with similar setups.

                3. In Global Settings, the option for "Remove Blocked Host Interval" could be set separately in each category so that we can better control how long the Block should last for.

                Just a thought.

                "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
                • bmeeksB
                  bmeeks
                  last edited by

                  @BBcan17:

                  Hi Bill,

                  I have been going thru the Snort rules and disabling/Enabling the ones to suit my network and I came across a few ideas.

                  My replies are below.  Thank you for the ideas.  Unfortunately, one of them I really don't think can ever work; however, the other two are possible.

                  @BBcan17:

                  1. Ability to create Multiple Snort Interfaces. Only one Interface per NIC would be online, the others could be offline.  It could also allow testing of Rulesets without compromising the Primary Interface settings.

                  I think the template idea suggested by user Supermule is a way to accomplish this.  It sounds like what you are really talking about is a way to quickly switch on or off a group of rules for an interface.

                  @BBcan17:

                  1. The ability to Copy the "Snort Interface" to another pfSense Box. This would allow managing rulesets for several boxes with similar setups.

                  This feature is available now thanks to user Marcelloc here on the forum.  He contributed the XML RPC sync part of Snort.  It is currently marked experimental, but in fact works quite well.  You can sync the Snort configuration across multiple boxes.  The one requirement for now is they must have the same NIC hardware so the real interface names match.  For example, em0, em1, etc.  I think the users currently making use of this sync feature are doing so on groups of virtual machines where the virtual hardware is identical.

                  The template idea I mentioned above might also fill this need when implemented.  Maybe I can incorporate something into the template code that would handle automatically the change in real interface names.

                  @BBcan17:

                  1. In Global Settings, the option for "Remove Blocked Host Interval" could be set separately in each category so that we can better control how long the Block should last for.

                  This one can't be done because it's not Snort that does the clearing.  Remember Snort is simply stuffing IP addresses into a pf table.  The table is called snort2c.  Once an IP is inserted there, it's the responsibility of the packet filter engine code to keep up with it.  The pf engine keeps a counter on "activity" by IP address.  In other words, it monitors the connections.  There is a cron job that the Snort package creates that calls the expiretable utility once per the interval you set (1 hr, 1 day, etc.).  The expiretable utility is given the pf table to clear and how many seconds of "no activity" must be in the stats for an entry to be removed.  The pf table has no way to store additional data about the IP address (such as what rule fired it, etc.).  This means Snort can't offer selective clear times based on rule origin.

                  Bill

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