Suricata Inline questions
-
I'm running suricata in inline mode and I love it but had a couple questions to see if what I would like to do is possible while using inline mode.
1. Is it possible to duplicate some of the functionality from the 'suricata blueprint thread' on this board? Specifically adding/tracking IP's that are attempting connections to known unused ports and blocking all ports from that IP. Could this be done via writing specific rules (not sure how IP's would be tracked manually/deduped)?
2. Is it possible to have the suricata inspection occur after the FW on an interface (ie. WAN)? The only way I can think of is adding inspection to every interface on the inside, which I'd like to avoid, since my intention is to reduce the load of the IPS.
-
I'll tackle question #2 first –
Is it possible to have the suricata inspection occur after the FW on an interface (ie. WAN)? The only way I can think of is adding inspection to every interface on the inside, which I'd like to avoid, since my intention is to reduce the load of the IPS?
No, that would require rewriting the internal plumbing of pfSense and FreeBSD. As you mentioned, one solution is running rules on an internal interface.
As for question #1 –
Is it possible to duplicate some of the functionality from the 'suricata blueprint thread' on this board? Specifically adding/tracking IP's that are attempting connections to known unused ports and blocking all ports from that IP. Could this be done via writing specific rules (not sure how IP's would be tracked manually/deduped)?
When an IP is dropped (when using inline) or added to the block table (when using Legacy Mode), all ports of that IP are blocked. Suricata does not block or drop on a port-based thing. True that a given rule may trigger due to some port number being used, but the drop or block is for all ports for that IP. So I'm not sure exactly what you want to accomplish with your request. That notwithstanding, however, there is currently no way to automatically parse IP addresses from alerts or drops and then take further actions based on the IP.
Bill
-
Thank you for the info
As I figured on #2, just wanted to make sure I wasn't missing something.
For #1, I was unaware that all comms would be dropped for a rule specifying a single port. That is actually my preference and what I was trying to accomplish, but it did not seem logical to me that it would work that way. I assumed only that session or initiation would be dropped.
Given that, I assume the global setting for removing blocked hosts applies to those IP's that are blocked via inline mode. Is there a way to see all the IP's on the current/active block list?
-
@tortue:
Thank you for the info
As I figured on #2, just wanted to make sure I wasn't missing something.
For #1, I was unaware that all comms would be dropped for a rule specifying a single port. That is actually my preference and what I was trying to accomplish, but it did not seem logical to me that it would work that way. I assumed only that session or initiation would be dropped.
Given that, I assume the global setting for removing blocked hosts applies to those IP's that are blocked via inline mode. Is there a way to see all the IP's on the current/active block list?
Inline mode is quite a bit different than Legacy Mode. Inline mode has no concept of a "block list". There is no interaction with the firewall part of pfSense at all. With inline mode, when a packet triggers an alert it is just dropped. This means it never makes it to the firewall or anywhere else in pfSense. It is just dropped on the floor on its way out of the NIC to the rest of pfSense. Netmap is used to provide this interface. It hooks itself between the NIC driver and the rest of the system. That's why Inline Mode only works with a handful of NICs. The driver has to support and be able to talk with the Netmap layer. When using Inline mode, the BLOCKED tab is not used at all. Dropped IP addresses are highlighted in red on the ALERTS tab.
Legacy Mode uses the pfSense firewall engine for blocking. It uses a system call to place the offending IP address into a special built-in pf table in pfSense called snort2c. Any IP address put into this table has its traffic blocked (all ports on that IP). The table blocks the IP and thus all ports associated with it. IP addresses live in that snort2c table for the time period specified in the GUI for auto-clearing blocked hosts. The snort2c table exists only in RAM, so if the firewall is rebooted all the IPs are lost and the blocking starts again from scratch. It is not persistent, and there really is no need. If the malicious traffic starts up again, it will trigger the rule again and get blocked again. There is no benefit to saving thousands of blocked IPs for months in the snort2c table. When you look at the BLOCKED tab in Legacy Mode, what actually happens is the contents of the snort2c table are read from RAM and displayed on that tab.
Bill
-
Inline mode is quite a bit different than Legacy Mode. Inline mode has no concept of a "block list". There is no interaction with the firewall part of pfSense at all. With inline mode, when a packet triggers an alert it is just dropped. This means it never makes it to the firewall or anywhere else in pfSense. It is just dropped on the floor on its way out of the NIC to the rest of pfSense. Netmap is used to provide this interface. It hooks itself between the NIC driver and the rest of the system. That's why Inline Mode only works with a handful of NICs. The driver has to support and be able to talk with the Netmap layer. When using Inline mode, the BLOCKED tab is not used at all. Dropped IP addresses are highlighted in red on the ALERTS tab.
Ok, that's how I thought it worked. But I got confused by the earlier post regarding that all ports of that IP are blocked if a drop rule is triggered. In order to do that some kind of memory or state table would be needed which doesn't exist in inline mode to my understanding. So I guess what I'm trying to accomplish from the legacy mode with inline mode isn't possible at the moment.
I don't think I explained throoughly what I was trying to do. I'm trying to drop all packets from an IP for a period of time if a drop rule (or any drop rule really) is triggered. For example, if IP A tries to connect via port 22 and that triggers a drop action via suricata, I would like IP A to then be dropped (suricata) or blocked (firewall) for all ports even though I do not have rules to drop/block port 443. Sort of a custom/personalized IP Reputation system, (if you connect to my site on this port which I know is invalid, you can't connect to my site on any port even if they are valid), similar if not identical to part of the suricata blueprint thread.
Only path forward I can think of at the moment is a log rule and handling the log parsing and dedupe individually and using a FW alias for that deduped file.
-
@tortue:
Only path forward I can think of at the moment is a log rule and handling the log parsing and dedupe individually and using a FW alias for that deduped file.
Correct, that would be a way to do it, but it is a bit labor intensive to develop. I would challenge if the effort was worth the gain, though. The firewall is already going to drop inbound traffic that is unsolicited or that does not match an open port. Good operating practice says to keep all Internet-facing public services (web, email, etc.) well patched and hardened. Having an automated system that locks out an IP due to it attempting to connect to a single non-existent port could be an issue for a commercial enterprise. Suppose the user who is also a customer of yours just fat-fingered the hostname or accidentally used your hostname when he was trying to connect to another service (RDP perhaps) when he meant to use another. Now his IP will be blocked from any contact with your domain, including your web site.
Of course if you are strictly a home user, then none of the above matters to you. But at the same time, as a home user you likely have no public-facing services (and thus open ports), so why bother?
Bill
