Avis Syn flood iptables

Bonjour,

Sur un serveur web/mail que pensez-vous de la valeur –limit 10/s --limit-burst 50

        $IPTABLES -N SYN_FLOOD
        $IPTABLES -A INPUT -i eth0 -p tcp --syn -j SYN_FLOOD
        $IPTABLES -A SYN_FLOOD -m limit --limit 10/s --limit-burst 50 -j RETURN
        $IPTABLES -A SYN_FLOOD -j DROP

Est-ce que cela n’est pas trop bas ?

Mon avis, c’est qu’avec ces règles il suffit d’envoyer 10 paquets SYN par seconde (ce qui n’est vraiment pas cher) à ton serveur pour le bloquer. J’appelle cela de l’“auto-DoS”.
Pourquoi veux-tu limiter les paquets SYN ?

Bonjour Pascal,

Je veux limiter les paquets SYN car ma machine a reçu le mois dernier des attaques syn_recv sur le port 80…

Je pense que cela permet de contrer un minimum les attaques de type syn flood…

Ensuite je me demande quelle valeur préférable/configuration d’iptables afin de contrer les attaques syn :079

Oui et non.
Oui si le but est de préserver les ressources du serveur.
Non si le but est de préserver la disponibilité des services.

En effet ce type de limitation ne fait aucune distinction entre les paquets SYN légitimes et ceux de l’attaque. Plus le volume du flood est important, moins la limitation laisse de place aux paquets légitime.

La parade classique contre les attaques de type SYN flood est plutôt l’activation des “SYN cookies”, au prix de quelques inconvénients (cf. lien).

En fait cela est d’essayer de préserver les ressources ET les services !

Concernant les syn cookies j’utilise cela :

        # TCP SYN Cookie
        echo 1 > /proc/sys/net/ipv4/tcp_syncookies
        # Maximum de SYN_WAIT
        echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
       # Taille de la fenetre TCP
        echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
        # DoS
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
        echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time

Les SYN cookies étaient déjà activés et cela n’a pas suffi à protéger le serveur de l’attaque ?

A noter que même avec les SYN cookies activés, un SYN flood peut avoir d’autres conséquences : notamment l’occupation de la bande passante s’il est suffisamment important (comme n’importe quel flood, pas grand-chose à faire contre) et la saturation de la table d’état de suivi de connexion de netfilter (nf_conntrack), ce qui l’empêche de gérer de nouvelles connexions.

[quote=“PascalHambourg”]Les SYN cookies étaient déjà activés et cela n’a pas suffi à protéger le serveur de l’attaque ?
[/quote]
Oui, activés sur le serveur.

Par contre de mémoire j’avais plus de 250 SYN_RECV… Je cherche juste a essayer de mitiger ce genre d’attaques pas de l’annuler car pas possible.
En gros essayer de filtrer le plus possible tout en essayant de garder le service “utilisable”…