[Snort-users] Disabled rules still triggering

Willst Mail willstmail at ...11827...
Thu Apr 29 07:54:12 EDT 2010


Snort rules are in /usr/local/etc/snort/rules.

snort.conf is in /usr/local/etc/snort, and defines the rules directory
as ./rules:
[ /usr/local/etc/snort]$ grep "var RULE_PATH" snort.conf
var RULE_PATH ./rules

Individual rules are included from $RULE_PATH:
[/usr/local/etc/snort]# grep netbios snort.conf
include $RULE_PATH/netbios.rules

We invoke oinkmaster via cron from a bash script like this, without
the careful mode option:
$OINKMASTER -o $RULEDIR

With these variable definitions:
OINKMASTER=/usr/local/bin/oinkmaster.pl
RULEDIR=/usr/local/etc/snort/rules

The script logs success if $? -eq 0, and failure otherwise.  Scheduled
runs are logging success, and manually running oinkmaster also results
in oinkmaster reporting success.

Any other suggestions for troubleshooting?


On Wed, Apr 28, 2010 at 6:17 PM, Joel Esler <jesler at ...1935...> wrote:
> Oinkmaster has a feature that it will tell you the rules it *would* modify
> but not actually modify them, I think it's called "careful" mode.  Are you
> running that.  Barring that, and I'm not trying to accuse you or anything,
> but it sounds like maybe Oinkmaster is writing one set of rules and the
> snort.conf is loading in a separate set of rules.
>
> On Wed, Apr 28, 2010 at 6:09 PM, Willst Mail <willstmail at ...11827...> wrote:
>>
>> Now this is interesting .. I ran oinkmaster manually, and it says it
>> disabled rules:
>>
>> >> Processing downloaded rules... disabled 27, enabled 0, modified 0,
>> >> total=8464
>>
>> The md5 of netbios.rules (contains sid:1295) was the same before and
>> after, as expected.  So, I looked at the timestamp on the file and it
>> was from April 14 - very odd considering I'd expect that every night
>> we are rewriting it.
>>
>> As a test, I manually edited netbios.rules to uncomment the 1295 rule,
>> made note of the new timestamp, reran oinkmaster, and the
>> netbios.rules was updated AFTER running oinkmaster.  I restarted snort
>> and so far at least haven't seen that signature triggered.  It's
>> possible but I'd say unlikely that we would have no traffic that would
>> trigger it since then.
>>
>> So, it looks like the rules files were not being updated and Snort was
>> loading the rule even though it was commented out.  So far it seems
>> constrained to this one sensor.  I'm guessing that on that sensor I
>> can probably delete the standard rules files, oinkmaster will reload
>> everything, and life will be good again.  Seems strange though.
>>
>> More curiously - sid 1295 happens to be disabled by default anyway in
>> the rules, but I think oinkmaster is "redisabling" it because there is
>> a space between # and alert before running oinkmaster and no space
>> after.
>>
>> On Wed, Apr 28, 2010 at 2:51 PM, Chan, Wilson <wchan at ...14702...> wrote:
>> > Just curious did you run oinkmaster? If its via a cron then try running
>> > it manually as you can read the output to see if it disabled the sid.
>> > Then restart snort so it takes the new rules.
>> >
>> > Wilson
>> >
>> > -----Original Message-----
>> > From: Willst Mail [mailto:willstmail at ...11827...]
>> > Sent: Wednesday, April 28, 2010 8:20 AM
>> > To: snort-users at lists.sourceforge.net
>> > Subject: [Snort-users] Disabled rules still triggering
>> >
>> > I have a Snort sensor running 2.8.5.3 and oinkmaster 2.0 on FreeBSD
>> > 6.2.  I have some signatures that I disable with oinkmaster, and in
>> > the rules files they show as commented out, but alerts are still being
>> > generated.  Example:
>> >
>> > >From oinkmaster.conf:
>> > # Nimda RICHED20.DLL (2010-03-09 wss)
>> > disablesid 1295
>> >
>> > >From /usr/local/etc/snort/rules:
>> > # grep "sid:1295;" *
>> > netbios.rules:#alert tcp $EXTERNAL_NET any -> $HOME_NET 139
>> > (msg:"NETBIOS nimda RICHED20.DLL"; flow:to_server,established;
>> > content:"R|00|I|00|C|00|H|00|E|00|D|00|2|00|0|00|.|00|D|00|L|00|L";
>> > nocase; reference:url,www.f-secure.com/v-descs/nimda.shtml;
>> > classtype:bad-unknown; sid:1295; rev:11;)
>> >
>> > This seems to be happening with some (not sure about all) signatures.
>> > I've tried both HUP'ing Snort and doing a full stop and start.
>> >
>> > Suppressing it in threshold.conf DOES seem to prevent alerts:
>> > $ grep 1295 /usr/local/etc/snort/threshold.conf
>> > suppress gen_id 1, sig_id 1295
>> > $ grep 1295 /var/log/messages
>> > Apr 28 14:11:45 mysnortsensor snort[92239]: | gen-id=1
>> > sig-id=1295       tracking=none
>> >
>> > But I'd rather disable than simply suppress, and the fact that the
>> > commented rule is still being loaded is troubling.  We've been running
>> > 2.8.5.3 on this sensor for a couple months, this issue seems to have
>> > started in the past few days, and I don't think I'm seeing it on other
>> > sensors.  We are using the paid signature subscription.
>> >
>> > Any ideas or how else to troubleshooting this?  Going to 2.8.6 isn't
>> > an option just yet.
>> >
>> > ------------------------------------------------------------------------
>> > ------
>> > _______________________________________________
>> > Snort-users mailing list
>> > Snort-users at lists.sourceforge.net
>> > Go to this URL to change user options or unsubscribe:
>> > https://lists.sourceforge.net/lists/listinfo/snort-users
>> > Snort-users list archive:
>> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Snort-users mailing list
>> Snort-users at lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe:
>> https://lists.sourceforge.net/lists/listinfo/snort-users
>> Snort-users list archive:
>> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>




More information about the Snort-users mailing list