# Syn flood

Une attaque **<span class="tadv-color" style="color: #cf2e2e;">SYN flood</span>** (attaque semi-ouverte) est un type d’attaque par [déni de service (DDoS)](https://www.cloudflare.com/fr-fr/learning/ddos/what-is-a-ddos-attack) qui vise à rendre un serveur indisponible pour le trafic légitime en consommant toutes les ressources serveur disponibles.

<div aria-hidden="true" id="bkmrk-"></div><div id="bkmrk--0"><figure class="aligncenter is-resized">![Progression of a SYN flood.](https://www.imperva.com/learn/wp-content/uploads/sites/13/2019/01/syn-flood.jpg)</figure></div>---

# **Three-way handshake**

<div aria-hidden="true" id="bkmrk--2"></div>L’attaque **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>** exploite le principe du **three-way handshake** du protocole **TCP**.

Lors d’une connexion classique entre un **client** et un **serveur** il y a 3 étapes :

<div aria-hidden="true" id="bkmrk--3"></div> Le client envoie un paquet **SYN**.

 Le serveur répond ensuite avec un paquet **SYN-ACK** accusant la réception.

 Le client envoie un paquet **ACK** et la connexion **TCP** est donc établie.

<div id="bkmrk--4"><figure class="aligncenter">![](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/images/image5.png)</figure></div>---

## Déroulement de l’attaque

<div aria-hidden="true" id="bkmrk--6"></div>En envoyant à plusieurs reprises des paquets de demande de connexion initiale (**SYN**), l’attaquant est en mesure de submerger tous les ports disponibles sur une machine serveur ciblée, ce qui oblige l’appareil ciblé à répondre lentement au trafic légitime, ou l’empêche totalement de répondre.

<div id="bkmrk--7"><figure class="aligncenter">![SYN flood — Wikipédia](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Tcp_syn_flood.png/400px-Tcp_syn_flood.png)</figure></div>Les **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>** sont fréquemment effectuées par des bots se connectant à partir d’**adresses IP usurpées** afin de rendre l’attaque plus difficile à identifier et à atténuer. Les **botnets** peuvent lancer des **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>** en tant qu’[attaques par déni de service distribué (DDoS)](https://www.f5.com/fr_fr/services/resources/glossary/distributed-denial-of-service-ddos-attack).

---

<div aria-hidden="true" id="bkmrk--9"></div>Voilà un exemple d’attaque **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>** &amp; **<span class="tadv-color" style="color: #0693e3;">DNS Flood</span>**:

<div aria-hidden="true" id="bkmrk--10"></div><div id="bkmrk-imperva-mitigates-a-"><figure class="aligncenter">![Imperva mitigates a 38 day-long SYN flood and DNS flood multi-vector DDoS attack.](https://www.imperva.com/learn/wp-content/uploads/sites/13/2019/01/syn-flood-ddos-attack.png)<figcaption>*Imperva mitigates a 38 day-long SYN flood and DNS flood* [multi-vector DDoS attack.](https://www.imperva.com/blog/funded-persistent-multi-vector-ddos-attack/)</figcaption></figure></div>---

## Protéger votre serveur contre le SYN Flood

<div aria-hidden="true" id="bkmrk--12"></div>Dans cet exemple, nous avons **deux machines** en local :

<div aria-hidden="true" id="bkmrk--13"></div> Une machine attaquante : **192.168.1.27**

Une machine victime : **192.168.1.23**

---

Avant de vouloir protéger notre machine, nous allons voir un filtre **<span class="tadv-color" style="color: #00d084;">wireshark</span>** nous permettant de détecter une attaque **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>**.

<div id="bkmrk-1-tcp.flags.syn-%3D%3D-1"><div><div><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td class="gutter"><div>1</div></td><td class="code"><div><div>`tcp.flags.syn == 1 and tcp.flags.ack == 0`</div></div></td></tr></tbody></table>

</div></div></div><div aria-hidden="true" id="bkmrk--15"></div><div id="bkmrk--16"><figure class="aligncenter size-large">![](https://mikadmin.fr/blog/wp-content/uploads/2021/03/image-3-1024x726.png)</figure></div><figure class="wp-block-image size-large" id="bkmrk--17">![](https://mikadmin.fr/blog/wp-content/uploads/2021/03/image-4.png)</figure><div aria-hidden="true" id="bkmrk--18"></div>Comme nous pouvons le voir, nous avons un très grand nombre de **paquets SYN** en destination de notre victime qui est **192.168.1.23** et en provenance d’**adresse IP usurpées**.

---

<div aria-hidden="true" id="bkmrk--20"></div>Nous pouvons aussi détecter une attaque **<span class="tadv-color" style="color: #cf2e2e;">SYN Flood</span>** à l’aide de la commande suivante qui va nous renvoyer le nombre de connexion dans l’état **<span class="tadv-color" style="color: #fcb900;">SYN\_RECV</span>** :

<div aria-hidden="true" id="bkmrk--21"></div><div id="bkmrk-1-netstat--npt-%7C-awk"><div><div><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td class="gutter"><div>1</div></td><td class="code"><div><div>`netstat -npt | awk '{print $6}' | sort | uniq -c | sort -nr | head`</div></div></td></tr></tbody></table>

</div></div></div>---

Il est temps d’ajouter des paramètres nous permettant de **limiter** ce type d’attaque.

<div aria-hidden="true" id="bkmrk--23"></div>Dans un premier temps, nous allons travailler avec le fichier **/etc/sysctl.conf** puis changer les variables suivantes :

<div aria-hidden="true" id="bkmrk--24"></div><div id="bkmrk-1-2-3-4-net.ipv4.tcp"><div><div><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td class="gutter"><div>1</div><div>2</div><div>3</div><div>4</div></td><td class="code"><div><div>`net.ipv4.tcp_syncookies = 1`</div><div>`net.ipv4.tcp_max_syn_backlog = 2048`</div><div>`net.ipv4.tcp_synack_retries = 3`</div><div>`net.ipv4.conf.all.rp_filter = 1`</div></div></td></tr></tbody></table>

</div></div></div>Pour plus d’informations sur ces dernières je vous recommande cet [article](https://linoxide.com/firewall/snapshot-syn-flood-attack/#:~:text=If%20you%20suspect%20a%20SYN,are%20in%20%E2%80%9CSYN_RECEIVED%E2%80%9D%20state.).

---

Nous pouvons également mettre en place des règles **iptables** permettant de **limiter** ceci comme par exemple :

<div aria-hidden="true" id="bkmrk--26"></div><div id="bkmrk-1-2-3-4-5-6-7-8-9-10"><div><div><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td class="gutter"><div>1</div><div>2</div><div>3</div><div>4</div><div>5</div><div>6</div><div>7</div><div>8</div><div>9</div><div>10</div><div>11</div></td><td class="code"><div><div>`# Création d'une nouvelle chaîne nommée syn_flood`</div><div>`iptables -N syn_flood`</div><div> </div><div>`# Match les segments TCP pour cette dernière`</div><div>`iptables -A INPUT -p tcp --syn -j syn_flood`</div><div> </div><div>`# Si la limite match alors on continue à lire les autres règles`</div><div>`iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN`</div><div> </div><div>`# Si ça ne match pas on drop le paquet`</div><div>`iptables -A syn_flood -j DROP`</div></div></td></tr></tbody></table>

</div></div></div><div aria-hidden="true" id="bkmrk--27"></div>Après avoir mis en place ceci on constate que la chaîne **syn\_flood** commence à **DROP** des paquets.

<figure class="wp-block-image size-large" id="bkmrk--28">![](https://mikadmin.fr/blog/wp-content/uploads/2021/03/image-5.png)</figure>