VPS pour DDoS : comment protéger son serveur contre les attaques en 2026

Un VPS offre beaucoup de liberté, mais cette liberté implique aussi une responsabilité importante : protéger le serveur contre les attaques réseau et les tentatives d’intrusion. Lorsqu’un site devient lent, qu’un service ne répond plus ou qu’une alerte de sécurité est envoyée par l’hébergeur, il n’est pas toujours simple de savoir s’il s’agit d’une attaque DDoS, d’un brute-force SSH ou d’un simple pic de trafic.✨ C’est précisément pour cette raison qu’il est essentiel de comprendre comment fonctionne la protection d’un VPS pour DDoS.🚀

Une partie de la défense dépend de l’infrastructure de l’hébergeur, notamment contre les attaques réseau massives. L’autre partie dépend de votre configuration système : SSH, pare-feu, Fail2ban, surveillance des logs et protection applicative. ⚡Pour un environnement plus encadré, vous pouvez aussi consulter notre guide pour sécuriser votre environnement serveur contre les attaques, notamment si vous utilisez cPanel.

Objectif

👇L’objectif de ce tutoriel est de vous aider à mettre en place une configuration défensive complète sur un VPS Debian ou Ubuntu. Vous allez comprendre ce qu’est une attaque DDoS, ce que l’hébergeur filtre côté réseau, puis ce que vous devez configurer côté serveur pour limiter les risques au niveau système et applicatif.🎉 À la fin de ce guide, vous saurez distinguer une protection anti-DDoS réseau d’une protection applicative. 🚀Vous disposerez aussi d’une base concrète pour durcir SSH, configurer iptables, installer Fail2ban, surveiller les connexions suspectes et utiliser Cloudflare si votre VPS héberge un site web. 💥L’idée n’est pas de promettre une protection absolue, car aucune configuration ne peut garantir cela. L’objectif est plutôt de réduire fortement la surface d’attaque et d’adopter une stratégie cohérente, combinant protection hébergeur et bonnes pratiques d’administration.

Comprendre les attaques DDoS sur VPS : ce qui se passe réellement

Une attaque DDoS, pour Distributed Denial of Service, consiste à rendre un serveur, un service ou une infrastructure indisponible en l’inondant de trafic ou de requêtes depuis de nombreuses sources. Sur un VPS, les effets peuvent être très visibles : bande passante saturée, charge CPU anormale, mémoire consommée rapidement, serveur web inaccessible ou connexions SSH instables. La documentation LWS rappelle qu’une attaque DDoS vise à rendre un service indisponible en surchargeant la bande passante ou les ressources du serveur.

Le point important à comprendre est que toutes les attaques ne se produisent pas au même niveau. Certaines ciblent directement le réseau, avec un volume massif de paquets. D’autres ciblent les services applicatifs, comme SSH, Apache, Nginx, WordPress ou une API hébergée sur le VPS. C’est cette distinction qui permet de savoir ce que l’hébergeur peut bloquer en amont et ce que vous devez sécuriser vous-même.

Les attaques de couche réseau, comme les floods UDP, ICMP ou certains SYN Floods, doivent idéalement être filtrées avant d’atteindre le VPS. Si le trafic malveillant arrive directement jusqu’à votre interface réseau, votre serveur peut être saturé avant même que vos règles locales aient un effet suffisant. C’est le rôle d’une protection anti-DDoS opérée côté infrastructure.

À l’inverse, les attaques applicatives sont plus difficiles à distinguer d’un trafic normal. Un HTTP Flood peut ressembler à une forte affluence de visiteurs. Un brute-force SSH peut prendre la forme de milliers de connexions échouées réparties sur plusieurs adresses IP. Dans ces cas, votre configuration locale devient indispensable : durcissement SSH, pare-feu, limitation des connexions, bannissement automatique des IP et analyse régulière des logs.

Il faut donc retenir une idée simple : la protection DDoS d’un VPS repose sur deux niveaux complémentaires :

• Le premier niveau est assuré par l’hébergeur, qui filtre les attaques réseau en amont,
• Le second niveau dépend de vous, administrateur du VPS, car vous contrôlez le système, les ports ouverts, les services installés et les règles de sécurité,

La protection anti-DDoS réseau LWS : ce qui est inclus côté infrastructure

