Project

General

Profile

Actions

Bug #2639

closed

Alert for tcp rules with established without 3whs

Added by Paulo Pacheco over 4 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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

no-3whs.tgz (953 Bytes) no-3whs.tgz established-issue-for-non-3whs Paulo Pacheco, 10/10/2018 09:29 AM
Actions #1

Updated by Victor Julien almost 4 years ago

  • Assignee set to OISF Dev
Actions #2

Updated by Andreas Herz over 3 years ago

  • Target version set to TBD
Actions #3

Updated by Victor Julien over 3 years ago

Can someone turn the tests into a SV test?

Actions #4

Updated by Andreas Herz over 3 years ago

  • Assignee changed from OISF Dev to Andreas Herz
Actions #6

Updated by Andreas Herz over 3 years ago

  • Status changed from New to Assigned
Actions #7

Updated by Victor Julien almost 3 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.

Actions #8

Updated by Victor Julien almost 3 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.

  1. 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
  2. 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

Actions #9

Updated by Sergey Gladskikh almost 3 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.

Actions #10

Updated by Igor Redko almost 3 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.

Actions #11

Updated by Igor Redko almost 3 years ago

FWIW suricata 4.1.5 and 5.0.2 also affected.

Actions #12

Updated by Victor Julien over 2 years ago

  • Status changed from Assigned to In Review
Actions #13

Updated by Victor Julien over 2 years ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF