You raise some good points. Maybe running a second
instance of snort with a different
HOME_NET/EXTERNAL_NET would mitigate the problem. I
agree though, sometimes (many times) it is really
important to see what is leaving your network.
Personally we use layer-2 isolation between our
internal boxes and we don't let our DMZ boxen initiate
connections out unless they have a legit reason to
(DNS...).

--- Jason Haar <Jason.Haartrimble.co.nz> wrote:
> Just some thoughts to start off the week:
>
> I'm running snort probably like most others; I
> define the internal
> address-space, then define EXTERNAL as everything
> else.
>
> Most rules work 'round that assumption: the rules
> search for matches from
> external addresses hammering at internal addresses.
> I *assume* the main
> reasons for that is to allow management to see how
> necessary information
> security infrastructure is (ahem), ...and to cut
> down on false positives? [I
> ran snort for some time with both internal and
> external being defined as
> "any" - to see the differences, and the biggest
> issue I found was the *huge*
> increase in false positives, effectively making it
> impossible to use live
> that way]
>
> 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.
>
> A good example is the current MS-SQL Sapphire worm -
> like most sites we are
> "by default" immune to it as our perimeter firewall
> doesn't allow incoming
> connections on non-desired ports - so the current
> alert of:
>
> alert udp $EXTERNAL_NET any -> $HOME_NET 1434
> (msg:"MS-SQL Worm propagation
> attempt"; content:"|04|"; depth:1; content:"|81 F1
> 03 01 04 9B 81 F1 01|";
> content:"sock"; content:"send";
> reference:bugtraq,5310;
> classtype:misc-attack; reference:bugtraq,5311;
> reference:url,vil.nai.com/vil/content/v_99992.htm;
> sid:2003; rev:2;)
>
> ...is of no use to us - except to prove that our
> firewall is working ;-)
>
> 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?
> Simply making more of the
> alerts "any any" doesn't really help, as they would
> appear under the same
> classtype - when they are actually more urgent.
>
> In fact, this does bring up another question: the
> usefulness of the current
> "classtype" option. One thing I'm really missing
> from snort is the ability
> to trigger alerts on some cleanly-defined situations
> - such as noticing that
> a LAN box is attempting to upload CodeRed/Sapphire
> onto a remote box.
> Currently if I look at our Snort alerts DB, I see
> tonnes of priority 1
> events - but they're all things like incoming
> CodeRed - of no consequence.
> Currently I rely on writing good swatch triggers so
> that I only trigger
> email alerts when snort sees a LAN to Internet
> event, but given the
> existing fine-grain classifications within snort, I
> venture this really is a
> snort issue, and not an post-filtering issue.
>
> Shouldn't snort look at classifying "you've been
> compromised" as higher than
> "they've been compromised"? Perhaps a priority 0
> would be easiest? :-)
>
> Anyway, just some thoughts...
>
> --
> Cheers
>
> Jason Haar
> Information Security Manager, Trimble Navigation
> Ltd.
> Phone: +64 3 9635 377 Fax: +64 3 9635 417
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063
> 5EBB FE1D 66D1
>
>
>
-------------------------------------------------------
> 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

=====
-----------------------------------------------------------
Know yourself and know your enemy and you will never fear defeat.
-----------------------------------------------------------

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-------------------------------------------------------
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

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