Re: stream4 reassembly oddity

[Jeremy Hewlett <jh () sourcefire com>]

On Fri, Jan 07, mark smith wrote:
> then nothing else for that session. Following this the newly
> infected web server starts new sessions, random SYN scanning for new
> vulnerable hosts but doesn't play nice and FINalise the session. 
>
> The stream pp reassembles the first 2 attack packets into an
> uberpacket just fine but never flushes the 3rd attack packet. It
> seems that the stream pp is waiting for some sort of session
> termination to occur before flushing the final attack payload
> packet. 

The stream is only flushed if we see an RST, ACK, FIN (depending on
state), or SEQ numbers differ by a certain amount (different from
stream to stream). You see no flush because none of the above
occurred. Eventually this stream times out and is pruned.

Stream5 should be available for testing in HEAD in the Near Future
(tm). Issues like the above are now properly implemented so you won't
see this type of behavior any longer.

> I've tried setting the session timeout configuration option to be 15
> seconds (which is recognised by snort as seen by the "Session
> timeout: 15 seconds" message at startup) but it doesn't seem to make
> any difference.

The timeout value is only how long a stream is kept in the cache, not
how long an idle stream sits before getting auto-flushed.



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