Sur les VPS KVM LWS, la protection anti-DDoS réseau est intégrée à l’infrastructure. Sur nos VPS KVM LWS, nous vous offrons un pare-feu physique, d’une protection Anti-DDoS qui analyse et filtre le trafic malveillant, ainsi que d’un réseau autonome pour renforcer la stabilité. Vous disposez aussi de l’accès root, des distributions disponibles comme Ubuntu et Debian, le monitoring des ressources, les sauvegardes quotidiennes et les snapshots gratuits.

Cette protection intervient avant votre serveur. Son rôle est de limiter l’impact des attaques qui cherchent à saturer la bande passante ou à perturber les protocoles réseau. C’est un point important : un pare-feu local comme iptables reste utile, mais il ne remplace pas un filtrage en amont. Si une attaque volumétrique dépasse la capacité réseau disponible pour votre VPS, votre serveur peut devenir inaccessible même avec de bonnes règles système.

Nos infrastructures incluent des dispositifs de sécurité comme un firewall physique de prévention d’attaque, un pare-feu de filtrage IP, un Web Application Firewall et une protection réseau DDoS sur ses services d’hébergement. Les centres de données sont situés en France, et nos datacenters sont certifiés ISO 27001, Tier 3/4, avec surveillance 24/7.

Le fonctionnement du filtre anti-DDoS LWS suit un mécanisme progressif lorsqu’un trafic anormal est détecté. Voici les niveaux décrits dans la documentation d’aide LWS :

Ce fonctionnement montre bien que la protection anti-DDoS peut agir fortement sur le trafic pour préserver l’infrastructure. En cas d’attaque importante, certaines restrictions temporaires peuvent donc être appliquées automatiquement. Ce comportement est normal : l’objectif est de contenir le trafic malveillant et d’éviter qu’il ne perturbe plus largement le service.

En revanche, cette protection réseau ne dispense pas de sécuriser le VPS lui-même. Elle ne remplace pas la configuration SSH, ne choisit pas à votre place les ports ouverts, ne crée pas vos règles iptables et ne surveille pas automatiquement tous vos journaux applicatifs. Elle complète votre configuration, mais ne l’annule pas.

C’est pour cette raison que la suite de notre guide se concentre sur la partie qui relève de l’administrateur : durcir SSH, limiter les connexions suspectes avec iptables, installer Fail2ban, protéger les sites web avec Cloudflare et mettre en place une surveillance régulière.

Besoin d’un VPS avec protection anti-DDoS incluse ?
Les VPS KVM LWS incluent une protection anti-DDoS réseau active dès la commande, sans configuration requise côté client. Ils proposent également un accès root complet, des datacenters français certifiés ISO 27001, des snapshots gratuits et un support 7j/7.
Voir les VPS KVM LWS

Sécuriser SSH : première ligne de défense

SSH est l’un des premiers services ciblés sur un VPS exposé à Internet. Même lorsqu’une attaque DDoS vise surtout à saturer le réseau, il est fréquent d’observer en parallèle des tentatives de brute-force sur le port SSH. Sécuriser cet accès est donc une étape prioritaire avant de configurer le pare-feu ou Fail2ban. L’objectif est simple : réduire les connexions inutiles, empêcher les attaques par mot de passe et limiter l’accès aux seuls utilisateurs autorisés.

1. Changer le port SSH par défaut

Par défaut, SSH écoute sur le port 22. Ce port est constamment scanné par des bots qui recherchent des VPS mal configurés. Le changer ne suffit pas à sécuriser totalement le serveur, mais cela réduit fortement le bruit dans les logs et limite les tentatives automatiques les plus basiques.

Ouvrez le fichier de configuration SSH :

nano /etc/ssh/sshd_config

Recherchez la ligne liée au port SSH, puis remplacez-la par un port non standard, par exemple :

Port 2222

Avant de redémarrer SSH, vérifiez que ce nouveau port sera bien autorisé dans votre pare-feu. C’est un point essentiel : si vous changez le port SSH sans l’ouvrir dans iptables ou dans votre pare-feu système, vous risquez de vous bloquer vous-même.

Redémarrez ensuite le service SSH :

systemctl restart sshd

systemctl restart ssh

ssh -p 2222 votre_utilisateur@IP_DU_VPS

2. Désactiver l’authentification par mot de passe, activer les clés SSH

L’authentification par mot de passe est pratique, mais elle expose le VPS aux attaques brute-force. La meilleure pratique consiste à utiliser une clé SSH : l’utilisateur se connecte avec une clé privée stockée sur son ordinateur, tandis que le serveur connaît uniquement la clé publique autorisée.

