Quand votre serveur subit une attaque, « on se fait DDoS » n'est pas exploitable ; « SYN flood, quatre millions de paquets par seconde, sources usurpées, ciblant le port 443 » l'est. La différence entre les deux tient à une capture de paquets de trente secondes et un examen structuré de celle-ci. Ce guide couvre la capture en toute sécurité sur une machine déjà saturée (tcpdump, pas l'interface graphique de Wireshark), le workflow de tri dans Wireshark (Protocol Hierarchy, Conversations, I/O Graphs) et les signatures de filtres d'affichage des vecteurs d'attaque courants, pour terminer sur la façon de transformer les constats en mitigation.

La mise en réseau peut sembler intimidante au début, mais avec la bonne approche, vous pouvez transformer un simple serveur virtuel en un backbone de routage performant qui s'étend de votre labo à domicile jusqu'à un VPS cloud. Ce guide explique comment construire une telle topologie avec VyOS. À la fin, vous aurez un routeur à domicile, un routeur VPS public, un tunnel sécurisé entre les deux, et le routage pour plusieurs sous-réseaux internes.

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

Le dimensionnement d'un serveur échoue le plus souvent de deux façons : payer des cœurs qui tournent au ralenti à 3% pendant un an, ou découvrir au lancement que l'ensemble de données actif de la base ne tient pas en RAM. Les deux erreurs viennent du fait de sauter la même étape : dimensionner à partir de la charge de travail plutôt qu'à partir d'une liste de prix. Ce guide vous donne la méthode (référence, marge, croissance), les règles empiriques par charge de travail pour le CPU, la RAM, le stockage et la bande passante, et une réponse honnête sur quand privilégier le scale up ou le scale out.

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.