(Snort) swap_pager_getswapspace(13): failed
-
@rloeb Did you disable rulesets you arenโt using? Such as web server rules if youโre not hosting a web server.
Add RAM?
-
You never want to be using swap as performance then totally tanks.
For starters, you do not need the Snort GPLv2 Community Rules at all if you are using the Snort Subscriber Rules. The Community Rules are already contained within the Subscriber Rules. So remove the Snort GPLv2 Community Rules from your configuration.
How many total rules do you have enabled? Most folks tend to way "over enable" when using Snort, especially in a home network. Analyze the actual vulnerability exposures on your network, then only enable rule categories and rules that cover those vulnerabilities. If you do not have an email server, public-facing DNS or web servers, then you do not need any of those rule categories enabled. 4GB of RAM is enough to run a properly configured Snort instance (where properly configured means using carefully selected rules for inspection).
You also have pfBlockerNG-devel installed. Are you by chance using the DNSBL option with Python with that package? It can also be memory hungry with large blacklists in operation. Is pfBlockerNG-devel's update cron task colliding with Snort's rules update? If so, that can push RAM consumption over the edge.
-
@bmeeks Thank you. Been in this business long enough to appreciate why "swap" is a no-no :-)
The person who originally configured this device chose a "balanced" IPS policy and I never looked at the choices. Now that I have, the choices are daunting! Now I need to some real research to identify which rulesets we really need. We don't run a mailserver or a webserver or a public-facing DNS,
Went through a bunch of your posts and changed IPS Policy from "balanced" to "connectivity," rather than having to figure out what each ruleset does :-)
Unsure of the relationship between "enabling download" on Global Settings and "connectivity" on individual LAN interfaces. Have no idea what OpenAppId detectors is about, but notice it's checked for download and left it alone. ETOpen and FEODO Tracker rules are also checked. Left them alone.
Took Snort off the WAN, although that makes me nervous. It has been blocking some inbound responses to web requests based on various rules that indicate an untrustworthy server. I need to watch what happens and review that decision.
And, yes, we are running DNSBL with Python. Takes mucho memory, although the memory usage gradually declines over time. Uses a bunch after reboot; about half as much several hours later.
I run a small consulting company that is increasingly being dragged into the "cybersecurity" world. Ugh. I have no idea how most small businesses can afford the expertise they need to protect themselves! We have long recommended that they never host their own website. Now I'm not sure they should even run their own LAN!
Rog
-
@rloeb Snort on WAN will scan all packets reaching the router, even if they will be dropped by the firewall. Snort on LAN will only scan packets making it through NAT, or outbound connections. Typically one doesn't need it running on both.
Does this router have any inbound NAT port forwards? If no, that should allow unchecking many of the rules. Basically, figure out what are you protecting, and use those rules.
Note nowadays most outgoing connections are HTTPS or encrypted which can't be scanned anyway. So if there aren't any inbound connections, Snort may not even be that helpful.
-
@steveits Thank you. I appreciate any advice I can get! I'm definitely in over my head.
Occasionally we need to open a port forward, but we tend to do that only for a specific purpose, require strong authentication., and shutdown the forward as soon as practical.
My broader concern is understanding which rules deal with what classes of threats. There are a LOT of rulesets, and they have interesting names, but there's nothing that explains what action they take unless you read each rule. The biggest threat we deal with is a malicious web site that someone ends up on. Worst case being guests on our wifi network.
Rog
-
@rloeb Yep, "click em all" functions but is overkill for most cases.
Guests should be on their own network for that reason. :)
-
The "Connectivity" policy is a good all-around policy that balances CPU and memory resource utilization with security.
OpenAppID is Snort's version of Layer 7 application filtering. Enabling that option is really only useful if you actually want to prohibit certain kinds of applications -- most notably social media stuff. But to use OpenAppID effectively you really need to also be using Inline IPS Mode for blocking and not Legacy Mode Blocking. Legacy Mode is too big of a hammer and entirely blocks an IP address, while Inline IPS Mode only drops the precise offending packets.
The GLOBAL SETTINGS tab is where you enable which rule archive gzip files will be downloaded from the respective creators (Snort VRT, Emerging Threats, etc.). Those gzip archives are download, unzipped, and stored in a common directory.
On the INTERFACE SETTINGS tab for a given Snort instance, the CATEGORIES tab is where you can select which categories of rules from those downloaded archives you want to use on a particular interface. The IPS Policy setting is a way to make life simpler by using the built-in metadata tags that the Snort/Cisco Vulnerability Research Team adds to their rules to associate them with a policy. Emerging Threats does not have that metadata, so you can't automatically select those rules based on a policy.
The RULES tab for an interface is where you can be even more selective and enable or disable the individual rules within a pre-defined category. Those categories are created by the rule authors and represent collections of rules that address similar threats.
Lastly, run Snort (or Suricata) on internal interfaces such as the LAN, DMZ, GUEST, etc. No need to run it on the WAN. Nothing can get to an internal host without traversing an internal interface, so having Snort running there is sufficient. Plus you can more accurately tune the rules for the vulnerabilities existing behind that specific internal interface. You don't need Snort to protect the firewall, and that's essentially what it is doing if you put it on the WAN. Unless your WAN rules are creating a firewall more full of holes than Swiss cheese, then you don't need an IDS/IPS on the WAN.
And one more comment -- I will reiterate what someone mentioned up above. Almost all network traffic today is encrypted, so unless you have a proxy with man-in-the-middle interception of encrypted traffic, Snort is seeing almost nothing in terms of actual payload data. It can only see the little bit of info available in the IP headers and something like SNI. End-to-end encryption is killing IDS/IPS. Much more effective to put intrusion detection/prevention down at the local host level so it can see the traffic after it has been decrypted.
-
@bmeeks Again, thank you for the advice and for your expertise, which is very much appreciated. I particularly note the observation that encryption makes a lot of rules irrelevant, e.g, AppIdDetectors.
Intrusion detection at the host level is very difficult to manage in a distributed organization where we don't control the hardware and device software. (I don't have employees; I have independent contractors who are engaged for a specific assignment. When they do come to our office, they connect to our network. Yes, they belong on a separate network, but they are in the office to access internal resources...)
-
@rloeb said in (Snort) swap_pager_getswapspace(13): failed:
@bmeeks Again, thank you for the advice and for your expertise, which is very much appreciated. I particularly note the observation that encryption makes a lot of rules irrelevant, e.g, AppIdDetectors.
Intrusion detection at the host level is very difficult to manage in a distributed organization where we don't control the hardware and device software. (I don't have employees; I have independent contractors who are engaged for a specific assignment. When they do come to our office, they connect to our network. Yes, they belong on a separate network, but they are in the office to access internal resources...)
Totally understand about the BYOD (bring your own device) scenario. It does make effective cybersecurity difficult. But one thing you can do is make sure your local servers and any local desktops are always up to date with security patches and run some kind of anti-virus client. The default Microsoft stuff is fine in my view. There are more sophisticated approaches to host security that involve third-party installed software products such as Event Viewer log watchers, etc.
I worked for a Fortune 500 corp (electric utility) and we managed that by having our own managed desktops we provided for contractors to use while onsite performing work. So we did not implement a BYOD. There was a totally separate guest network for their private mobile devices (mostly phones), but that network had no access to company resources -- only direct to the Internet.
I realize not all companies can do that, though. So you make the best of the hand you are dealt.
-
@bmeeks We do a lot of work for [unnamed] clients who highly value the security of their information. My consultants are very attuned to those requirements, so I have little concern about their device healthcare. We have very few other visitors, so I didn't pay much attention to who was on the wifi until I discovered that the janitorial service phones were connecting. Now we have a separate guest wifi, direct to Internet on a separate circuit.
pfsense seems much happier since I took Snort off the Wan and cutback severely on the rulesets being used on the LANs.
My wife works for one of those companies that provides the hardware and controls the software. They're still running Win7! They offered to put their access software on her phone, but she would have to sign a document that basically gave them ownership of the phone. Hah!
I, too, think the current Windows Defender does a pretty good job. We happen to have a long term subscription for Malwarebytes, so we stick with it, at least for now. The Linux boxes run ClamAV. None of those are exposed outside the firewall.
Thank you, again, and SteveITS. You saved me a lot of wasted time and a significant addition to my collection of gray hairs!
Rog
-