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

    Snort/Oinkmaster - Maintaining Disabled/Enabled Rules After Update?

    Scheduled Pinned Locked Moved pfSense Packages
    7 Posts 6 Posters 2.7k 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.
    • K
      kevross33
      last edited by

      Hi,

      I am new to pfsense (I used smoothwall for a lot of years) and I want to be able to have snort rules tuned by the disable/enable sid arguments to remain. I was hoping (I did a few as a test) that if you disable rules in the GUI for the interface they will disable after an update but this isn't the case. Is there a place I can define a disablesid list that will be applied during the autoupdate safely. Also is there a place where snort.conf is taking from that i can make changes to it for the interface and they will remain. I added in necessary HTTP ZLIB decompression and other stuff into the snort configuration then after update it reverted back - unfortunately ZLIB decompression is essential for detection of a lot of threats.

      Only other option I can think of if not currently possible is what I did with smoothwall - disable autoupdating and manually use pulledpork to get updates to local PC and then upload them to pfsense though I want it to do it itself.

      Thanks for any help given.

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

        You can provide your changes here so they can be integrated into pfsense package.
        Or you can report them on redmine.pfsense.org as feature requests.

        1 Reply Last reply Reply Quote 0
        • E
          Eldan
          last edited by

          @ermal:

          You can provide your changes here so they can be integrated into pfsense package.
          Or you can report them on redmine.pfsense.org as feature requests.

          I don't understand this response. Isn't this a feature of pfsense/snort that is already supposed to be working? Something is creating an oinkmaster.conf file, apparently incorrectly. This has already been reported to redmine. Is it really necessary to respond to bug reports in the forum or on redmine with a statement like "fix it yourself and send us the patch?"

          1 Reply Last reply Reply Quote 0
          • D
            darklogic
            last edited by

            This has been an ongoing issue for as long as I can remember the SNORT package being added to pfsense.

            1 Reply Last reply Reply Quote 0
            • H
              hatch
              last edited by

              I am also having an issue with snort resetting rules after it updates them.. Is there some recommended way of dealing with this? A different way of settings rules or a way to script resetting the rules to what I want after the update goes through? Or is this just a temporary bug? It's obvious a little hard to use the package when the rules reset every day :-).

              Other then that, seems like a pretty awesome package (I just started using it)!

              1 Reply Last reply Reply Quote 0
              • K
                kevross33
                last edited by

                Ok the changes that are needed that I have shown in the attached snort.conf file are:

                1. HTTP and extended inspection options in HTTP preprocessor (very important as many attacks and legit stuff use ZLIB compression as for content providers it means less bandwidth and for attackers it means obfuscation if IDS cannot (or is not set) to undo the zlib compression to see content

                2. Extending HTTP ports that have been defined.

                3. if you upgrade package to snort 2.9.2 there are SIP, IMAP and POP preprocessors too (and a blacklist one though if you are like me you use URL Alias for IP lists like botnet CnCs, Russian Business network etc (http://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt for instance) and then use it in a block rule at the top of list linking it as destination for LAN rules and souce as WAN rules to kill all access)

                I would love to see:

                1. Pulledpork being used as update manager
                2. Ability to define rules to enable, disable (and it also to remember if you disable it in GUI so next time they update they stay disabled/enabled) - if that is difficult at least provide an unchanging oinkmaster.conf file we can defined disable and enablesids for tuning
                3. Perhaps using pmgraph from perfmon stats to create a page showing that output (so you can see drops, alerts, fragmentation etc to speed up tuning for interfaces

                Main things though is to ensure HTTP preprocessor configured right for detection and ideally provide some way to permantly disable rules that I choose because I dare not enable blocking until FPs are tuned down.

                snort.txt

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

                  I've started using the Snort package a couple of days ago and this bug is really annoying… But I think I might found a semi-working solution for it. In /usr/local/etc/snort/rules are the categories such as snort_* and emerging-*. When I disable/enable specific rules in these files they will at least stay permanent for interface restart and updates when no new rules files are downloaded. But I guess these changes will be overwritten when new rules are actually downloaded (not just checked and no new files where found). But yeah... Not perfect, but at least the rules won't reset every 12 hour anymore.
                  For some reason I don't seem to have a oinkmaster.conf file on my system at all? 2.0.1-RELEASE (amd64) with Snort 2.9.1 pkg v. 2.1.1.
                  What's the current status of this bug btw?

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