[Snort-devel] 'DECODE_TCP_MUST_ACK' and 'DECODE_TCP_NO_SYN_ACK_RST' in combination with FreeBSD and Darwin

Russ Combs rcombs at ...402...
Tue Aug 20 08:35:02 EDT 2013


Thanks for reporting the issue.  I'll open a bug.

To handle this correctly, we'll have to alert in stream5 based on OS.

On Tue, Aug 20, 2013 at 5:11 AM, Bram <bram-fabeg at ...3414...> wrote:

> 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<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/ <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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130820/de44035b/attachment.html>


More information about the Snort-devel mailing list