Sécuriser son VPS contre les attaques DDoS

Mettre en place une stratégie anti-DDoS VPS efficace n'est plus optionnel en 2026 : les attaques volumétriques et applicatives se sont banalisées, ciblant aussi bien les petites infrastructures que les plateformes critiques. Cet article détaille les mécanismes de mitigation, la configuration système côté serveur et les bonnes pratiques concrètes pour protéger durablement un VPS Linux ou Windows exposé sur Internet.

Comprendre les attaques DDoS et l'anti-DDoS VPS

Une attaque par déni de service distribué (DDoS) consiste à saturer une ressource — bande passante, CPU, table de connexions, pile applicative — depuis un grand nombre de sources. La logique d'un dispositif anti-DDoS VPS est de filtrer le trafic illégitime avant qu'il n'atteigne votre serveur, tout en laissant passer les requêtes légitimes.

Les grandes familles d'attaques

• Volumétriques (L3/L4) : UDP flood, ICMP flood, amplification DNS/NTP. Objectif : saturer le lien réseau en Gbps.
• Protocolaires : SYN flood, ACK flood, fragmentation. Objectif : épuiser les tables d'état et les ressources kernel.
• Applicatives (L7) : HTTP flood, slowloris, requêtes coûteuses. Objectif : saturer le serveur web ou la base de données avec un faible débit.

Où se joue la mitigation

La protection volumétrique doit se faire en amont, au niveau de l'infrastructure réseau. Un VPS seul ne peut pas absorber plusieurs dizaines de Gbps : son uplink serait saturé bien avant que nftables n'ait le temps d'agir. C'est pourquoi la mitigation kernel-level et le filtrage réseau en bordure de datacenter sont déterminants.

Sur les VPS OmegaCloud, l'anti-DDoS volumétrique est inclus par défaut sur tous les services, avec une mitigation transparente au niveau infrastructure. Vous n'avez rien à installer côté client pour absorber les floods L3/L4.

Cela ne dispense pas d'un durcissement système : les attaques L7 et la protection de vos propres services restent sous votre responsabilité. On combine donc protection réseau amont et hardening serveur.

Durcir un VPS Linux contre les attaques applicatives

Une fois le trafic volumétrique filtré en amont, la surface d'attaque restante concerne surtout la couche 7 et les connexions établies. Voici les couches à configurer sur un VPS Linux (Debian, Ubuntu, Rocky ou Alma).

1. Réduire la surface d'exposition

Le premier réflexe : n'exposer que les ports strictement nécessaires. Un port ouvert inutilement est une cible potentielle.

sudo apt update && sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Pour un contrôle plus fin, nftables permet de poser des limites de débit par IP directement au niveau kernel, ce qui reste utile contre les floods applicatifs de faible volume.

sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 ct state new limit rate 10/minute accept
sudo nft add rule inet filter input tcp dport { 80, 443 } accept

2. Protéger SSH avec fail2ban et clés uniquement

Les tentatives de brute force SSH consomment des ressources et polluent les logs. Désactivez l'authentification par mot de passe et passez aux clés.

ssh-keygen -t ed25519 -C "admin@monserveur"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@mon-vps

Puis dans /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

sudo systemctl restart sshd

Installez ensuite fail2ban pour bannir automatiquement les IP abusives :

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

3. Durcir la pile réseau kernel

Certains paramètres sysctl renforcent la résistance aux SYN floods et à l'usurpation. Ajoutez-les dans /etc/sysctl.d/99-hardening.conf :

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0

sudo sysctl --system

La documentation officielle de référence sur ces paramètres réseau est disponible sur kernel.org.

4. Limiter le débit au niveau du serveur web

Contre les HTTP floods et slowloris, configurez des limites de connexions et de requêtes. Avec Nginx :

limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {
    limit_req zone=req_limit burst=20 nodelay;
    limit_conn conn_limit 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Protéger un VPS Windows et superviser efficacement

Sur un VPS Windows OmegaCloud, la logique reste identique : réduire la surface d'exposition, filtrer le trafic et surveiller. L'accès RDP est la cible privilégiée des attaques par force brute.

Sécuriser RDP et le pare-feu Windows

Limitez l'accès RDP à des IP de confiance via le pare-feu Windows Defender, en PowerShell :

New-NetFirewallRule -DisplayName "RDP-Restreint" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 203.0.113.10 -Action Allow

Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction Block

Activez le NLA (Network Level Authentication) pour exiger une authentification avant l'ouverture de session :

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name "UserAuthentication" -Value 1

Les bonnes pratiques Microsoft sur le durcissement RDP et l'accès distant sont documentées sur Microsoft Learn.

Superviser via le panel OmegaCloud

La détection précoce d'une attaque passe par la métrologie. Un pic de bande passante, une saturation CPU ou une explosion des connexions établies sont des signaux clairs. Le panel OmegaCloud fournit un dashboard temps réel CPU/RAM/SSD/réseau qui permet de repérer une anomalie avant qu'elle ne dégénère.

• Snapshots : capturez un état sain avant toute intervention lourde.
• Reboot / reinstall 1 clic : reprise rapide en cas de compromission.
• Console KVM : accès hors bande si le réseau est saturé.
• 2FA sur le panel : indispensable pour protéger l'accès administrateur.

Automatiser la réaction avec l'API et les webhooks

Pour industrialiser la détection, les Integrations & API OmegaCloud permettent de déclencher des actions (alerte, snapshot, notification) via webhooks lors d'un dépassement de seuil. Exemple d'appel à une API de supervision maison :

curl -X POST https://api.mon-monitoring.local/alert \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"host":"vps-prod-01","event":"traffic_spike","gbps":3.2}'

Choisir un hébergement adapté à la résilience

La qualité de l'infrastructure conditionne directement l'efficacité de l'anti-DDoS. Voici les critères neutres à évaluer avant de choisir un hébergeur pour un service exposé.

Critère	Pourquoi c'est important
Anti-DDoS inclus	La mitigation volumétrique doit être native, sans option payante ni délai d'activation.
CPU dédié vs partagé	Un CPU dédié encaisse mieux les pics sans effet de voisinage bruyant.
Stockage NVMe Gen4	Les I/O rapides limitent la dégradation sous charge et lors des snapshots.
Bande passante	Plusieurs Gbps et uplink redondant pour absorber le trafic légitime en cas de mitigation.
Panel de gestion	Métrologie temps réel, console KVM et reinstall rapide pour réagir vite.
Datacenters	Localisation UE, faible latence et alimentation redondée N+1.

Les VPS Linux OmegaCloud combinent SSD SAS, KVM avec kernel récent, anti-DDoS inclus et datacenters premium en Europe. Cette base réduit la charge de configuration côté administrateur : vous vous concentrez sur le durcissement applicatif plutôt que sur l'absorption des floods réseau.

Checklist de mise en production

1. Firewall configuré (ufw ou nftables), politique deny by default.
2. SSH par clés uniquement, root sans mot de passe, fail2ban actif.
3. Paramètres sysctl de durcissement réseau appliqués.
4. Rate limiting configuré sur le serveur web (L7).
5. 2FA activée sur le panel de gestion.
6. Snapshots réguliers et procédure de restauration testée.
7. Supervision temps réel avec alertes sur pics réseau/CPU.

Pour approfondir les mesures de sécurité système, l'ANSSI publie des guides de durcissement de référence sur cyber.gouv.fr.

Conclusion

Protéger un VPS contre les attaques DDoS repose sur deux couches complémentaires : une mitigation volumétrique gérée en amont par l'infrastructure, et un durcissement système rigoureux côté serveur. Firewall strict, SSH par clés, rate limiting L7 et supervision temps réel forment le socle. En 2026, cette combinaison reste la façon la plus fiable de garder un service disponible sous pression.

FAQ

Un anti-DDoS VPS suffit-il à lui seul à sécuriser mon serveur ?

Non. La mitigation volumétrique protège contre la saturation réseau (L3/L4), mais elle ne remplace pas le durcissement système. Vous devez toujours configurer un firewall, désactiver l'authentification SSH par mot de passe, activer fail2ban et poser du rate limiting applicatif contre les attaques L7 comme les HTTP floods.

Comment savoir si mon VPS subit une attaque DDoS ?

Surveillez les métriques : un pic soudain de bande passante, une saturation CPU inexpliquée ou une explosion du nombre de connexions établies (ss -s) sont des signaux typiques. Un dashboard temps réel comme celui du panel OmegaCloud permet de détecter l'anomalie tôt et de réagir avec snapshot ou reboot.

Dois-je installer un logiciel anti-DDoS sur mon VPS OmegaCloud ?

Non pour la partie volumétrique : la mitigation kernel-level est incluse par défaut et transparente au niveau infrastructure. Votre travail consiste à durcir la couche applicative avec ufw ou nftables, fail2ban, des clés SSH et du rate limiting sur votre serveur web.