Sid Ranges do not function in disablesid

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In disablesid.conf, enter:
   1:3000-1:4000   # comment
2. Run pulledpork -v -c /etc/snort/pulledpork.conf
3. Review disabled output to see that only the start and end of the
   range have been processed, not the entire range:
   Processing /etc/snort/disablesid.conf....
        Disabled 1:3000
        Disabled 1:4000
        Modified 2 rules

What is the expected output? What do you see instead?
Expect sids 3000 through 4000 to be disabled.  Instead only sids 3000 AND 4000 
were disabled.  3001, 3002, etc were not disabled as expected.

What version of the product are you using? On what operating system?
0.5

Please provide any additional information below.
This seems like a pretty bad bug, can you reproduce or is there a flaw in my 
config elsewhere that might cause this to happen.

Original issue reported on code.google.com by mikeloc...@gmail.com on 23 Dec 2010 at 11:53

[GoogleCodeExporter]

Erm... perhaps something much stranger is going on here.  I seem to be unable 
to disable these sids in any way:

3091, 3092, 3093, 3094, 3095, 3096

I've tried a range, I've tried a comma separated list, and I've tried listing 
on individual lines.  I think this might have something to do with some 
automatic intelligence pulledpork has related to flowbits.  This is a range of 
sids that all share a flowbit.

Original comment by mikeloc...@gmail.com on 24 Dec 2010 at 12:19

[GoogleCodeExporter]

Issue 54 has been merged into this issue.

Original comment by Cummin...@gmail.com on 3 Jan 2011 at 8:33

[GoogleCodeExporter]

I suspect that it is flowbit related, but let me have a look right quick and 
post an update, apologies for the delay, but you know, holidays and all!

Original comment by Cummin...@gmail.com on 3 Jan 2011 at 8:36

[GoogleCodeExporter]

You have a rule somewhere that is calling : 
flowbits:set,smb.tree.create.llsrpc; and as a result PP is automatically 
enabling those flowbits:set rules, otherwise the calling rule would rule would 
be silently disabled, make sense?

Original comment by Cummin...@gmail.com on 3 Jan 2011 at 8:40

[GoogleCodeExporter]

Marking as wontfix currently, may revisit later if we want to adjust the logic 
a bit, but this is more a rules issue than PP functionality.  May also consider 
more verbose output that says "I won't disable this because SID:XXXX is calling 
it" kinda thing..

Original comment by Cummin...@gmail.com on 3 Jan 2011 at 8:41

• Changed state: WontFix

[GoogleCodeExporter]

Two further comments...

1) The verbose output should definitely speak-up if pulled-pork's flowbits 
logic contradicts config-file input. If you silently ignore config-directives, 
users must do orders-of-magnitude more troubleshooting to understand what's 
going on than if you tell them why you're ignoring them.

2) In comment 4 you said:

> You have a rule somewhere that is calling: 
flowbits:set,smb.tree.create.llsrpc;
> and as a result PP is automatically enabling those flowbits:set rules

I think you meant to say that I "have a rule somewhere calling 
flowbits:isset..." (note the ISSET instead of the SET). My understanding is 
that the isset-directive is a check that depends on the set-rules to work, but 
I don't have rules with isset-directives in them.  The reason that I attempted 
to disable these rules in the first place was due to snort warning me on 
startup about them being unnecessary:

   "Warning: flowbits key 'smb.tree.create.llsrpc' is set but not ever checked."

To confirm this, I've performed the following greps:

Returns 0 lines:
grep 'isset,smb.tree.create.llsrpc' *.rules | less

Returns 8 lines, sids 3090-3097 which all contain set directives:
grep 'set,smb.tree.create.llsrpc' *.rules | less

Are you sure that PP is doing its flowbits checking correctly?  I can provide 
my full config offline if you'd like.  I'd rather not attach it to a public 
bug-db, though.

Original comment by mikeloc...@gmail.com on 4 Jan 2011 at 11:28

[GoogleCodeExporter]

Please feel free to email it to me, or catch me in #pulledpork or #snort on IRC 
and we'll do some debugging!

Original comment by Cummin...@gmail.com on 5 Jan 2011 at 2:47

[GoogleCodeExporter]

As a quick note... pp looks for the set flowbit by looking for a calling isset 
(only for enabled rules though)  Are you running the latest svn code or tarball?

Original comment by Cummin...@gmail.com on 5 Jan 2011 at 3:01

[GoogleCodeExporter]

This is also affecting 1:7047 which is currently the worst performing rule in 
my snort instance.  1:7047 sets object.excel, which is also unused according to 
snort and my own rule greps.

I've sent you some config files via email and am idling in #pulledpork as 
mikelococo if you want to chat.

Original comment by mikeloc...@gmail.com on 5 Jan 2011 at 11:04

[GoogleCodeExporter]

Looking into this more

Original comment by Cummin...@gmail.com on 6 Jan 2011 at 12:15

• Changed state: Accepted

[GoogleCodeExporter]

Committed revision 189.

Original comment by Cummin...@gmail.com on 6 Jan 2011 at 5:16

• Changed state: Fixed

[GoogleCodeExporter]

Confirmed that all the problem rules I listed above are disabled when I run PP 
from today's SVN.

Original comment by mikeloc...@gmail.com on 7 Jan 2011 at 12:55