Snort alerts do not trigger block [Solved]
-
Hi,
first of all: snort was working like charm for months without any issues.
Last week I stopped the service due troubleshooting some connectivity issues that was not caused by snort. After location of the issue, I started snort again, but since that startup its not blocking the alerts comming up. The block offenders option is still checked and active. There were no changes done at all concerning to the snort configuration.
I restarted/killed/reinstalled snort dozens times.
Flowbit warnings are the only ones at the logfile, the service itself is starting/stopping properbly - lists are u2d and traffic becomes checked by snort (e.g when I am performing a download mit max bandwidh I see the cpu-load of the snort process). Alerts are beeing logged (just the amount of listed alerts seemed higher before).2017-08-30 03:44:18 ET TOR Known Tor Relay/Router (Not Exit) Node UDP Traffic group 197
Just no blocks..
I thought, well maybe a general issue and tried to reproduce this behavior at another system with same configuration, but its working there without any issues?!
Snort version: 3.2.9.5
pfsense version: 2.3.4-RELEASE-p1 (latest stable)Hope you've some hints for me :-)
Thanks in advance!
-
Is it possible one of the IP addresses in the alert is now in a Pass List? Snort will always automatically whitelist all of the interface IP addresses on the firewall. You did not provide the entire alert message from the ALERTS tab. What IP addresses were shown in the alert that was logged but did not block? Please post the full alert message.
What exactly was the "connectivity issue" you were troubleshooting? Perhaps its resolution is related to what you see now with Snort. Did any interface names or IP addresses change?
Bill
-
Hi Bill,
thank you for your answer.
What exactly was the "connectivity issue" you were troubleshooting? Perhaps its resolution is related to what you see now with Snort. Did any interface names or IP addresses change?
The "connectivity issue" was caused by a accidental change of the configuration from one of mine remote vpn (IPsec) endpoints. So no influence to the pfsense instance that shows up the "non blocking issue. Also there were no changes proceed with the view onto IPv4/v6 addresses and interface names.
You did not provide the entire alert message from the ALERTS tab. What IP addresses were shown in the alert that was logged but did not block? Please post the full alert message.
all kinds of alerts that come up are not beeing blocked. For me it seems like that even the amount and varity of alerts is much less than before. For example:
2017-08-30 15:56:27 2 TCP Misc Attack 82.146.62.226 57519 $WAN-IP 3390 1:2403408 ET CINS Active Threat Intelligence Poor Reputation IP TCP group 55 2017-08-30 16:00:03 2 TCP Misc Attack 101.79.44.115 46088 $WAN-IP 22 1:2500000 ET COMPROMISED Known Compromised or Hostile Host Traffic TCP group 1 2017-08-30 16:01:29 2 UDP Misc Attack 176.9.1.211 123 $WAN-IP 34651 1:2522393 ET TOR Known Tor Relay/Router (Not Exit) Node UDP Traffic group 197All these IPs are not listed at the pass-list/whitelist. At this pass-list/whitelist there are just about 12 WAN hosts/servers from different AS included, where I do not want to get blocks/false pos.
And its very weird that not even SSH-login attempts/scans/brutes are beeing alerted as it was before. Mostly just "misc attacks" of category 2 are beeing alerted.Before (about a week ago)
08/20/17-09:47:45.270083 ,1,2019876,2,"ET SCAN SSH BruteForce Tool with fake PUTTY version",TCP,116.31.116.33,61256,$WAN-IP,22,22054,Detection of a Network Scan,3, 08/20/17-09:48:43.126437 ,1,2001219,19,"ET SCAN Potential SSH Scan",TCP,58.218.198.146,21978,$WAN-IP,22,54759,Attempted Information Leak,2, 08/20/17-09:49:08.536635 ,1,2001219,19,"ET SCAN Potential SSH Scan",TCP,116.31.116.33,52040,$WAN-IP,22,63031,Attempted Information Leak,2, 08/20/17-09:52:56.035124 ,1,2010935,2,"ET POLICY Suspicious inbound to MSSQL port 1433",TCP,123.249.94.29,49638,$WAN-IP,1433,40716,Potentially Bad Traffic,2,But surprise.. today the very first block within a week was beeing listed:
1 2a00:1450:401f:1f::b (portscan) UDP Filtered Portscan -- 2017-08-30 16:35:28Following the alert to that triggered the block:
2017-08-30 16:35:28 2 Attempted Information Leak 2a00:1450:401f:1f::b 2001:470:1f0b:dead:beef::1(client host inside the LAN network) 122:21 (portscan) UDP Filtered PortscanBest greetings
-
A change in the number of alerts from one time period to the next is not much to worry about. Maybe the "bad guys" just lost interest for a while.
From your last comment, it appears that you are getting block results now (at least one so far). The package code seems fine. I have loads of active blocks on my home firewall, and I'm sure there would be lots of chatter here if Snort was not blocking for a large number of users. Something weird may have happened to the configuration of that particular firewall.
Bill
-
Hi Bill,
I guess I found the issue(s):
about a year ago I temporary configured a IPsec-VPN tunnel that routes all traffic through the site (ANY). This VPN wasnt active anymore, just disabled.
@the snort interface and the home-net list there was "0.0.0.0/0" included. After removing this inactive tunnel Snort started blocking close to normal again.During the investigation I also activated "Sourcefire OpenAppID Detectors" and checked "Enable RULES OpenAppID" together with "Application ID Detection preprocessor" without paying attention to the ruleset that needs to get activated @ the WAN-Categories of its assigned snort interface. This reduced the amount of alerts massively, Portscans for example where not been detected. After correcting this(disable and or adding the ruleset) everything was running as usual.
Thanks for your help!
-
Glad you found the issue. That 0.0.0.0/0 network in the pass list would prevent blocks. That's why you got no IPv4 blocks but got an IPv6 block. That IPv4 net block would of course match any IPv4 adress, so Snort would think all IPv4 addresses were on the pass list.
Bill
