Bug #2639
closedAlert for tcp rules with established without 3whs
Description
I am seeing alerts being created when having a rule for tcp with the flow keyword 'established' while processing packets for a "session" without a 3whs.
To reproduce this we can send a few tcp packets with the psh flag and having some content payload. The rst flag to_client will create the flow.
for i in {1..2}; do sudo hping3 127.0.0.1 -c 1 -d 6 -E match -p 1212 -P -A; done
The rule to test should be like this:
alert tcp 127.0.0.1 any -> 127.0.0.1 1212 ( msg:"RULE:to_server,established #1"; content:"MATCH?"; flow:to_server,established; priority:3; sid:2; )
I'm attaching the pcap, eve.json and fast.log
To workaround this, I put only_stream on every rules.
Files
Updated by Victor Julien over 4 years ago
Can someone turn the tests into a SV test?
Updated by Andreas Herz over 4 years ago
- Assignee changed from OISF Dev to Andreas Herz
Updated by Andreas Herz over 4 years ago
Updated by Victor Julien about 4 years ago
- Assignee changed from Andreas Herz to Victor Julien
- Target version changed from TBD to 6.0.0beta1
We keep 2 levels of 'state' for TCP flows: the flow itself is considered established if it has seen a packet for both sides of the conversation. The TCP session within the flow however, tracks the 3whs. It looks like the `flow` keyword follows the flow's concept of established.
I checked the Snort manual, and it seems the goal of this setting is to track the TCP state. Will have a look at if we can support that.
Updated by Victor Julien about 4 years ago
I think its going to hard to change this. I've done a test and it leads to multiple failures in matching rules against test pcaps. On inspection it turns out there are a couple of cases where we do match on traffic, even though the tcp state < established.
- during startup, while we still try to determine if csum offloading is in use, and it is (this mostly applies to pcaps). In this case the 'flow' is established, but the tcp state isn't because of the bad csums
- in cases of packet loss, where the tcp state tracking may get disrupted. Here a loose concept of 'established' helps with avoiding missed detection
I wonder if we could create specific support for the case in the attached pcap. Perhaps it makes sense to not set the 'flow' state to established if one side only sends error packets, like TCP RST in this case
Updated by Sergey Gladskikh about 4 years ago
I checked the Snort manual, and it seems
But in Suricata Manual (https://suricata.readthedocs.io/en/suricata-4.1.5/rules/flow-keywords.html#flow) it's also stated:
The determination of established depends on the protocol:For TCP a connection will be established after a three way handshake.
Updated by Igor Redko about 4 years ago
during startup, while we still try to determine if csum offloading is in use, and it is (this mostly applies to pcaps). In this case the 'flow' is established, but the tcp state isn't because of the bad csums
I believe this type of problems reside to tcp checksum-check option.
in cases of packet loss, where the tcp state tracking may get disrupted. Here a loose concept of 'established' helps with avoiding missed detection
There is separate midstream option defined in documentation which handles those cases.
Maybe one of ways is to change default values for midstream setting for sake of backward compatibility, but introduce option of 3whs strict check for tcp session.
Updated by Igor Redko about 4 years ago
FWIW suricata 4.1.5 and 5.0.2 also affected.
Updated by Victor Julien over 3 years ago
- Status changed from Assigned to In Review
Updated by Victor Julien over 3 years ago
- Status changed from In Review to Closed