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
Pourquoi les plages d'IP privées ne devraient jamais se résoudre publiquement
La RFC 1918 a réservé trois plages IPv4 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16) spécifiquement pour un usage à l'intérieur de réseaux privés, justement parce qu'il n'y a pas assez d'adresses IPv4 publiques pour que chaque appareil de chaque réseau privé en ait une unique à l'échelle mondiale. Ces plages sont réutilisées, simultanément, dans des millions de réseaux sans rapport dans le monde entier. Votre routeur domestique distribue presque certainement des adresses 192.168.x.x ; celui de presque tout le monde aussi.
Ce que signifie qu'un domaine public se résolve dans cette plage
Comme ces adresses n'ont de sens qu'au sein du réseau local qui interroge, un domaine public qui se résout vers l'une d'elles est, au mieux, une erreur de configuration, et au pire une tentative délibérée de pousser un système exposé au public à envoyer une requête à ce qui se trouve à cette adresse sur son propre réseau interne. L'internet public n'a aucune idée cohérente de ce que 10.0.0.5 désigne même ; c'est une machine différente selon le réseau qui interroge.
| Plage | Nom | Pourquoi elle est bloquée |
|---|---|---|
| 10.0.0.0/8 | Privée (RFC 1918) | Réutilisée dans des millions de réseaux sans rapport |
| 172.16.0.0/12 | Privée (RFC 1918) | Idem |
| 192.168.0.0/16 | Privée (RFC 1918) | Idem : la plage courante des routeurs domestiques |
| 127.0.0.0/8 | Boucle locale (loopback) | Renvoie à la machine qui interroge elle-même |
| 169.254.0.0/16 | Lien local (link-local) | Inclut 169.254.169.254, le point d'accès aux métadonnées cloud |
| 100.64.0.0/10 | Espace d'adressage partagé (RFC 6598) | NAT de niveau opérateur : souvent absente des listes de blocage faites maison |
| 0.0.0.0/8 | Non spécifiée | Pas une véritable destination routable |
| 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | Plages de documentation | Réservées aux exemples, jamais destinées à être actives |
- Un domaine public légitime n'a aucune raison de se résoudre vers une adresse d'une plage privée : si vous en voyez une, considérez-le comme un signal à examiner, pas comme un résultat normal.
- IPv6 a ses propres plages privées et réservées équivalentes (adresses locales uniques fc00::/7 et lien local fe80::/10) qui exigent le même traitement.
Filtrer ces plages au moment de la résolution, plutôt que de supposer qu'un domaine d'apparence publique se résout toujours vers une adresse d'apparence publique, est l'exigence de base pour tout outil qui résout des domaines pour le compte d'un utilisateur.
La plage que la plupart des listes de blocage oublient
100.64.0.0/10 (l'« espace d'adressage partagé », défini par la RFC 6598) est loin d'être aussi connue que 10.0.0.0/8 ou 192.168.0.0/16, alors qu'elle est tout aussi non routable sur l'internet public. Elle existe spécifiquement pour le NAT de niveau opérateur, qui permet à un fournisseur d'accès d'adresser en interne un grand nombre de connexions clients sans consommer d'espace IPv4 public pour chacune. Parce qu'elle est plus récente et moins connue que les plages classiques de la RFC 1918, c'est celle qui manque le plus souvent dans une liste de blocage faite maison, exactement le genre de lacune qui n'apparaît que lorsque quelqu'un fait volontairement pointer un domaine vers une adresse située dedans.
Le « fail closed » compte autant que la liste elle-même
Une liste de blocage ne vaut que ce qui se passe lorsqu'une adresse ne peut pas du tout être analysée. Une entrée mal formée, une notation inhabituelle ou une valeur qui ne correspond clairement à aucune plage connue ne devrait jamais être traitée comme « probablement correcte » par défaut : le réflexe sûr est de rejeter tout ce qui ne peut pas être classé avec certitude comme public, plutôt que de ne rejeter que les adresses qui correspondent positivement à une plage connue comme dangereuse. Cette posture « fail closed » (échec fermé) est ce qui rend une liste de blocage robuste face aux plages que personne n'a encore pensé à ajouter, et pas seulement face aux plages bien connues déjà listées.
Besoin de vérifier les adresses DNS publiques d'un domaine ? Utilisez l'outil Domain IP Lookup.
Outils gratuits sur ce sujet
À lire aussi
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
Métadonnées cloud : la surface d'attaque cachée
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
Attaques SSRF expliquées : comment le DNS est exploité
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
Qu'est-ce que le DNS rebinding et pourquoi s'en soucier ?
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.