Snort 2.9.2.3 pkg v. 2.5.1 service fails overnight, unable to restart



  • I used to use ac/bnfa but since the new binary the memory use seems to be under control and I switched to a/c a week or so ago, snort has not stopped since.  BTW I have 4 gig memory in i386 and 8 gig in amd63



  • Here's a different error in the log… same symptom though.

    Jul 27 12:04:37 kernel: pid 44861 (snort), uid 0: exited on signal 11
    Jul 27 12:04:37 snort[44861]: FATAL ERROR: Character value out of range, try a binary buffer.

    Happens after a rules update. Has anybody seen this one?



  • I use AC-BNFA with ET and Snort rules, also a few .SO rules on 2.1-Dev i386. Using only what is provided by the package only.. This is really the only way to test and to let the developer know what is going on with the code… Now if we can get Fesoj's code updated with what is currently being offered from the package manager, i'll be willing to test it also.

    PS i386 can't take 4gigs, its a little over 3 gigs. Limitation of 32-bit with memory address allocation.

    With it reloading, that kinda makes sense. Just have to figure out why is it increasing its usage.



  • I am currently using a fresh package install on 2 (virtual) machines and I have NOT applied my latest patch. Both systems are running fine for a couple of hours now. My latest patch is not needed if you load the Snort.org rules (unless my second last patch has been removed meanwhile, but a quick check of the sources show that that is not the case). The rule sets will update during the night, so I'll see tomorrow morning if there is an issue (but I doubt that).

    Alerting, blocking, blacklisting (with squid/squidGuard), reporting (with Sarg), and freeRADIUS (hooked up to a MySQL server) is working smoothly. I couldn't be happier.

    If others are still seeing problems, I could strip personal info from the images and publish an ova file somewhere. Then we'll see whether the problems persist (maybe some problems could be due to subtle hardware failures ;D).



  • Confirming the latest snort code restarts automatically after the update of Snort and ET rules but ONY if the 'Enable Sensitive Data' pre-processor is disabled.

    Is anyone else having this issue and is there a way to correct even with a patch until the next code update?



  • Confirming the latest snort code restarts automatically after the update of Snort and ET rules but ONY if the 'Enable Sensitive Data' pre-processor is disabled.

    Yes, I disabled the sensitive data preproc for my latest tests as well.



  • miles267,

    snort chokes on the missing sdf declaration. For now, https://github.com/bsdperimeter/pfsense-packages/pull/291/files should solve the problem. I haven't looked at the details why the declaration is missing again, but I guess you've enabled only the ET rules (but I could be wrong).



  • One more thing:

    kilthro said

    … The only thing I am noticing is snort memory usage keeps increasing...

    and Cino agreed

    … I've noticed the same thing this morning...

    I looked at the memory usage of the snort daemon as there were some reports about s.th. like memory leaks and I was worried a bit myself.

    When you look at snort.sh, you'll see that there is some intelligence coded into rc_start. Basically if a snort instance is already running there is no restart but rather a reload triggered by sending a HUP signal, otherwise there is a cold start (stop and start). You can clog and grep the system.log file for START to find out what happened on the last restart, either SOFT START for reloading using the HUP signal or just START for a real restart.

    If you don't trust the HUP signal you can call rc_stop before the rc_start function for restarting. I've looked at both scenarios for the following test.

    I restarted and reloaded snort for 50 times with s.th. like /bin/sh /usr/local/etc/rc.d/snort.sh restart followed by a ps -u for the snort processes. After grabbing the RSS values (real memory usage) and plotting the values for reloading and restarting I got the nice diagram that I've attached.

    As expected the memory usage for restarting remains constant. When reloading, the memory initially increased, but only up to a maximum value, then it stays essentially constant with some cyclic deviations. I guess this is just how the OS handles real memory. There is definetely no runaway behavior. BTW, your memory values will typically differ from mine which depends mainly on the rules that are used.

    To summarize, there doesn't seem to be a memory leak problem when the daemon reloads. Comments are welcome.




  • @Fesoj:

    miles267,

    snort chokes on the missing sdf declaration. For now, https://github.com/bsdperimeter/pfsense-packages/pull/291/files should solve the problem. I haven't looked at the details why the declaration is missing again, but I guess you've enabled only the ET rules (but I could be wrong).

    Fesoj, I just applied the fix you've added to github.  Will echo back if there are any issues.  Are you using the Sensitive data preprocessor in your config?

    For example, I've added the following to the bottom of my Snort suppress list.  Please let me know if this is accurate.  Also, wasn't sure whether I should have so many suppression rules or just certain ones for the HTTP/HTTPS inspect suppress?  Please let me know your thoughts.  Wasn't sure whether this is the proper use of the suppress list.

    uppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 201481
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 119, sig_id 2
    suppress gen_id 119, sig_id 4
    suppress gen_id 119, sig_id 14
    suppress gen_id 119, sig_id 31
    suppress gen_id 119, sig_id 32
    suppress gen_id 120, sig_id 2
    suppress gen_id 120, sig_id 3
    suppress gen_id 120, sig_id 6
    suppress gen_id 120, sig_id 8
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    suppress gen_id 137, sig_id 1

    Sensitive Data disable

    Credit Card Numbers

    #suppress gen_id 138, sig_id 2

    U.S. Social Security Numbers (with dashes)

    #suppress gen_id 138, sig_id 3

    U.S. Social Security Numbers (w/out dashes)

    #suppress gen_id 138, sig_id 4

    Email Addresses

    suppress gen_id 138, sig_id 5

    U.S. Phone Numbers

    suppress gen_id 138, sig_id 6



  • miles267,

    Are you using the Sensitive data preprocessor in your config?

    I verified that the error can occur when the sensitive data preproc is enabled.



  • miles267,

    you've got quite a few suppressions. In a way it doesn't make too much sense to enable all kind of rules, just to suppress their alerts (unless you are testing snort  ;) ). Personally I don't find the sensitive data preproc very useful (so why enable it?).

    You should also watch your system log for warnings like

    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.HTTP.at.SSL' is set but not ever checked.
    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.bmp_seen' is set but not ever checked.
    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.MSSQL' is set but not ever checked.

    , where entries like

    checked but never set

    are worse. My current approach is to specify only the stuff I really need, and then add additional sets to fullfill the state requirements, but not messing with individual rules.



  • @dwood:

    1.  Uninstall (if you have an older version, suggest you not toggle "save settings" to on.  In other words, start fresh.
    2.  Create an alias in pfsense to reflect your old whitelist.  You will select this alias in the snort whitelist tab later.
    3.  Run this command using Diagnostics -> Command Prompt:  find /* | grep -i snort | xargs rm -rv  (removes old snort references)
    4.  Install latest.  Likely for this version you'll want to make sure that senstive data preprocessor is not selected.  I've got all others on.
    5.  Monitor blocking and prepare to add quite a few exclusions!  This is the set I'm using pretty much copy/pasted from the suppression tab:

    Tried this 3 times, and each night snort fails.  I can restart again in the morning with very little effort, but that's clearly not the best solution.  I may open a ticket with support about this, as I've spent quite a bit of time dealing with it already.



  • @Fesoj:

    miles267,

    you've got quite a few suppressions. In a way it doesn't make too much sense to enable all kind of rules, just to suppress their alerts (unless you are testing snort  ;) ). Personally I don't find the sensitive data preproc very useful (so why enable it?).

    You should also watch your system log for warnings like

    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.HTTP.at.SSL' is set but not ever checked.
    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.bmp_seen' is set but not ever checked.
    Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.MSSQL' is set but not ever checked.

    , where entries like

    checked but never set

    are worse. My current approach is to specify only the stuff I really need, and then add additional sets to fullfill the state requirements, but not messing with individual rules.

    Appreciate the insight.  Are there a base set of Snort and/or ET rules you'd recommend be enabled for a home network?  Currently, I have ICMP and NETBIOS rules enabled on my LAN (not my WAN) and nearly every rule enabled on my WAN.  Thanks.



  • @miles267:

    Appreciate the insight.  Are there a base set of Snort and/or ET rules you'd recommend be enabled for a home network?  Currently, I have ICMP and NETBIOS rules enabled on my LAN (not my WAN) and nearly every rule enabled on my WAN.  Thanks.

    While I don't entirely disagree with Fesoj, I spoke with support about enabling snort on the WAN interface if you don't host any external sites.  Jim referred to it as the "belt and suspenders" approach, which basically means that there's no point in having Snort on your external interface unless you have some server publicly available, and even then it depends on what kind of server it is (snort can't see inside https, for instance).  pfSense blocks everything by default so Snort would just give you a bit of specificity that you don't really need.

    For that reason, I keep snort on my LAN interface with all categories enabled (I don't mess with rules much, just categories)  and suppress the false positives.  There are MANY ways to do this, and mine probably isn't the best but performance is fine and it gives me great insight into my network.



  • miles267,

    sapere aude!

    It all depends on what you want to and where your risks are. That's why you can configure it. What you could do is, set up snort interfaces for the LAN and the WAN side and enable the same rules and attack your system from the LAN side and the WAN side. When your router shows up in alerts as either the destination or source on one side and not on the other, you know on which side the rule makes sense. Unfortunately, this requires some time for testing and learning. As far as NETBIOS goes, I think they are better off on the WAN side (just have a look at the src nets for most of the rules). On the other hand, if your snort box is not an edge router, chances are that you do not need the NETBIOS rules.

    Another line of thought is looking at the size of the NETBIOS rule set, which is pretty large. Since many rules are rather MS related, one could doubt that you need them if your desktop boxes are Linux based. Last not least, most of the vulnerabilities have probably been fixed by MS meanwhile.



  • I set up the package on 7/27 on PF2.01/Amd64

    When the updates processed (last night I think) things broke.  I removed the package, reinstalled about 3pm EST and it seems to have fixed things.  Just FYI.



  • @Fesoj:

    miles267,

    snort chokes on the missing sdf declaration. For now, https://github.com/bsdperimeter/pfsense-packages/pull/291/files should solve the problem. I haven't looked at the details why the declaration is missing again, but I guess you've enabled only the ET rules (but I could be wrong).

    Fesoj, your code from the github has allowed snort to run on both i386 and amd64 boxes continuously since you originally posted the code. This is with the Sensitive data prepros on with both Snort and ET rules. Checking for updates every six hours, I have not had one error on six different boxes and not all the boxes have the same rules enabled.



  • Is it normal to get errors on certain rulesets?

    
    snort[1441]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/rules/snort_exploit.rules(362) Unknown rule option: 'ssl_state'.
    
    

    I get similar for botnet-cnc, policy-other, specific-theats.  Not always same error.



  • I was getting that error on that specific category myself, so you're not alone.  Just disable it for now.



  • mschiek01,

    I could go through the source code and find out under what circumstances the sdf declaration is missing, but if you patch the classification.config file of the ET rules, then the details on how pfSense generates the configuration files for the individual interfaces doesn't matter. With all this patching, the code gets pretty ugly, this is probably the reason why ermal did not patch his sources. My boxes are also running fine without any problems.



  • blundar, onhel,
    does  it matter if you toggle the settings in Snort: Interface Preprocessors and Flow: General Preprocessor Settings: Enable SSL Data?



  • I had it disabled when I was getting those errors.
    Enabling it fixed snort.botnet-cnc

    still getting errors on other once, mostly related to dce_iface

    Searching around these seem to be related to a conf issue so I'll keep digging.

    Thanks!



  • @blundar:

    I set up the package on 7/27 on PF2.01/Amd64

    When the updates processed (last night I think) things broke.  I removed the package, reinstalled about 3pm EST and it seems to have fixed things.  Just FYI.

    This is my exact setup, and I'm still having trouble after a few re-installs.  Fails overnight, restart manually is successful.



  • I must eat my words!  Snort died again last night!

    from logs:

    
    20	snort[32228]: Initializing rule chains...
    Jul 31 12:03:20	snort[32228]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 31 12:03:20	snort[32228]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 31 12:03:20	php: : Snort has restarted with your new set of rules...
    Jul 31 12:03:20	kernel: em0: promiscuous mode disabled
    
    

    Unchecking the "sensitive-data" checkbox for the CC# check, etc. in preprocessors was enough to get snort running again, albeit without some useful checks.



  • @blundar:

    I must eat my words!  Snort died again last night!

    Unchecking the "sensitive-data" checkbox for the CC# check, etc. in preprocessors was enough to get snort running again, albeit without some useful checks.

    This is my exact same issue.  I'm not sure how to find logs for past snort events?



  • Services… System logs.



  • @blundar:

    Services… System logs.

    Unfortunately it only displays the last 50 events, which doesn't take me back to the overnight failure.



  • blundar,

    the sdf problem is known for quite a while and if you search backwards in this thread you'll find a way of handling it.



  • you can change the number of lines using the settings tab.  I have mine set to 500.



  • @blundar:

    you can change the number of lines using the settings tab.  I have mine set to 500.

    Thanks - can't believe I never noticed that.  I'll check it again first thing in the AM.



  • dumb question, is everyone seeing updated rules? Since Sunday, i've had the same hash:

    SNORT.ORG >>>   "7017498f85ec6d0fc34c904c950ed8c1"
    EMERGINGTHREATS.NET >>>   13611f17ed1c94d40c8f0a78566dbb90

    I've been deleting the hash to force a manual update.. The auto update kicks off but nothing is downloaded since there isn't a new hash



  • @Cino:

    dumb question, are is everyone seeing updated rules? Since Sunday, i've had the same hash:

    SNORT.ORG >>>   "7017498f85ec6d0fc34c904c950ed8c1"
    EMERGINGTHREATS.NET >>>   13611f17ed1c94d40c8f0a78566dbb90

    I've been deleting the hash to force a manual update.. The auto update kicks off but nothing is downloaded since there isn't a new hash

    Sunday-Monday was the only day snort did not fail during updates, so it's possible there just weren't any that night.  I can't account for Monday, however.



  • You can check the actual MD5 Hash of "Only Registered Users" here:

    http://www.snort.org/downloads/1778/show_md5

    It is still:
    "7017498f85ec6d0fc34c904c950ed8c1"

    I am also checking that, because I also suspect snort to only update ET rules automatically. Manual updates work so far.

    Greets, Judex



  • auto update finally kicked for snort for me… 2 test boxes fresh installs of pfsense and snort...

    box with using snort and et with sensitive data preprocessor enabled: failed to reload, the usually error everyone is seeing
    box with using snort and et with sensitive data preprocessor disabled: reloaded fine

    IMHO, I feel the sensitive preprocessor option should be removed from snort until a working fix can be applied to the package. or a warning that auto updates should be disabled and and to run updates manually



  • Finally getting back to the original post, I think this is what's causing the issue:

    kernel: pid 31475 (snort), uid 0, was killed: out of swap space

    As a test, I disabled updates.  As expected, snort ran fine until I did a manual update.  The error above was what showed up after running the update.  Restarting snort by hand brought success.

    Is the swap space error helpful?  I do not have a swap partition on my install, as I have significant excess RAM.


Log in to reply