Snort - Please help
-
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.
-
As a matter of interest, what are the memory requirements for snort in it's various mode (ac, sparsebands, lowmem etc).
I'm running with 256mb and it seems like it's not enough (nowhere near enough?)
I'll upgrade the ram if needs be, but I'd like to make sure I get enough :)
-
Depends on which rules you use. In general it's "just snort" so you should check out requirements at the snort homepage/mailinglists.
-
512 megs of ram or above. The release notes for pfSense mention a GIG.
Snort is really a hog.
-
Thanks, I'll upgrade then :)
-
Hi all,
sorry for my 'noobiness' with all these snort business.
But I'm having problem with snort+pfsense combination.some detail:
pfsense-1.0-RC3
download and install snort package from pfsense :
snort
BETA
2.6.0.2.4
platform: 1.0Got the oinkcode from snort.org and then it started downloading
some of the rules.Have NOT messed with the setting after that ( not ticking
any rules etc )
though It generates alerts, ever since it's activated with the oink code
Next day, I found it blocked some IPs ( my IP too )Tried to put my IP in the whitelist. But I couldn't go through.
Had to de-install snort and revert to the original config.
What would be the 'minimal' setup setting for snort in pfsense ?
Originally, I intend to put DNS rule in snortps : you can't sort of disable snort once it's installed and activated
with oink code, can you ?Thanks for the help.
-networknoob -
-
Hoba : Thx for the quick reply. will try that one and we'll see how it goes