Sur votre ordinateur local, générez une paire de clés si vous n’en avez pas encore :

ssh-keygen -t ed25519 -C "votre_email@example.com"

ssh-copy-id -p 2222 votre_utilisateur@IP_DU_VPS

ssh -p 2222 votre_utilisateur@IP_DU_VPS

Une fois la connexion par clé confirmée, modifiez le fichier SSH :

nano /etc/ssh/sshd_config

Ajoutez ou ajustez les paramètres suivants :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Redémarrez ensuite SSH :

systemctl restart sshd

3. Limiter les utilisateurs autorisés

Même avec une clé SSH, il est recommandé de limiter explicitement les comptes autorisés à se connecter au VPS. Cette règle évite qu’un utilisateur système inutile ou mal configuré puisse devenir une porte d’entrée.

Dans le fichier /etc/ssh/sshd_config, ajoutez la directive suivante :

AllowUsers votre_utilisateur

Remplacez votre_utilisateur par le compte réellement utilisé pour administrer le VPS. Si plusieurs administrateurs doivent accéder au serveur, listez-les sur la même ligne :

AllowUsers admin1 admin2

Redémarrez ensuite SSH et testez l’accès depuis un nouveau terminal.

Configurer iptables pour bloquer les attaques DDoS courantes

Après avoir sécurisé SSH, l’étape suivante consiste à configurer le pare-feu local du VPS. Sur Debian et Ubuntu, iptables permet de filtrer le trafic entrant, de limiter certaines connexions et de bloquer des paquets suspects avant qu’ils n’atteignent vos services. Cette configuration ne remplace pas la protection anti-DDoS réseau de l’hébergeur, mais elle ajoute une couche de défense indispensable côté système.

Avant toute modification, gardez votre session SSH ouverte et testez vos règles progressivement. Une erreur de pare-feu peut bloquer l’accès au VPS.

1. Règles de base : politique par défaut

La première étape consiste à définir une politique claire : bloquer le trafic entrant par défaut, puis autoriser uniquement ce qui est nécessaire. Cette approche limite l’exposition du VPS et évite de laisser ouverts des ports inutiles.

Voici une base de configuration :

# Politique par défaut : tout bloquer sauf ce qui est explicitement autorisé
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Autoriser les connexions déjà établies ou liées
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Autoriser l’interface locale
iptables -A INPUT -i lo -j ACCEPT

# Autoriser SSH sur le nouveau port
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

Si vous avez conservé le port SSH par défaut, remplacez 2222 par 22. Si votre VPS héberge un site web, pensez aussi à autoriser les ports HTTP et HTTPS :

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

2. Protection contre le SYN Flood

Une attaque SYN Flood consiste à envoyer un grand nombre de demandes de connexion TCP incomplètes. Le serveur réserve alors des ressources pour des connexions qui ne se terminent jamais, ce qui peut ralentir ou rendre indisponibles certains services.

Vous pouvez limiter le nombre de nouvelles connexions TCP SYN acceptées par seconde :

# Limiter les nouvelles connexions TCP SYN
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT

# Bloquer les paquets SYN excédentaires
iptables -A INPUT -p tcp --syn -j DROP

La première règle accepte les nouvelles connexions à un rythme limité. L’option --limit 1/s autorise une nouvelle connexion par seconde, tandis que --limit-burst 3 permet un petit pic temporaire. La seconde règle bloque les paquets SYN qui dépassent cette limite.

Ces valeurs doivent être adaptées selon l’usage du VPS. Pour un petit site, elles peuvent suffire. Pour un site à fort trafic, une limite trop basse risque de bloquer des visiteurs légitimes. L’objectif est donc de réduire les abus sans pénaliser le trafic normal.

3. Bloquer les paquets invalides

Certains paquets réseau ne correspondent à aucune connexion valide ou présentent un état incohérent. Ils peuvent être liés à des scans, à des erreurs réseau ou à des tentatives d’exploitation. Les bloquer permet de nettoyer une partie du trafic inutile avant qu’il ne sollicite davantage le serveur.

Ajoutez la règle suivante :

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Elle doit être placée avant les règles d’autorisation trop larges, afin que les paquets anormaux soient bloqués le plus tôt possible.

4. Limiter le nombre de connexions simultanées par IP

