[Stream5] "FIN inside r_last_ack, bailing" Message for [FIN, PSH, ACK] LEN != 0 Packets

[Henry Yuan <forwardmy () gmail com>]

Hi,

I am studying the Stream5 pre-processor, my understanding is that the
Stream5 unit keeps tracking of TCP flows, and it rebuilds one or more
pseudo-packets when the TCP connection is successfully terminated.

I ran the Snort in IDS mode with debug option to inspect the following
TCP transmission packets: (A is client, B is server).

I got message "FIN inside r_last_ack, bailing" for Packet 12, and this
TCP flow was not successfully terminated either.

---------------------------------------------------------------------------------------------------------------------------
No.     Time   Source     Destination   Protocol Info
      1 0.000000    A         B       TCP      46057 > 1521 [SYN]
Seq=0 Win=5840 Len=0 MSS=1460 TSV=2310610926 TSER=0 WS=2
      2 0.000031    B         A       TCP      1521 > 46057 [SYN, ACK]
Seq=0 Ack=1 Win=3792 Len=0 MSS=960 TSV=93595 TSER=2310610926 WS=7
      3 0.000129    A         B       TCP      46057 > 1521 [ACK]
Seq=1 Ack=1 Win=5840 Len=0 TSV=2310610926 TSER=93595
      4 0.000217    A         B       TCP      46057 > 1521 [ACK]
Seq=1 Ack=1 Win=5840 Len=948 TSV=2310610926 TSER=93595
      5 0.000230    B         A       TCP      1521 > 46057 [ACK]
Seq=1 Ack=949 Win=5760 Len=0 TSV=93595 TSER=2310610926
      6 0.000236    A         B       TCP      46057 > 1521 [ACK]
Seq=949 Ack=1 Win=5840 Len=948 TSV=2310610926 TSER=93595
      7 0.000249    B         A       TCP      1521 > 46057 [ACK]
Seq=1 Ack=1897 Win=7680 Len=0 TSV=93595 TSER=2310610926
      8 0.000258    A         B       TCP      46057 > 1521 [PSH, ACK]
Seq=1897 Ack=1 Win=5840 Len=948 TSV=2310610926 TSER=93595
      9 0.000264    B         A       TCP      1521 > 46057 [ACK]
Seq=1 Ack=2845 Win=9600 Len=0 TSV=93595 TSER=2310610926
  10 0.000269      A         B       TCP      46057 > 1521 [ACK]
Seq=2845 Ack=1 Win=5840 Len=948 TSV=2310610926 TSER=93595
     11 0.000275   B         A       TCP      1521 > 46057 [ACK] Seq=1
Ack=3793 Win=11392 Len=0 TSV=93595 TSER=2310610926
     12 0.000379   A         B       TCP      46057 > 1521 [FIN, PSH,
ACK] Seq=3793 Ack=1 Win=5840 Len=419 TSV=2310610926 TSER=93595
     13 0.000555   B         A       TCP      1521 > 46057 [FIN, ACK]
Seq=1 Ack=4213 Win=13312 Len=0 TSV=93595 TSER=2310610926
     14 0.000704   A         B       TCP      46057 > 1521 [ACK]
Seq=4213 Ack=2 Win=5840 Len=0 TSV=2310610927 TSER=93595
---------------------------------------------------------------------------------------------------------------------------

I checked the source code that sent out this message in
Snort_stream5_tcp.c file.

---------------------------------------------------------------------------------------------
 if(p->tcph->th_flags & TH_FIN)
    {
        STREAM5_DEBUG_WRAP(DebugMessage(DEBUG_STREAM_STATE,
                    "Got an FIN...\n"););
        STREAM5_DEBUG_WRAP(DebugMessage(DEBUG_STREAM_STATE,
                    "   %s state: %s(%d)\n", l,
                    state_names[talker->s_mgr.state],
                    talker->s_mgr.state););

        STREAM5_DEBUG_WRAP(DebugMessage(DEBUG_STREAM_STATE,
                    "checking ack (0x%X) vs nxt_ack (0x%X)\n",
                    tdb->seq, listener->r_nxt_ack););
        if(SEQ_LT(tdb->seq,listener->r_nxt_ack)) <<<<---------This is
the problem
        {
            STREAM5_DEBUG_WRAP(DebugMessage(DEBUG_STREAM_STATE,
                        "FIN inside r_last_ack, bailing\n"););
            goto dupfin;
        }
        else
        {
            listener->r_nxt_ack++;
---------------------------------------------------------------------------------------------

The message was sent out because "tdb->seq,listener->r_nxt_ack" , that
is, the sequence number is this packet is less than the next expecting
ack sequence number in the TCP tracker.


Basically, Stream5 processes ACK flag first, and then the FIN flag.

In most cases, the FIN packet has LEN=0, therefore, r_nxt_ack is not
updated for the FIN packets, and the message "FIN inside r_last_ack,
bailing" is not triggered.

However, in the Packet 12 shown above, it's a packet with [FIN, PSH,
ACK] flags and data LEN = 419. Therefore, when Steram5 process ACK and
the packet payload, the r_nxt_ack parameter is increased by 419.
Therefore  "tdb->seq,listener->r_nxt_ack" , and the message was sent.

I think Packet 12 should be a valid packet. I'm not sure why there has
to be a "FIN inside r_last_ack, bailing" message for it. Is there some
special requirement for the FIN packets (like LEN has to be 0) ??  Is
there something wrong with my packets??

Thank you for your help in advance.


Regards,
Henry

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel