Snort doing too much work? [RESOLVED]
cruiseplanners last edited by
Hi, I'm new to these forums and relatively new to pfSense. I have Snort installed and set up and working on my external WAN interface. Via the firewall rules, I only have a select number of protocols/ports open to the public. If I look at the Snort alerts, it seems that Snort is processing/blocking ALL traffic that could potentially be going through the interface. Tons of stuff that would never make it through the firewall anyways. Is there any way to make Snort smarter and not have it do all that work? It seems a waste of CPU for it to be constantly monitoring all of these things that could never cause any problems. I want pfSense to be as lean as possible so that when it needs the CPU for important things, it's not bogged down trying to inspect and block things that can't possibly happen. Any insight/help will be appreciated. Thanks.
bmeeks last edited by
Snort and Suricata both put the interface they monitor into promiscuous mode. This means all traffic is monitored. Also, both IDS packages use the libpcap library to get a copy of packets traversing the monitored interface. The libpcap copy happens before any firewall rules are processed, so it is currently unavoidable that all traffic on the interface is inspected by the IDS even if the traffic is later blocked/dropped by a firewall rule.
mer last edited by
Snort has a different mandate than firewalling. Lots of folks make good arguments about not running Snort on your firewall. One advantage of it is Snort can insert rules into the firewall when it detects bad things happening, but as noted the cost is promiscuous interface and processing every packet. I don't know if there are thin clients that could react to Snort events and insert rules (that would let you run Snort on a different machine, reducing load on your firewall).
If you set up your firewall as default deny (the default case on pfSense WAN interface I think) you are ahead of the game and Snort isn't buying you much (mostly just notification that something bad may be happening).
My opinions only.
Cmellons last edited by
"Snort and Suricata both put the interface they monitor into promiscuous mode. This means all traffic is monitored. Also, both IDS packages use the libpcap library to get a copy of packets traversing the monitored interface. The libpcap copy happens before any firewall rules are processed, so it is currently unavoidable that all traffic on the interface is inspected by the IDS even if the traffic is later blocked/dropped by a firewall rule."
I agree Bill.
(to the original poster)
I think that most of us are happy that our IDS's work this way because it really does catch some traffic that would otherwise slip through whether it's an application that you are using and maybe it wants to phone home to hook you up on their special botnet or something as simple as multiplayer games in which you are required to open certain ports which will then sometimes allow undesirable traffic to get through, especially if there are cheaters on the servers and they run trainers which are in most cases, just Trojans that alter memory and unfortunately it can affect people that they are playing with such as you or me because unfortunately them getting an advantage, to them requires you to have a disadvantage and that can sometimes mean that packets will be altered before they get back to you. That's my thoughts on it and I really love the way that Suricata works. You just have to tame the beast so to speak and there is a nice tutorial on that if you happen to search for it. Just type, tame the beast and you should see a post tutorial about suricata.
cruiseplanners last edited by
Thanks for all of the replies. I was able to actually resolve this issue by moving Snort to a different interface. I was already bridging my wan interface with an internal interface to be able to use my public IPs directly on my servers. I moved Snort to the internal bridged interface instead of the external one (the wan) and left the firewall rules set up on the external interface. The firewall on the external interface prevents any unwanted data from entering and ever making it to the internal interface. Snort therefore no longer sees all of this garbage traffic. I tested the whole setup by opening up the firewall on the external interface and watching all of the Snort alerts fly in. As soon as I re-enabled the firewall, the alerts stopped. My CPU load has been reduced by almost 75% as a result of this. If you are using a similar setup, you may want to consider doing this as it seems to help quite a bit.