Snort mailing list archives

Re: A couple of design comments/questions


From: twig les <twigles () yahoo com>
Date: Sun, 2 Feb 2003 17:07:38 -0800 (PST)

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.Haar () trimble 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-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


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