DNS rebinding, empoisonnement de cache, points de terminaison de métadonnées cloud et plages d'IP qu'un outil de recherche sûr doit refuser de renvoyer.
Les enregistrements que vous croiserez dans presque toutes les zones
Découvrez comment les enregistrements DNS CAA désignent les émetteurs de certificats autorisés et comment éviter les erreurs de configuration courantes.
Une recherche DNS récursive, saut après saut
Navigateur
veut example.com
Résolveur
votre FAI / 1.1.1.1
Racine + TLD
qui gère .com ?
Faisant autorité
la vraie réponse
Chaque saut de cette chaîne est lui-même une recherche DNS, ensuite mise en cache
Découvrez le rôle des signatures DNSSEC et des enregistrements DS et DNSKEY, le fonctionnement de la validation et comment une erreur provoque des SERVFAIL.
Chaque plage IPv4 a son équivalent IPv6
Côté sécurité, IPv6 n'est pas « de l'IPv4 avec plus d'adresses » : quelques-unes de ses différences changent réellement le modèle de menace.
Gagner la course avec une réponse falsifiée
Attaquant
devance la vraie réponse
Réponse falsifiée
arrive en premier
Cache du résolveur
empoisonné pour tous ses utilisateurs
Falsifier des réponses DNS pour détourner le trafic est l'un des plus vieux trucs du réseau, et la raison d'être de DNSSEC et des défenses des résolveurs.
Espace d'adressage public et privé
IP publique
192.0.2.10
unique au monde : routable de partout
Plages privées
non routables sur Internet
10.0.0.0/8, 192.168.0.0/16 et leurs voisines existent précisément pour ne jamais être uniques à l'échelle mondiale : voici pourquoi cela compte pour le DNS.
Le SSRF transforme un serveur en proxy malgré lui
Attaquant
fabrique une URL de requête
Serveur vulnérable
la récupère, dupé par le SSRF
169.254.169.254
le point de terminaison des métadonnées
Identifiants
renvoyés à l'attaquant
Une seule adresse IP d'apparence non routable donne aux instances cloud l'accès à des identifiants et à leur configuration, et c'est une cible SSRF courante.
La même adresse, quatre façons de l'écrire
Une falsification de requête côté serveur commence souvent par un simple nom de domaine que votre serveur a été piégé à résoudre puis à interroger.
Le même domaine, deux réponses différentes
Première requête
résolue vers une IP publique
Validation
réussie : semble sûre
Expiration du TTL
quelques secondes plus tard
Seconde requête
résolue vers 127.0.0.1
Un domaine qui se résout d'abord vers une adresse sûre, puis vers une adresse interne : le DNS rebinding fait du DNS lui-même une surface d'attaque.