Contrer une attaque DDOS de type SYN flood sous Linux


XSS Cross site scripting
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.


29 Commentaires pour "Contrer une attaque DDOS de type SYN flood sous Linux"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    En 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! ^^

    RépondreRépondre
    Stagueve , le 13 mai 2009 à 20:12
  •  

    @Stagueve : mort de rire !

    RépondreRépondre
    pti-seb , le 13 mai 2009 à 20:18
  •  

    Merci pour ces précieux conseils...

    Je m'en vais de ce pas contrôler la config de mes différents serveurs...

    RépondreRépondre
    Boloms , le 13 mai 2009 à 21:00
  •  

    Encore merci de ton aide en tt cas...

    RépondreRépondre
    Korben , le 13 mai 2009 à 21:01
  •  

    @Boloms : ouais en cette période il vaut mieux faire attention visiblement.

    @Korben : de rien l'ami.

    RépondreRépondre
    pti-seb , le 13 mai 2009 à 21:50
  •  

    C'est sympa de voir la bonne ambiance et l'entraide régner entre blogeur !
    Et puis très instructif ce pitit tuto !!

    RépondreRépondre
    Nshoky , le 14 mai 2009 à 10:24
  •  

    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 ;)

    RépondreRépondre
    pydubreucq , le 14 mai 2009 à 11:16
  •  

    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 :)

    RépondreRépondre
    Nicolargo , le 14 mai 2009 à 12:30
  •  

    @Nicolargo : j'ai corrigé.

    RépondreRépondre
    pti-seb , le 14 mai 2009 à 13:40
  •  

    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 ?

    RépondreRépondre
    Etienne , le 17 mai 2009 à 15:24
  •  

    @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.

    RépondreRépondre
    pti-seb , le 17 mai 2009 à 15:32
  •  

    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 ?

    RépondreRépondre
    Etienne , le 1 juin 2009 à 15:49
  •  

    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 ;-)

    RépondreRépondre
    lo0w , le 15 juin 2009 à 02:07
  •  

    @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 :

    kernel.sysrq = 1

    Si cela ne marche pas, tu peux soit ignorer le message, soit mettre la ligne en commentaire ...

    RépondreRépondre
    pti-seb , le 16 juin 2009 à 00:23
  •  

    Merci pour ces précieux conseils !

    RépondreRépondre
    ireo , le 18 juin 2009 à 12:30
  •  

    Merci pour cet article :)

    RépondreRépondre
    forum flood , le 20 février 2011 à 16:42
  •  

    -tanpu ne fonctionne pas, est ce que -tanu fera la même chose ?
    # CentOS 5.5

    RépondreRépondre
    SckyzO , le 6 avril 2011 à 14:13
  •  

    @SckyzO : bizarre, chez moi ça fonctionne sans problème sous CentOS 5.5. Tu lance bien la commande en root ?

    $ cat /etc/redhat-release
    CentOS release 5.5 (Final)
    $ netstat -tanpu | wc -l
    137

    RépondreRépondre
    pti-seb , le 6 avril 2011 à 14:43
  •  

    Très bonne synthèse, je met en place ces conseils :)

    RépondreRépondre
    Benoist , le 18 avril 2011 à 11:36
  •  

    Merci je reçois des attaques en boucle depuis une semaine cela m'aide... Si vous avez d'autres solution je suis preneur...

    RépondreRépondre
    Itachi , le 7 septembre 2011 à 12:54
  •  

    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

    RépondreRépondre
    Groskéké , le 29 mars 2012 à 18:10
  •  

    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 ?

    RépondreRépondre
    PomCompot , le 2 juillet 2012 à 15:18
  •  

    Merci beaucoup pour ces précieux conseils.

    RépondreRépondre
    ddos protection , le 6 février 2013 à 00:34
  •  

    Très bien résumé! Je partage.

    RépondreRépondre
    DDoS Protection , le 30 avril 2013 à 15:20
  •  

    Merci pour le tuto :)

    RépondreRépondre
    Nemri , le 1 mai 2013 à 16:18
  •  

    Salut votre présentation fonctionne t'elle toujour ?
    Vue qu'il y a maintenant ip6 ?

    RépondreRépondre
    linax , le 5 octobre 2013 à 12:49
  •  

    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 ?

    RépondreRépondre
    Maxime , le 28 octobre 2013 à 00:39
  •  

    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.

    RépondreRépondre
    DV , le 30 janvier 2014 à 13:21
  •  

    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) ??

    RépondreRépondre
    DV , le 30 janvier 2014 à 13:38
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum