Contrer une attaque DDOS de type SYN flood sous Linux
Une attaque par déni de services SYN flood est une technique visant à saturer un serveur en envoyant une multitude de paquets TCP, avec le flag SYN. Les connexions sont alors établies vers la machine, mais restent à moitié ouvertes, car le client malveillant (hacker) ne renvoie pas de confirmation (ACK).
Le serveur attend pendant un certain délai la réponse et la connexion semi-ouverte consomme alors un certain nombre de ressources. En multipliant ce type de connexions, le hacker peut arriver à créer un déni de service qui rendra la machine inopérante.
1. Détection d'une l'attaque DDOS SYN flood
Pour détecter la présence de l'attaque, il faut utiliser la commande netstat et repérer la présence des connexions de type SYN_RECV. Si il y a beaucoup de réponses, c'est qu'une attaque est sans doute en cours :
# netstat -an | grep SYN_RECV
tcp 0 0 10.xxx.xxx.xxx 237.177.154.8:25882 SYN_RECV -
tcp 0 0 10.xxx.xxx.xxx 236.15.133.204:2577 SYN_RECV -
tcp 0 0 10.xxx.xxx.xxx 127.160.6.129:51748 SYN_RECV -
tcp 0 0 10.xxx.xxx.xxx 230.220.13.25:47393 SYN_RECV -
Voici une autre commande, un peu plus sophistiquée, qui donnera de meilleures résultats quant à la détection d'une attaque DDOS :
for i in ` netstat -tanpu | grep "SYN_RECV" | awk {'print $5'} | cut -f 1 -d ":" | sort | uniq -c | sort -n | awk {'if ($1 > 3) print $2'}` ; do echo $i; done
2. Contrer une attaque DDOS SYN flood
La dernière commande renvoie plusieurs dizaines de résultats. L'attaque par SYN flood est donc confirmée. Pour la contrer une solution consiste à modifier quelques paramètres du noyau Linux à chaud. Voici les commandes à utiliser en root uniquement :
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1024" > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
Quelques explications :
- La première ligne fait en sorte que la machine ne garde pas en mémoire les demandes de connexion semi-ouverte tant qu'elle n'a pas reçu la confirmation ACK
- La deuxième commande positionne à 1024 le nombre maximum de SYN_WAIT
- Enfin, la variable rp_filter permet de vérifier qu'un paquet arrive bien par l'interface sur laquelle il devrait arriver
Il est possible de paramétrer ses valeurs de façon permanente en modifiant le fichier /etc/sysctl.conf :
# Protection SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_max_syn_backlog = 1024
On pourra ensuite recharger la configuration avec la commande :
sysctl -p /etc/sysctl.conf
Enfin, voici une autre commande qui permet d'utiliser iptables pour bloquer automatiquement toutes les adresses IP qui font du Syn Flood.
for i in ` netstat -tanpu | grep "SYN_RECV" | awk {'print $5'} | cut -f 1 -d ":" | sort | uniq -c | sort -n | awk {'if ($1 > 3) print $2'}` ; do echo $i; iptables -A INPUT -s $i/24 -j DROP; done
On pourra par exemple la mettre en crontab le temps que l'attaque passe...
Note : un grand merci à Korben et Stagueve pour avoir subi cette attaque sur leurs serveurs dédiés pendant toute la journée. Cela nous a fait un peu d'animation sur Twitter et m'a donné de l'inspiration pour écrire ce soir.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
30 Commentaires pour "Contrer une attaque DDOS de type SYN flood sous Linux"
Flux des commentaires de cet article Ajouter un commentaireEn fait avec Korben on avait décidé de s'auto flooder toute la journée histoire de t'inspirer, mission réussie ^^
Merci pour ces explications, j'ai du pain sur la planche! ^^
@Stagueve : mort de rire !
Merci pour ces précieux conseils...
Je m'en vais de ce pas contrôler la config de mes différents serveurs...
Encore merci de ton aide en tt cas...
@Boloms : ouais en cette période il vaut mieux faire attention visiblement.
@Korben : de rien l'ami.
C'est sympa de voir la bonne ambiance et l'entraide régner entre blogeur !
Et puis très instructif ce pitit tuto !!
Bien le bonjour,
Un moyen simple et efficace pour se protéger des attaques du web est de mettre en place mod-security
En plus l'interface web (non-opensource), mais tolérant la supervision de 3 machines gratuitement tout de même est vraiment bien faite est permet de gérer les faux positifs et avoir des stats sur ses attaques
En tous cas merci pour le tuto
Petit coquille au niveau du fichier sysctl.conf c'est:
net.ipv4.tcp_max_syn_backlog = 1024
et pas:
net.ipv4.tcp_max_syn_backlog = 102
Sinon rien à dire c'est du bon boulot réactif
@Nicolargo : j'ai corrigé.
Super conseil je note ces commandes.
Par contre la machine reste évidemment toujours victime possible du SYN flood, ce serait intéressant de savoir à quel point ca réduit sa vulnérabilité. Vous avez pensé faire des tests ?
@Etienne : oui la machine reste sous le coup de l'attaque mais c'est limitée. Pour contrer complètement le DDOS, à part changer d'adresse IP, je ne vois pas trop comment faire.
Je pense pas qu'il y ait encore de moyen de bloquer complètement une attaque DOS, mais ce serait intéressant de chiffrer à quel point ca réduit l'ampleur de l'attaque. Une idée ? Votre machine résiste à combien de SYN par seconde ?
Bonjour à tous,
Je rencontre un problème lorsque j'essaye d'appliquer cette commande "sysctl -p /etc/sysctl.conf":
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
error: "kernel.sysrq" is an unknown key
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_max_syn_backlog = 1024
À votre avis l'error mentionnée risque d'affection quelque chose au serveur ?
Merci pour cet excellent article
@lo0w : d'après ton commentaire l'erreur est "error: "kernel.sysrq" is an unknown key". A première vue, sysrq désigne le système qui permet de débloquer Linux avec des touches spéciales. Tu trouveras des infos là dessus ici.
Sysrq est par défaut désactivé sur les systèmes Linux. Personnellement je pense que cette erreur n'est pas grâve, au pire elle n'a aucun lien avec les attaques DDOS cité ici.
Normalement la bonne syntaxe est :
Si cela ne marche pas, tu peux soit ignorer le message, soit mettre la ligne en commentaire ...
Merci pour ces précieux conseils !
Merci pour cet article
-tanpu ne fonctionne pas, est ce que -tanu fera la même chose ?
# CentOS 5.5
@SckyzO : bizarre, chez moi ça fonctionne sans problème sous CentOS 5.5. Tu lance bien la commande en root ?
Très bonne synthèse, je met en place ces conseils
Merci je reçois des attaques en boucle depuis une semaine cela m'aide... Si vous avez d'autres solution je suis preneur...
Dangereuse la crontab... car un attaquant peut mettre n'importe quelle IP en adresse source d'un paquet. Du coup, ton iptables peut droper des connexion légitimes.
Exemple: l'attaquant envoie une attaque syn flood, avec en adresse source ta propre IP.
Ton script détecte l'attaque, et drop ton adresse IP.
Tu seras blacklisté de ton propre serveur, sauf si tu as une règle spécialement pour toi ^^
Et tu devrais rajouter le nom de l'interface réseau dans la règle.
ex: iptables -A INPUT -i eth0 -s $i/24 -j DROP
Merci pour le tuto.
Question bonus 1 : même si le post commence à dater, on ne sait jamais. Avec l'IPV6 qui se généralise, c'est tout pareil le paramétrage en remplaçant ipv4 par ipv6 ? Apparemment oui, mais mieux vaut être sûr.
Question bonus 2 : ce truc du CERTA qui date de 2001, c'est bien entendu corrigé depuis un bail ?
Merci beaucoup pour ces précieux conseils.
Très bien résumé! Je partage.
Merci pour le tuto
Salut votre présentation fonctionne t'elle toujour ?
Vue qu'il y a maintenant ip6 ?
error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key
D'ou cela peux prévenir ?
Merci beaucoup pour ce tuto,
Il m'a sauvé aujourd'hui, je n'avais pas encore subi ce type d'attaque.
Et Iptable n'arrete pas cette attaque, meme ne bloquant l'adresse IP du Hacker.
malgré la mise l'application de ce tuto, l'attaque est revenu.
Si l'on diminue net.ipv4.tcp_max_syn_backlog = 1024 à beaucoup moins, ex : 128 ou moins,
est ce que cela va bloquer les appli client (web ou autres) ??
Merci beaucoup pour ce tuto très précieux avec tous les attaques qui existe de nos jours.