Limiter le nombre de connexions simultanées par adresse IP permet de réduire l’impact de certains comportements abusifs. C’est particulièrement utile pour les services web exposés sur les ports 80 et 443, car un même client ne devrait généralement pas ouvrir un nombre excessif de connexions en parallèle.

Voici un exemple de règles iptables :

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 -j REJECT

Dans cet exemple, une même adresse IP ne peut pas dépasser 50 connexions simultanées vers le port HTTP ou HTTPS. Au-delà de cette limite, les nouvelles connexions sont rejetées.

Cette valeur doit être adaptée à votre usage réel. Pour un petit site vitrine, 50 connexions par IP est souvent large. Pour une application web, une API ou un site recevant beaucoup de trafic légitime depuis des réseaux partagés, il peut être nécessaire d’augmenter cette limite afin d’éviter les faux positifs.

L’objectif n’est pas de bloquer tous les pics de trafic, mais de réduire les abus les plus évidents. Dans une stratégie de protection DDoS VPS, cette règle complète le filtrage réseau de l’hébergeur et les protections applicatives comme Cloudflare ou Fail2ban.

5. Rendre les règles persistantes

Les règles iptables ajoutées en ligne de commande sont actives immédiatement, mais elles peuvent être perdues après un redémarrage du VPS si elles ne sont pas sauvegardées. Pour éviter cela, installez le paquet iptables-persistent sur Debian ou Ubuntu :

apt update
apt install iptables-persistent -y

Pendant l’installation, le système peut vous demander si vous souhaitez enregistrer les règles IPv4 et IPv6 actuelles. Acceptez l’enregistrement si vos règles sont correctement configurées.

Vous pouvez ensuite sauvegarder manuellement les règles avec :

netfilter-persistent save

iptables -L -n -v

Cette commande affiche les chaînes iptables, les règles appliquées, les ports concernés et le nombre de paquets traités.

Installer et configurer Fail2ban

Une fois le pare-feu configuré, Fail2ban permet d’ajouter une protection dynamique. Contrairement à iptables, qui applique des règles fixes, Fail2ban surveille les journaux système et bannit automatiquement les adresses IP qui multiplient les tentatives échouées.

C’est particulièrement utile contre les attaques brute-force SSH. Lorsqu’une adresse IP tente plusieurs connexions avec de mauvais identifiants, Fail2ban peut la bloquer temporairement. Il peut aussi surveiller certains services web comme Apache ou Nginx si les filtres correspondants sont activés.

Fail2ban ne bloque pas une attaque DDoS volumétrique à lui seul. En revanche, il est très efficace pour limiter les attaques applicatives répétées, les scans agressifs et les tentatives d’intrusion automatisées.

1. Installation

Sur un VPS Debian ou Ubuntu, l’installation de Fail2ban se fait directement avec apt :

apt update && apt install fail2ban -y

Activez ensuite le service au démarrage du VPS :

systemctl enable fail2ban

Puis démarrez le service :

systemctl start fail2ban

systemctl status fail2ban

Si le service est actif, vous pouvez passer à la configuration des règles de bannissement. Sur certaines images serveur, Fail2ban peut déjà être présent, mais il est préférable de vérifier son installation et sa configuration avant de considérer qu’il protège réellement le VPS.

2. Configuration de base pour SSH

La configuration personnalisée de Fail2ban doit se faire dans le fichier /etc/fail2ban/jail.local. Il est déconseillé de modifier directement jail.conf, car ce fichier peut être écrasé lors d’une mise à jour du paquet. Le fichier jail.local permet de conserver vos réglages spécifiques.

Créez le fichier :

nano /etc/fail2ban/jail.local

Ajoutez ensuite une configuration de base pour SSH :

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled  = true
port     = 2222
logpath  = /var/log/auth.log
maxretry = 3

Dans cet exemple, bantime = 3600 signifie qu’une adresse IP bannie le reste pendant une heure. Le paramètre findtime = 600 indique que Fail2ban observe les tentatives sur une période de dix minutes. Enfin, maxretry = 5 définit le nombre maximal d’échecs autorisés avant bannissement.

Dans le bloc [sshd], le port doit correspondre au port SSH réellement utilisé. Si vous avez suivi la section précédente et remplacé le port 22 par le port 2222, conservez donc cette valeur. Si votre SSH écoute encore sur le port 22, adaptez la ligne ainsi :

port = 22

Redémarrez ensuite Fail2ban pour appliquer la configuration :

systemctl restart fail2ban

