WAN Interface has to be manually restarted each day
-
The instance itself would stop. It wouldn't run and the rule set would show fail on update. If I manually run it, it would start and if I forced a rule update, it would work.
I checked the logs as you recommended. The only thing I could see were entries where Snort was "killed: out of swap space." I tried to research this and from what I could find it sounds like it was out of memory. I only had it and pfBlocker running. I removed the pfBlocker package to free up memory. Hopefully the Snort interface will continue to run without stopping now. Feel free to let me know if you disagree with the steps I took. Thanks for your help.
-
That means you do not have enough free RAM to run all the stuff you have enabled. Snort can use a lot of RAM, especially when you enable lots of rules. How much RAM is in your firewall? You really need an absolute minimum of 2 GB to run Snort, and really you should have 4 GB or even 8 GB to run it comfortably.
Snort's RAM usage will increase during the automatic rule updates. Since you say it dies overnight and logs the swap error then, that tells me it was performing a daily rules check.
Both of the IDS/IPS packages require tuning of the enabled rule sets to be practical. Don't just go through and enable everything. Choose the rules you enable carefully. You want to provide protection only for the actual risks (vulnerabilities) in your internal network. For example, most users do not have public-facing DNS, mail, or web servers. So that means you don't need to enable any of those rules as they are looking for threats to things that do not exist in your network. There are other examples as well of rule categories that probably should not be used in most networks (especially home networks).
Finally, remember that unless you run a proxy setup with full MITM (man-in-the-middle) SSL interception/termination, then Snort does not really do a whole lot because it cannot inspect encrypted traffic. And the vast majority of all network traffic today is encrypted. Web traffic is almost exclusively HTTPS (encrypted over SSL), email is pretty much always sent encrypted over TLS, and even DNS traffic is increasingly moving to encryption with either DoT (DNS over TLS) or DoH (DNS over HTTPS).
-
@coffeeman what hardware are you trying to run Snort on?
-
I am going to guess you're running this on an 1100. That's a horrible plan -- the 1100 has only 1GB RAM and only can use the eMMC storage. Running things on it that require heavy logging and file writing (IDS/IPS, Proxy software) requires a dedicated SSD -- which the 1100 cannot use.
There are definitely ways around the writing to the eMMC issue but they will either carve up your RAM for a RAM disk or will result in zero logs to reference. Neither is a good idea.
-
Yeah, it's the 1100. I had no idea at the time I bought it the amount of space that an ids/ips would take up.
-
@coffeeman I would first search this section of the forum to see who has done this with an 1100 and then see how they did it.
You absolutely have to disable the logging part of the package (for both snort and suricata) or you will burn through your eMMC's lifespan of writes in less than 180 days -- no joke. I see it often in TAC and it's not a warranty replacement item, either. The eMMC cannot be fixed or replaced.
You can do some off-device logging if you know how to set up a syslog on another system. The RAM is another issue altogether and I don't know how you're going to get around that one.
-
If I'm willing to eat the cost of the 1100 and purchase another router, what would be the best one to get? I need it for home use, but I believe I was the victim of a dns tunnel attack, which is why I downloaded Snort. The attacks kept bypassing the firewall. As soon as I had Snort, the attacks seemed to stop.
-
@coffeeman The 2100 would do the work and could have an mSATA drive in it for logging -- that would be a help but it only has 2GB RAM.
The 4100 has 4GB RAM but the base is also an eMMC. You'd need/want the MAX to get the NVMe storage for log writing/retaining. You could do the zero-logs or log to RAM disk easily on the 4100.
Then there's the 6100 with 8GB RAM (still need to get the MAX here for logging) and the new 8200 as well. The 8200 only comes in the MAX model and is a bit of a sports car but has 16GB RAM. Overkill, most likely for your needs, but would do the job really well.
The last part to consider is what your internet connection speed is.
The general max throughput without IDS on those models starts at about 400mbps on the 1100, 600 on the 2100, and a hair under 1Gbps on the 4100 over the ix ports or 1.5 or so (an estimate, not personal experience) on the igc (the 2.5gbps LAN) ports.
The 6100 and 8200 speeds I don't have experience with and the one 4100 I've used was a setup for a family member so not one I've used much directly.
-
To cut down on the logging of typical Internet "noise", run IDS/IPS instances on your LAN and not on the WAN. The default firewall setup will generally drop unsolicited inbound traffic on the WAN already, so why waste Snort's time inspecting traffic that the firewall is likely to drop? Also, putting Snort on the WAN exposes it to all the typical "noise" which will trigger rules and cause them to log alerts. But nothing is really accomplished there if your firewall denies unsolicited inbound traffic anyway. Snort just inspected and alerted on traffic the firewall will drop, so what would be the point?
To illustrate, here are two diagrams that show where Snort is positioned in the network traffic path. Notice that in both operating modes (Legacy Blocking and Inline IPS) the IDS/IPS is on the NIC side of the firewall engine.
You can run Snort on an SG-1100, but you must be VERY selective and frugal with your rules selection. You can't enable many rules. Probably just a few hundred tops.
-
Thank you both for taking the time to review the problem and for not making me feel stupid for asking my question. You both have made some good suggestions here. I'm going to take them all into consideration and figure out what my next steps. Thanks again!