OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Frank Knobbe (fknobbe_at_knobbeits.com)
Date: Sun Feb 02 2003 - 23:06:25 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (FreeBSD)

    iD8DBQA+PfjQpo+MRgtrF98RAsQJAKCFNPHubCmcMHV70sJDOUC8yYAecwCeKncf
    VmETwQEuX3IVWRR2noAb6wk=
    =MZAy
    -----END PGP SIGNATURE-----

    -------------------------------------------------------
    This SF.NET email is sponsored by:
    SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
    http://www.vasoftware.com
    _______________________________________________
    Snort-users mailing list
    Snort-userslists.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