Cette configuration protège SSH contre les tentatives répétées de connexion échouée, ce qui réduit fortement les attaques automatisées visant les VPS exposés sur Internet.

3. Ajouter la protection pour les services web (si Nginx/Apache actif)

Si votre VPS héberge un site web avec Nginx ou Apache, Fail2ban peut aussi surveiller certains journaux liés aux erreurs d’authentification. Cette protection est utile si vous avez des espaces protégés par mot de passe, des interfaces d’administration ou des applications web sensibles.

Pour Nginx, ajoutez par exemple ce bloc dans jail.local :

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Pour Apache, ajoutez ce bloc :

[apache-auth]
enabled = true
port    = http,https
logpath = /var/log/apache2/error.log

Ces règles ne remplacent pas une protection applicative complète, mais elles ajoutent une barrière contre les tentatives répétées d’authentification. Avant de les activer, vérifiez que les chemins de logs correspondent bien à votre installation. Sur certaines configurations personnalisées, les journaux peuvent être stockés ailleurs.

Après modification, testez la configuration :

fail2ban-client -t

Puis redémarrez le service :

systemctl restart fail2ban

4. Commandes de gestion utiles

Fail2ban dispose de plusieurs commandes pratiques pour contrôler son fonctionnement. La première permet de voir les protections actives, aussi appelées jails :

fail2ban-client status

Pour obtenir le détail de la protection SSH, utilisez :

fail2ban-client status sshd

Cette commande affiche notamment le nombre d’échecs détectés, les adresses IP actuellement bannies et le fichier de log surveillé. En cas de faux positif, vous pouvez débannir manuellement une adresse IP :

fail2ban-client unban X.X.X.X

Remplacez X.X.X.X par l’adresse IP concernée. Cette commande est utile si vous avez bloqué votre propre accès après plusieurs erreurs de connexion.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Cloudflare comme bouclier applicatif (L7) pour les sites web hébergés sur le VPS

Lorsque votre VPS héberge un ou plusieurs sites web, la protection réseau de l’hébergeur et les règles iptables ne suffisent pas toujours à filtrer les attaques applicatives. Un HTTP Flood, par exemple, peut envoyer un grand nombre de requêtes qui ressemblent à des visites classiques. Le serveur web, PHP, la base de données ou WordPress peuvent alors être saturés même si la couche réseau reste disponible.

Cloudflare peut jouer le rôle de bouclier applicatif en se plaçant entre les visiteurs et votre VPS. Le trafic web passe d’abord par Cloudflare, qui peut filtrer les bots, appliquer des règles WAF, limiter certaines requêtes et absorber une partie des attaques HTTP avant qu’elles n’atteignent le serveur.

Cette approche est particulièrement intéressante pour un site WordPress, une boutique WooCommerce, une application web ou une API publique. Elle ne protège pas tous les services du VPS, comme SSH ou les ports personnalisés, mais elle renforce fortement la défense des sites exposés en HTTP et HTTPS.

Pour aller plus loin sur ce point, vous pouvez consulter notre tutoriel dédié pour configurer Cloudflare pour protéger votre site WordPress hébergé sur VPS.

1. Ajouter le domaine sur Cloudflare (compte gratuit suffisant)

Pour utiliser Cloudflare comme bouclier applicatif, vous devez d’abord ajouter le domaine de votre site dans votre compte Cloudflare. Le principe est simple : au lieu de laisser les visiteurs contacter directement l’adresse IP de votre VPS, vous faites passer le trafic web par le réseau Cloudflare.

Commencez par créer un compte sur Cloudflare, puis ajoutez votre nom de domaine.

Cloudflare analyse ensuite les enregistrements DNS existants et vous propose de nouveaux serveurs de noms.

Si votre domaine est enregistré chez LWS, vous devrez remplacer les serveurs DNS actuels depuis votre espace client LWS par ceux fournis par Cloudflare.

Une fois la zone DNS active, vérifiez les enregistrements de type A ou AAAA qui pointent vers l’adresse IP du VPS. Pour que Cloudflare protège réellement le site, le proxy doit être activé sur ces enregistrements. Dans l’interface Cloudflare, cela correspond au nuage orange.

Un enregistrement proxifié permet à Cloudflare de recevoir les requêtes HTTP/HTTPS avant votre VPS. À l’inverse, un enregistrement en DNS only laisse apparaître l’IP réelle du serveur et ne bénéficie pas du filtrage applicatif.

