[Snort-users] Question on stream4 preprocessor
sgt_b at ...11733...
Wed Apr 28 07:04:08 EDT 2004
Let's say an exploit is sent from one host to another, one byte at a
time. It's the stream4_reassemble preprocessor's job to reassemble each
byte of that session into its intended form, and pass that down to the
detection engine. From there the exploit attempt should be detected by
I've tested this, and it works of course.
Here's my question though. As each packet is sent over the wire snort
picks it up one packet at a time. Each packet along the stream is sent
to the detection engine as well. If one of these packets triggers an
alert, what is supposed to happen?
From what I've read, it looks to me like there should be an alert
generated for that packet, as well as the entire stream once the session
is reassembled by stream4.
In practice though, I've noticed some different behavior. In testing
Nessus's Injection TCP NIDS evasion feature, I've notcied some
inconsistencies in Snort's reactions.
I'm testing this using the Apache Chunked encodiing vulnerability
plugin. Utilizing the Injection method, Nessus will send the exploit to
the webserver one character at a time (ie G in one packet, E in the
next, T in another, etc) along with garbage packets in between.
Snort will alert on any of the valid packets that only contain a '.' or
|20| as a libwhisker space splicing attempt. It will not however send
any alerts regarding the Chunked Encoding vulnerability.
At first I questioned stream4, but if I disable the libwhisker rule,
stream4 reassembles the packet just fine, and an alert is issued for the
chunked encoding vulnerability.
Shouldn't two alerts be issued though? One for the libwhisker attempt,
and once the stream is reassembled, one for the chunked encoding
More information about the Snort-users