Snort: Where do I find a specific rule?
-
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.
-
…With regards to Snort on pfSense, it is currently what I term a hybrid; but cyber security purists would take offense at my characterization. …
<<< World's First And Only Cyber Security Purist.
Ideally the pfsense box should be running suricata in IPS mode and send the logs to another device.
A)Capturing a live stream of the packets going through/getting blocked by the box (and historically archiving it) would be an added bonus but you need to take into consideration their rotation, I'm thinking daily and datestamping the compressed file. A gui to download Monday the 29th of 3084 would be appreciated. While you are at it, logs/captures need to get pushed away from the firewall box ASAP, so as soon as it is finished datestamping the file, a copy is emailed to an address of your choice (in case a creative rm -rf ./* is executed on the captured packets). Most home users will not notice any slowing down, since a 10Mbps connection only puts out 1.25MB/s (most drives should be able to write well above that). Double that (symmetric connection) and it's still way to low for a disk to stress over it. We might run into some difficulties as we approach the 100Mbps mark, but nothing an SSD can't solve. Or Fiber Channel with the new 120Gbps standard. Oops, forgot we are talking about (holds a giant sign) >HOME< connection. Emphasising since some forum members have difficulty reading the HOME word. I do realise that most people are using gigabit for their internal networks, but how many of those have the need for a true IPS capturing a live stream of the traffic passing through their wifi? (routers set up to forward all packets upstream, clients can't communicate directly with each other, most asus(es?) do that.)
B)Logs ("I blocked this packet from passing through") should be sent to existing syslog facilities (so they can be sent to a remote syslog server if so configured).In summary, the new suricata package should concentrate on working as a true IPS system, and be able to capture information/data for criminal procecution (there are those of us who need that) and troubleshooting.
EDIT:Capturing the live stream could be done upstream with a mirror port, but it saves you the trouble if you don't have a managed switch. That, and since all the traffic passes through the box already, you might as well capture it anyway and saves you the trouble of setting up a separate sniffing host (connected to aforementioned mirroring port).
-
@jflsakfja:
…With regards to Snort on pfSense, it is currently what I term a hybrid; but cyber security purists would take offense at my characterization. …
<<< World's First And Only Cyber Security Purist.
Ideally the pfsense box should be running suricata in IPS mode and send the logs to another device.
A)Capturing a live stream of the packets going through/getting blocked by the box (and historically archiving it) would be an added bonus but you need to take into consideration their rotation, I'm thinking daily and datestamping the compressed file. A gui to download Monday the 29th of 3084 would be appreciated. While you are at it, logs/captures need to get pushed away from the firewall box ASAP, so as soon as it is finished datestamping the file, a copy is emailed to an address of your choice (in case a creative rm -rf ./* is executed on the captured packets). Most home users will not notice any slowing down, since a 10Mbps connection only puts out 1.25MB/s (most drives should be able to write well above that). Double that (symmetric connection) and it's still way to low for a disk to stress over it. We might run into some difficulties as we approach the 100Mbps mark, but nothing an SSD can't solve. Or Fiber Channel with the new 120Gbps standard. Oops, forgot we are talking about (holds a giant sign) >HOME< connection. Emphasising since some forum members have difficulty reading the HOME word. I do realise that most people are using gigabit for their internal networks, but how many of those have the need for a true IPS capturing a live stream of the traffic passing through their wifi? (routers set up to forward all packets upstream, clients can't communicate directly with each other, most asus(es?) do that.)
B)Logs ("I blocked this packet from passing through") should be sent to existing syslog facilities (so they can be sent to a remote syslog server if so configured).In summary, the new suricata package should concentrate on working as a true IPS system, and be able to capture information/data for criminal procecution (there are those of us who need that) and troubleshooting.
EDIT:Capturing the live stream could be done upstream with a mirror port, but it saves you the trouble if you don't have a managed switch. That, and since all the traffic passes through the box already, you might as well capture it anyway and saves you the trouble of setting up a separate sniffing host (connected to aforementioned mirroring port).
I hear you on the true IPS mode. That is the desire, but some more pfSense patches are likely needed to make that work for TCP, UDP and ICMP. The first BETA package will be IDS only just to get some feedback from users on the general look and feel and performance in detection-only mode. It will offer pretty much all the Suricata bells and whistles such as TLS handshake logs, HTTP logs, file-json logs and optional capture of downloaded files (if suitable rules are created), full Barnyard2 support with both MySQL and remote syslog output, and finally full packet capture to pcap-format files. Even in my little VMware environment this gobbles up a lot of disk really quickly! I've got to find a way to move this data off the firewall in a quick and efficient manner to something else that is beefier and meant to take the load.
Unless you turn off all these capturing features, Suricata is NOT going be something you run on NanoBSD… :). I also don't see home users taking advantage of all this except for just playing around. As you say, though, there are some commercial users of pfSense that will find the Suricata features useful.
I am very close to releasing the BETA of Suricata. Testing the install/uninstall scripts now, and need to add some code to allow viewing of all those log files I mentioned above in the GUI.
Bill
-
I have had snorby going on seperate box. Wish it would just run on same machine. Along with the other tools that security onion has in there. Nice to see some in depth data from your net and find out what is really going on under the hood.
-
Bill, you can also use Suricata 2.1beta4. Been using it on linux boxes for months, w/0 trouble. More stable and feature rich than 2.0.8, including CIDR IP Rep, etc..
Considering inline operation in IPS mode. Its now a real must. Malware as small as 20kb get pass the snort hybrid mode of pfsense…
F.
