Snort mailing list archives
Re: flow_depth and WMF exploit
From: purplebag <purplebag () gmail com>
Date: Wed, 4 Jan 2006 22:08:38 -0500
On 1/4/06, Frank Knobbe <frank () knobbe us> wrote:
On Wed, 2006-01-04 at 12:33 +1300, Jason Haar wrote:The "fix" is to set flow_depth to zero - which apparently will/might effectively DoS your IDS on a busy network. So it's not much of a fix. Also, I get the impression flow_depth only ever looks at the first packet?Hi Jason, here an excerpt from README.http_inspect: ---8<--- * flow_depth [integer] * [...] This value can be set from -1 to 1460. A value of -1 causes Snort to ignore all server side traffic for ports defined in "ports." Inversely, a value of 0 causes Snort to inspect all HTTP server payloads defined in "ports" (note that this will likely slow down IDS performance). Values above 0 tell Snort the number of bytes to inspect in the first packet of the server response. --->8--- I'm not quite sure how to read that, but from the performance collapse of flow_depth 0, I think 0 truly means ALL packets (or all data in the stream). I don't think 0 means 1460. As such, there is probably no limit. But you can inspect only, say two packets. It's either the max of one, or all data. (someone please correct me where I'm wrong).Is that the case, and if so, are there better ways of doing it? Reading returned HTTP data seems to me to be rather a necessary act for an IDS...Heh... it would certainly helps ;) There were several rules that people wrote to detect content on web pages. With the default settings, Snort would never get to that content. It would evaluate 300 bytes, which covers the header, and providing there are no massive cookies set, part of the web page. Usually that part is <html><head>, scripts and stuff, but by the time you reach <body>, you are most likely past the 300 bytes. So all rules trying to detect stuff like "terrorist" on a web page would never fire (unless terrorist is in a meta-tag way on top of the html content... ;)
I would phrase that as: hard to inspect from any network or host based system that is not directly charged with controlling the content served. A seriously powerful proxy ( that does not exist today ) would be needed to handle these things on the network with any amount of confidence. Host based techniques would also fail in most cases if someone really wants to get content to the browser.
At the end of the day, Snort will probably remain to detect intrusions after they happened, not while they are happening (meaning, watching the HTTP or SMTP content). However, I still like to be able to see gzipped HTTP content. :)
How would you propose handling inline content that is encoded inline in the document and served over http as a gzip stream? Further complicate that by creating a javascript object that is itself embedded and encoded and writes out the suspect content in a random place within the document. http://www.w3.org/TR/REC-html40/struct/objects.html Inline vs. external data. Data to be rendered may be supplied in two ways: inline and from an external resource. While the former method will generally lead to faster rendering, it is not convenient when rendering large quantities of data. Here's an example that illustrates how inline data may be fed to an OBJECT: <P> <OBJECT id="clock1" classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502" data="data:application/x-oleobject;base64, ...base64 data..."> A clock. </OBJECT> Bottom line is wrong tool for the job.
It's a bit of concern, but an IDS is an Intrusion Detection System, not a web filter :) We should probably use screening web proxies for that purpose.
BINGO! -- Purple Bag Society of the Crown ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ 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:
- flow_depth and WMF exploit Jason Haar (Jan 03)
- Re: flow_depth and WMF exploit Frank Knobbe (Jan 04)
- Re: flow_depth and WMF exploit purplebag (Jan 04)
- Re: flow_depth and WMF exploit Jason Haar (Jan 04)
- Re: flow_depth and WMF exploit Matthew Watchinski (Jan 05)
- Re: flow_depth and WMF exploit Frank Knobbe (Jan 05)
- Re: flow_depth and WMF exploit Jason (Jan 05)
- Re: flow_depth and WMF exploit Frank Knobbe (Jan 05)
- Re: flow_depth and WMF exploit Jason (Jan 05)
- Re: flow_depth and WMF exploit Frank Knobbe (Jan 05)
- Re: flow_depth and WMF exploit Jason (Jan 05)
- Re: flow_depth and WMF exploit Jason Haar (Jan 05)
- Re: flow_depth and WMF exploit purplebag (Jan 04)
- Re: flow_depth and WMF exploit Frank Knobbe (Jan 04)
- <Possible follow-ups>
- RE: flow_depth and WMF exploit Ron Jenkins (Jan 03)