Ai-je besoin d'une protection DDoS sur un serveur dédié ?

Qu'est-ce que la protection DDoS, et quelles attaques arrête-t-elle ?

La protection DDoS est un filtrage placé en amont de votre serveur : elle supprime le trafic d'attaque avant que ce trafic n'atteigne votre port réseau. Une attaque par déni de service distribué (DDoS) envoie du trafic depuis de nombreuses machines à la fois pour saturer une liaison, un pare-feu ou une application. Les attaques se répartissent en deux groupes :

• Attaques de la couche réseau (couches 3 et 4). Des flots de paquets : SYN floods, ACK floods, floods UDP et ICMP, et attaques par réflexion comme l'amplification DNS ou memcached. Les floods volumétriques cherchent à saturer la liaison elle-même : seul un filtrage avant la liaison est utile.
• Attaques de la couche applicative (couche 7). Des flots de requêtes HTTP d'apparence réelle, des requêtes qui contournent le cache, ou des connexions lentes comme Slowloris. Elles nécessitent peu de bande passante. Elles épuisent le CPU, les workers web ou la base de données à la place.

La documentation de Cloudflare répertorie ces vecteurs sous deux rulesets managés : un pour la couche réseau, un pour le HTTP. Un serveur peut repousser seul certains floods de couche 7, mais jamais un flood plus important que son uplink.

Quelle est la différence entre une protection permanente et une protection à la demande ?

Une protection permanente inspecte votre trafic en continu ; une protection à la demande redirige votre trafic vers un réseau de scrubbing seulement quand une attaque commence. Le scrubbing consiste à faire passer le trafic par un réseau de filtrage qui supprime les paquets d'attaque et transmet le reste propre à votre serveur.

• Permanente. Aucun délai de basculement, mais chaque paquet passe par le filtre. Un CDN ou un reverse proxy devant un site web fonctionne ainsi.
• À la demande. Le trafic va directement chez vous jusqu'à une attaque, puis le fournisseur annonce votre préfixe IP depuis son propre réseau. Le mode à la demande de Cloudflare Magic Transit active cette annonce pendant l'attaque et la désactive ensuite. Jusqu'à la bascule, l'attaque vous atteint.

Pour un seul serveur loué, un filtrage permanent devant chaque service public est le choix pratique.

Qui a besoin d'une protection DDoS sur un serveur dédié, et qui n'en a pas besoin ?

Vous en avez besoin quand des inconnus connaissent votre adresse IP et ont une raison de mettre le service hors ligne. Vous pouvez généralement vous en passer quand seuls vous et des personnes de confiance vous connectez à la machine.

Est-ce que Ironatoll protège mon serveur dédié contre les attaques DDoS ?

Ironatoll vend du bare metal, pas un réseau filtré. La règle, mot pour mot : Contre les attaques DDoS, nous ne promettons rien au-delà du traitement par défaut du réseau du datacenter. Nous ne publions ni capacité d'atténuation, ni périmètre de filtrage, ni temps de réponse, car nous n'en promettons aucun.

Cela permet de garder des offres bon marché, et cela fait de tout service UDP public un service que votre projet doit protéger. Pour du trafic de jeu filtré, placez un service de filtrage devant le serveur. Ou choisissez un hébergeur qui vend de l'atténuation avec des chiffres écrits. Notre classement des fournisseurs de serveurs dédiés offshore compare les hébergeurs sur les mêmes critères.

Selon la vérification de 30 October 2026 par Ironatoll, un serveur dédié comparable à Atoll 64 coûtait un prix médian de $337.49 chez 14 hôtes, qui accepte la crypto sans pièce d'identité ; Ironatoll facture $72.62. Cet écart de 78% laisse de la place pour une offre CDN ou un proxy filtré. Chaque offre est détaillée sur combien coûte un serveur dédié Ironatoll.

Comment protéger un site web hébergé sur un serveur dédié contre les attaques DDoS ?

Placez un reverse proxy ou un CDN devant le site web, puis masquez l'adresse IP réelle du serveur. Cloudflare est une option. Ces points proviennent de sa documentation, lue le 30 octobre 2026 :

• La protection DDoS est incluse dans chaque offre Cloudflare, y compris l'offre gratuite. Cloudflare la présente comme une protection standard et illimitée pour les couches 3 à 7.
• Seuls les enregistrements proxifiés sont protégés. Le proxy fonctionne sur les enregistrements A, AAAA et CNAME et couvre le trafic HTTP et HTTPS. Un enregistrement DNS-only révèle l'IP de votre origine à quiconque l'interroge.
• Le trafic web proxifié utilise des ports fixes. HTTP : 80, 8080, 8880, 2052, 2082, 2086 et 2095. HTTPS : 443, 2053, 2083, 2087, 2096 et 8443.
• Acceptez le trafic web uniquement depuis Cloudflare. Cloudflare publie ses plages sur cloudflare.com/ips et conseille de bloquer tout le reste au niveau de l'origine. Un attaquant qui trouve l'IP réelle, dans d'anciens enregistrements DNS ou les paramètres mail, peut frapper directement le serveur.
• D'autres protocoles nécessitent Spectrum. SSH, les ports de jeu et autres services TCP ou UDP ne sont pas couverts par un enregistrement proxifié. Spectrum pour tous les ports TCP et UDP n'est disponible que sur l'offre Enterprise.

Chaque serveur Ironatoll dispose d'une seule adresse IPv4 : un enregistrement DNS-only qui pointe vers elle, comme un enregistrement mail, révèle donc l'origine.

Comment limiter le débit des connexions avec nftables ?

nftables peut plafonner les nouvelles connexions par adresse source, ce qui freine les petits floods et les tentatives de brute-force, mais il ne peut pas arrêter un flood qui sature votre lien. Au moment où nftables voit un paquet, ce paquet a déjà consommé votre bande passante.

Le wiki nftables maintient un limiteur de débit par IP source dans un set dynamique. Chaque entrée expire après 60 secondes sans trafic. Le ruleset ci-dessous applique cette idée à SSH, accepte le trafic web et rejette le reste. Derrière Cloudflare, acceptez les ports 80 et 443 uniquement depuis un set de ses plages publiées. Chargez-le avec nft -f /etc/nftables.conf, gardez une seconde session SSH ouverte, puis exécutez systemctl enable nftables. La limite SSH couvre l'IPv4 ; ajoutez un set ipv6_addr avec ip6 saddr pour l'IPv6.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set ssh_meter {
    type ipv4_addr
    timeout 60s
    flags dynamic
  }

  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto ipv6-icmp accept
    icmp type echo-request limit rate 10/second accept
    tcp dport 22 ct state new update @ssh_meter { ip saddr limit rate 10/minute } accept
    tcp dport { 80, 443 } accept
  }
}

# http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
    }
}

Qu'est-ce qui réduit encore le risque sans rien acheter ?

Donnez moins à voir aux attaquants :

• Fermez chaque port que vous ne servez pas. Une interface web Proxmox, une base de données ou une API LLM se place derrière un tunnel SSH.
• Gardez les services privés hors de la machine qui fait tourner les services publics. Un flood contre un serveur de jeu fait tomber tout ce qui partage son lien.
• Ne publiez jamais l'IP d'origine d'un site web proxifié, ni dans l'historique DNS ni dans les en-têtes mail.

Notre comparatif serveur dédié ou VPS explique quand le bare metal vaut le coup pour un service public.