Attaques par amplification DNS : EDNS0, filtrage BCP 38 et défense anti-spoofing

Le protocole de datagramme utilisateur (User Datagram Protocol — UDP) est un protocole de transport sans connexion conçu pour limiter les surcoûts d'en-tête et minimiser la latence. Fonctionnant sans établissement de liaison préalable en trois étapes (Three-way Handshake) ni validation d'état au niveau du transport, le champ d'adresse source de l'en-tête IP n'est soumis à aucune authentification cryptographique. N'importe quel système connecté à un réseau dépourvu de contrôle d'adresse source peut émettre des paquets UDP contenant des adresses d'expédition arbitraires et falsifiées.

Cette propriété structurelle fait d'UDP le principal vecteur des attaques par déni de service distribué à réflexion (Distributed Reflection Denial of Service — DrDoS). Parmi les mécanismes de réflexion, l'amplification DNS demeure particulièrement répandue et destructrice. En exploitant des résolveurs récursifs publics mal configurés et des extensions protocolaires conçues pour élargir la taille des messages, les attaquants transforment des liaisons grand public en vagues de trafic saturant atteignant plusieurs centaines de gigabits par seconde.

Comprendre la mécanique d'une amplification DNS nécessite d'examiner les fonctionnalités du protocole à l'origine d'un facteur multiplicateur de 70, ainsi que les mesures de filtrage réseau requises pour neutraliser ce vecteur.

Anatomie de la réflexion DNS et multiplicateur EDNS0

Une attaque par amplification DNS repose sur la synchronisation de deux mécanismes : la réflexion et l'amplification volumétrique.

Attaquant (Usurpe l'adresse IP de la cible)
       |
       |  (Requête compacte de 45 octets)
       v
+-------------------------------+
|    Résolveur DNS récursif     |
+-------------------------------+
       |
       |  (Réponse volumineuse de 3500 octets)
       v
Destination visée (Hôte / Réseau de la cible)

1. Le principe de la réflexion

Lors d'un échange standard, un client émet une requête DNS depuis un port source vers le port 53 du résolveur. Le serveur lit l'adresse IP source dans l'en-tête IPv4 et renvoie la réponse vers cette même origine.

L'assaillant tire parti de cette règle en modifiant les métadonnées du paquet :

• Adresse source : Assignée à l'adresse IP publique de la cible visée.
• Adresse de destination : Assignée à un résolveur récursif ouvert accessible sur Internet.

Le résolveur traite la requête comme un échange valide et réexpédie l'ensemble des données de réponse vers la cible. Comme l'attaquant ne reçoit aucun paquet en retour, cette technique dissimule son emplacement géographique et son infrastructure réseau réelle.

2. Le multiplicateur volumétrique via EDNS0 (RFC 6891)

Sous les règles originelles de la RFC 1035, les données DNS transportées par UDP étaient strictement plafonnées à 512 octets. Toute réponse excédant ce volume imposait l'activation du drapeau de troncature (TC), contraignant le client à réitérer sa requête via une connexion TCP avec état.

Afin d'intégrer les enregistrements cryptographiques modernes tels que DNSSEC (RFC 4034), l'IETF a normalisé les mécanismes d'extension pour DNS (EDNS0) au sein de la RFC 6891. EDNS0 introduit un pseudo-enregistrement de ressource OPT permettant au client d'annoncer une capacité de mémoire tampon étendue, couramment fixée à 4096 octets.

Les attaquants exploitent cette capacité pour maximiser le coefficient multiplicateur :

1. Une requête est forgée pour solliciter les enregistrements de type ANY ou TXT d'une zone disposant d'une signature DNSSEC complète.
2. Le paquet de requête n'occupe qu'entre 45 et 65 octets sur le réseau.
3. Le résolveur génère une réponse englobant les chaînes de certificats, les clés de zone et les champs textuels, atteignant 3000 à 4200 octets.

$$\text{Facteur d'amplification} = \frac{\text{Taille de la réponse (octets)}}{\text{Taille de la requête (octets)}} = \frac{3200}{45} \approx 71.1$$

Avec un facteur dépassant les 70x, un assaillant mobilisant une bande passante montante de seulement 1 Gbit/s peut projeter plus de 70 Gbit/s de trafic réfléchi contre la cible désignée.

Norme BCP 38 / RFC 2827 : L'impératif du filtrage d'entrée

L'origine de ces attaques ne réside pas uniquement dans les protocoles applicatifs, mais dans l'absence de vérification des adresses source par les fournisseurs d'accès Internet avant d'acheminer les paquets vers le réseau de transit mondial.

Publié en mai 2000 par l'IETF, le document Best Current Practice 38 (BCP 38, rédigé sous la référence RFC 2827) formalise le filtrage d'entrée réseau (Network Ingress Filtering) :

« Les routeurs reliant les clients finaux au réseau d'agrégation DOIVENT rejeter les paquets dont l'adresse IP source ne correspond pas à la plage de préfixes attribuée à ce lien physique spécifique. »

Validation du chemin inverse en mode strict (Strict uRPF)

Sur les équipements de routage Linux et le matériel réseau d'entreprise, la recommandation BCP 38 s'applique généralement au moyen du transfert inverse de chemin de monodiffusion (Unicast Reverse Path Forwarding — uRPF, RFC 3704). Dès qu'un paquet se présente sur une interface, le moteur de routage consulte sa table d'acheminement (FIB) pour vérifier si l'adresse source correspond au chemin inverse valide vers cette même interface physique.

En mode strict :

• Si l'adresse source relève du sous-réseau assigné à l'interface, le paquet est accepté.
• Si le paquet revendique une adresse joignable par un autre port ou non routable, le noyau l'élimine immédiatement au niveau du pilote réseau.

Bien que formulé il y a plus de vingt ans, le déploiement de BCP 38 demeure hétérogène à l'échelle mondiale. Les systèmes autonomes dépourvus de filtrage d'entrée continuent de laisser transiter des paquets falsifiés, reportant la charge d'infrastructure sur les résolveurs et les victimes.

Durcissement des systèmes Linux : Protection des résolveurs et du noyau

Les gestionnaires d'infrastructures hébergeant des démons de résolution DNS récursive doivent appliquer des configurations rigoureuses pour éviter que leurs serveurs ne servent de relais d'amplification involontaires.

1. Restriction de la récursion ouverte sous Unbound et BIND

La RFC 5358 préconise de limiter strictement la récursion aux seules plages d'adresses IP de clients autorisés.

Dans la configuration d'Unbound (/etc/unbound/unbound.conf), limitez l'écoute aux adresses internes sécurisées :

server:
    # Écoute exclusive sur les interfaces internes désignées
    interface: 127.0.0.1
    interface: 10.0.0.1

    # Rejet des demandes récursives émanant de l'Internet public
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.0.0.0/24 allow

Dans les paramètres de BIND 9 (named.conf.options), désactivez la récursion publique et instaurez la limitation du débit de réponse (RRL) :

options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/24; };
    allow-query { any; };
    
    # Activation du Response Rate Limiting (RRL)
    rate-limit {
        responses-per-second 10;
        window 5;
    };
};

