[Snort-devel] Stream5, 129:4 strange alerting behavior

Steven Sturges steve.sturges at ...402...
Wed Mar 19 07:52:57 EDT 2008


Hi Lee--

Based on what I remember off the top of my head from the TCP
spec... If I get some extra time in the next few days, I'll
follow up if this is incorrect (and someone else doesn't chime
in).

A sent a FIN (packet #5 of your example)
B ACK'd that FIN (packet #6)
At this point, the receiver on A's side of the TCP connection
should no longer expect to see data from B, since B ACK'd the
FIN.

This is independent of B sending its own FIN to tell A to
no longer send data.

So the additional data packets that B sends are effectively
being sent on a closed connection.  This part is correct, as
you surmised.

Not sure why you're seeing 14 of those alerts, however that may
be related to TCP Stream reassembly... Can you try this with 2.8.1
RC -- hopefully you can capture a PCAP of the same and just try it
in read-back mode?

Cheers.
-steve

Lee Clemens wrote:
> Hello all,
> 
> I have seen something strange with the Stream5 preprocessor I wanted to ask
> about, since I'm not sure it is alerting with the correct payload
> information.
> 
> The snort interface is connected to a network tap to monitor traffic
> traversing the inside interface of the firewall. I noticed 14 alerts from
> Stream5 (129:3), "Data sent on stream not accepting data".
> 
> After looking at the packet capture of the session, I found exactly 14
> packets within the timeframe and between the same hosts that were in the
> alerts.
> 
> Remote SMTP Host, "A"
> Local SMTP Server, "B"
> 
> A -> B SYN
> A <- B SYN,ACK
> A -> B ACK
> A <- B 220 ... (SMTP banner)
> A -> B FIN,ACK
> A <- B ACK
> A <- B FIN,ACK
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> A <- B FIN,PSH,ACK TCP Retransmission, 220 ...
> 
> 
> The first 7 packets here seem normal (for someone <i>trying</i> to grab my
> SMTP banner anyway) and mostly comply with a legal TCP session (the Remote
> Server never ACK'ed the last FIN).
> 
> Since the session's state never changed from TIME-WAIT to CLOSED, the Local
> Server continued to retransmit the 220. Given the wording of the signature
> and that the frame alerted on had the PSH flag set was sent after both ends
> of the connection sent a (Close) transmission - I can understand why the
> preprocessor alerted to something here.
> 
> The strange part is that all 14 alerts are with Local Server:25 as the
> Source and Remote Server:2387 as the Destination and all with the same exact
> payload (the 220) and timestamp - and there were 14 packets that traversed
> the snort interface between these two hosts during this period.
> 
> Therefore, I'm not sure if this is the correct/intended behavior for Stream5
> to generate 14 alerts with the same payload (the retransmitted FIN,PSH,ACK
> frame) sent only 7 times.
> 
> Kind Regards,
> Lee
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> 




More information about the Snort-devel mailing list