Suricata - Block for Drop rule & Source IP on snort2c?
-
Hi all,
I have been using pfsense for a while, its great, but I am at a loss when it comes to the suricata package (since suricata on pfsense operates differently than suricata on its own). I would appreciate any advice on the two issues below, or if its possible to get them implemented into the next suricata package update that would be great :)
Firstly, one of the issues I am having is that if I write a suricata rule to drop or reject it doesn't work because suricata is setup as an IDS not an IPS. That would be fine, if the snort2c table could hold an IP address for the host and another IP for the source address. Otherwise, what happens is anytime you get an alert, a block occurs on the host in your whole network. That is a problem as maybe half of my network is servers and the other half could be clients, or I have different clients with different software and thus need different rules. I can add the host to the pass list, but then it allows the host to pass for everyone, making it useless in that fashion.
The second issue is that there is absolutely no way to block offenders that trigger drop or reject rules instead of alert rules. This removes any capability to test alerts first, while maintaining active blocks on offenders. Its essentially all or nothing. It also doesn't give me the ability to silently inspect traffic while maintaining block rules on the rest, as to accomplish the former, I have to disable killing states and blocking offenders.
Any advice on the above would be appreciated!
-
Suricata is patterned after Snort on pfSense. Both packages use a piece of custom code compiled into the binary that inserts the IP address of traffic that generates alerts into the pf firewall. It does so using a pf table created at pfSense boot-up called snort2c. The design simply triggers off any alert and the source and/or destination IP address is inserted into the snort2c table. Because the blocking mechanism depends on libpcap and getting copies of packets for inspection by Suricata or Snort, there is no real support for DROP or REJECT. In other words, there is no inline mode available and thus those rule operations make no sense on pfSense at the moment.
There are plans in a future pfSense version to support the Netmap API. This will allow Suricata (and maybe Snort, but not sure yet) to work in a true inline IPS mode. At that point support for DROP and REJECT would be there.
Bill
-
Suricata is patterned after Snort on pfSense. Both packages use a piece of custom code compiled into the binary that inserts the IP address of traffic that generates alerts into the pf firewall. It does so using a pf table created at pfSense boot-up called snort2c. The design simply triggers off any alert and the source and/or destination IP address is inserted into the snort2c table. Because the blocking mechanism depends on libpcap and getting copies of packets for inspection by Suricata or Snort, there is no real support for DROP or REJECT. In other words, there is no inline mode available and thus those rule operations make no sense on pfSense at the moment.
There are plans in a future pfSense version to support the Netmap API. This will allow Suricata (and maybe Snort, but not sure yet) to work in a true inline IPS mode. At that point support for DROP and REJECT would be there.
Bill
Thanks for the reply Bill, for current releases is it not possible to add a simple option to block hosts that trigger drop or reject rules instead of alert? Sorry if I am being redundant but I assume there is a way to distinguish between an alert and drop rule even though the packet doesn't drop.
I read a lot of the information in regards to the netmap API and I am excited to see it for the future releases.
-
Thanks for the reply Bill, for current releases is it not possible to add a simple option to block hosts that trigger drop or reject rules instead of alert? Sorry if I am being redundant but I assume there is a way to distinguish between an alert and drop rule even though the packet doesn't drop.
For Suricata I think it would be possible, but there would be a potentially big user learning curve. Let me explain. Many users of Suricata and Snort on pfSense are not full-time IDS/IPS folks (this is my opinion based on some of the questions asked here occasionally and is not meant as a slight … ;) ). They sort of expect to install the package, enable some rules and turn on blocking and have it start blocking hosts. Having the default state be alerting only with blocking only possible by changing the rule actions would be a big paradigm shift.
None of the popular rules packages (Snort VRT and Emerging Threats) provide rules with any kind of action keyword other than ALERT. So if the package were changed to truly just "alert" on ALERT action keywords and only "block" on DROP action keywords, then users would have to modify their rules to achieve the same type of auto-blocking they get today.
Now what I have thought about is an option to switch modes between what I call the "current legacy mode" and a mode such as what you describe where ALERT means alert and only DROP means block. Doing this in Suricata would be easy. The Snort package may be more difficult, though. I took a quick look into the API code used by the blocking plugin, and it was not readily apparent that the rule "action" was provided in the alert data seen by the Snort blocking plugin. I need to investigate that more deeply to see if I overlooked something. The Snort code is not well commented in this particular area.
Bill
