Dans un précédent tutoriel, je vous présentais un type d’attaque DOS/DDOS particulière : Le SYN Flood.
Après l’avoir lu vous pouvez vous demander comment protéger votre serveur Linux de ce type de cyberattaque.
Iptables est un pare-feu à filtre de paquets basé sur le noyau Linux. Les modules iptables sont présents dans le noyau lui-même, il n’y a pas de démon séparé pour cela. Cela rend le pare-feu très rapide et efficace.
Les règles d’Iptables contrôlent le trafic entrant et sortant sur un périphérique réseau.
Avec de bons réglages réseaux, vous pouvez atténuer ces attaques par déni de service.
Dans ce tutoriel, je vous explique comment bloquer un SYN flood avec iptables pour protéger votre votre VPS, serveur dédié, cloud, bare metal en Linux.
Table des matières
Comment bloquer un SYN flood avec iptables
Voici deux méthodes pour atténuer les attaques SYN Flood.
Notez que si l’attaque est trop importante et vont au delà des ressources matériel du serveur, iptables ne pourra pas faire de miracle.
Toutefois, une bonne configuration permet de survivre aux Syn Flood peu importants.
Cette attaque et d’autres formes d’attaques DOS/DDOS peuvent être bloquées en limitant les paquets de demande de connexion TCP entrants. Il est important de noter que nous ne devons pas limiter les demandes de connexions établies. Pour éviter ce type d’attaque, seules les nouvelles demandes de connexion doivent être contrôlées.
De plus, le nombre de demandes qu’un serveur peut traiter dépend des ressources disponibles du serveur.
Ainsi, dans l’exemple ci-dessous, la limite sur la connexion TCP doit être modifiée en fonction de la capacité du serveur.
- Editer le fichier sysctl.conf :
vim /etc/sysctl.conf- Puis à la fin, ajoutez :
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_synack_retries = 3 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 10
- Passez la commande suivante pour prendre en compte les modifications :
sysctl -p /etc/sysctl.conf- Enfin passez les commandes suivantes :
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROPVoici les explications :
- –limite : Spécifie la vitesse à laquelle les jetons sont rechargés dans le seau. 4/heure signifie 4 jetons par heure (1 jeton toutes les 15 minutes).
- –limite-burst : Spécifie la quantité maximale de jetons qui peuvent être remplis dans le seau. (C’est aussi la quantité de jetons avec laquelle le seau commence).
Il peut aussi être judicieux de filtrer les paquets avec des valeurs MSS anormaux.
En effet, cela peut être utilisés par certaines attaques SYN Flood.
Par exemple :
iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
Méthode 2 – règles iptables + SYNPROXY
L’objectif de SYNPROXY est de vérifier si l’hôte qui a envoyé le paquet SYN établit réellement une connexion TCP complète ou s’il ne fait rien après avoir envoyé le paquet SYN.
S’il ne fait rien, il rejette le paquet avec un impact minimal sur les performances.
Editer le fichier sysctl.conf :
vim /etc/sysctl.conf- Puis à la fin, ajoutez :
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_synack_retries = 3 net.netfilter.nf_conntrack_tcp_loose = 0 net.netfilter.nf_conntrack_max = 2000000
- Passez la commande suivante pour prendre en compte les modifications :
sysctl -p /etc/sysctl.conf- Enfin passez les commandes suivantes :
iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROPCes règles s’appliquent à tous les ports. Si vous souhaitez utiliser SYNPROXY uniquement sur certains ports TCP actifs (recommandé – vous devriez également bloquer tous les ports TCP qui ne sont pas utilisés à l’aide de la table mangle et de la chaîne PREROUTING), vous pouvez simplement ajouter -dport 80 à chacune des règles si vous souhaitez utiliser SYNPROXY sur le port 80 uniquement.
Pour vérifier que SYNPROXY fonctionne, vous pouvez faire :
watch -n1 cat /proc/net/stat/synproxy
Si les valeurs changent lorsque vous établissez une nouvelle connexion TCP sur le port sur lequel vous utilisez SYNPROXY, cela signifie que le système fonctionne.
Protection iptables contre les SYN flood : ce qu’il faut savoir
Iptables est le pare-feu qui permet de bloquer et filtrer les connexions.
Mais pour gérer et atténuer les attaques Syn Flood, il faut aussi paramétrer les options réseaux du noyau Linux.
Voici quelques informations supplémentaires.
Le but étant d’adapter les valeurs selon vos besoins qui diffèrent selon le type de serveurs et applications.
A propos du Syn Cookie
Dans ce tutoriel, nous avons modifier les paramètres du noyau Linux à l’aide de sysctl et avons activé le SYN Cookie.
Un SYN Cookie une technique d’atténuation des attaques par laquelle le serveur répond aux requêtes TCP SYN avec des SYN-ACKs modifiés, sans insérer de nouvel enregistrement dans sa file d’attente SYN. Un nouvel enregistrement n’est ajouté que lorsque le client répond à cette réponse élaborée. Cette technique est utilisée pour empêcher la file d’attente SYN du serveur de se remplir en cas d’inondations TCP SYN.
Elle est assez efficace contre inondation de requêtes SYN et accessoirement par IP spoofing.
Toutefois, elle consomme beaucoup de CPU et ne fonctionne que contre les petites attaques.
A lire : https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
Si vous voyez des avertissements SYN flood dans vos journaux, mais une enquête montre qu’ils se produisent
qu’ils se produisent à cause d’une surcharge de connexions légales, vous devriez régler d’autres paramètres jusqu’à ce que cet avertissement disparaisse.
TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.
L’activation de Syn Cookie désactive des extensions TCP telles que TCP_SAVED_SYN, TCP_DEFER_ACCEPT or TCP_FAST_OPEN..
Les valeurs de tcp_max_syn_backlog, net.core.somaxconn et tcp_synack_retries
Linux a une file d’attente relativement petite par défaut, et garde les demandes semi-ouvertes dans la file d’attente jusqu’à 3 minutes. C’est ainsi qu’est née la nécessité de modifier la façon dont le noyau Linux traite ces demandes.
Il faut alors jouer sur les valeurs suivantes :
- net.ipv4.tcp_max_syn_backlog – Combien de connexions semi-ouvertes pour lesquelles le client n’a pas encore envoyé de réponse ACK peuvent être conservées dans la file d’attente (source). Ce sont les connexions avec l’état SYN_RECV. Défaut : 2048
- net.ipv4.net.core.somaxconn – Le nombre maximum de connexions qui peuvent être mises en file d’attente pour acceptation. Ce sont les connexions avec l’état ESTABLISHED. Défaut 4096
- net.ipv4.net.core.netdev_max_backlog Le nombre maximum de paquets dans la file d’attente de réception qui sont passés par l’interface réseau et qui attendent d’être traités par le noyau
- net.ipv4.tcp_synack_retries – Nombre de fois que les SYNACKs pour une tentative de connexion TCP passive seront retransmis être retransmis. Ne doit pas être supérieur à 255. La valeur par défaut par défaut est 5, ce qui correspond à 31 secondes jusqu’à la dernière retransmission avec le RTO initial actuel de 1 seconde. Avec cette valeur, le délai d’attente final pour une connexion TCP passive se produira après 63 secondes.
De bonnes explications sur le blog de Cloudflare : https://blog.cloudflare.com/syn-packet-handling-in-the-wild/
Recycler connexion semi-ouverte
Ceux-ci ne permettent pas une connexion à partir d’une socket « utilisée » (en état d’attente) et forcent les sockets à durer le cycle complet de time_wait. Je recommande de définir :
Cela permet de recycler rapidement les sockets dans l’état time_wait et de les réutiliser.
sysctl net.ipv4.tcp_tw_reuse=1Autre paramètre réseau du noyau Linux
Enfin vous pouvez réduire les délai réseau pour réduire l’impact d’un SYN flood :
net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 10 net.netfilter.nf_conntrack_max = 10000000 net.netfilter.nf_conntrack_tcp_loose = 0 net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10