Snort / Suricata for inbound traffic only
-
In the past, my network was simple and mainly for outbound use only (no services needed to be reached from the outside).
Now, however, I have the need to host a small web server on my network.
I was thinking of adding snort or suricata to my pfSense to more actively analyze the traffic coming into that web server. However, I really just want to use it for incoming traffic to that one specific server, and not change/analyze any of my other outbound traffic.
Is that possible?
-
Yes, providing you put that web server on a subnet and interface (or VLAN) by itself. You would then run Suricata or Snort on that interface (or VLAN) only. That would really be best practice anyway – putting your Interfacing web server in a DMZ. Run the IDS only on the DMZ interface.
Bill
-
Good idea, and that is what I did - kind of.
Unfortunately (for now) the server also needs to be on the LAN network. But I was able to install a 2nd NIC on the server and use an unused NIC on the pfSense box to make a DMZ of sorts. I make a new NAT rule that goes to the new DMZ server IP address. I then added the 'DMZ' interface to suricata.
Yes, the web server is now dual-homed, but I thought that would still be better than allowing external traffic to my main LAN.
Thoughts on dual-homing the server versus just letting the outside talk to the server's LAN IP?
Jason
-
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
pf
firewall 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 thepf
firewall 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.