Short question about Suricata in cooperation with pfblocker
-
Hello Guys
my understanding is that packets first go through pfblocker's floating rule. There the IP is checked against my lists and eventually blocked. If an IP is not found in the pfblock lists, the packet is forwarded to Suricata.
With pfblocker I want to relieve Suricata a little bit.Today, however, I noticed that I find IP addresses in both logs. Suricata should not see the packets at all, right?
Do I understand something wrong?
ThankspfBlocker:
Suricata
-
You have your packet flow wrong.
The IDS/IPS packages (whether Snort or Suricata) are inserted immediately at the output of the physical NIC before any piece of the FreeBSD operating system.
So, using Inbound traffic on any interface as an example, the packets leave the physical NIC on their way into the operating system. But their first stop is the IDS/IPS. That happens before any other processing has happened, including the firewall.
Here are two diagrams I've shared many, many times here on the forum showing how the IDS/IPS is plumbed into pfSense. There are two diagrams because the traffic flow is slightly different between the two available IPS blocking modes (Legacy versus Inline) --
-
@Trust9 said in Short question about Suricata in cooperation with pfblocker:
Today, however, I noticed that I find IP addresses in both logs. Suricata should not see the packets at all, right?
This is only true when pfBlockerNG is configured on the WAN and Suricata is on an internal interface such as the LAN. If both are on the same interface, Suricata will always see the traffic first. Refer to my diagrams in my earlier post to see why.
-
Hi,
this is exactly the answer I needed :)
Thank you.I have Suricata running in legacy mode on the WAN interface.
Your diagram showed me very nicely why I find entries in both logs.In legacy mode, the packet is simply duplicated and arrives in IDS and pfblocker at the same time.
In inline mode the packets would then not arrive in the firewall, correct?
It's just for the sake of interest. The inline mode does not work for me on the wan interface.
Thanks again :)
-
@Trust9 If you move Suricata to LAN, then 1) only packets that pass through the firewall will be scanned, and 2) internal IPs will show in the alerts instead of your WAN IP.
-
@Trust9 said in Short question about Suricata in cooperation with pfblocker:
In inline mode the packets would then not arrive in the firewall, correct?
Correct, but as @SteveITS mentioned, it is now recommended to put the IDS/IPS on an internal interface (such as the LAN). That helps reduce the amount of traffic it has to process as it will not see all the Internet "noise" that hits the WAN but that the firewall rules there are likely going to block anyway. Second benefit is, as he stated, local hosts appear in the alerts with their actual IP address. When you run the IDS/IPS on the WAN, all local host IP addresses are hidden by NAT and show up as only the WAN public IP.
-
I have a lot of open ports.
Web server, Voip, and other services. Don't you think it makes sense to enable IPS on the wan interface as well? -
@Trust9 said in Short question about Suricata in cooperation with pfblocker:
I have a lot of open ports.
Web server, Voip, and other services. Don't you think it makes sense to enable IPS on the wan interface as well?No, I would not put Suricata on the WAN and here is why.
-
Nothing can reach your internal services (web server, VoIP box, etc.) without the traffic passing through either a LAN or DMZ interface on the firewall. pfSense is a router and a firewall. It takes incoming traffic on the WAN from the Internet, applies the firewall rules to the traffic, then routes the traffic to the appropriate internal interface.
-
You do not run an IDS/IPS to protect your firewall. If you have a firewall that needs an IDS/IPS in front of it for protection, then you need to find a new and more secure firewall . The firewall should be more than capable of protecting itself and should not need an IDS/IPS in front of it for protection.
-
In light of the above two points, what is the point of putting Suricata on the WAN? When running on the WAN, it will see and have to process all of the Internet "noise" on the WAN interface, but then your firewall rules are going to drop the vast majority of that traffic anyway. So, why waste CPU cycles having Suricata scan that stuff? Refer to the two diagrams I linked earlier. See how Suricata will always be the first thing traffic coming into an interface hits.
-
Suricata running on say a LAN or DMZ interface will still see and be able to scan all traffic traversing that interface (both inbound and outbound). That interface is the only way something from the Internet (via a port forward on the WAN, for example) can reach your internal host (a web server or VoIP box). Suricata sitting on the interface will see and police the traffic. But it will only have to deal with traffic that the firewall rules have already filtered thus saving CPU cycles.
In my view, the only time putting Suricata on the WAN makes any sense is if you have very limited RAM in the box, an anemic CPU, and you have several interfaces you want to protect with the same rules on all. Maybe then for overall conservation of RAM and CPU you compromise with a single WAN instance of Suricata. But at that point it may also be time to replace the firewall hardware with something with more capability.
-
-
@bmeeks
I think you have convinced me to install using the LAN instead of the WAN. I have one question in that I use a layer3 Cisco switch connected to 1 LAN port on pfsense. Will the IDS see all the hosts or will it see all traffic as the layer 3 switch IP? I really only care about outbound traffic since pfsense will not see locally routed traffic as it is all within the L3 switch.I am just waiting for the next release of pfsense to solidify.
-
@coxhaus said in Short question about Suricata in cooperation with pfblocker:
@bmeeks
I think you have convinced me to install using the LAN instead of the WAN. I have one question in that I use a layer3 Cisco switch connected to 1 LAN port on pfsense. Will the IDS see all the hosts or will it see all traffic as the layer 3 switch IP? I really only care about outbound traffic since pfsense will not see locally routed traffic as it is all within the L3 switch.I am just waiting for the next release of pfsense to solidify.
Suricata will put the interface it runs on in promiscuous mode. It will then be able to see all the traffic that hits that port. But of course the firewall port is only going to see what the Layer 3 switch in front of it routes to the firewall (and thus Suricata).
Does your Layer 3 switch do any NAT? If not, then the IP addresses that Suricata sees on the firewall's LAN port will be "native". I would not expect your Layer 3 switch to be doing NAT, though. It should not change the IP source/destination IPs in the packets, but it will change the MAC address since it is Layer 3.
-
@bmeeks
Thanks. No NAT on my layer 3 switch. I don't have that kind of money plus I am not sure I would need pfsense if I had NAT on my L3 switch.I remember using promiscuous mode back in the old Sniffer days looking for irregular packets.
-
@bmeeks said in Short question about Suricata in cooperation with pfblocker:
@Trust9 said in Short question about Suricata in cooperation with pfblocker:
I have a lot of open ports.
Web server, Voip, and other services. Don't you think it makes sense to enable IPS on the wan interface as well?No, I would not put Suricata on the WAN and here is why.
-
Nothing can reach your internal services (web server, VoIP box, etc.) without the traffic passing through either a LAN or DMZ interface on the firewall. pfSense is a router and a firewall. It takes incoming traffic on the WAN from the Internet, applies the firewall rules to the traffic, then routes the traffic to the appropriate internal interface.
-
You do not run an IDS/IPS to protect your firewall. If you have a firewall that needs an IDS/IPS in front of it for protection, then you need to find a new and more secure firewall . The firewall should be more than capable of protecting itself and should not need an IDS/IPS in front of it for protection.
-
In light of the above two points, what is the point of putting Suricata on the WAN? When running on the WAN, it will see and have to process all of the Internet "noise" on the WAN interface, but then your firewall rules are going to drop the vast majority of that traffic anyway. So, why waste CPU cycles having Suricata scan that stuff? Refer to the two diagrams I linked earlier. See how Suricata will always be the first thing traffic coming into an interface hits.
-
Suricata running on say a LAN or DMZ interface will still see and be able to scan all traffic traversing that interface (both inbound and outbound). That interface is the only way something from the Internet (via a port forward on the WAN, for example) can reach your internal host (a web server or VoIP box). Suricata sitting on the interface will see and police the traffic. But it will only have to deal with traffic that the firewall rules have already filtered thus saving CPU cycles.
In my view, the only time putting Suricata on the WAN makes any sense is if you have very limited RAM in the box, an anemic CPU, and you have several interfaces you want to protect with the same rules on all. Maybe then for overall conservation of RAM and CPU you compromise with a single WAN instance of Suricata. But at that point it may also be time to replace the firewall hardware with something with more capability.
Your explanations are really awesome. You really take a lot of time to share your knowledge.
Thank you very much.
I will activate Suricata only on the lan interface and see how it goes. -