Snort: Where do I find a specific rule?
-
There seems to be thousands. For instance, we began blocking certain downloads that we wish to allow or, at least, control. How do I find the specific rule that blocks the download of exe files, for example? Thanks in advance.
-
There seems to be thousands. For instance, we began blocking certain downloads that we wish to allow or, at least, control. How do I find the specific rule that blocks the download of exe files, for example? Thanks in advance.
Unfortunately it's not very easy to just search the rules in the Snort package. Folks generally do it the other way around starting with a specific SID (Signature ID). When Snort "blocks" or "alerts" on a rule, it will put the rule's GID (Generator ID #) and the SID (Signature ID #) in the entry on the ALERTS tab. These values are displayed as GID:SID. So the second number in the sequence is the SID. For the text rules that are the likely source of your block on an EXE file, the GID is "1".
My guess is one of the "policy" rule sets is the likely source of your block.
If you are good with a FreeBSD command-line interface, you can "grep" the rules files looking for that SID. The exact path to the rules is determined by the version of pfSense (2.1 or 2.0.x) and whether you have a 32-bit or 64-bit installation.
There are several SID lookup sites on the web that can describe Snort rules for you given the GID and SID.
If you are getting "blocks" on those EXE downloads, and you wish to allow them, then you can insert a Suppress List entry for that SID. Here's how to do this.
Go to the ALERTS tab in Snort.
Scroll down and find the line representing the "block" you wanted to allow.
In the next-to-the-last column on the right is the GID:SID pair. Underneath is a plus (+) icon. Click that to suppress rule and prevent further blocks for any IP address from that rule.
You will also notice plus signs (+) in the SRC and DST IP columns. Clicking one of those will insert a slightly more controlled "suppress entry" in that the traffic will only be allowed when either the SRC or DST IP address matches the one shown in the alert.
Bill
-
If you are good with a FreeBSD command-line interface, you can "grep" the rules files looking for that SID. The exact path to the rules is determined by the version of pfSense (2.1 or 2.0.x) and whether you have a 32-bit or 64-bit installation.
BillHi Bill,
I know I asked about this previously, but having the disablesid.conf/enablesid.conf files would be a great benefit to the Snort Rule Process in pfSense. As i do not use the generic policys so its a very tedious process to tune snort rules one by one.
You can always wish? ;)
-
@BBcan17:
If you are good with a FreeBSD command-line interface, you can "grep" the rules files looking for that SID. The exact path to the rules is determined by the version of pfSense (2.1 or 2.0.x) and whether you have a 32-bit or 64-bit installation.
BillHi Bill,
I know I asked about this previously, but having the disablesid.conf/enablesid.conf files would be a great benefit to the Snort Rule Process in pfSense. As i do not use the generic policys so its a very tedious process to tune snort rules one by one.
You can always wish? ;)
I have considered adding support for them. I need to figure out what level of GUI interaction is appropriate, though. Have any ideas or suggestions?
Bill
-
I have considered adding support for them. I need to figure out what level of GUI interaction is appropriate, though. Have any ideas or suggestions?
BillI think a GUI screen for each file (Disablesid and Enablesid) similar to "Arguments here will be automatically inserted into the Snort configuration" in Snort Interface settings.
In Security Onion, pulled pork downloads the rulesets and mesh's the enable/disable sids. So maybe this can be achieved at each pfSense Snort Rule Update Frequency.
Snort also uses state_order=disable,drop,enable in the snort.conf. This should probably be in the GUI as "priorities" as different configuration would require disabling sids before enable or vice versa.
I have a list of 50-60, pcre:"EXAMPLE Application Name" in my disablesid file to disable applications that I don't want to loadup and use resources (My pcre list disables about 1,600 rules). The disablesid/enablesid can also disable/enable whole categories ie "browser-firefox.rules" or individual SIDs "119:14"
So for me, I enable "Download all Rules", Disable rules with Disablesid.conf and than enablesid.conf for ones that I want to override.
Having a link on the "Snort Alert" screen to populate entries in the disablesid/enablesid would be nice. It could work the same way as the suppression lists.
I'm not sure whats the best configuration for the the tabs "WAN Categories" and "WAN Rules". Maybe it could be setup as is, and an overide button to blank out these two tabs and manually run with the disable/enablesid configuration section? Or a hybrid where the two tabs populate the enable/disablesids?
-
Thanks, really appreciate the input.
I did finally find the rule, but there is something that seems odd:
I choose interface (WAN 3)
Go into WAN3 Categories tab
Enabled are ET Open Rules, beneath that is emerging-policy-rules
I find the rule I'm looking for; 2000419 (EXE or DLL windows file download), but it is greyed out.
I would guess that it being grey means it is not enabled. But, this rule will trigger an alert and it will block traffic if blocking is enabled.
-
Thanks, really appreciate the input.
I did finally find the rule, but there is something that seems odd:
I choose interface (WAN 3)
Go into WAN3 Categories tab
Enabled are ET Open Rules, beneath that is emerging-policy-rules
I find the rule I'm looking for; 2000419 (EXE or DLL windows file download), but it is greyed out.
I would guess that it being grey means it is not enabled. But, this rule will trigger an alert and it will block traffic if blocking is enabled.
You are correct, showing as grey means the rule is "default disabled" in that rule package. This means it has a comment symbol ("#") preceding it in the rules file. It should not usually be generating an alert, but there is one other possibility where it can get enabled by the backend. It may be enabled as an auto-flowbit rule. Some of the ET rules that set flowbits don't always use the "no-alert" keyword to prevent alerts. Go back to the Rule Categories tab for that interface and click the button to view flowbit rules. Look in there for that SID. If you see it, you can auto-add a Suppress List entry for it by clicking the plus icon (+) beside the SID. This assumes two things: (1) you are using a current version of the Snort package; and (2) you have Auto-Flowbit Rules enabled.
Bill
-
@BBcan17:
I have considered adding support for them. I need to figure out what level of GUI interaction is appropriate, though. Have any ideas or suggestions?
BillI think a GUI screen for each file (Disablesid and Enablesid) similar to "Arguments here will be automatically inserted into the Snort configuration" in Snort Interface settings.
In Security Onion, pulled pork downloads the rulesets and mesh's the enable/disable sids. So maybe this can be achieved at each pfSense Snort Rule Update Frequency.
Snort also uses state_order=disable,drop,enable in the snort.conf. This should probably be in the GUI as "priorities" as different configuration would require disabling sids before enable or vice versa.
I have a list of 50-60, pcre:"EXAMPLE Application Name" in my disablesid file to disable applications that I don't want to loadup and use resources (My pcre list disables about 1,600 rules). The disablesid/enablesid can also disable/enable whole categories ie "browser-firefox.rules" or individual SIDs "119:14"
So for me, I enable "Download all Rules", Disable rules with Disablesid.conf and than enablesid.conf for ones that I want to override.
Having a link on the "Snort Alert" screen to populate entries in the disablesid/enablesid would be nice. It could work the same way as the suppression lists.
I'm not sure whats the best configuration for the the tabs "WAN Categories" and "WAN Rules". Maybe it could be setup as is, and an overide button to blank out these two tabs and manually run with the disable/enablesid configuration section? Or a hybrid where the two tabs populate the enable/disablesids?
Thanks for taking the time to share your ideas. The Snort package already is storing enabled/disabled SIDS in the config.xml file, so it would be easy to just supplement that list with the results from processing an enablesid or disablesid file. I'm thinking maybe a global level tab (similar to WHITELISTS) that would let you select and edit an enableside or disablesid file for any configured interface. Once saved and processed, any SID changes would be merged into the collection in config.xml. That way none of the other tabs in Snort would have to change.
I will experiment with this a bit after I get the initial BETA version of my Suricata package posted. I'm almost finished with it. For the first BETA release, it will only run in IDS mode (no blocking). Later, IPS (blocking) mode will be added. Ermal and I are trying to get it to work as a true inline IPS.
Bill
-
Thanks Bill.
Can you share the path for config.xml. What would be the best place to enter the pcres in the config.xml file?
I have attached my disablesid.conf file. Maybe you could make use of it for yourself.
Looking forward to the Beta package. I have enough memory on my box, so would I be able to run both the Snort and Suricata Beta (non-ids mode) simultaneously?
-
@BBcan17:
Thanks Bill.
Can you share the path for config.xml. What would be the best place to enter the pcres in the config.xml file?
I have attached my disablesid.conf file. Maybe you could make use of it for yourself.
Looking forward to the Beta package. I have enough memory on my box, so would I be able to run both the Snort and Suricata Beta (non-ids mode) simultaneously?
The config.xml file is the master configuration repository for all of pfSense. It is in /conf. Don't monkey around in it without fully understanding its contents or you can severely break pfSense – even to the point of not booting up! Every installed package keeps most of its configuration information in the config.xml file.
As for the Snort section in there and pcre, Snort does not currently recognize anything except GID:SID pairs in two sections called and . When you selectively enable or disable rules in the GUI (on the RULES tab), the corresponding GID:SID values get put in this section. Note that what I've described is how it will work in the new 3.0.4 package now under review but not yet release. The older versions basically did the same thing, but stored only the SID (assuming the GID was always 1) along with an unused tag.
Thanks for the disablesid.conf file. That will help me out in developing and testing the new functionality.
Bill
-
Thanks for the disablesid.conf file. That will help me out in developing and testing the new functionality.
Bill
Hi Bill,
Do you think it would be easier for the users to have the most common pcre's in a GUI menu where they could select/deselect what they want to monitor on their network? Snort and ET should provide a list of rules by application name as I think its easier to apply the rules that you need for each network. or pre-populating the GUI with a list of (#pcre:"Application name") where the user will have to manually un-comment the appropriate lines?
Looking forward to the Beta package. I have enough memory on my box, so would I be able to run both the Snort and Suricata Beta (non-ids mode) simultaneously?
-
@BBcan17:
Thanks for the disablesid.conf file. That will help me out in developing and testing the new functionality.
Bill
Hi Bill,
Do you think it would be easier for the users to have the most common pcre's in a GUI menu where they could select/deselect what they want to monitor on their network? Snort and ET should provide a list of rules by application name as I think its easier to apply the rules that you need for each network. or pre-populating the GUI with a list of (#pcre:"Application name") where the user will have to manually un-comment the appropriate lines?
Looking forward to the Beta package. I have enough memory on my box, so would I be able to run both the Snort and Suricata Beta (non-ids mode) simultaneously?
I was just going to make a GUI "edit dialog" very similar to the current Diagnostics…Edit File feature in pfSense today. In fact, I will probably reuse most, if not all, of that code. This way users can copy/paste to just type in whatever they want.
The answer to your second question is "probably", depending on exactly how much memory you have. With full rule sets enabled on each, I can see at least 8 GB being necessary.
Bill
-
The answer to your second question is "probably", depending on exactly how much memory you have. With full rule sets enabled on each, I can see at least 8 GB being necessary.
Bill
If the new BETA package running Suricata (non IDS) is installed alongside the existing Snort Package (IDS Mode), how would the packet filter system work? Would Snort block it before the new beta package sees the packets?
Would be nice to have a real world test to see Suricata (non-IDS) in front of Snort (IDS mode) on the same Firewall device.
-
I have been playing with Suricata in Security Onion. Haven't noticed much difference so far. However, it is using another GB of memory compared with Snort.
Bill, any comment from my post above?
-
@BBcan17:
I have been playing with Suricata in Security Onion. Haven't noticed much difference so far. However, it is using another GB of memory compared with Snort.
Bill, any comment from my post above?
Sorry, been away for the day. Currently both Snort and the upcoming Suricata beta packages use libpcap (the pcap library) to capture packets. This is a "copy" process that copies all incoming/outgoing packets on the interface. So basically both will see everything if they are running on the same interface. It's the source of the complaint some folks have today about their pfBlocker/Snort combos where Snort still sees and processes pfBlocked traffic.
This scenario will be different in a true inline IPS mode where the IPS (Snort or Suricata) hooks itself into the actual firewall rule chain and simply "swallows" any packet it wants to drop. This means the packet comes in and then simply vanishes. This is a bit different than the current pcap capture (in promiscuous mode), analysis, and then subsequent block further down the chain.
Not nitpicking, but I need to correct your IDS vs IPS definitions. IDS is an Intrusion Detection System. It detects and alerts, but does not block. An IPS is an Intrusion Prevention System. It detects and blocks. With regards to Snort on pfSense, it is currently what I term a hybrid; but cyber security purists would take offense at my characterization. When I say hybrid for Snort on pfSense I mean that it can block like an IPS, but it is not in a true inline mode whereby a packet must get by Snort before entering the network. See my explanation above on how pcap works. Snort gets a copy of packets as they traverse the interface. The "originals" continue on through the interface while Snort analyzes its "copy". If Snort decides something is bad in its "copy", then it inserts a block that will block subsequent packets from that IP. However, that first original packet or possibly first few original packets made it through while Snort was analyzing its copy and deciding what to do. So because of that initial "leakage", you can't truly term Snort on pfSense as an ideal IPS. However, it's still better than just a pure IDS.
Bill
-
This scenario will be different in a true inline IPS mode where the IPS (Snort or Suricata) hooks itself into the actual firewall rule chain and simply "swallows" any packet it wants to drop. This means the packet comes in and then simply vanishes. This is a bit different than the current pcap capture (in promiscuous mode), analysis, and then subsequent block further down the chain.
Bill
Great. Is this inline processing issue a Snort issue or a FreeBSD issue? Do you forsee being able to capture the payload (transcript) of what the package will be blocking? Or full packet capture?
Possibly sending the PCAPS to a secondary process? -
@BBcan17:
This scenario will be different in a true inline IPS mode where the IPS (Snort or Suricata) hooks itself into the actual firewall rule chain and simply "swallows" any packet it wants to drop. This means the packet comes in and then simply vanishes. This is a bit different than the current pcap capture (in promiscuous mode), analysis, and then subsequent block further down the chain.
Bill
Great. Is this inline processing issue a Snort issue or a FreeBSD issue? Do you forsee being able to capture the payload (transcript) of what the package will be blocking? Or full packet capture?
Possibly sending the PCAPS to a secondary process?It is specifically a "pfSense on FreeBSD" issue. Well, probably more accurate to say FreeBSD issue as the version of pf packaged with 8.x versions can't do divert sockets. pfSense uses pf instead of ipfw for the firewall function, and some customization of pf was done a while back to allow some limited divert sockets support (mainly for the Layer 7 DPI functionality). However, that customization currently only supports TCP and UDP, and even there I am having issues getting it to work for an inline IPS. Ermal is helping out, though. Divert sockets is how Suricata (and the DAQ part of Snort) do inline IPS mode on BSD derivatives.
My Suricata package currently captures the full content of offending packets and saves it to pcap log files in /var/log/suricata/xxx (where xxx is the UUID of the interface). The logging directory structure mimics what Snort does today. These files can consume quite a bit of disk space, though. I'm working on the best way to archive them and rotate them. Also looking at other approaches for offloading them to some other external processor.
Bill
-
My Suricata package currently captures the full content of offending packets and saves it to pcap log files in /var/log/suricata/xxx (where xxx is the UUID of the interface). The logging directory structure mimics what Snort does today. These files can consume quite a bit of disk space, though. I'm working on the best way to archive them and rotate them. Also looking at other approaches for offloading them to some other external processor.
Bill
"Also looking at other approaches for offloading them to some other external processor."
You should take a moment to download the Security Onion .ISO ( http://sourceforge.net/projects/security-onion/files/12.04.3/ and test it out. It has a quick setup that takes care of almost the entire setup and have you running in no time.
After using it for the last four months, i have to say that SGUIL is far superior to the Snorby package. With a little tweaking, the Snort_Agent can listen for pfSense Snort/Suricata, and have the Full Packet Capture available for viewing and Logging.
Doug Burks has added all of the tools that go along with SGUIL/Snorby so that you can do more than just see "Alerts" you can pivot on the data into Wireshark, Network Miner, BRO, ELSA, Xplico… Its is a Distributed Architecture so that you can have a Server or Server/Sensor installation and an army of distributed sensors that can capture remote networks and talk back to the main Server. Its really slick.
Just trying to spread the Gospel... I wouldn't suggest it if I didn't believe in it...
-
@BBcan17:
My Suricata package currently captures the full content of offending packets and saves it to pcap log files in /var/log/suricata/xxx (where xxx is the UUID of the interface). The logging directory structure mimics what Snort does today. These files can consume quite a bit of disk space, though. I'm working on the best way to archive them and rotate them. Also looking at other approaches for offloading them to some other external processor.
Bill
"Also looking at other approaches for offloading them to some other external processor."
You should take a moment to download the Security Onion .ISO ( http://sourceforge.net/projects/security-onion/files/12.04.3/ and test it out. It has a quick setup that takes care of almost the entire setup and have you running in no time.
After using it for the last four months, i have to say that SGUIL is far superior to the Snorby package. With a little tweaking, the Snort_Agent can listen for pfSense Snort/Suricata, and have the Full Packet Capture available for viewing and Logging.
Doug Burks has added all of the tools that go along with SGUIL/Snorby so that you can do more than just see "Alerts" you can pivot on the data into Wireshark, Network Miner, BRO, ELSA, Xplico… Its is a Distributed Architecture so that you can have a Server or Server/Sensor installation and an army of distributed sensors that can capture remote networks and talk back to the main Server. Its really slick.
Just trying to spread the Gospel... I wouldn't suggest it if I didn't believe in it...
Quite some time back I briefly experimented with Security Onion. I think that was maybe four years ago or so. I will check out the latest version. What I want is something distributed so that all the analysis and database stuff happens away from pfSense. Ideally you want your firewall to be just a firewall. Adding IDS/IPS is OK, but you certainly don't want the SQL DB and log handling/analysis stuff running on the firewall.
Bill
-
Ideally you want your firewall to be just a firewall. Adding IDS/IPS is OK, but you certainly don't want the SQL DB and log handling/analysis stuff running on the firewall.
Bill
I agree completely. My thought was that pfSense Snort is just another sensor pushing all data to a central system. So if you have three offices with a firewall and an SO sensor, it all can be a local environment at each site and still talk back to the central server managing all of the alerts and understanding what is happening on the network.
No matter what you do at the Firewall, stuff will still get thru and "SO" brings not only the Distributed Architecture you were talking about but allows for the analysis side of all your NSM data.
The only issue with "SO" is that Barnyard2 is configured to listen to Localhost not its interface address.
