Snort mailing list archives
A couple of design comments/questions
From: Jason Haar <Jason.Haar () trimble co nz>
Date: Mon, 3 Feb 2003 11:48:43 +1300
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
Current thread:
- A couple of design comments/questions Jason Haar (Feb 02)
- Re: A couple of design comments/questions twig les (Feb 02)
- Re: A couple of design comments/questions Frank Knobbe (Feb 02)