Snort Brings Network to Crawl
-
Howdy folks!
I'm running a Netgate SG-3100 in my SOHO network. I have a self-owned modem that connects to my ISP, then connects to the WAN port on my SG-3100. I have a 1 Gbps connection.
I've tried to get Snort up and running before, but I continue to experience an unusual issue where after several days of Snort running, I notice that my network will slow to a crawl. Turning the Snort service off returns the network to normal operation. It will seem fine for roughly two days before the issue happens again. I recently watched a tutorial from Lawrence Systems (YouTube) and I've read the pinned guides at the top of this forum. I have also paid for an oinkcode.
Snort is enabled on my WAN interface only. I have it set to USE IPS Policy, Balanced mode. It is set to blocking mode, and currently only four hosts are blocked.
I'm happy to provide any further information that is needed. Just looking for guidance on the best way to determine if it is, in fact, the Snort service causing the issue; and if so, what's the best way to approach troubleshooting so that I can resolve it and continue using the Snort service.
Thanks in advance!
-Andy -
I suspect you are hitting a RAM limit. The IPS Balanced Policy will load up quite a few rules, and the 2GB of RAM installed in an SG-3100 is not a lot.
I would cut back to the IPS Connectivity Policy in Snort. That is plenty secure enough for any home office or even most small offices.
And by the way, you want to run Snort on your LAN and not the WAN. The WAN side of the firewall is going to block all incoming unsolicited traffic anyway (assuming you don't have open port forwards), and so putting Snort out in front of the firewall is sort of pointless. It is just going to block what the firewall was going to block anyway. The Snort process sits between the NIC driver and the firewall engine. So that means packets come off the NIC, enter Snort, and then go to the firewall for handling. This is true for any interface Snort runs on.
Another advantage of putting Snort on the LAN is that the IP addresses of local hosts in the alerts log will be "correct". When you run Snort on the WAN, because Snort exists outside the firewall engine and just before the physical NIC driver, all the LAN host IP addresses will show up in the alerts after NAT is applied. Thus all of your LAN hosts will appear in the alerts tab having the WAN's public IP address. Not very helpful at all when trying to find which LAN host generated some particular alert.
-
Excellent! Thank you so much. I appreciate the explanation.
I will switch it over to the LAN interface and see if that makes a difference. My thought process was that Snort would be stopping potentially malicious traffic from both directions by putting it on the WAN interface.
I was keeping an eye on system resources using the widget on the home page and wasn't seeing any major spikes in RAM usage, but definitely can see the CPU usage spike occasionally. I also logged into SSH and was running htop to see which specific processes were using system resources. Snort would jump up to the high-teens in CPU percentages, but never anything that looked super concerning.
Nonetheless, I'll switch the interface that it's operating on and see how that goes.
Thanks again!
-
@AndyBlak said in Snort Brings Network to Crawl:
Nonetheless, I'll switch the interface that it's operating on and see how that goes.
Thanks again!
Switching the interfaces will have zero impact on your initial reported problem. I suspect something else might be going on to cause the slowdown. I suggested the interface switch mainly to help your alerts make more sense and increase their usefulness by having actual LAN host IP addresses in them.
I would swap to the Connectivity Policy and see if that helps.
One last advantage to putting Snort somewhere besides the WAN is that now your alert logs are not full of all the Internet noise out there that your firewall was going to block anyway.
-
@bmeeks Ah, sorry for my misunderstanding. I'll do that, as well. I turned off the WAN interface, turned on the LAN one, and set it to Connectivity instead of Balanced.
Here's my system resources with those changes:
