[Snort] Possible flaw in ET rules and IPS Policy Security
-
Hey Guys,
I've noticed that Snort stops working when the following rule, either by itself or with other emerging rules and on either WAN or LAN interfaces, is applied to a IPS policy 'Security':
emerging-trojan.rules
Seems to work without any problems with other IPS Policies, i.e. Connectivity and Balanced
Global Settings:
Snort VRT rules ENABLED
Snort GPL rules ENABLED
Emerging Threats ENABLED
FEODO Botnut Rules ENABLEDLAN Settings:
Block Offenders ENABLED
IPS Mode LEGACY
Kill States ENABLED
Which IP Block BOTHLAN Categories:
Use IPS Policy ENABLED
IPS Policy Selection SECURITY
Snort GPL Rules ENABLED
FEODO Botnet Rules ENABLED
ET Open Rules -> emerging-trojan.rulesIt could be a security flaw as it disables Snort on that interface. Looking for some feed back before I submit as a bug.
TIA.
-
@ASGR71 said in [Snort] Possible flaw in ET rules and IPS Policy Security:
I've noticed that Snort stops working when the following rule
Which rule? You did not specify the signature ID (SID). All I see is a category name, but that category file contains many rules.
What errors are you seeing in the pfSense system log when Snort quits working?
What kind of hardware are you running Snort on? Using the 'Security' IPS policy loads the most rules. You might simply be running out of free RAM.
-
@bmeeks Thanks for your reply.
It's running on an 1100.
This is the output from the logs...
May 27 16:02:49 php 21847 /tmp/snort_mvneta0.4090_startcmd.php: The command '/usr/local/bin/snort -R _9897 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_mvneta0.40909897 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 9897 -c /usr/local/etc/snort/snort_9897_mvneta0.4090/snort.conf -i mvneta0.4090' returned exit code '9', the output was ''
May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory
...
May 27 16:00:28 snort 38637 +++++++++++++++++++++++++++++++++++++++++++++++++++
May 27 16:00:28 snort 38637 30643 Option Chains linked into 1413 Chain Headers
May 27 16:00:28 snort 38637 291 preprocessor rules
May 27 16:00:28 snort 38637 153 decoder rules
May 27 16:00:28 snort 38637 30199 detection rules
May 27 16:00:28 snort 38637 30643 Snort rules read
May 27 16:00:12 snort 38637 WARNING: /usr/local/etc/snort/snort_9897_mvneta0.4090/rules/snort.rules(507) threshold (in rule) is deprecated; use detection_filter instead.
May 27 16:00:12 snort 38637 Initializing rule chains...
May 27 16:00:12 snort 38637 +++++++++++++++++++++++++++++++++++++++++++++++++++ -
If you are running on an SG-1100, then my first suspicion is you are simply running out of RAM. Snort can eat a lot of memory, and the more rules you enable the more memory is required. As I mentioned, the "Security" IPS policy enables the most rules out of the policy selections. So, not really surprised that is causing you problems. Adding in those ET rules probably is the last straw that is breaking the camel's back in terms of memory usage.
You need to use a lean and mean rule set on an SG-1100 due to the very limite amount of RAM.
-
@bmeeks Thanks again B. I'm currently running 'Security' Policy with Snort VRT, Snort GPL, FEODO and 12 other ET rules sets and all is fine. Processor fluctuates between at 9 and 53% and RAM at 76%.
As soon as I enable 'emerging-trojans.rules', with the above, it will eventually fail on next update/reload or manual restart.
For future reference and as a process of elimination, I turned everything off except for Snort VRT to keep the IPS Policy Option and all is running OK. Processor fluctuating between 11 and 52% and RAM 68%
Again, adding 'emerging-trojans.rules' to just the Snort VRT rule set results in a failure to start the interface.
I did have Snort setup in the first paragraph, without the problem rule set, running along side pfBlocker without any problems.
I'll try a factory reset in the near future and see if that makes any difference...
-
You could have too many rules enabled, I learned the hard way you want to only use 50 percent of you memory under no loads, or else the system will start to disable things to free up memory. I use snort ET and subscriber rules with a key for the free version, and that's it plus manual et rules 3Com rules. Anymore for the 4GB memory just boggs it down.
-
@ASGR71 said in [Snort] Possible flaw in ET rules and IPS Policy Security:
I did have Snort setup in the first paragraph, without the problem rule set, running along side pfBlocker without any problems.
That's asking a lot of an SG-1100 with its limited RAM.
When you enable the ET-Trojans rules, what kind of error is logged in the pfSense system log when Snort crashes?
@ASGR71 said in [Snort] Possible flaw in ET rules and IPS Policy Security:
I'll try a factory reset in the near future and see if that makes any difference...
A factory reset is unlikely to make any difference with Snort. In my opinion that will be wasted effort.
-
May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memoryMay 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory
Can be pointed to the storage space and/or
the amount of ram.
