Snort 2.9.4.1 pkg v.2.5.8



  • @Deadringers:

    Guys I updated and lost all my settings - no big deal but now I have an issue with http_inspect.

    Constantly sites like google, reddit, imgur, yahoo, youtube…the list goes on... are getting blocked.

    Can you please tell me what I am doing wrong with the setup of this and if any of you are seeing the same issues?

    I tried to disable it via options but then snort won't start - guessing some WAN categories are dependent on http_inspect starting.

    There is a check box on the Preprocessors tab at the bottom of the HTTP_INSPECT section that says "disable http_inspect alerts" or something similar.  Tick that box.  You should then no longer get blocks from HTTP_INSPECT alerts.  There is also a new button at the bottom of the page for 2.5.8 that will reset all the preprocessor settings to their defaults.  The default for HTTP_INSPECT should be enabled but with alerts disabled.

    Attached below are my HTTP_INSPECT settings.  You can also automatically add problem alerts to the Suppress List by clicking the plus icons (+) under the alert on the Alerts tab.  Once you do this, you will need to stop and restart Snort to pick up the change.

    Bill




  • Did you see the thread I created about finding a notification script by someone else?  I am making good use of it.  I only block on the LAN snort instance though.  I would get too many notifications on the wan side.
    http://forum.pfsense.org/index.php/topic,63418.0.html



  • @adam65535:

    Did you see the thread I created about finding a notification script by someone else?  I am making good use of it.  I only block on the LAN snort instance though.  I would get too many notifications on the wan side.
    http://forum.pfsense.org/index.php/topic,63418.0.html

    Yes, I saw the post. It is a handy script, but with a number of commercial Snort installations I think it could lead to "information overload" with the number of blocks and unblocks that routinely happen.  An improvement might be to filter the events and only send notifications for high priority ones so that you don't get an e-mail flood for something like blocks/unblocks from IPs on the RBN or CIARMY lists.

    Bill


  • Banned

    I agree. Currently it would mean that I would get about 1000+ emails a day and I dont have time for that…

    It would consume a LOT of space on the mailserver for nothing really.



  • @bmeeks:

    @Deadringers:

    Guys I updated and lost all my settings - no big deal but now I have an issue with http_inspect.

    Constantly sites like google, reddit, imgur, yahoo, youtube…the list goes on... are getting blocked.

    Can you please tell me what I am doing wrong with the setup of this and if any of you are seeing the same issues?

    I tried to disable it via options but then snort won't start - guessing some WAN categories are dependent on http_inspect starting.

    There is a check box on the Preprocessors tab at the bottom of the HTTP_INSPECT section that says "disable http_inspect alerts" or something similar.  Tick that box.  You should then no longer get blocks from HTTP_INSPECT alerts.  There is also a new button at the bottom of the page for 2.5.8 that will reset all the preprocessor settings to their defaults.  The default for HTTP_INSPECT should be enabled but with alerts disabled.

    Attached below are my HTTP_INSPECT settings.  You can also automatically add problem alerts to the Suppress List by clicking the plus icons (+) under the alert on the Alerts tab.  Once you do this, you will need to stop and restart Snort to pick up the change.

    Bill

    Thanks for that…but I am still getting alerts and blocks for it?

    Have changed my settings to be exactly the same as yours and still getting things like this:



  • @Deadringers:

    @bmeeks:

    @Deadringers:

    Guys I updated and lost all my settings - no big deal but now I have an issue with http_inspect.

    Constantly sites like google, reddit, imgur, yahoo, youtube…the list goes on... are getting blocked.

    Can you please tell me what I am doing wrong with the setup of this and if any of you are seeing the same issues?

    I tried to disable it via options but then snort won't start - guessing some WAN categories are dependent on http_inspect starting.

    There is a check box on the Preprocessors tab at the bottom of the HTTP_INSPECT section that says "disable http_inspect alerts" or something similar.  Tick that box.  You should then no longer get blocks from HTTP_INSPECT alerts.  There is also a new button at the bottom of the page for 2.5.8 that will reset all the preprocessor settings to their defaults.  The default for HTTP_INSPECT should be enabled but with alerts disabled.

    Attached below are my HTTP_INSPECT settings.  You can also automatically add problem alerts to the Suppress List by clicking the plus icons (+) under the alert on the Alerts tab.  Once you do this, you will need to stop and restart Snort to pick up the change.

    Bill

    Thanks for that…but I am still getting alerts and blocks for it?

    Have changed my settings to be exactly the same as yours and still getting things like this:

    And you did restart Snort after the change, correct?

    If you did, and are still getting the alerts, then click on the (+) icon under the SID column on the Alerts tab.  That will add the Generator ID:Signature ID for that alert to the Suppress List.  After doing this, stop and restart Snort on the Snort Interfaces tab.  That should for sure silence the alert.

    If you restarted Snort after changing the Preprocessor settings and still got the alerts, post back and let me know. That should have silenced them, and if it did not, I need to investigate that in the code.

    Bill



  • hmmm right some weird stuff happening now.

    I restarted snort under the interfaces tab after checking

    Turn off alerts from HTTP Inspect preprocessor. This has no effect on HTTP rules. Default is Checked.

    But still getting the IPs blocked for http_inspect.

    So as you said I tried to add to the suppress list:

    However when I go to the suppress list there is nothing entered?


    I am going to try to re-install snort right now and see if that helps!



  • @Deadringers:

    hmmm right some weird stuff happening now.

    I restarted snort under the interfaces tab after checking

    Turn off alerts from HTTP Inspect preprocessor. This has no effect on HTTP rules. Default is Checked.

    But still getting the IPs blocked for http_inspect.

    So as you said I tried to add to the suppress list:

    However when I go to the suppress list there is nothing entered?


    I am going to try to re-install snort right now and see if that helps!

    I do believe you will need to manually create it first. Mine working as I already have suppress list



  • okay quick update

    uninstalled snort

    re-installed it

    put all my setting back to how they were.

    having the check box ticked for it to not block for http_inspect issues didn't work.

    So added that ID to the suppress list as you said - this seems to have worked now.

    need any logs from me to see why the http_inspect check box isn't working?



  • @Deadringers:

    okay quick update

    uninstalled snort

    re-installed it

    put all my setting back to how they were.

    having the check box ticked for it to not block for http_inspect issues didn't work.

    So added that ID to the suppress list as you said - this seems to have worked now.

    need any logs from me to see why the http_inspect check box isn't working?

    With that box checked, you will see the alerts logged on the Alerts tab, but you should not be getting blocks for those IP addresses on the Blocked tab.  If you are no longer getting blocks for those IPs listed on the Blocked tab, then the check box is working correctly.  It's a bit of a misnomer with the titling.  The Alerts tab is really just reading the Snort logs.  Snort will log everything.  What pfSense calls blocks on the Blocked tab is what Snort calls alerts.  A little confusing, probably for new users.  When you put something on the Suppress List, it will no longer cause blocks, but will still get logged on the Alerts tab (since the event will be logged by Snort).  If you truly do not want to even see the event in the logs, then you have to disable the rule.  Your screenshot was of the Alerts tab, so I assume the Blocked tab no longer shows an active block for those hosts listed.

    As to the blank Suppress List page, go to the If Settings tab for the WAN interface and post a screenshot of the Suppression List setting in the drop-down near the bottom of the page.  Unless you specifically had a name set there, it should be either "default" or "wansuppress".

    Bill



  • yea the box was checked and the hosts were getting blocked

    100% sure on this because as soon as the host ip was on that block list the website in question would stop working.



  • Anyone still having issues where a blocked IP is removed from snort2c within a few minutes? I'm banging my head here. I've set it for never expire, disabled log limit and removed the 2 cron jobs. They still disappear. I've done a clean install of snort with my old config.. Only 2 options left are to either wipe all snort settings and start fresh or rebuild my box from iso install..



  • @Cino:

    Anyone still having issues where a blocked IP is removed from snort2c within a few minutes? I'm banging my head here. I've set it for never expire, disabled log limit and removed the 2 cron jobs. They still disappear. I've done a clean install of snort with my old config.. Only 2 options left are to either wipe all snort settings and start fresh or rebuild my box from iso install..

    When the packet filter is reloaded the table "snort2c" will be cleared. This can have many causes and the log file should give clues. It is discussed before.



  • @Cino:

    Anyone still having issues where a blocked IP is removed from snort2c within a few minutes? I'm banging my head here. I've set it for never expire, disabled log limit and removed the 2 cron jobs. They still disappear. I've done a clean install of snort with my old config.. Only 2 options left are to either wipe all snort settings and start fresh or rebuild my box from iso install..

    gogol is correct.  Anything that causes pfSense to reload the packet filter will automatically dump the table Snort's output plugin uses to implement blocks.  Reloads can happen because of edits within the GUI, DHCP address changes, links going up and down, etc.  Look for the tag check_reload_status: Syncing firewall in the system log.  That's an event that clears the table, I believe.

    Not really sure why this is a big deal to folks, though.  If an offending packet for that IP traverses the firewall again, the IP will be "re-blocked".  Or put another way, if whatever caused it to get blocked in the first place repeats, then it will be blocked again.  Maybe I'm missing something?

    Bill



  • I've been away for a couple of weeks and when I brought it up last month, there wasnt a reason why. Going thru my cron jobs, there is a job that re-sync every 15 minutes so that would explain why the table is being cleared..

    This is new behavior for snort. I've been using snort on pfsense for many years and it never acted this way. And if it did, I've never noticed it while testing for last 2 developers of the snort package. This is why I bring it up.



  • @Cino:

    I've been away for a couple of weeks and when I brought it up last month, there wasnt a reason why. Going thru my cron jobs, there is a job that re-sync every 15 minutes so that would explain why the table is being cleared..

    This is new behavior for snort. I've been using snort on pfsense for many years and it never acted this way. And if it did, I've never noticed it while testing for last 2 developers of the snort package. This is why I bring it up.

    Snort really has nothing at all to do with clearing the snort2c table.  Perhaps pfSense made some changes to the expiretable script?  All the Snort package does is create a cron task that executes every 5 minutes.  That tasks looks for snort2c entries that have had no activity for the last period specified in the "Clear Blocks Interval" on the If Settings tab.  Entries matching that are removed.  You can see the content of the cron task in /etc/crontab.  Here is the line:

    */5	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 3600 snort2c
    
    

    I have mine set for 1 hour, hence the 3600 seconds value.  The expiretable script is used to clear a number of other tables as well and is not proprietary to Snort.  I have not noticed any premature clearing of entries on my system, but Snort is the only package I run.  Perhaps something else loaded on your firewall is triggering the reloading of the packet filter and thus dumping the snort2c table?

    Bill



  • I figured out what was clearing it. My rules would reload every 15 minutes because of schedule fw rule I have (pfsense creates this cron if you have schedule fw rules). I've had this rule for a while.. Either I haven't noticed it clearing out snort2c or like you said, something change with the expiretable script itself on 2.1. What I dont understand, if you set it for never; a simple reload of the rules will wipe it out. I'll have to dig deeper on why this is because I would think other tables would get wiped out then.

    Thank you again for all your work you have done on this package.. Its come a long way



  • @Cino:

    I figured out what was clearing it. My rules would reload every 15 minutes because of schedule fw rule I have (pfsense creates this cron if you have schedule fw rules). I've had this rule for a while.. Either I haven't noticed it clearing out snort2c or like you said, something change with the expiretable script itself on 2.1. What I dont understand, if you set it for never; a simple reload of the rules will wipe it out. I'll have to dig deeper on why this is because I would think other tables would get wiped out then.

    Thank you again for all your work you have done on this package.. Its come a long way

    The key is that it's not Snort that really does the blocking/unblocking of an IP.  Not directly, anyway.  A third-party plug-in called Spoink is compiled into Snort as an output plugin.  This plugin inserts itself into the Alert chain in Snort so that it gets a copy of every alert.  It then compares the IP addresses in the alert to the Whitelist, and if there is no match based on the SRC/DST/BOTH logic it uses pfctl to insert the IP into the packet filter engine.  At that point any part of Snort is done with the block.

    I suspect what happens is the reload of the firewall rules on the scheduled task is wiping the block table.  That is logical, because on the assumption a new set of rules are coming into play, you would not want old blocks leftover in the block table.  In this scenario, Snort's snort2c table is essentially "collateral damage" as they say… :D

    Bill



  • So funny thing happend, from what i can make out from the logs.  Snort rules updated last night.  After that it ran the snortstart and it stopped running.  Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a

    "/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it



  • Another question from me , is it normal , both lan and wan snort interface is not running after server restart (auto restart using cron). Need to click on the enable button again to make it run.

    If yes , perhaps , Bmeeks can add to wish list , to auto enable the interface , as some server (low spec) will need to be auto restart from time to time using cron.



  • @shinzo:

    So funny thing happend, from what i can make out from the logs.  Snort rules updated last night.  After that it ran the snortstart and it stopped running.  Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a

    "/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it

    To continue my story, i found out what deleted it.  bandwidthd was maxing out my cpu the other day so i figured i remove it.  When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again



  • @shinzo:

    @shinzo:

    So funny thing happend, from what i can make out from the logs.  Snort rules updated last night.  After that it ran the snortstart and it stopped running.  Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a

    "/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it

    To continue my story, i found out what deleted it.  bandwidthd was maxing out my cpu the other day so i figured i remove it.  When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again

    The new PBI package management system in 2.1 eliminates these issues.  Each package has the equivalent of its own chroot jail, so to speak, where its executables and libraries go.

    Bill



  • Not trying to get the thread off topic, but just FYI.

    I have submitted the Pull Requests to the Core Developer Team for updating the Snort package to 2.9.4.6 pkg version 2.5.9.  This will update the Snort binary to the current 2.9.4.6 code.  The 2.5.9 GUI package update fixes a couple of bugs and introduces Host Attribute Table support along with configurable rule update start times (an often asked for feature).

    The full details can be seen here for the GUI:  https://github.com/pfsense/pfsense-packages/pull/461 and here for the binary: https://github.com/pfsense/pfsense-tools/pull/122

    I will start a new thread on this version when it is approved and posted.

    Bill



  • Thanks Bill!!!



  • yay updates, I look forward to all the updated features.

    I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest.  Is there any benefits to compiling them with the newest ones?  Was just curious thank you



  • @shinzo:

    yay updates, I look forward to all the updated features.

    I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest.  Is there any benefits to compiling them with the newest ones?   Was just curious thank you

    On the 2.0.x platform Snort has to work as harmoniously as possible and utilize the libraries shared with other packages.  On the 2.1 platform with PBI, that's not an issue.  So for now, with the Snort package supported on both 2.0.x and 2.1, the slightly older libraries are used.  Once everything is just 2.1 with PBI, then each package can use its own library versions.

    In my testing with 2.9.4.6 I've seen no issues with the current library versions.

    Bill



  • @bmeeks:

    @shinzo:

    yay updates, I look forward to all the updated features.

    I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest.  Is there any benefits to compiling them with the newest ones?   Was just curious thank you

    On the 2.0.x platform Snort has to work as harmoniously as possible and utilize the libraries shared with other packages.  On the 2.1 platform with PBI, that's not an issue.  So for now, with the Snort package supported on both 2.0.x and 2.1, the slightly older libraries are used.  Once everything is just 2.1 with PBI, then each package can use its own library versions.

    In my testing with 2.9.4.6 I've seen no issues with the current library versions.

    Bill

    makes sense.  Thank you



  • @bmeeks:

    Not trying to get the thread off topic, but just FYI.

    I have submitted the Pull Requests to the Core Developer Team for updating the Snort package to 2.9.4.6 pkg version 2.5.9.  This will update the Snort binary to the current 2.9.4.6 code.  The 2.5.9 GUI package update fixes a couple of bugs and introduces Host Attribute Table support along with configurable rule update start times (an often asked for feature).

    The full details can be seen here for the GUI:  https://github.com/pfsense/pfsense-packages/pull/461 and here for the binary: https://github.com/pfsense/pfsense-tools/pull/122

    I will start a new thread on this version when it is approved and posted.

    Bill

    Glad to hear this


  • Banned

    Apparently Shinzo allready posted the update and the Core team has pushed the update.



  • @Supermule:

    Apparently Shinzo allready posted the update and the Core team has pushed the update.

    Yes, they were very fast to approve and push.  Haven't had time yet to create the Change Log (thanks to Shinzo for doing this for me!) and post some screenshots of the changes.

    Bill



  • A third-party plug-in called Spoink

    This is probably a silly question, but searching hasn't (yet) found me a definitive answer - are alerts automatically blocked by the Spoink / pf mechanism even if no blocking is turned on in snort's gui ?

    Thanks..



  • @Craigusoz:

    A third-party plug-in called Spoink

    This is probably a silly question, but searching hasn't (yet) found me a definitive answer - are alerts automatically blocked by the Spoink / pf mechanism even if no blocking is turned on in snort's gui ?

    Thanks..

    No, if "Block Offenders" is not checked on the If Settings tab for the interface in the Snort GUI, no blocking will occur.  You will see Alerts, but remember that in the pfSense implementation an "alert" does not automatically equate to a "block".  Alerts are simply read from the log and displayed to show a detected event that matched a rule.  The Spoink plugin also sees these "alerts" and compares the IP addresses in them to its Whitelist of "never block IP addresses".  If blocking is enabled for the interface, and the IP is not in the Whitelist, then the IP is added to the block table in the firewall.

    Bill



  • Thanks Bill, that explains things perfectly.

    Another question if I may - if I'm running snort on the WAN interface, I should choose DST rather than SRC in the block offenders option, yes?

    (I think last time I did this, I chose SRC, which caused all internet traffic incoming to the WAN interface to be blocked  :-[ )



  • @Craigusoz:

    Thanks Bill, that explains things perfectly.

    Another question if I may - if I'm running snort on the WAN interface, I should choose DST rather than SRC in the block offenders option, yes?

    (I think last time I did this, I chose SRC, which caused all internet traffic incoming to the WAN interface to be blocked  :-[ )

    [/quote]

    I have SRC set on my WAN.  With a properly constructed Whitelist containing your WAN IP, your WAN IP itself will never be blocked but the "bad guys" sending traffic your way will be.  That is generally what we want – the bad guys locked out.  If a "good guy" is misclassified as a "bad guy" due to some anomaly in their traffic that matches a Snort rule, we call that a "false positive".  Those are what the Whitelist can also be used for.  You can whitelist known "good guys" so they are never blocked.

    You might also get a lot alerts (and potentially blocks) from preprocessor rules that normalize and validate traffic such as HTTP, SSL, FTP, etc., before passing it along to the other rules.  If a preprocessor finds something it does not like in the packet stream, it can also raise an alert (and potentially a block).  The HTTP_INSPECT preprocessor is famous for this.  The Suppression List can help here.  If known "good guy" web sites are frequently blocked by an overly cautious and strict preprocessor rule, the Generator ID and Signature ID (gid:sid) of the alert can be added to the Suppression List.  This will stop future logging (and blocking) of the event.  Use this with care, though.

    Bill



  • OK, thanks again - that's very helpful also.



  • Hi,

    i have one, maybe stupid, question…

    My goal is to migrate our iptables firewall to pfsense with snort filtering.
    In our configuration we have several carp interfaces based on one physical wan interface.

    In the snort interface configuration i can only choose between the "physical interfaces".
    The dropdown does not show any of the carp (vip) interfaces.

    What happen when i choose the phyical wan interface for snort filtering?
    Will the incoming traffic on the carp interfaces will be filtered too?

    Thanks

    Holger



  • Yes with WAN you will see all carp related traffic since interface is in promiscuous mode.



  • @ermal:

    Yes with WAN you will see all carp related traffic since interface is in promiscuous mode.

    Thanks, then snort works perfect for my needs… :)



  • @shinzo:

    @shinzo:

    So funny thing happend, from what i can make out from the logs.  Snort rules updated last night.  After that it ran the snortstart and it stopped running.  Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a

    "/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it

    To continue my story, i found out what deleted it.  bandwidthd was maxing out my cpu the other day so i figured i remove it.  When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again

    Thank you, Kinzo, that did the trick for me too  :P



  • HI

    I have massive problems with lags in onlinegaming (computer).
    Is it normal that snort generates massive lags?
    The CPU is on max 1% load, memory on 20% load.


Log in to reply