A couple of design comments/questions

[Jason Haar <Jason.Haar () trimble co nz>]

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-users () lists 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