2. Activer le mode « Under Attack » en cas d’attaque active

En cas d’attaque HTTP Flood ou de trafic web anormal, Cloudflare propose un mode appelé “I’m Under Attack”. Ce mode ajoute une vérification supplémentaire avant de laisser passer les visiteurs vers votre site. Les utilisateurs légitimes voient généralement une page de challenge temporaire, tandis qu’une partie des bots automatisés est bloquée ou ralentie.

Ce mode peut être activé depuis le tableau de bord Cloudflare, dans les paramètres de sécurité du domaine. Il ne doit pas forcément rester actif en permanence, car il ajoute une étape visible pour les visiteurs. En revanche, il est utile lorsqu’un site hébergé sur le VPS devient soudainement lent, que les logs montrent un volume anormal de requêtes ou que l’utilisation CPU/RAM augmente fortement sans raison légitime.

Pour un site e-commerce ou une application critique, activez ce mode avec prudence et surveillez le comportement des visiteurs après activation.

2. Règles WAF recommandées (plan gratuit)

Le WAF, ou Web Application Firewall, permet de filtrer des requêtes web suspectes avant qu’elles n’atteignent votre VPS. Il est particulièrement utile contre les attaques visant des failles connues, des URL sensibles ou des comportements automatisés.

Pour un site WordPress, WooCommerce ou une application web classique, vous pouvez commencer par activer les règles de sécurité gérées disponibles dans Cloudflare. Elles permettent de bloquer une partie des attaques courantes sans écrire vous-même toutes les règles.

Vous pouvez également créer des règles simples pour protéger les pages sensibles. Par exemple, il est pertinent de renforcer la protection sur :

• /wp-admin ;
• /wp-login.php ;
• /login ;
• /admin ;
• les pages d’authentification personnalisées;

Le rate limiting peut aussi être utile pour limiter le nombre de requêtes par IP sur certaines URL. L’objectif n’est pas de bloquer les visiteurs légitimes, mais d’éviter qu’une même adresse ou un même comportement automatisé sollicite trop fortement votre serveur web.

4. Masquer l’IP réelle du VPS

Cloudflare protège efficacement un site web uniquement si l’attaquant ne peut pas joindre directement l’adresse IP réelle du VPS. Si cette IP est exposée dans un enregistrement DNS non proxifié, dans un ancien sous-domaine, dans une configuration mail ou dans un historique DNS, un attaquant peut contourner Cloudflare et cibler directement le serveur.

Vérifiez donc que les enregistrements A et AAAA pointant vers le VPS sont bien proxifiés lorsque cela est possible. Évitez aussi de créer des sous-domaines comme direct.example.com ou server.example.com qui exposent directement l’IP du serveur.

Pour renforcer cette protection, vous pouvez configurer votre serveur web afin qu’il n’accepte les connexions HTTP et HTTPS que depuis les plages IP Cloudflare. Ainsi, même si l’adresse IP du VPS est découverte, les requêtes directes vers Apache ou Nginx peuvent être bloquées.

Surveillance et détection proactive

Une bonne configuration de sécurité ne s’arrête pas à l’installation d’iptables, de Fail2ban ou de Cloudflare. Pour protéger efficacement un VPS contre les attaques DDoS et les comportements suspects, il faut aussi surveiller régulièrement ce qui se passe sur le serveur.

La surveillance permet de repérer rapidement un pic de trafic, une hausse anormale du nombre de connexions, des tentatives SSH répétées ou une activité inhabituelle dans les logs web. Plus vous détectez tôt une anomalie, plus vous pouvez réagir vite : activer une règle Cloudflare, renforcer Fail2ban, ajuster iptables ou contacter le support de votre hébergeur si l’attaque semble réseau.

1. Surveiller le trafic réseau en temps réel

Pour savoir si votre VPS subit un trafic anormal, commencez par observer les connexions actives. La commande ss permet d’afficher les connexions TCP/UDP, les ports en écoute et les processus associés :

ss -tunapl

Les options utilisées permettent d’obtenir une vue détaillée :

• t affiche les connexions TCP ;
• u affiche les connexions UDP ;
• n affiche les adresses et ports au format numérique ;
• a montre toutes les connexions ;
• p indique le processus associé ;
• l affiche les ports en écoute.

Vous pouvez aussi compter rapidement le nombre de connexions établies :

netstat -an | grep ESTABLISHED | wc -l

Si ce nombre augmente fortement sans raison, cela peut indiquer un trafic anormal, une attaque applicative ou un service très sollicité.

