Configurer une protection DDoS sur MikroTik sans bloquer les vrais visiteurs
Détecter les rafales de nouvelles connexions, placer temporairement les sources abusives en quarantaine et les bloquer tôt dans RAW, tout en connaissant les limites du routeur.
Une attaque par déni de service ne commence pas toujours par des centaines de gigabits. Elle peut prendre la forme de quelques centaines de nouvelles connexions par seconde, suffisantes pour saturer le serveur Web, la base de données ou la table de suivi des connexions du routeur. Dans ce scénario, MikroTik peut détecter les sources anormalement actives et écarter leurs paquets avant qu’ils ne consomment davantage de ressources.
Cette protection reste locale. Elle peut préserver le processeur du serveur et du routeur tant que la liaison Internet possède encore de la capacité. Si le trafic hostile remplit déjà le lien fourni par l’opérateur, le routeur reçoit les paquets trop tard : il faut alors une action en amont, un CDN avec protection DDoS, un WAF, un service de nettoyage ou le filtrage de l’opérateur.
DoS, DDoS et saturation applicative
Une attaque DoS provient d’une source ou d’un groupe réduit de sources. Une attaque DDoS distribue le trafic entre de nombreuses machines ou objets connectés compromis. La distinction ne change pas le premier objectif : empêcher que des paquets abusifs épuisent une ressource avant les demandes légitimes.
| Forme d’attaque | Ressource visée | Ce que MikroTik peut faire |
|---|---|---|
| Rafale de connexions TCP | Conntrack, pare-feu, serveur Web | Limiter les nouvelles connexions et mettre les sources en quarantaine |
| SYN flood | File de connexions TCP incomplètes | Activer les SYN cookies et filtrer les rafales |
| HTTP flood réaliste | Application, PHP, base de données | Fournir des indices, mais un WAF ou une limitation applicative reste nécessaire |
| Amplification UDP | Bande passante descendante | Bloquer certains paquets localement, sans libérer le lien déjà saturé |
| Attaque volumétrique | Capacité de la liaison Internet | Escalader vers l’opérateur ou un service de mitigation en amont |
Reconnaître l’incident avant de modifier le pare-feu
Un processeur de serveur proche de 100 %, une base de données très active et une hausse brutale des connexions ne prouvent pas à eux seuls une attaque. Une campagne légitime, un robot d’indexation, une boucle applicative ou un client mal configuré peuvent produire des symptômes similaires.
Dans RouterOS, Torch affiche en temps réel les flux observés sur une interface et permet de les classer par adresse source, adresse de destination, port et protocole. Il montre le trafic avant son filtrage : une source peut donc rester visible même si le pare-feu la bloque déjà.
/tool/torch interface=ether1
/interface monitor-traffic ether1Adaptez ether1 au véritable lien WAN. Comparez les résultats avec les journaux du proxy inverse ou du serveur Web. Surveillez surtout :
- le nombre de nouvelles connexions par source et par destination ;
- les ports et protocoles réellement visés ;
- le débit en bit/s et le nombre de paquets par seconde ;
- la taille de la table de suivi des connexions ;
- l’usage CPU du routeur et du serveur ;
- les codes HTTP, temps de réponse et requêtes répétées côté application.
Une seule adresse qui ouvre beaucoup de sessions peut être bloquée manuellement, mais une liste statique devient vite inutilisable lors d’une attaque distribuée. L’objectif est donc de créer une quarantaine dynamique, courte et mesurable.
Comprendre dst-limit correctement
Le paramètre dst-limit applique une limite distincte à chaque flux défini par son mode. Sa syntaxe est :
dst-limit=taux[/période],rafale,mode[/expiration]Dans l’expression suivante :
dst-limit=32,32,src-and-dst-addresses/10s32est le taux autorisé, ici 32 paquets par seconde puisque aucune période différente n’est indiquée ;- le second
32est la rafale initiale autorisée ; src-and-dst-addressescrée un compteur par paire source–destination ;10sest le délai d’expiration d’un compteur inactif, pas une fenêtre de dix secondes pour les 32 paquets.
La règle avec l’action return accepte dans la chaîne de détection les flux qui restent sous la limite. Lorsque le seau est épuisé, elle ne correspond plus : le paquet tombe sur les règles suivantes, qui placent la source dans une liste dynamique.
Pourquoi les chaînes input et forward ne sont pas interchangeables
La chaîne input traite les paquets destinés au routeur lui-même. La chaîne forward traite ceux qui traversent le routeur vers une autre machine. Un serveur Web publié par dst-nat se protège donc dans forward, même si le client contacte l’adresse publique du MikroTik.
Une règle de détection placée uniquement dans input peut incrémenter ses compteurs pour WebFig ou un VPN hébergé sur le routeur, mais elle ne verra pas correctement le trafic redirigé vers le serveur interne.
forward ; les paquets suivants des sources mises en quarantaine peuvent être écartés plus tôt dans RAW.Avant de commencer : sauvegarder et travailler en mode sécurisé
Une erreur d’ordre ou de chaîne peut couper l’accès au routeur. Connectez-vous depuis le LAN, activez le Safe Mode dans WinBox ou avec Ctrl+X, puis exportez la configuration.
/export file=avant-protection-ddos
/system backup save name=avant-protection-ddosVérifiez que la liste d’interfaces WAN contient réellement le lien Internet et que le serveur fonctionne déjà derrière une règle dst-nat. Les ports utilisés dans RAW doivent être les ports publics avant traduction. Si le port externe 8443 est traduit vers 443, indiquez 8443 dans la règle RAW.
Configuration ciblée pour un serveur Web derrière dst-nat
Le jeu de règles suivant est volontairement limité aux nouvelles connexions TCP arrivant depuis la liste WAN vers un service publié sur 80 ou 443. Il évite de transformer une détection Web en interdiction globale de toute communication avec l’adresse source.
1. Préparer une liste d’exclusion
Ajoutez à ddos-allow uniquement les adresses externes réellement fiables : supervision, proxy inverse ou plages officielles de votre CDN. L’adresse ci-dessous appartient à un bloc réservé à la documentation et doit être remplacée.
/ip firewall address-list
add list=ddos-allow address=198.51.100.10 \
comment="EXEMPLE RFC 5737 - a remplacer"2. Envoyer les nouvelles connexions Web vers une chaîne dédiée
/ip firewall filter
add chain=forward action=jump jump-target=detect-ddos-web \
connection-state=new connection-nat-state=dstnat \
in-interface-list=WAN protocol=tcp dst-port=80,443 \
src-address-list=!ddos-allow \
comment="DDoS: inspecter les nouvelles connexions Web"Placez cette règle après l’acceptation des connexions established,related et le rejet des paquets invalid, mais avant la règle qui autorise les nouvelles connexions dstnat. Elle ne remplace pas le pare-feu normal.
3. Définir le seuil et la quarantaine
/ip firewall filter
add chain=detect-ddos-web action=return \
dst-limit=32,32,src-and-dst-addresses/10s \
comment="DDoS: trafic sous le seuil"
add chain=detect-ddos-web action=add-src-to-address-list \
address-list=web-ddos-attackers address-list-timeout=10m \
comment="DDoS: quarantaine temporaire"
add chain=detect-ddos-web action=drop \
comment="DDoS: abandonner le paquet declencheur"La durée de dix minutes limite le coût d’un faux positif. Une semaine de blocage automatique est rarement justifiable sans analyse supplémentaire : les adresses changent, des visiteurs partagent une sortie CGNAT et les relais de services légitimes peuvent concentrer beaucoup de connexions.
4. Bloquer tôt dans RAW
/ip firewall raw
add chain=prerouting action=drop place-before=0 \
in-interface-list=WAN protocol=tcp dst-port=80,443 \
src-address-list=web-ddos-attackers \
comment="DDoS: bloquer Web avant conntrack"RAW intervient avant le suivi des connexions. Le routeur évite ainsi de créer une entrée conntrack pour chaque nouveau paquet déjà identifié comme abusif. La règle reste limitée au WAN et aux ports Web publics : l’adresse mise en quarantaine n’est pas bloquée arbitrairement sur tous les autres services.
Variante officielle par paire source–destination
La documentation MikroTik propose une logique générique qui place à la fois la source dans ddos-attackers et la destination dans ddos-targets, puis ne bloque dans RAW que lorsque les deux listes correspondent. Cette méthode est élégante pour une destination publique routée sans traduction.
/ip firewall filter
add chain=forward connection-state=new \
action=jump jump-target=detect-ddos
add chain=detect-ddos action=return \
dst-limit=32,32,src-and-dst-addresses/10s
add chain=detect-ddos action=add-dst-to-address-list \
address-list=ddos-targets address-list-timeout=10m
add chain=detect-ddos action=add-src-to-address-list \
address-list=ddos-attackers address-list-timeout=10m
/ip firewall raw
add chain=prerouting action=drop \
src-address-list=ddos-attackers \
dst-address-list=ddos-targetsAvec dst-nat, le filtre forward peut voir l’adresse interne après traduction alors que RAW voit encore l’adresse publique. Les listes de destination risquent donc de ne pas désigner la même adresse aux deux étapes. C’est la raison pour laquelle la configuration précédente bloque par source, mais seulement sur le WAN et les ports publics explicitement protégés.
Activer les SYN cookies
Pour les SYN floods, RouterOS dispose également des SYN cookies. Ils réduisent la quantité d’état conservée tant que le client n’a pas prouvé qu’il reçoit bien la réponse TCP.
/ip settings set tcp-syncookies=yesCette option complète la limitation, mais ne remplace ni les règles de pare-feu ni la capacité du serveur à traiter des requêtes HTTP complètes. Un robot capable d’établir correctement TCP et TLS peut toujours solliciter l’application.
Tester sans se verrouiller dehors
- Commencez avec un seuil élevé et observez les compteurs pendant une période normale et une période de pointe.
- Vérifiez l’ordre des règles avec
/ip firewall filter print statset/ip firewall raw print stats. - Surveillez la liste dynamique sans journaliser chaque paquet rejeté.
- Testez depuis une adresse externe contrôlée, avec un outil de charge limité et uniquement contre votre propre service.
- Confirmez qu’un visiteur normal reste servi, que le serveur répond et que la charge diminue lorsque la quarantaine se déclenche.
- Quittez le Safe Mode seulement après validation et conservez l’export hors du routeur.
/ip firewall filter print stats
/ip firewall raw print stats
/ip firewall address-list print where list=web-ddos-attackers
/ip firewall connection print count-onlyÉvitez log=yes sur une règle qui peut correspondre à des milliers de paquets par seconde. Les écritures et le traitement des messages peuvent devenir une seconde attaque contre le routeur. Utilisez les compteurs de règles, la taille des listes et, si nécessaire, Traffic Flow vers un collecteur externe.
Quand la protection locale ne suffit plus
Un MikroTik ne peut pas retirer du lien des paquets que l’opérateur lui a déjà livrés. Sur une connexion de 1 Gbit/s, une attaque entrante supérieure à cette capacité rend les services indisponibles même si le routeur rejette parfaitement chaque paquet.
Préparez donc un plan d’escalade avant l’incident :
- coordonnées du centre réseau de l’opérateur et procédure d’urgence ;
- seuil à partir duquel demander un filtrage, un blackhole temporaire ou un nettoyage du trafic ;
- CDN et WAF devant les services HTTP publics ;
- DNS avec TTL et accès de secours adaptés au plan de continuité ;
- métriques externes pour conserver de la visibilité lorsque le site n’est plus joignable ;
- captures limitées, horodatage, journaux du serveur et historique des volumes pour l’analyse.
Une protection sérieuse combine plusieurs couches : filtrage précoce dans le routeur, limitation dans le proxy inverse, cache et WAF au niveau HTTP, puis capacité de mitigation chez l’hébergeur ou l’opérateur.
Erreurs courantes à éviter
- Placer la détection du serveur dans
input: le trafic redirigé traverseforward. - Bloquer une source sur tous les ports pendant une semaine : le faux positif devient durable et global.
- Copier le seuil 32/32 sans mesurer : le trafic légitime varie fortement selon l’architecture.
- Oublier l’ordre des règles : une acceptation générale placée avant la détection rend celle-ci invisible.
- Journaliser chaque rejet : les logs peuvent consommer CPU, mémoire et stockage pendant l’attaque.
- Confondre filtrage et capacité : un paquet abandonné localement a déjà traversé la liaison Internet.
- Ignorer IPv6 : les règles IPv4 ne protègent pas un service également publié en IPv6.
Conclusion
RouterOS peut amortir efficacement une attaque modérée contre un serveur publié : dst-limit repère une paire source–destination trop active, une liste dynamique met la source en quarantaine et RAW abandonne les paquets suivants avant le suivi des connexions. La protection gagne en efficacité lorsqu’elle est ciblée sur l’interface, le protocole et les ports réellement exposés.
Le bon réglage n’est toutefois pas celui qui produit la plus longue liste noire. Il est celui qui réduit la charge sans punir les visiteurs légitimes, expire rapidement, reste observable et s’inscrit dans un plan d’escalade vers l’amont lorsque le volume dépasse la capacité de la liaison.
Références techniques
À lire ensuite
À propos de l’auteur
Jeremy Kraft administre les infrastructures et les services auto-hébergés de l’IBCSC. Ces guides reprennent des configurations réellement déployées, revérifiées avant publication.
Discussion
Commentaires
Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.