Snort and pfsense firewall - order of processing?
-
Hi,
I am using snort and - of course - the pfsense integrated firewall. At the moment I do not have any allow rule on the WAN so everything is blocked from the WAN. But my snort is running on the WAN interface, too, and I can see that snort lists many alers and is blocking hosts. So it seems that traffic first reaches snort and then is hitting the firewall. Is this right?
In my opinion it would make more sense that traffic first hits the firewall and when there is an open port and traffic passes this port then it should be inspected by snort.
So does snort always places before the firewall when activated on an interface?
I would really appreciate any ideas, suggestions and explainations!
-
Hi,
I am using snort and - of course - the pfsense integrated firewall. At the moment I do not have any allow rule on the WAN so everything is blocked from the WAN. But my snort is running on the WAN interface, too, and I can see that snort lists many alers and is blocking hosts. So it seems that traffic first reaches snort and then is hitting the firewall. Is this right?
In my opinion it would make more sense that traffic first hits the firewall and when there is an open port and traffic passes this port then it should be inspected by snort.
So does snort always places before the firewall when activated on an interface?
I would really appreciate any ideas, suggestions and explainations!
Snort uses the libpcap library to get copies of packets hitting an interface. The library will put the interface in promiscuous mode, so it will see all traffic that hits the interface and BEFORE the firewall acts on it. In fact, Snort and the firewall see the packets at the same time.
It is better in my opinion to run Snort on the LAN side and maybe the DMZ side (if you have one). It will see everything on the WAN side and be bit chatty.
Bill
-
(…)
It will see everything on the WAN side and be bit chatty.
(...)Don't know exactly what you mean with that. Why can snort then see everything on WAN? Or dou you mean it sees everything which flows between LAN and WAN and vice versa - but it does not see things which come from WAN but do not reach LAN because of blocked by firewall rules and not interface in promiscous mode on WAN?
But nevertheless - I will give it a try on the LAN interface.
I am running this on an APU.1d4 and for the first try I enabled all signatures to get a feeling what alerts will be genrated and how it performs on my 6/0.5MBit/s WAN connection ::) -
What I mean by "see everything on WAN" is that, when in promiscuous mode, your WAN NIC no longer drops frames whose destination MAC address is not your WAN interface card's MAC. So this means Snort will see packets on the WAN side that would not normally be passed down the network stack from the network interface card's layer 2.
Depending on what your WAN connects into, this may mean not much. For example, if you have a dedicated "switched port" provided by your ISP, then your "port" is only going to see traffic headed for your card's MAC address anyway. However, if your WAN is part of some larger shared segment, then in promiscuous mode the NIC will pass down received packets regardless of the destination MAC address. If you are not familiar, read up on promiscuous mode to get a better explanation.
So how does this relate to Snort on the WAN and the packet filter firewall? From the WAN side, Snort sees packets as they first leave the network stack on their way to the packet filter (firewall). So Snort might alert on packet traffic that your firewall is not going to allow anyway. For example, if you don't accept any inbound traffic (the default pfSense WAN rule), then you expect Snort to never alert on unsolicited inbound traffic (say some spammer trying to connect to SMTP port 25). But with Snort situated above the firewall in the packet chain, it will see that unsolicited inbound traffic and potentially alert on it. That's what I mean by being noisy.
Bill
-
Ok, thanks for help.
So it could make sense if I am planning to use OpenVPN to make it listen to LAN interface an make a NAT rule from WAN to LAN for this special port.
This will make sure that snort can see and inspect the traffic which connects to the OpenVPN port on LAN interface but will not generate so much alerts as it would do when running on the WAN interface. Right? -
Ok, thanks for help.
So it could make sense if I am planning to use OpenVPN to make it listen to LAN interface an make a NAT rule from WAN to LAN for this special port.
This will make sure that snort can see and inspect the traffic which connects to the OpenVPN port on LAN interface but will not generate so much alerts as it would do when running on the WAN interface. Right?Yes, running Snort on the LAN will not generate as many useless alerts (where "useless" means Snort alerted on something the firewall is going to block anyway). I prefer to run Snort on the LAN side in a home environment. In a commercial setup with public-facing services like HTTP and/or SMTP, etc., I would run Snort on the WAN. But I would only enable the rules specifically needed to protect those public-facing assets. For instance, if it's a SMTP server only, then you don't need any HTTP rules.
This part of your question confuses me a bit, though –
…make a NAT rule from WAN to LAN for this special port...
All you will need to do is allow inbound UDP port 1194 for OpenVPN. I don't think you need any manual port forward rule. The OpenVPN setup itself will take care of the routing for you.
Bill
-
In general I will Open port UDP/1194 on WAN and make OpenVPN listen to this port on WAN interface. But then snort will not see traffic on this interface (WAN) because it is only running on LAN.
So my Idea was to make OpenVPN listen to the LAN interface and port 1194 and to make it possible to access the service from the WAN I create a PortForwarding WAN–>LAN.
And then snort (running on LAN) will be able to inspect the OpenVPN traffic arriving on LAN/udp/1194. -
You don't need to do that. When you define the OpenVPN server setup, you specify what net blocks o the firewall VPN clients will have access to. So long as a Snort instance is listening on those net blocks (interfaces), your VPN traffic will be inspected. Typically the LAN is the net block VPN clients have access to.
By the way, I fixed my typo in the VPN UDP port in my original post.
Bill
