Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions
-
I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...
-
@murzik said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...
The only possibility I can imagine that would cause a DROP action to not appear on the ALERTS tab (highlighted in RED to indicate a drop) is if the alert line from the log did not parse correctly. The code on the ALERTS tab reads the alert log for the interface line-by-line and parses each line into a set of fields delimited by commas. If a line does not parse out the correct number of fields, it is discarded and not displayed on the ALERTS tab.
To see if this is the case, get to the command line in pfSense either directly via the console or remotely via SSH. Then change to the correct Snort log interface directory in
/var/log/snort. There will be a separate sub-directory under that path for each configured Snort interface. Once in the correct sub-directory, usegrepto search thealertfile for the rule SID in question to see if it is in there. Post back here with your findings. If the SID is there but is not showing on the ALERTS tab, then it is a parsing issue I need to look into. If you don't see the SID in thealertfile for the interface, then that would be a binary issue you would take up with the upstream Snort team. -
@bmeeks
I think that is a binary issue. Alert is not in alert file.
Thanks... -
@crazybrain I believe the Atom 3558 with ix NIC's do work with netmap.
I'm running Suricata with inline no problem. There is also a command you can run (cant recall) and it shows its netmap enabled.Now just waiting for pfSense 2.5 to drop.
@bmeeks can/will you be able to release Snort v4 on pfSense 2.4.5 release? Or is it only when 2.5 comes out?
-
@N0_Klu3 said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks can/will you be able to release Snort v4 on pfSense 2.4.5 release? Or is it only when 2.5 comes out?
Only when 2.5 comes out. The inline netmap option requires the netmap library from FreeBSD 12, and pfSense-2.4.5 is still FreeBSD 11 (although it is 11-STABLE).
-
So inline mode won't work with vlans? Even though they are hosted on a supported nic? what about a lacp lagg?
Should inline mode work on Intel 82576 or a Intel I340-T4?
I don't mean to seem lazy but this is the best write up I've found and I wouldn't mind listing some tested hardware here.
Thanks for all the great info!
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
So inline mode won't work with vlans? Even though they are hosted on a supported nic? what about a lacp lagg?
Should inline mode work on Intel 82576 or a Intel I340-T4?
I don't mean to seem lazy but this is the best write up I've found and I wouldn't mind listing some tested hardware here.
Thanks for all the great info!
VLANs may work now in FreeBSD-12.3/STABLE. I have not tested them. pfSense-2.5 DEVEL moved to FreeBSD-12.3/STABLE a little while back. NIC drivers (the majority of them, anyway) in FreeBSD 12.3 have been ported to a new API called iflib. The iflib system handles all of the netmap stuff now for NICs that use iflib, and thus the NIC hardware driver is not burdened with that code development. The iflib subsystem is also supposed to support features such as VLANs, but there can still be issues with certain NICs that perform hardware-level VLAN tag manipulations.
So a long answer to basically say "I don't know for sure, but VLANs may work with some NICs now in pfSense-2.5 DEVEL with the Snort-4.x package using Inline IPS Mode".
The answer to your other question about netmap support in a given NIC depends on whether or not that hardware vendor migrated their driver over to iflib. Many have, a few have not per my understanding. And even some of those that have migrated may not have ported all versions of their hardware. So far as I know, most of the Intel NICs are ported over to iflib.
-
@bmeeks Thank you for your hard work and response! You've helped me in the past!
amazing!
So there shouldn't be an issue with running my wan in inline mode and my dmz vlan in legacy correct?
Most of my work with pfsense is remote so it is difficult to make risky changes, but i'd really like inline mode up on at least the wan.
Thanks again,
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks Thank you for your hard work and response! You've helped me in the past!
amazing!
So there shouldn't be an issue with running my wan in inline mode and my dmz vlan in legacy correct?
Most of my work with pfsense is remote so it is difficult to make risky changes, but i'd really like inline mode up on at least the wan.
Thanks again,
Yes, you can run your LAN in Legacy Mode and WAN in Inline IPS Mode if desired. However, in my view it is usually more efficient in terms of resource utilization to just put the IDS/IPS on the LAN side (or DMZ and LAN, etc., if you have multiple internal interfaces). My reasoning is thus:
-
The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.
-
The IDS/IPS sits between the firewall engine and the physical interface. So that means on the WAN it only sees traffic from your internal hosts after NAT rules are applied. That means in most cases every internal host will show up in WAN alerts as having the public IP address of the firewall. That is not helpful when trying to track down a problematic internal host.
-
If you have a properly configured firewall and have not installed a lot of extra "stuff" on it, then it has an extremely small attack surface and is pretty well "hardened" against attack. Snort or Suricata out front on the WAN is not going to really offer much additional protection- if any. So couple this fact with the items I mentioned in #1 and #2 above and you can see why I recommend putting the IDS/IPS on the internal interfaces only.
But there is no harm in using the setup you propose, but there are more efficient ways to consider configuring your setup.
-
-
@bmeeks That makes sense,
I host a small site and a few apps with pfblocker for geofencing.
Would it still be a good idea to disable the ips on the wan with those services running?I am trying to sort out another issue with port mirroring for Security Onion as I keep getting zeek/bro notices telling me there is packet loss over the pfsense port mirror.
In your experience, how is the port mirroring performance in pfsense compared to Cisco's port span?
Thanks again, it's good talking to a master!
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks That makes sense,
I host a small site and a few apps with pfblocker for geofencing.
Would it still be a good idea to disable the ips on the wan with those services running?To answer that question, trace a network packet from the Internet to your internal web server. Doesn't that packet have to traverse your DMZ interface (assuming the web server is on a DMZ subnet)? If configured on your DMZ interface, Snort will be seeing all traffic coming from and going to your web server from any other firewall interface (including the WAN). So it can offer exactly the same protection to the web server on the DMZ as it would offer if Snort were running on the WAN.
Now consider the potential issues/irritations if Snort is running on the WAN. I assume you are using NAT and port forwarding to reach your internal web server in the DMZ. If not, then skip the rest of this paragraph. That means all the alerts you see on your WAN have the firewall's public IP in them. So how do you determine if you have an infected internal host and which one it is? To do that you would likely want to run the same Snort setup on your internal interfaces. Now you have duplicate or triplicate Snort instances just chewing up RAM and CPU cycles for what real benfit?
Why not just put the IDS/IPS close to the hosts it is actually protecting? The IDS/IPS is for your internal network. It is not to protect your firewall. Right? If your firewall needs protection, then you would want to find you another firewall ...
. And when on the WAN interface, Snort is just going to see and alert on all the Internet "noise" traffic that the firewall is not going to pass anway. So why bog down your CPU logging crap that your firewall is not going to pass anyway?So my answer is run Snort on your DMZ and maybe your LAN, but you likely don't want or need the same rules in both places. Select and enable rules to protect from the actual threats you face on that interface based on the services provided behind it. If you don't have a DNS server on the DMZ, then you don't need any DNS rules taking up CPU cycles and chewing up RAM. If you don't have a mail server running, then you don't need any of the SMTP server rules enabled. Being smart about the rules you select and enable and choosing those rules by the actual attack surface behind the interface lets you be efficient with the resource consumption of the IDS/IPS.
I am trying to sort out another issue with port mirroring for Security Onion as I keep getting zeek/bro notices telling me there is packet loss over the pfsense port mirror.
In your experience, how is the port mirroring performance in pfsense compared to Cisco's port span?
Thanks again, it's good talking to a master!
Port-mirroring is a hardware-intensive task. And when you have very high speed network ports it can get overwhelming for any switch very quickly. How exactly do you have port mirroring configured? What brand of switch are you using?
-
@bmeeks I'm totally blown away, that makes perfect sense! Excellent example.
Thank you! Again!
Currently I am using pfsense to mirror my vlans, which run over a 3GB lagg. The mirror port is a 10GB nic which is direct/copper attach to my seconion box.
I monitor pfsense cpu usage closely with either the dashboard or pftop and it never seems overwhelmed.pfsense specs: i3 4170 with 16gb ram.
switch: Cisco WS-C4948E-Sbreaking out ports to get inline working will complicate my port mirroring. That should be fun!!
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks I'm totally blown away, that makes perfect sense! Excellent example.
Thank you! Again!
Currently I am using pfsense to mirror my vlans, which run over a 3GB lagg. The mirror port is a 10GB nic which is direct/copper attach to my seconion box.
I monitor pfsense cpu usage closely with either the dashboard or pftop and it never seems overwhelmed.pfsense specs: i3 4170 with 16gb ram.
switch: Cisco WS-C4948E-Sbreaking out ports to get inline working will complicate my port mirroring. That should be fun!!
I suspect you would get much better performance letting your Cisco switching fabric (which is pure hardware for the most part) do the mirroring (called a SPAN port in Cisco speak).
If SecurityOnion says you are dropping packets, then it would follow that the dashboard and pftop and not providing all the relevant data. Or else SecurityOnion is mistaken ...
. -
@bmeeks Yep, well...
That seems to have done it.
Stayed up to 3am Sat re-configuring the network, swapping the hypervisor's nics around, and replacing the router. I now have the span port on the switch instead of the pfSense box and while Seconion was up, it didn't have any packet loss, but now it's being crash-happy so I've re-imaged it.Also, inline mode appears to be working on my dmz vlan, so that's a bonus.
We'll see how long this config lasts.
Thanks for your help, the guys at the office suggested it my be the span but I suppose I didn't want to believe them.
edit: Looks like the "CaptureLoss::Too_Much_Loss" is back, but inline mode is still holding strong!
new config for posterity:
So the lacp LAGG's gone, dual intel nic for wan (Intel 82576), single intel 10gb for lan (X520-DA1), same i3 4170 and now 8gb of ram. Cisco WS-C4948E-S now performing the port span to security onion. -
Hi all, I'm using a Chelsio T520-CR in a lagg0 with LACP and I get the following error when trying to select inline mode on one of the vlans;
The following input errors were detected:
The 'opt3' interface do not support Inline Mode.The Chelsio does support netmap via the cxgbe driver. https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 any ideas what I might be doing wrong. Running 2.4.5-RELEASE-p1
Thanks
-
@brezlord said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Hi all, I'm using a Chelsio T520-CR in a lagg0 with LACP and I get the following error when trying to select inline mode on one of the vlans;
The following input errors were detected:
The 'opt3' interface do not support Inline Mode.The Chelsio does support netmap via the cxgbe driver. https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 any ideas what I might be doing wrong. Running 2.4.5-RELEASE-p1
Thanks
The
cxgbedriver is included in the "acceptable" list recently added to the package code. Are you sure that your specific NIC is actually using that specific driver?Additionally, LAGG interfaces have a special psudeo-interface driver that runs on top of the physical NIC driver, and that driver is still not, so far as I know, compatible with the netmap kernel device.
-
Thanks. The NIC is using clx driver that come under the cxgbe(4) family. I thought that the issue might have been the lagg.
Thanks for the info.
-
@brezlord said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Thanks. The NIC is using clx driver that come under the cxgbe(4) family. I thought that the issue might have been the lagg.
Thanks for the info.
The idea behind netmap is great, but unfortunately the implementation has not lived up to the promise. And by that I mean so many other parts of the kernel network stack don't work with the netmap device. That makes it difficult when trying to create a high-speed IPS engine for FreeBSD-derived firewall distros. Things like LAGG, VLANs and other psuedo drivers just don't work well - and some don't work at all.
-
@bmeeks said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Then click the ADD button to
BTW...for those of you wanting to easily import something the exported file I have looks like this in plain text named "whatever.conf".
#Drop Rules
openappid-ads
snort_attack-responses
emerging-attack_response
snort_backdoor
emerging-botcc.portgrouped
emerging-botcc
snort_exploit-kit
emerging-ciarmy...and so forth. You can get your list literally from the categories list from your interface.
You still have to go into all your individual IPS categories and "enable all". Lame!
I want to enable all + block all. The block all is here but not the enable all to be blocked.
Also, you have to still go and select the dumb rules with the tickbox. So putting them in that list doesn't tick them and enable them. Too much clicking here people! :)
-
@wolfsden3 said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Then click the ADD button to
BTW...for those of you wanting to easily import something the exported file I have looks like this in plain text named "whatever.conf".
#Drop Rules
openappid-ads
snort_attack-responses
emerging-attack_response
snort_backdoor
emerging-botcc.portgrouped
emerging-botcc
snort_exploit-kit
emerging-ciarmy...and so forth. You can get your list literally from the categories list from your interface.
You still have to go into all your individual IPS categories and "enable all". Lame!
I want to enable all + block all. The block all is here but not the enable all to be blocked.
Also, you have to still go and select the dumb rules with the tickbox. So putting them in that list doesn't tick them and enable them. Too much clicking here people! :)
Do you know you can combine an
enablesid.conffile with yourdropsid.conffile? On the SID MGMT tab create an "enable" file and put the category names in there same as you are doing for the "drop" file. Assign that file in the Enable drop-down for the interface. That will eliminate you having to click categories on the CATEGORIES tab.Too much clicking here people! :)
You simply need to learn how to use the tool ...
.Finally, enabling all rules and all categories is not a good move. You waste CPU cycles and RAM doing that, not to mention increasing your odds of getting a lot of false positives. You only need to enable categories that protect from threats that you are actually vulnerable to. My favorite three examples are these (but there are many others): (1) if you don't have a public-facing web server, then you don't need to enable any web server rules as they are pointless without an exposed web server to be attacked; (2) if you don't run a public DNS server, then you certainly do not need the DNS server rules; and (3) if you don't run a public-facing mail server behind your firewall, then you certainly do not need any of the SMTP, IMAP or POP3 server rules.
You generally do not want to "enable all" the rules in a given category either. They are default-disabled for a good reason! Mostly it's due to frequent false positive triggering, or the rule author considers that rule for very specific circumstances and does not suggest it for widespread use. Research default-disabled rules before you just willy-nilly do an "enable all" on a category. Failure to do that can result in you shooting your foot off.