2. Activation du filtrage strict du chemin inverse sous Linux

Pour rejeter au niveau du noyau les paquets dont l'adresse est falsifiée, paramétrez /etc/sysctl.d/99-urpf-anti-spoofing.conf :

# Application du filtrage strict du chemin inverse sur toutes les interfaces IPv4
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Neutralisation des diffusions ICMP pour parer aux attaques Smurf
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Journalisation des paquets portant des adresses d'expédition invalides
net.ipv4.conf.all.log_martians = 1

Pour charger immédiatement les règles dans la pile réseau active :

sudo sysctl --system

Neutralisation cryptographique de l'usurpation avec WireGuard & VPNRice

Les réseaux privés virtuels constituent une barrière indispensable contre l'usurpation d'adresses et les abus d'amplification. Les architectures modernes de niveau 3 valident mathématiquement la provenance de chaque paquet reçu.

Routage par clé cryptographique (Cryptokey Routing)

Les anciens protocoles d'encapsulation (tels que GRE brut ou les liaisons Point-à-Point sans clés) intègrent des paquets IP sans s'assurer que l'expéditeur interne est bien le client qui émet la trame. Une machine compromise au sein d'un VPN traditionnel peut émettre des paquets UDP usurpés via la passerelle de sortie.

WireGuard neutralise cette vulnérabilité grâce à sa table Cryptokey Routing. Chaque pair est associé de manière fixe à une clé publique unique ainsi qu'à une plage d'adresses IP autorisées (AllowedIPs) :

+---------------------------------------------------------------+
|                     Passerelle WireGuard                      |
|                                                               |
|  Pair A (Clé publique A) <---> AllowedIPs = 10.8.0.2/32       |
|  Pair B (Clé publique B) <---> AllowedIPs = 10.8.0.3/32       |
+---------------------------------------------------------------+

À la réception d'un paquet chiffré provenant du Pair A :

1. Le noyau déchiffre et authentifie la charge utile avec ChaCha20-Poly1305.
2. Le pilote réseau examine l'adresse IP source interne.
3. Si l'adresse source interne n'appartient pas strictement à la liste AllowedIPs du Pair A (par exemple, en cas de tentative d'injection d'une IP appartenant au Pair B ou à une adresse publique), le pilote supprime instantanément le paquet.

Aucun paquet doté d'une adresse source falsifiée ne peut franchir une interface WireGuard. Cryptokey Routing garantit une mise en œuvre matérielle et rigoureuse de la directive BCP 38.

Mesures de protection au sein de l'infrastructure RiceGuard

Sur l'ensemble du réseau VPNRice, l'intégrité du trafic est assurée sur les liaisons entrantes et sortantes :

1. Liaison cryptographique stricte : Chaque session de tunnel RiceGuard verrouille l'identité du point de terminaison à son adresse IP privée attribuée, prévenant toute émission de requêtes d'amplification.
2. Résolveurs Anycast internes dédiés : Les requêtes DNS des utilisateurs sont prises en charge par des résolveurs récursifs propres, fermés aux sollicitations de l'Internet public, configurés avec RRL et protégés par un canal chiffré.
3. Épuration du trafic volumétrique : Aux nœuds d'interconnexion de transit, VPNRice emploie des règles BGP Flowspec et des filtres eBPF pour éliminer les flux UDP réfléchis avant la saturation des interfaces.

En combinant les principes de filtrage de la RFC 2827 et l'authentification cryptographique de WireGuard, les infrastructures bloquent l'usurpation d'adresses à la source, protégeant l'écosystème réseau et la confidentialité des utilisateurs.