Project

General

Profile

Actions

Bug #8303

open

Suricata treats flow as established without client ACK

Added by Aneesh Patel 5 days ago. Updated 2 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs Suricata-Verify test, Needs backport to 7.0

Description

We have found some unusual behavior on suricata 7.0.8. To reproduce this, you can set up an instance of suricata 7.0.8 and run it in af-packet mode. You can have a TX interface going into Suricata and a RX interface coming out. I have attached the yaml used alongside the following rule:

drop tcp any any -> any any (msg:"Default TCP Drop"; flowbits:isnotset,blocked-policy-internal-id; flowbits:isnotset,allow-this-policy-internal-id; flow:established; sid:9999907;)

If you use tcpreplay, you can replay the attached pcap on the TX interface and listen on the RX interface. You will see in the pcap that the server sends a SYN-ACK, then sends a FIN-ACK without the client ever sending an ACK. The rule matches on the FIN-ACK, however, which implies that Suricata is treating the connection as established at that point. The behavior you will see is that the FIN-ACK gets dropped, when my belief is that it should not since the TCP handshake never truly completed.

We tested this on 8.0.3 and found that 8.0.3 does not treat this as established and the rule does not match (what I would expect).

Also of note: I have dug a bit and found that per TCP RFC 9293 Section 3.10.4, a FIN can be sent on a SYN-RECEIVED state as well. So if this is expected, my question is why is the behavior different in 8.x? Thanks in advance!


Files

Actions #1

Updated by Aneesh Patel 2 days ago

Hi - I just wanted to follow up and check if there was any update on this one?

Actions

Also available in: Atom PDF