Snort not starting anymore
-
You have a typo in the rule on line 264 of the snort.rules file. That beginning phrase of 'referalert' is the problem. The line should start with just 'alert' and then the rest of the rule. You are using NanoBSD, and that can be problematic with memory and disk space (since disk space is part of memory). It's easy to run out of temp space during some of Snort's configuration generation. Not saying that is for sure happening to you, but it is a definite possibility. That error means something is getting corrupted during the snort.rules file creation process.
I recommend that folks do not run Snort or Suricata on NanoBSD installs.
Bill
-
Ugh…disappointing answer to say the least. But thanks for the heads-up.
My file system seems to be free enough I got 38M of free space right now, 2GB of RAM....in any case, given that CF cards aren't that expensive is there a plan for 8G or 16G nanobsd images, to accomodate this kind of issue?
In the end though, if snort can't run reliably on nanoBSD maybe the package should give a warning or not be available. My 2 cents.
-
I asked for bigger nano images some time ago, answer: no.
I run snort for some years now on nano installs, what counts is the amount of RAM. With 1 GB it works fine for 1-2 interfaces, with 2 GB for 3 interfaces was no problem. But it takes really long for a rules update and sometime snort gets killed running out of swap space.
Increase /tmp size (750 MB? whatever you can afford…) under System/Advanced/Misc, that's essential to startup snort reliably!
4 GB RAM is cool. Or switch to a full install on SSD. Shortens updates of rules from 20-30 min to 3-4 min, on the same Atom board, no joke... ;-)
-
4 GB RAM is cool. Or switch to a full install on SSD. Shortens updates of rules from 20-30 min to 3-4 min, on the same Atom board, no joke… ;-)
I guess I can first try to update to 4GB, that seems like a painless upgrade.
Although I only have one interface right now, and 2GB of RAM, so I shouldn't have an issue according to your experience.
Besides losing the benefit of having dual images, any downsides to using the normal pfSense install?
-
Did you read my update (completely forgot about this… :-) )
"Increase /tmp size (750 MB? whatever you can afford...) under System/Advanced/Misc, that's essential to startup snort reliably!"
If you are there, increase /var to... lets say... 350 MB... :-)
Then it should run smoothly...
One interface? But not WAN! More important is LAN. WAN is optional, especially if you have none of the usual suspect ports open on WAN, or?
-
"Increase /tmp size (750 MB? whatever you can afford…) under System/Advanced/Misc, that's essential to startup snort reliably!"
I somehow missed that! I can confirm my swap space was filled up during rules update, I made sure to look closely during a rules update. What you suggested seems to have fixed my issue. Great, and thank you!!!
As for which interface I am using, I am just trying to figure out Snort at this point, so I consider this more of a proof-of-concept than a production feature at this moment, so yes I am using WAN. That being said, it's also a remote data-center sort of setup, where there are no PCs and only a few servers (usual suspects: mail, web…). It felt WAN was the right thing to watch. Wrong?
I realize on a "normal" network with clients browsing, LAN is probably more of an issue.
-
All the experts say: WAN only with reduced rule set (and if you have no ports open on WAN it will make nearly no sense at all!), but watch LAN/OPT closely, in case same infection etc. wants to "phone home"…
-
All the experts say: WAN only with reduced rule set (and if you have no ports open on WAN it will make nearly no sense at all!), but watch LAN/OPT closely, in case same infection etc. wants to "phone home"…
That makes a lot of sense, thank you
-
If your are testing snort, maybe you should skip the "block for 1h" part for "offenders" or reduce to some minutes.
There are sometimes false alarms (http inspection rules, VPN tunnel kills or smtp protocol inspection, but also other stuff) and then it can be really frustrating for your users, if your servers kicks them out for one hour (and you start debugging and finally and in the end find snort has fired them from the clear blue sky).
Just a suggestion, keep an eye on this snort guy ;-)
-
If your are testing snort, maybe you should skip the "block for 1h" part for "offenders" or reduce to some minutes.
I'm already aware of how much false positives there are. Let's say my new modus operandi is to add myself to the exclusion list first and foremost ;-)