Pour visualiser le trafic par interface réseau, installez iftop :

apt install iftop -y

Puis lancez-le sur l’interface réseau principale, souvent eth0 :

iftop -i eth0

ip a

iftop permet de voir quelles adresses échangent le plus de données avec votre VPS. C’est très utile pour repérer une IP ou un groupe d’IP qui consomme anormalement la bande passante.

2. Analyser les logs d’attaque

Les logs sont indispensables pour comprendre ce qui se passe réellement sur un VPS. En cas de suspicion d’attaque, ils permettent d’identifier les services ciblés, les IP les plus actives et les erreurs répétées.

Pour analyser les tentatives SSH échouées sur Debian ou Ubuntu, utilisez :

grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

Cette commande extrait les adresses IP liées aux échecs de connexion SSH, les regroupe, les compte, puis affiche les plus fréquentes. Si une même IP apparaît des dizaines ou centaines de fois, elle doit être surveillée ou bannie automatiquement via Fail2ban.

Pour les sites hébergés avec Nginx, vous pouvez afficher les IP les plus actives dans les logs d’accès :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Avec Apache, adaptez le chemin :

awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

Ces commandes aident à repérer les comportements anormaux : une IP qui charge trop souvent une page de connexion, un bot qui explore toutes les URL du site ou un trafic massif vers une ressource précise.

Il ne faut toutefois pas bannir une IP sans analyse. Certaines adresses peuvent appartenir à des proxys, des réseaux d’entreprise, des robots légitimes ou des services de supervision. Croisez toujours les informations avec l’heure, l’URL ciblée, le code HTTP retourné et le volume de requêtes.

3. Monitoring depuis le Panel KVM LWS

En complément des commandes Linux, le Panel KVM LWS permet de suivre les ressources du VPS depuis une interface graphique. Cette supervision est utile pour repérer rapidement une hausse inhabituelle de la charge CPU, de la mémoire vive ou du trafic réseau.

Un pic soudain de trafic peut être le premier signe visible d’une attaque DDoS ou d’un comportement applicatif anormal. Une montée brutale du CPU peut aussi indiquer un HTTP Flood, un script PHP saturé, une attaque sur WordPress ou une base de données trop sollicitée.

Vérification du bon fonctionnement

Une fois SSH, iptables, Fail2ban et Cloudflare configurés, il est essentiel de vérifier que chaque couche de protection fonctionne correctement. Cette étape évite deux problèmes fréquents : croire que le VPS est protégé alors qu’une règle n’est pas active, ou au contraire bloquer un accès légitime à cause d’une configuration trop stricte.

Commencez par tester la connexion SSH depuis un nouveau terminal, sans fermer votre session actuelle :

ssh -p 2222 votre_utilisateur@IP_DU_VPS

iptables -L -n -v

Contrôlez que les ports nécessaires sont autorisés, notamment SSH, HTTP et HTTPS si votre VPS héberge un site web. Vérifiez aussi que les règles de limitation et de blocage des paquets invalides apparaissent bien dans la liste.

Testez ensuite Fail2ban :

fail2ban-client status
fail2ban-client status sshd

Pour aller plus loin, vous pouvez simuler plusieurs connexions SSH échouées depuis une autre adresse IP, puis vérifier que Fail2ban bannit bien l’adresse après le nombre d’échecs défini.

Si Cloudflare est actif, vérifiez dans la zone DNS que les enregistrements du site sont bien proxifiés avec le nuage orange. Enfin, consultez la supervision du Panel KVM LWS pour confirmer que le trafic réseau, la mémoire et le CPU sont bien visibles.

VPS pour DDoS : erreurs fréquentes et cas de blocage

Même avec une bonne méthode, certaines erreurs peuvent rendre le VPS inaccessible ou empêcher une protection de fonctionner correctement. Le tableau suivant regroupe les cas les plus fréquents et les solutions à appliquer.

Pour éviter ces blocages, appliquez toujours les modifications dans cet ordre : ouvrir les ports nécessaires, tester l’accès, sauvegarder la configuration, puis seulement ensuite fermer les anciennes sessions. Sur un VPS en production, il est également recommandé de créer un snapshot avant toute modification sensible.

Bonnes pratiques : sécurité VPS au-delà du DDoS

