Snort mailing list archives
Re: What is the relationship
From: SN ORT <snort_on_acid () yahoo com>
Date: Mon, 10 Jan 2005 10:30:19 -0800 (PST)
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
Current thread:
- Re: What is the relationship SN ORT (Jan 10)