Re: A couple of design comments/questions

[Frank Knobbe <fknobbe () knobbeits com>]

On Sun, 2003-02-02 at 16:48, Jason Haar wrote:
> [...]
> IMHO,a problem with this approach is that you end up looking for events that
> are actually less important than their reverse. I'd say in most peoples'
> eyes, seeing an incoming CodeRed event is less important than an
> outgoing, but other than doubling every rule (one for incoming, one for
> outgoing), I can't see any clean way of doing this. 
> [...]
> What would be more useful is probably a new rule option, something like
> "also_on_reverse:successful-admin". Such an option could do the same job as
> reversing the network ranges (i.e. from "$EXTERNAL_NET any -> $HOME_NET
> 1434" to "$HOME_NET any -> $EXTERNAL_NET 1434"), and changes the classtype
> to successful-admin. Does that sound too insane? 

Jason,

you are right on. I always stress the fact that running stock Snort
rules is not enough. I have a habit of defining 'behavioral' rules.
These typically define the traffic flow that is expected. Any unexpected
traffic, such as a web server establishing connections to the outside,
or a SQL server sending UDP packets to the outside, are caught by those
rules.

The beauty is that I don't even need a signature. I don't care if my web
server is sending traffic to the outside that triggers the CodeRed
signature. What about other, unknown nasties? The mere fact that the web
server is sending data out (instead of just answering incoming web
requests) is reason enough to sound an alert.

Yes, there are valid signatures that might be important to catch in
reverse direction. But in general (at least in my cases) I can cover
that traffic with 'ip any' rules.

Thanks for bringing this topic back up. I think it is important to add
rules to Snort to define your network. Just relying on stock Snort rules
is not enough.

Cheers,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part