[Snort-sigs] Why not the otherway around??

Chris Green cmg at ...26...
Wed Oct 17 06:47:24 EDT 2001

Edwin Eefting <edwin at ...149...> writes:

> Ok..let me explain the weird subject. The rules that currently generate
> the most false positives are rules like this:
> #alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd.exe
> access"; flags: A+; content:"cmd.exe"; nocase; classtype:attempted-user;
> sid:1002; rev:1;)
> (you can even see i commented it out ;-)
> These rules have two huge disadvantages:
> 1)They are triggered by worms VERY often. (serveral thousand events/hour
> at our isp.)

Now, yes they are.  They have been used for a lot more than just IIS
worms though in the past.

> 2)It only indicates an ATTEMPT, not a succes.

Tags are part of what I use to see what the outcome of the attmept
is.  Great feature :)
> For succesfull attacks we offcourse have the "attack response
> rules".  (very usefull indeed!)  infected. This way, once a server
> is infected, there's no way to detect there is something wrong!
> (because they don't generate those nice attack responses anymore)

Right but part of IDS is the initial attack recognition. It's not
everything.  The tags help use it more as a passive psuedo
vulnerabilty detector.
> But we are lucky! The worm wants to spread itself, so it's doing
> "cmd.exe access" and similar thing to other ip adresses. The problem is
> that this will NOT be logged by rules like the one I mentioned above.
> Therefore I currently turning some rules around:
> alert tcp $HTTP_SERVERS  any -> $EXTERNAL_NET 80 (msg:"P-1-INFECTED worm
> cmd.exe access"; flags: A+; content:"cmd.exe"; nocase;
> classtype:attempted-user; sid:1002; rev:1;)

Right - I do tons of outgoing rules for things like this and popular
exploits.  Since the rule is different thgouh, you should use a
different sid.

We probably should try and add a lot more "outgoing rules" to the
default ruleset to make life easier on people.
> This rule almost never generates false positives and should be able to
> detect infected servers. 

Save for one of cnet's business channels that created a false positves
has a cgi named "admin-cmd.exe" or something like that.  Complained to
the address on the webpage it came up on and bounced around for a
while but I Don't think they ever renamed it.

To lower this type of false positive rate, I have thought about
creating something like "passcontent: admin_cmd.exe" that would work
after a rule is going to be decalred successful and work at a certain
depth/offset ( preferably with lots of knowledge about the previous
content rule so that it doesn't create a gaping hole in your ruleset
that easily ).

> Everytime a worm on one of your servers try's to spread it self, it
> should be triggered.  Is my story correct, or am I missing something
> here? If it is, then why nobody else thought about it?? :-)

Lots of people have.  Perhaps there should be an "outgoing.rules" in
snort that contains the list of popular attacks but it does fall into
one of the things that is part of tuning your own ruleset b/c thats
probably too many rules for a lot of folks to run.

> btw. I'm security engineer at a large(?) ISP and snort has to analyse a
> continuous flow of 3Mbytes/s. So you can imagine that rules with too
> much false positives just aren't usefull to me.

What I do is mine out what I Don't want and only investigate a certain
subset.  It's not really setup to be tied to my pager though :>

Chris Green <cmg at ...26...>
"Yeah, but you're taking the universe out of context."

More information about the Snort-sigs mailing list