Re: What is the relationship

[SN ORT <snort_on_acid () yahoo com>]

Guess I kinda like it with the few ports configured,
since those would be the only ports allowed through my
firewall. Also depends upon the placement of your IDS.
 Before or after the FW? So IMHO, I'd want to know
about fragmented attacks only on traffic allowed
through. At this point the engine would be working
overtime for nothing if I had it keeping track of
every session.

Then again, it depends as well if you want to watch
outgoing traffic as well if you allow unhindered
outbound traffic. Personally, I would not watch all
inside-established streams, but rather would depend
upon the non-fragmented attack alerts.

So, my vote, if there is one to be had, would be to
watch only certain ports, most of which would be
directed at our public servers.

Cheese!

Marc


--__Original Message--__--

Message: 3
Date: Mon, 10 Jan 2005 10:57:07 +1300
From: Jason Haar <Jason.Haar () trimble co nz>
Organization: Trimble Navigation
To:  snort-users () lists sourceforge net
Subject: Re: [Snort-users] What is the relationship
between flow: and stream4_reassemble?

Brian Caswell wrote:

> On Jan 8, 2005, at 6:14 PM, Jason Haar wrote:
>
> > e.g. does it mean that if you have a rule that
needs to look for 
> > content that may cross a packet boundary, then it
will fail unless 
> > that port is listed in stream4_reassemble?
>
>
> yes.

Isn't that serious? I mean:

 egrep "^alert tcp .* any -> .* any .*content:"
/etc/snort/rules/*rules|wc

shows 64 rules that match - so they will not reliably
work unless the 
ports used just *happen* to match those listed by
stream4_reassemble?

[Actually, "reliably" is the wrong word -
"consistently" would be a 
better choice]

So standard fragmentation attacks would bypass these
rules?

Shouldn't Snort default to setting stream4_reassemble
to reassemble ALL 
ports - to remedy this? I appreciate this would
seriously affect 
performance - but isn't this a fundamental design
issue? It appears to 
be that the default state of Snort is that the
official rules do not 
consistently catch events due to this preprocessor
setting. The 
documentation could state that better performance
could be gained by 
going back to a fixed number of ports - but that would
mean a loss in 
capability to handle fragmentation events/etc. Or at
least have 
commented out lines like:

# If you want to be sure you are reconstructing all
packets so as to 
ensure all the rules
#trigger even on fragmented streams, you should enable
"ports all" instead.
#Note that this will have a serious performance
impact.
#preprocessor stream4_reassemble ports all

Jason


--__--__--


                
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
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