Les attaques DDoS se répartissent en trois grandes familles : les floods volumétriques qui saturent votre tuyau, les attaques de protocole qui épuisent l'état des connexions, et les floods applicatifs qui ressemblent à du trafic légitime. Chacune épuise une ressource différente, chacune exige donc une défense différente, et aucune couche à elle seule n'arrête les trois. Ce guide met en correspondance les formes d'attaque courantes avec la ressource qu'elles visent et la mitigation qui fonctionne réellement contre elles, explique ce qu'un pare-feu sur le serveur peut arrêter et ce qu'il ne peut pas, et se termine par un plan d'action concret pour la réponse à incident quand votre serveur est attaqué.

Un serveur Linux fraîchement installé ne possède aucune règle de pare-feu. Chaque listener que vous démarrez devient instantanément accessible depuis l'ensemble d'Internet. La solution est une base courte et bien comprise : default-deny en entrée, autoriser le trafic established, et une allow-list explicite pour les services que vous faites réellement tourner. Ce guide construit cette base dans nftables règle par règle, explique les points que tout le monde rate (ICMP et IPv6), montre la même politique dans ufw et firewalld, et explique comment éviter de vous verrouiller vous-même dehors, ainsi que le piège de la publication de ports Docker.

Si votre serveur exécute une distro Debian, Ubuntu ou de la famille RHEL à jour, vos règles « iptables » s’exécutent presque certainement déjà à l’intérieur de nftables. La commande iptables est un shim de compatibilité depuis 2019. La vraie question n’est pas de savoir lequel l’emporte ; c’est de savoir si vous devez continuer à écrire des règles dans une syntaxe legacy par-dessus le nouveau moteur. Ce guide couvre ce qui a réellement changé au niveau architectural, une comparaison de syntaxe côte à côte, ce que disent honnêtement les données de performance, et un chemin de migration qui ne casse pas Docker et ne vous enferme pas dehors.