Snort / Suricata for inbound traffic only
-
Well…dual-homed means if any bad guy finds a way into the web server, then he has immediate free access to you LAN. With a true DMZ, firewall rules protect the LAN from the DMZ.
Oh, and in my original reply up above I badly misspelled "Internet-facing web server". I put "Interfacing web server" instead... :-[.
Bill
-
Yeah, I realize if the dual-homed web server is compromised then the LAN is still compromised as well.
I was just thinking out loud whether making it dual homed like that with a dedicated 'outside' interface really buys me anything. And I still think it does in terms of making it a lot easier to monitor the traffic, even if it doesn't add much additional security.
The other thing it allows me to do is to keep my suricata rules very tight, as there is limited traffic of a specific type going through that one interface.
Again, not as good as a real DMZ, but will have to do for now until I rebuild a few things.
-
@bmeeks I was reading the forum and found this topic, from 9 years ago, and it is exactly what I'm looking for! A way to monitor and block only inbound traffic with IDS/IPS Suricata.
But, I became confused with your answer here. If the intention is to protect only inbound traffic from the internet to the servers located in the LAN, VLAN, or DMZ, why not activate Suricata / Snort to monitor the WANs instead of the LANs?
For example, in case of a DDoS attack, is not interesting to block directly in the WAN first, instead to permit this traffic to pass to LAN and then analyze and block?BR,
Edgar -
@edgarquadros They run outside the pf firewall so on WAN it ends up scanning and blocking traffic that would not be allowed by WAN rules anyway. So it’s a trade off.
-
Hello @SteveITS !
So, the recommendation is to monitor the LANs/VLANs that I have the hosted services running, right? But about the not monitoring outbound traffic and just inbound traffic, that is coming from the WAN to LAN? Remember, I have no clients/users located in the LANs, just services running in servers. So, there is no sense to monitor outbound traffic, just inbound traffic.
In this way, can I disable the WAN monitoring and put the LANs to monitor with the same rules (Pass List, Home Net, etc)? -
@edgarquadros said in Snort / Suricata for inbound traffic only:
So, the recommendation is to monitor the LANs/VLANs that I have the hosted services running, right? But about the not monitoring outbound traffic and just inbound traffic, that is coming from the WAN to LAN? Remember, I have no clients/users located in the LANs, just services running in servers. So, there is no sense to monitor outbound traffic, just inbound traffic.
In this way, can I disable the WAN monitoring and put the LANs to monitor with the same rules (Pass List, Home Net, etc)?It seems you are misunderstanding "inbound" and "outbound" in this discussion. An IDS/IPS instance on any given interface (WAN, LAN, DMZ, etc.) sees both inbound and outbound traffic on that interface. That is, it sees traffic from local hosts attached to that interface "outbound" to some other interface (typically the WAN, but could just be the DMZ, for example). It also sees traffic from outside that interface "inbound" to hosts behind that interface.
As mentioned by others, the network plumbing in FreeBSD results in the IDS/IPS instance being outside or in front of the
pffirewall engine. That means the IDS/IPS sees the traffic before the firewall rules have been applied. Check out these two diagrams for Legacy Mode Blocking and Inline IPS operation (these are showing traffic coming from the NIC port into pfSense, but simply reverse the arrows and the diagram is accurate for traffic leaving pfSense and being handed off to the NIC port):
So, placing the IDS/IPS instance on the LAN results in the IDS/IPS not having to scan and analyze traffic the WAN rules are going to drop anyway. And nothing can get to a host on the LAN interface without first passing through the IDS/IPS engine, so security is not really compromised. But performance is enhanced because the IDS/IPS is not scanning packets that are going to be discarded by thepffirewall engine at the next step in the path (particularly when talking about IDS/IPS on the WAN interface).Finally, you really can't use any kind of rule or IPS on your WAN to prevent a DDoS -- at least not the majority of them. That's because in a typcial DDoS the bad guy is flooding and saturating your inbound link (your WAN pipe) with traffic so that nothing else can get through. Your firewall can't do a thing about traffic coming from your ISP link down to you. If you have a 1 Gig/sec WAN connection and the bad guy is sending 2 Gigs/sec of packet traffic to you, your WAN is effectively dead (saturated) and there is not a single thing your firewall can do about that. Only your ISP or something else upstream of your firewall can realistically deal with a true DDoS attack. If it was a piece of cake to block a DDoS with a firewall, then DDoS would not be a threat at all as any firewall could block it. The only thing you can potentially do on your firewall to help defend a DDoS on a given host behind the firewall is limit inbound connections to that host. But if you examine the diagrams posted above, Suricata on the LAN can still do that just perfectly fine as it will see the traffic before the local host on the LAN sees it.
-
@bmeeks thanks a lot for the explanation. So, looking at the drawings, I understand that Inline Mode can act and drop "bad" traffic before it reaches the pfSense engine. In Legacy Mode, the traffic will reach the pfSense engine and then will be blocked based on block rules, but in this way use more CPU/mem resources of pfSense hardware, right?
From what I saw here, Suricata is acting and blocking the DoS attacks (I can see the IP sources in the block list), but it seems that the Suricata is acting after the traffic passed to the internal server, because I can see the lots of TCP_SYN arriving on port 443 of the internal server and the server is answering ACK.
In my mind, this traffic needs to be dropped and never reach the internal server.I tried to change from Legacy to In Line Mode, but I received an error message "The 'opt9' interface does not support Inline IPS Mode with native netmap". In my scenario, I'm using all 4 pfSense physical ethernet ports configured in LAGG between pfSense and switches, for redundancy reasons. May this can be it can be the cause, right?
-
@edgarquadros Inline drops that one packet and lets others through. Legacy blocks the IP for the set amount of time. Either way the initial handshake up to the "bad packet" might get through.
Inline uses netmap which requires certain drivers... see the list at https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions though it's a few years old.
-
A bit of clarification seems to be in order ...
--With Inline IPS Mode, no packet makes it through to the pfSense firewall engine until Suricata has reached a verdict on the flow. Suricata internally buffers the flow (starting with the initial SYN packet) until it has decoded enough traffic to render a verdict on the flow (either DROP or PASS assuming the triggering rule's action is drop). Once Suricata reaches a verdict on a given flow, then no other packets associated with that flow are checked. But once a given flow is buffered, then all the rules are evaluated against that flow to see what the final verdict should be (ALERT, DROP, or PASS, for example). But Inline IPS Mode requires a compatible NIC driver that operates in native mode with the FreeBSD netmap kernel device. Synthetic virtual interfaces such as LAGG are not compatible with netmap in pfSense. Because the emulated netmap mode of operation was so slow and bug-prone, I elected to restrict Inline IPS Mode operation in the pfSense Suricata package to native-netmap mode devices only. VLANs are also not compatible with Inline IPS Mode due to the behavior of the netmap kernel device.
Legacy Blocking Mode is a different animal entirely. It allows traffic to pass through to the firewall while the Suricata engine is rendering a verdict. This is because Suricata is getting copies of interface packets to analyze. Once Suricata reaches a verdict, it makes an API call into the
pffirewall engine in the kernel and adds the offender's IP address to a built-in table called snort2c. Any IP address placed in that table is blocked completely by hidden built-in pfSense firewall rules. And optionally, if the "Clear States" checkbox is checked on the INTERFACE SETTINGS tab, then any previously open states associated with the newly blocked IP are closed to block the session. That checkbox is enabled by default. -
@bmeeks said in Snort / Suricata for inbound traffic only:
our firewall can't do a thing about traffic coming from your ISP link down to you. If you have a 1 Gig/sec WAN connection and the bad guy is sending 2 Gigs/sec of packet traffic to you, your WAN is effectively dead (saturated)
Well i will also state that even if the DDoS stream wasnt saturating your WAN, there is still firewall system resources being taken up by sessions that will never complete OR sessions that do complete but no further data. If your firewall resources are being maxed out that makes it difficult for other functions to operate correctly i.e. Routing
So a DoS doesnt have to be about filling a pipe.
