SYN Flood Attack

Intro

To perform a SYN Flood attack, we have to send a lot of SYN messages but without answer back with an ACK message after receiving the SYN-ACK message from the server, in this way we will fill the half-open connection queue.

To perform the experiment I'm using these scripts: https://github.com/0xabi/PyNetAttacks/tree/main/SYN-Flood-Attack

Disable mitigations and configure queue

To do the experiments and to notice the attack's effect, we have to consider disabling the SYN cookie mitigation and to choose the correct queue size.

Disable SYN Cookie

By default, it should be enabled, to check if it's enabled, run:

sudo sysctl -a | grep "cookie"

In my case, I got:

net.ipv4.tcp_syncookies = 1

To disable it, we can run:

sudo sysctl -w net.ipv4.tcp_syncookies=0

TCP Retransmission

After SYN-ACK, the machine will wait the ACK, if not received it will re-transmit SYN-ACK, but by default it will try it for 5 times and then remove the item from the half-open connection queue.

In my case:

sudo sysctl net.ipv4.tcp_synack_retries

gives

net.ipv4.tcp_synack_retries = 5

I increase this value to 20 with:

sudo sysctl -w net.ipv4.tcp_synack_retries=20

TCP Size Queue

The attack's success depends on also by the queue's size

I got the backlog size with:

sudo sysctl net.ipv4.tcp_max_syn_backlog

gives

net.ipv4.tcp_max_syn_backlog = 512

I decrease to 80 with:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=80

TCP Cache

On newer version of many distributions, you can notice that the clients that were connected to the victim before the SYN attack, can continue to communicate with it for a kind of cache mechanism.

You can check the entries with:

ip tcp_metrics show

To delete the entries:

sudo ip tcp_metrics flush

Test

• Disabled SYN-COOKIE and configured the queue's parameters

• Listening on port 8080 with listener python script

• Run the syn flood python script

Normally if I connect to the server with

nc IP 8080

And send something, I should receive a message "ACK: Message received"

After running the script, and trying to send messages with netcat, I didn't receive any message in return, so the attack worked.

Note: if you try to connect with a user that was cached before the attack, the message could be received.

And looking on the connections state with:

netstat -nat

We can count how many connections are in SYN_RECV state i.e. half-opened connection that didn't receive the ACK message, with:

netstat -nat | grep SYN_RECV | wc -l

In my case are 61, the server is not responsive despite I set 80 as backlog size because ¼ of the size are used for the cached user connections.

After the test, we can remove all the connections that are stuck on SYN_RECV state with:

sudo ss --tcp state SYN-RECV --kill  

Possible TCP RST Issue

It's possible that the client will send an RST message during experiments, here explained why: Client sends [RST] after receive [SYN, ACK]

Possible fix is to temporary drop all the RST messages outgoing with:

sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s IPADDR -j DROP

Sources

https://medium.com/@rahulbagul07/seed-labs-tcp-ip-attack-lab-df656b5f3a74 https://www.alibabacloud.com/blog/tcp-syn-queue-and-accept-queue-overflow-explained_599203 https://seedsecuritylabs.org/Labs_20.04/Files/TCP_Attacks/TCP_Attacks.pdf