La protection contre les attaques DDoS ne doit pas être isolée du reste de la sécurité serveur. Un VPS bien protégé repose aussi sur des mises à jour régulières, une gestion stricte des comptes utilisateurs, des sauvegardes fiables et une surveillance continue.

Commencez par maintenir le système à jour :

apt update && apt upgrade -y

Les mises à jour corrigent des failles de sécurité dans le noyau Linux, OpenSSH, Apache, Nginx, PHP, MariaDB et les autres paquets installés. Un serveur non maintenu devient rapidement vulnérable, même avec un pare-feu correctement configuré.

Évitez aussi d’utiliser le compte root pour les tâches courantes. Créez plutôt un utilisateur dédié avec des droits sudo, puis limitez l’accès SSH à ce compte. Cela réduit les risques en cas d’erreur ou de tentative d’intrusion.

Avant de modifier iptables, SSH, Fail2ban ou la configuration réseau, créez un snapshot depuis le Panel KVM LWS. Vous pourrez ainsi revenir plus facilement à un état stable si une règle bloque l’accès ou perturbe un service.

Activez également les sauvegardes automatiques lorsque votre projet est important. Une attaque ne se limite pas toujours à une saturation réseau : elle peut aussi précéder une tentative d’intrusion, une suppression de fichiers ou une altération de données.

Enfin, surveillez régulièrement les logs et les alertes Fail2ban. Pour aller plus loin, vous pouvez aussi analyser automatiquement la configuration sécurité de votre VPS avec Claude Code, en complément d’un contrôle manuel.

FAQ

Est-ce qu’un VPS LWS inclut une protection anti-DDoS ?

Oui, les VPS KVM LWS incluent une protection anti-DDoS réseau côté infrastructure. Cette protection agit en amont du serveur pour filtrer une partie du trafic malveillant avant qu’il n’atteigne le VPS.

Fail2ban protège-t-il contre les attaques DDoS ?

Fail2ban ne bloque pas une attaque DDoS volumétrique. En revanche, il est très utile contre les attaques applicatives répétées, comme le brute-force SSH ou certaines tentatives d’authentification web.

Quelle est la différence entre une protection DDoS réseau et une protection applicative ?

La protection réseau agit sur les couches L3/L4, par exemple contre les floods UDP, ICMP ou SYN. La protection applicative agit sur les couches supérieures, comme les requêtes HTTP, les connexions SSH ou les formulaires de connexion.

Comment savoir si mon VPS est en train de subir une attaque DDoS ?

Surveillez les pics de trafic réseau, la hausse brutale du CPU, le nombre de connexions actives, les logs SSH et les logs web. Le Panel KVM LWS et les commandes comme ss, iftop ou fail2ban-client status peuvent aider à confirmer l’anomalie.

Cloudflare est-il suffisant pour protéger un VPS contre les DDoS ?

Cloudflare protège surtout les sites web exposés en HTTP/HTTPS. Il ne protège pas automatiquement SSH, les ports personnalisés ou les services accessibles directement par l’IP du VPS.

Faut-il des compétences avancées pour configurer iptables et Fail2ban ?

Il faut être à l’aise avec SSH et la ligne de commande Linux, mais les configurations de base restent accessibles si vous appliquez les étapes avec prudence et testez chaque modification avant de fermer votre session active.

Conclusion

Protéger un VPS contre les attaques DDoS demande une approche en plusieurs couches. La protection réseau de l’hébergeur joue un rôle essentiel pour filtrer les attaques volumétriques en amont, mais elle doit être complétée par une configuration sérieuse côté serveur.🦉 En durcissant SSH, en appliquant des règles iptables adaptées, en installant Fail2ban, en surveillant les logs et en utilisant Cloudflare pour les sites web, vous réduisez fortement les risques d’indisponibilité et d’intrusion.🧛‍♂️ Un bon VPS pour DDoS n’est donc pas seulement un serveur avec une protection réseau incluse. C’est aussi un environnement correctement administré, surveillé et maintenu à jour.

Besoin d’un VPS sécurisé pour vos projets ?
Pour héberger vos sites, applications ou services sur un VPS avec protection anti-DDoS incluse, accès root complet et infrastructure souveraine française, consultez les offres VPS KVM LWS.
Découvrir les VPS KVM LWS

Prenez le temps de tester chaque règle, de vérifier vos accès et de créer des snapshots avant toute modification sensible. Et si vous avez des questions ou des ajouts sur la façon de lutter contre les attaques DDoS, écrivez-nous dans la section Commentaires.