[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-devel
Subject:    Re: [Snort-devel] Stream5, 129:4  strange alerting behavior
From:       "Lee Clemens" <snort () leeclemens ! net>
Date:       2008-03-20 1:44:22
Message-ID: 00a601c88a2b$ee9db980$c921de0a () edl1314rmfsp7
[Download RAW message or body]

I just [configure/make/make install]'ed snort 2.8.1.rc with the same
configure options and executed snort with the same snort.conf as 2.8.0.2, so
the only change was to read from a pcap of the 14 frames below (from
original session) (-r <pcap>).

Unfortunately, I still received 14 alerts, all with a payload of the
FIN,PSH,ACK retransmissions - the same as before.

--Lee

-----Original Message-----
From: Steven Sturges [mailto:steve.sturges@sourcefire.com] 
Sent: Wednesday, March 19, 2008 7:53 AM
To: Lee Clemens
Cc: 'Snort Developers Postings'; bugs@snort.org
Subject: Re: [Snort-devel] Stream5, 129:4 strange alerting behavior

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> 



-------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel
[prev in list] [next in list] [prev in thread] [next in thread]