Signature for dropping TCP RST attack

Rules
1

I have recently started using Suricata. I would like to know if there are predefined for well-known TCP attacks like TCP reset attacks and unexpected sequence number issues.

I have found some signatures below. However, I could not find more details about these signatures.

#alert tcp any any → any any (msg:“SURICATA STREAM 3way handshake with ack in wrong dir”; stream-event:3whs_ack_in_wrong_dir; sid:2210000; rev:1;)

#alert tcp any any → any any (msg:“SURICATA STREAM 3way handshake async wrong sequence”; stream-event:3whs_async_wrong_seq; sid:2210001; rev:1;)

Any help would be greatly appreciated. Thanks.

2

Just curious – how is Suricata supposed to differentiate from a legitimate TCP RST and one in a so-called “TCP reset attack”? And how much of a problem is this? These days the only TCP RSTs I hear of in production are used by out-of-line security appliances that want to try to tear down connections.

3

Can the following checks be done

if the TCP RST packet contains a sequence number that is not expected, it can be dropped.
Validating the source IP and MAC of the packet with the host IP and MAC that initated the seesion.

Are these checks done already by the TCP stack or IDS/IPS engines are required to do these ?

4

I don’t understand the point of checking MAC addresses in the real world… they are only significant on the same L2 network. Are you worried about some kind of TCP RST being sent by a local host?

The TCP stack should handle sequence number issues.

Is this for a school project?

Richard

5

Thanks Richard for the quick response. I am trying to understand Suricata’s capabilities as an Intrusion Prevention System (IPS). I have begun exploring TCP attacks and came across the TCP RST attack. I am interested in knowing if any specific Suricata rules need to be developed to counter this attack.

Other TCP attacks that I came across are:

  • Strict TCP handshake check: Dropping all TCP connections if the IDS does not detect the TCP 3-way handshake.

  • Discarding non-syn TCP packets during the TCP handshake.

As per your explanation, I understand that the TCP RST packet checks will be taken care of by the TCP/IP stack.

What about other TCP DoS attacks? Are there any pre-defined rules in Suricata that can mitigate these attacks?

Thanks in advance.