Besoin d'une explication de la règle iptables

Radhil a été trop prudent en supprimant sa réponse, qui est correcte bien que nécessitant une intégration.

Tout d'abord, la signification littérale de la règle : elle abandonne (-j DROP) tous les paquets commençant une nouvelle connexion (-m state --state NEW) qui sont no du type SYN (!--syn) pour le protocole TCP (-p tcp).

Puis quelques commentaires. Dans le protocole TCP, une connexion est initiée par l'échange rituel de trois paquets, SYN (client vers serveur) -> SYN/ACK (serveur vers client)-> ACK (client vers serveur). Une connexion no initiée par le paquet SYN, comme celle rejetée par la règle iptables ci-dessus, est une manière inappropriée d'établir une connexion qui poursuit des objectifs différents, comme l'a correctement souligné radhil.

Cette règle est souvent, et à tort, jugée nécessaire pour supprimer les attaques syn-flood sur le Web : voir par exemple cette page Web où il est explicitement indiqué :

Le prochain modèle à rejeter est une attaque syn-flood.

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Les attaques SYN-Flood signifient que les attaquants ouvrent une nouvelle connexion, mais ne précisent pas ce qu'ils veulent (c'est-à-dire SYN, ACK, etc.). Ils veulent simplement accaparer les ressources de nos serveurs. Nous n'acceptons pas de tels paquets.

Bien sûr, ça n'a aucun sens d'essayer de désamorcer les attaques de Syn-Flood en accepter ( !!!!) paquets SYN pour les nouvelles connexions. Et ça devrait être des paquets, pas des paquets.

Les attaques de Syn-flood posent certains problèmes qui ne sont pas encore complètement résolus. Cela a conduit au développement d'un nouveau module iptables, appelé SYNPROXY, dont vous trouverez peut-être la discussion dans le document suivant aquí . La limitation du débit est souvent utilisée, voir par exemple aquí mais cela pose le problème mentionné dans la référence précédente, c'est-à-dire le module conntrack, qui est nécessaire pour garder la trace des nouvelles connexions, des anciennes et de leur état, fonctionne parfaitement pour un nombre limité de connexions mais consomme une quantité disproportionnée de temps lorsque le nombre de connexions augmente (par exemple, à cause d'une attaque SYN-flood). C'est ce que l'on entend par évolutivité question.

Dans l'ensemble, il n'est pas tout à fait clair pour moi que la règle iptables ci-dessus sert à quelque chose de significatif.

-A INPUT - ajouter à la fin de la chaîne "INPUT".

-p tcp - correspond au protocole TCP

! --syn - correspond aux paquets sans drapeau TCP SYN

-m state - utiliser le module "state" (déprécié ; les nouveaux jeux de règles doivent utiliser "conntrack" à la place)

--state NEW - correspondre aux paquets ayant l'état "NEW" (c'est-à-dire n'appartenant à aucune connexion établie)

-j DROP - saut vers la cible "DROP" (qui est une cible finale qui rejette le paquet)

En principe, les paquets TCP ouvrent une nouvelle connexion (et ont toujours le drapeau SYN), ou appartiennent à une connexion existante, ou tentent de fermer une connexion interrompue (avec le drapeau RST), ou sont des déchets. Cette règle essaie donc d'éliminer les paquets de la dernière catégorie, qui n'essaient pas d'ouvrir une nouvelle connexion ou d'appartenir à une connexion existante.

Je pense que c'est un peu redondant... Peut-être que c'est censé protéger contre les différents types de portscan (comme vu dans nmap). Cela pourrait aussi être de la paranoïa.