'DECODE_TCP_MUST_ACK' and 'DECODE_TCP_NO_SYN_ACK_RST' in combination with FreeBSD and Darwin

[Bram <bram-fabeg () mail wizbit be>]

Hi,


The TCP implementation on FreeBSD (and by extension on Darwin) appears  
to contain a bug which causes it to send a 'TCP FIN' without a 'TCP  
ACK'.
This then results in the alerts:
* WARNING: TCP has no SYN, ACK, or RST
* WARNING: TCP PDU missing ack for established session

For FreeBSD I found a bug report about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=168842 - kern/168842: [tcp]  
FreeBSD hosts are sending TCP packets with FIN flag and no ACK set

I've attempted to reproduce this using a FreeBSD livecd but so far  
have failed - so there might be some 'special' circumstances in which  
this happen.
I have however managed to capture the TCP stream of one of the clients  
that triggered both rules.

Looking at the other data from the source IP indicates that this was  
coming from an iPhone (HTTP User-agent contains: "iPhone; CPU iPhone  
OS 6_1_3 like Mac OS X")
This is also confirmed by looking up the mac address  
vendor/manufacturer (http://www.macvendorlookup.com/ indicates 'Apple  
Inc')

Looking at the captured stream shows similar behaviour as in the  
FreeBSD bug report but with different intervals in the syn resents..


Config:
        dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/

	alert ( msg:"DECODE_TCP_MUST_ACK"; sid:422; gid:116; rev:2;  
metadata:rule-type decode; )
	alert ( msg:"DECODE_TCP_NO_SYN_ACK_RST"; sid:423; gid:116; rev:2;  
metadata:rule-type decode; )

        output alert_fast: stdout

Running it:
	$ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/ -r  
/tmp/116_422_2.cap 2>&1   | grep '116:'
	07/31-11:10:05.586962  [**] [116:423:2] (snort_decoder) WARNING: TCP  
has no SYN, ACK, or RST [**] [Priority: 0] {TCP} 192.168.32.101:60705  
-> 54.214.17.96:80
	07/31-11:10:05.586962  [**] [116:422:2] (snort_decoder) WARNING: TCP  
PDU missing ack for established session [**] [Priority: 0] {TCP}  
192.168.32.101:60705 -> 54.214.17.96:80



If this is left unchanged then the 'DECODE_TCP_MUST_ACK' and  
'DECODE_TCP_NO_SYN_ACK_RST' become less useful (IMHO): each time the  
alert is generated it should be checked if this was a 'FIN' packet  
(coming from FreeBSD/Darwin) or something else..
If it's a 'FIN' packet then it is 'expected' that the alert is  
generated and then it can be ignored.
If it's not a 'FIN' packet then a deeper look is needed since  
something odd/malicious could be happening.

What I'm not sure about is how to 'fix' this (if a fix is needed)..

My first thought was to check the state of the tcp session and ignore  
the 'FIN' without 'ACK' when the state is 'SYN_SENT' but the decoder  
does not appear to track the state;
Another possible fix would be to add a specific alert for the 'FIN'  
packet and *not* generate the  
'DECODE_TCP_MUST_ACK'/'DECODE_TCP_NO_SYN_ACK_RST';
Yet another 'fix' would be to mention this in the documentation of both rules;



Best regards,

Bram


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Attachment: 116_422_2.cap
Description:

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!