Snort - Please help
-
If you hit 100% mem processes will be killed. Check status>systemlogs for terminating processes.
-
That doesn't seem to be the case :
Oct 25 15:45:40 snort[4906]: Snort initialization completed successfully (pid=4906) Oct 25 15:45:40 snort[4906]: Snort initialization completed successfully (pid=4906) Oct 25 15:45:40 snort[4906]: Not Using PCAP_FRAMES Oct 25 15:45:40 snort[4906]: Not Using PCAP_FRAMES Oct 25 15:48:14 snort2c[4909]: attack detected non-whitelisted ip: 194.109.21.230 blocked ! Oct 25 15:48:14 snort2c[4909]: attack detected non-whitelisted ip: 194.109.21.230 blocked ! Oct 25 15:48:14 snort2c[4909]: attack detected non-whitelisted ip: 194.159.164.195 blocked ! Oct 25 15:48:14 snort2c[4909]: attack detected non-whitelisted ip: 194.159.164.195 blocked !the blocked IP's refer to these intrusions :
[ ** ] [ 1:6182:1 ] CHAT IRC channel notice [ ** ] [ Classification: Potential Corporate Privacy Violation ] [ Priority: 1 ] 10/25-15:48:14.827532 xxx.xxx.131.153:65507 -> 194.159.164.195:6666 TCP TTL:127 TOS:0x0 ID:2329 IpLen:20 DgmLen:94 DF ***AP*** Seq: 0x9526AB21 Ack: 0x13230EA5 Win: 0xFFFF TcpLen: 20 [ ** ] [ 1:1729:6 ] CHAT IRC channel join [ ** ] [ Classification: Potential Corporate Privacy Violation ] [ Priority: 1 ] 10/25-15:48:15.093922 xxx.xxx.131.153:65507 -> 194.159.164.195:6666 TCP TTL:127 TOS:0x0 ID:30017 IpLen:20 DgmLen:73 DF ***AP*** Seq: 0x9526AB57 Ack: 0x13230EA5 Win: 0xFFFF TcpLen: 20The IP's are showing as blocked In the "Blocked screen" :
194.159.164.195 CHAT IRC dns responseand yet I'm still merrily chatting away in IRC
The logs show nothing terminating and I am using the "blocked" IPs for IRC AFTER the warning / block.
This is me reloading mirc and rejoining
[ ** ] [ 1:1729:6 ] CHAT IRC channel join [ ** ] [ Classification: Potential Corporate Privacy Violation ] [ Priority: 1 ] 10/25-15:53:56.555003 xxx.xxx.131.153:61684 -> 194.159.164.195:6666 TCP TTL:127 TOS:0x0 ID:12741 IpLen:20 DgmLen:127 DF ***AP*** Seq: 0x19193DC9 Ack: 0x24BFD0BE Win: 0xFFB9 TcpLen: 20The ip is the same one that was banned previously and it was definately showing as blocked at the time, so why am I able to rejoin the server and chat?
What I'm most concerned about is that if it's not blocking that IP, is it blocking any of them?
-
I just commited a fix to snort2c to kill states, too.
Reinstall the package after 9:25PM EST.
-
I am experiencing this issue as well. Not everything that is reportedly blocked is actually being blocked. Chat rules do appear to be blocking, however porn is not. If you type in nudeceleb.com, and you have porn to be blocked, it will still show. However, the site will appear in the blocked list. (I reinstalled the package just a few minutes ago. It does not block it still).
-
Still not working, using the nudeceleb test above :(
-
I think the porn rule in general does not work. None of the keywords successfully block the websites.
-
Neither does the chat (see the logs above), the problem is though is that the keywords DO pick up the alert, the alert is then logged and the hosts IP address added to the blocked hosts list, but it's not really blocked.
The question is, if the porn rules don't block and the chat rules don't block, do any of them?
-
Hmm…odd. My chat rules used to block messenger. Now when I enabled chat rules it does not block it. I have been able to verify that running a port/vulnerability scan on my firewall will detect it and block it for an hour. Maybe snort is only blocking activity inbound from the WAN interface.
-
Neither does the chat (see the logs above), the problem is though is that the keywords DO pick up the alert, the alert is then logged and the hosts IP address added to the blocked hosts list, but it's not really blocked.
The question is, if the porn rules don't block and the chat rules don't block, do any of them?
Snort isn't an IPS, it's an IDS. It's not going to PREVENT the bad traffic, just detect it. However, we do monitor for the bad traffic and block it after the fact so it can't happen again. But if it's already in flight, it's not going to block it.
–Bill
-
I realise that, BUT it isn't blocked and does allow visits after the "block" is in place.
I can visit a site which triggers the block, close the browser, then restart the browser later (within the hour obviously) and browse to the site which shows as being blocked
In the IRC example above, I opened IRC, joined a chat room (at 15:48:14.827532) which caused snort to detect and SAY that it had blocked the ip (194.159.164.195:6666) I then closed mIRC, waited 5 mins and rejoined the SAME host at (15:53:56.555003).
If it blocks after the fact, then how was I able to log on again 5 minutes later?
I may be misunderstanding the usage of the term blocked in this context, how should it work?
-
I realise that, BUT it isn't blocked and does allow visits after the "block" is in place.
I can visit a site which triggers the block, close the browser, then restart the browser later (within the hour obviously) and browse to the site which shows as being blocked
In the IRC example above, I opened IRC, joined a chat room (at 15:48:14.827532) which caused snort to detect and SAY that it had blocked the ip (194.159.164.195:6666) I then closed mIRC, waited 5 mins and rejoined the SAME host at (15:53:56.555003).
If it blocks after the fact, then how was I able to log on again 5 minutes later?
I don't know, maybe you hit a bug that the package maintainer hasn't hit yet. I didn't catch that you'd reloaded mirc in your previous email. OTOH, maybe snort only blocks people port scanning, I dunno. Guess we'll have to wait for the maintainer to chime in.
–Bill
-
Try this.
Use the Diagnostics Edit program to edit /tmp/rules.debug and find:
block in quick from <snort2c>to any label "Block snort2c hosts"
Change to:
block quick from <snort2c>to any label "Block snort2c hosts"
Save the file and then in Diagnostics, Command Prompt, Execute Shell command run:
pfctl -f /tmp/rules.debug
Does the block rule work correctly now?</snort2c></snort2c>
-
No, I'm afraid not :(
-
From a shell, issue:
fetch -o /etc/inc/filter.inc http://www.pfsense.com/~sullrich/filter.inc
/etc/rc.filter_configure_syncNow try to trigger a block and test again.
-
I just tried all those procedures and nothing was blocked, or logged for that matter. Could this have something to do with running in lowmem performance?
-
Yes, it could.
-
I've found that lowmem doesn't work at all, switching to ac-sparsebands did the trick for me
AND I've just tried the fix above and SNORT is now working as I would expect it to :)
Thank you VERY much sullrich, much appreciated.
Out of interest, what was the change?
-
A number of changes have happened:
-
Snort2c now issues pfctl -k
-
The filter rules now block items in the snort2c table in both directions
-
-
I've found that lowmem doesn't work at all, switching to ac-sparsebands did the trick for me
AND I've just tried the fix above and SNORT is now working as I would expect it to :)
…So keeping up with this post, should all of us that are having issues do the following:
*Reinstall the package if we have not done so in the past day or two?
*Change to ac-sparsebands from whatever other scheme was selected?
*Run Use the Diagnostics Edit program to edit /tmp/rules.debug ….?
*Run the scripts/commands that Sullrich just posted right before this post?
*Cross fingers?Thanks... I just want to clarify steps to correct/enhance this very useful package
-
So keeping up with this post, should all of us that are having issues do the following:
*Reinstall the package if we have not done so in the past day or two?
*Change to ac-sparsebands from whatever other scheme was selected?
*Run Use the Diagnostics Edit program to edit /tmp/rules.debug ….?
*Run the scripts/commands that Sullrich just posted right before this post?
*Cross fingers?Thanks... I just want to clarify steps to correct/enhance this very useful package
That sounds about right. I should note that the filter changes will be included with 1.0.1 which is scheduled for release sometime this weekend.