Snort alerts problem.
-
I've noticed that SNORT processes traffic but some alerts do not appear on alert list. I only noticed that because I was running SNORT in inline mode and could not SSH to a server on WAN. I found the rule that was dropping traffic and switched action to Alert. Alert still won't appear on alert list. Then I switched SNORT to legacy mode. Same thing , alert won't appear on alert list.
In this particular case rule was
-
I can only think of a few things, offhand. Alert being suppressed, or something else doing the block. Yo mentioned you found the rule that was dropping traffic... But without an alert, was this in a log? What confirmed that this rule actually fired and blocked.
-
@tzvia
Suppressed rule should not drop traffic or create an alert.
Log was empty. I had to look at rules one by one, until I found one that was dropping traffic.
After rule was disabled I was able to SSH. -
@murzik said in Snort alerts problem.:
I've noticed that SNORT processes traffic but some alerts do not appear on alert list. I only noticed that because I was running SNORT in inline mode and could not SSH to a server on WAN. I found the rule that was dropping traffic and switched action to Alert. Alert still won't appear on alert list. Then I switched SNORT to legacy mode. Same thing , alert won't appear on alert list.
In this particular case rule was
How many Snort interfaces do you have configured? You do realize that on the ALERTS tab it filters by configured interface. Second issue can be if you have lots of alerting traffic the log file can be rotated. The ALERTS tab only shows data from the currently active alerts log for the selected interface.
-
@bmeeks
I have SNORT running only one interface LAN. I do realize that alerts are filtered by interface. Trust me, took some time to found rule causing traffic to drop. No alert was logged by SNORT, but traffic was dropped. In this case that is very easy for you to test. Enable the rule and try to SSH to remote server. The rule is part of ET Open Rules, emerging-scan.rules -
@murzik said in Snort alerts problem.:
@bmeeks
I have SNORT running only one interface LAN. I do realize that alerts are filtered by interface. Trust me, took some time to found rule causing traffic to drop. No alert was logged by SNORT, but traffic was dropped. In this case that is very easy for you to test. Enable the rule and try to SSH to remote server. The rule is part of ET Open Rules, emerging-scan.rulesThat is a special type of rule. It is an OUTBOUND scan rule designed to detect internal hosts doing an SSH scan to an external network (actually, it is looking for an internal host trying to "brute force" an external host). Because it is a scan rule, it has some unusual threshold parameters set within it. It needs to see 5 attempts over a period of 120 seconds to "fire" and generate an alert. Here is the complete rule text:
alert tcp $HOME_NET any -> $EXTERNAL_NET 22 (msg:"ET SCAN Potential SSH Scan OUTBOUND"; flags:S,12; threshold: type threshold, track by_src, count 5, seconds 120; reference:url,en.wikipedia.org/wiki/Brute_force_attack; reference:url,doc.emergingthreats.net/2003068; classtype:attempted-recon; sid:2003068; rev:6; metadata:created_at 2010_07_30, updated_at 2010_07_30;)Look at the rule text and you can see what I mean.
-
@bmeeks Even so, the question remains, why traffic was blocked without alert being generated?
-
@murzik said in Snort alerts problem.:
@bmeeks Even so, the question remains, why traffic was blocked without alert being generated?
I don't know unless it has something to do with the way Snort works internally (I'm talking about the binary and not the PHP GUI package). When you run with Inline IPS Mode, that is totally under the control of the Snort binary. Perhaps the thresholding is only being applied to the logging side and not the alerting side. Granted that would not be logical, so it might also be a bug in the Snort binary itself. That question would have to be asked over on the Snort mailing list thread. But to get a good answer, you would not need to mention pfSense at all. Just say you are running Snort using Inline IPS Mode on FreeBSD and "blah blah blah". If you mention pfSense, they will just refer you back to here, and hence you enter a loop.
Legacy Mode Blocking uses a custom output plugin I wrote, but it hooks itself into Snort as a Logging plugin. So ostensibly that should mean my custom plugin only gets alerts that have "fired". It should not be seeing rules that have not met their thresholds, and thus should not block.
Just set that rule to ALERT (if using Inline IPS Mode) and you're set. If using Legacy Mode, disable that particular rule if the blocks are a nuisance.
