[Snort-sigs] Why not the otherway around??
edwin at ...149...
Wed Oct 17 01:50:17 EDT 2001
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;
(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.)
2)It only indicates an ATTEMPT, not a succes.
For succesfull attacks we offcourse have the "attack response rules".
(very usefull indeed!)
HOWEVER, some worms automaticly patch the hole in the server they have
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
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;)
This rule almost never generates false positives and should be able to
detect infected servers. 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?? :-)
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.
Edwin Eefting /- \ _/ Business Internet Trends BV
/--- \/ __________________
More information about the Snort-sigs