IDS Evasion with Syncookies

Is it possible that after a destination host (server) sends you a RST packet, you still can continue to send the server some data and continue the connections?

Yes, it is possible, on a Linux server with SynCookies enabled.

sysctl -a | grep net.ipv4.tcp_syncookies

net.ipv4.tcp_syncookies = 1

Steps (howto):

• During the 3-way handshake, the client sends a ACK packet (3rd packet) to the server with a value one more than the expected value.
• The Linux server will response with a RST at the 4th packet. - > fool the IDS that the TCP connection is terminated.
• Then, the client can continue to send EVIL stuff to the server.

Summary:

• TCP SynCookies is used to combat Syn flood (DoS) attack.
• By right, should see a re-transmit of SYN+ACK instead of RST, by the server.
• The faked ACK packet (4th) is just a stray packet (in SynCookies).
• The subsequent GET /EVIL packet (5th), is considered as valid final ACK of three-way handshake since the syn-cookie will match.
• With Snort IDS, the default stream5 policy of "windows" will not be fooled by this because of what it considers an invalid reset sequence number.

Source articles:

• IDS/IPS Evasion - Step 1. Awareness
• IDS/IPS Evasion with SynCookies

Source codes:

• FakeRST (by famousjs)
• Scapy Code for Bad ACK Reset

How TCP SynCookies Work?

So far, TCP Syn-Cookies is only available in Linux (some are turned on by default). Below is an interesting quirk of TCP Syncookies of how it works.

>>> From IDS/IPS Evasion with SynCookies

I will start off by covering the relevant parts of syncookies. There are many types of Denial of service attack, but the most powerful are low rate DoS attacks; attacks that need very little of the attackers resources, but cause major disruption to the attacked host or network. 

One such attack was the SYN flood attack. The attacker would spoof thousands of packets from fake hosts. Since the destination would half-open a connection for each of these, its resources would soon be overwhelmed with these faked connections, and it would then stop acting as it should (either by rejecting new connections, or dropping old ones, or even crashing outright). 

Some clever folks devised TCP Syncookies to combat this problem. Whenever a SYN was received, the connection was not opened by the destination. Instead, it SYN-ACK’d using a ‘magic’ sequence number that it calculated. The calculation involved the IP Source, Destination, TCP Source port and Destination port, along with an unknown random bit of data that only the server would know. No entry was added to the servers table, so its resources would stay free. When the client would ACK, it would increase the sequence number by one. The server would see this ack, and would do the same math it did before to create its magic sequence number, and subtract one from the received number. 

Since the number is only based on the IP, Port, and random number, the numbers should be identical, even though it would not remember the original connection. If the two matched, it would open the connection. Since the magic number was effectively unguessable to the client, this would make it impossible for an attacker to flood the server with a low rate SYN flood attack.