Tout d'abord, clarifiez : cherchez-vous l'enregistrement, le routage, la localisation ou le risque ?
Les outils de requête IP sont nombreux, mais la distinction essentielle réside dans les différentes questions auxquelles ils répondent. Pour savoir sous quel organisme se trouve une plage d'adresses, l'adresse e-mail de contact ou le portail de signalement d'abus, consultez les données d'enregistrement RDAP ; pour savoir quels systèmes autonomes annoncent actuellement un préfixe dans le réseau, consultez un instantané de la table de routage BGP ; pour savoir si un préfixe spécifique dispose d'une autorisation d'origine de route valide, consultez l'état de validation RPKI ; et pour évaluer le risque d'abus ou de proxy lié à une adresse IP, vous pouvez consulter le rapport de réputation IP. Mélanger ces questions, ou s'attendre à ce qu'un outil fournisse simultanément une localisation physique précise, un chemin en temps réel et un score de risque commercial, conduit souvent à des erreurs de jugement.
Le champ pays sur la page peut provenir de l'enregistrement des ressources ou de la base de données GeoIP, il faut d'abord en lire la source. Voir un utilisateur constater une incohérence entre le pays, la langue de la page ou la marque du réseau, et en déduire l'utilisation d'un VPN ou d'Anycast, constitue une preuve insuffisante. Vous pouvez d'abord utiliser la Recherche d’adresse IP pour enregistrer chaque champ, puis vérifier séparément RDAP, BGP et l'estimation de localisation ; consultez ensuite le Réputation IP : comprendre les scores et listes de blocage si vous vous intéressez à la réputation. Ces outils ne répondent pas à la même question.
Lors du traitement d'incidents ou d'événements de sécurité, le personnel d'exploitation doit limiter la conclusion de chaque outil à son champ de preuve. Par exemple, une requête de routage BGP ne peut que vous indiquer les annonces de route observées et les attributs AS_PATH, elle ne peut pas prouver directement par quels liens physiques les paquets passent de bout en bout. Utilisez les résultats de requête comme pistes de dépannage, puis combinez-les avec d'autres preuves telles que traceroute, les données de flux ou les compteurs d'interface, pour former un jugement fiable. Éviter de nier toutes les autres informations avec un seul résultat de requête est une discipline fondamentale dans l'interprétation des données IP.
À quelles questions d'enregistrement RDAP peut-il répondre ?
RDAP (Registration Data Access Protocol) fournit des données d'enregistrement via des réponses structurées, utilisé à la fois pour les ressources de numérotation Internet et pour l'enregistrement de noms de domaine ; cet article se concentre sur les ressources de réseau IP et de systèmes autonomes. La réponse peut contenir des plages d'adresses, des identifiants d'objet, des rôles de contact et des événements, mais le degré de divulgation et l'exhaustivité des champs sont déterminés par la politique du registre et l'enregistrement spécifique. On ne peut pas présumer que chaque requête fournisse l'utilisateur final, l'historique complet ou une adresse e-mail d'abus utilisable.
Il est important de noter que l'adresse de contact dans RDAP est une adresse d'enregistrement publique, généralement l'adresse du bureau ou l'adresse légale de l'organisation enregistrée, et ne peut être assimilée à l'emplacement du périphérique IP ou à la position actuelle de l'utilisateur. Par exemple, l'adresse RDAP d'une entreprise multinationale peut être enregistrée dans la ville du siège social, tandis que les serveurs utilisant réellement cet IP peuvent se trouver dans des centres de données d'autres pays. Utiliser directement la carte d'adresse RDAP comme « localisation IP » surestime la précision de la localisation. Les spécifications du protocole RFC 9082 et RFC 9083 précisent la structure des requêtes et réponses RDAP, mais n'exigent pas que les données d'enregistrement contiennent la localisation physique.
Lorsqu'il est nécessaire de confirmer la partie responsable de l'enregistrement d'un préfixe, utiliser directement l'outil Recherche RDAP pour consulter les enregistrements originaux est plus fiable que de se fier à des résumés de seconde main. Les résultats de requête affichent le nom du réseau, le code pays, l'organisme d'enregistrement, l'état (comme allocated, assigned), l'historique des événements et l'adresse e-mail d'abus. Ces champs peuvent aider l'opérateur à déterminer si une plage d'adresses a des informations d'enregistrement non mises à jour depuis longtemps, ou si elle appartient à une allocation spéciale, mais ils ne permettent pas d'en déduire si cette plage lance des attaques, héberge des services malveillants, ou appartient à un utilisateur final particulier. La preuve RDAP ne couvre que le cycle de vie de l'enregistrement, pas le comportement en temps réel.
Pourquoi l'ASN n'équivaut-il pas à la marque du fournisseur de services ?
Un ASN (numéro de système autonome) identifie un domaine de politique de routage sous le contrôle d'un ou plusieurs opérateurs de réseau. Les préfixes sous un même ASN peuvent être utilisés pour divers services, notamment l'hébergement de centres de données, les services cloud, les CDN, les réseaux de contenu, ainsi que les services de proxy transparent fournis pour différentes marques de détail ou locataires. Par conséquent, le seul ASN ne permet pas de déterminer à quelle marque grand public ou à quel emplacement spécifique appartient un IP. L'ASN d'un grand fournisseur cloud peut héberger simultanément les adresses IP de dizaines d'entreprises, et le nom de l'organisation enregistrée peut n'avoir aucun lien direct avec ces entreprises.
Un système autonome peut couvrir plusieurs régions et activités, et le nom de l'organisation peut différer de la marque de détail, du client ou du locataire cloud. Les opérateurs transnationaux peuvent annoncer des préfixes dans plusieurs pays, et une même entreprise peut gérer plusieurs ASN. L'Anycast est l'un des modes de déploiement de service possibles, dont les limites opérationnelles peuvent être consultées dans la RFC 4786, mais on ne peut pas déduire directement la localisation géographique d'une adresse IP spécifique, l'identité du locataire ou le déploiement Anycast à partir du pays d'enregistrement de l'ASN ou du nom de l'entreprise.
Dans l'analyse de sécurité, un petit ASN ne doit pas non plus être simplement assimilé à un risque élevé. Un système autonome avec peu de préfixes et un historique court peut être un nouveau fournisseur de contenu légitime, un réseau de recherche ou un FAI régional. Le jugement du risque doit être basé sur le comportement de routage, la stabilité des annonces historiques, l'état de validation RPKI et les plaintes d'abus réelles, et non uniquement sur la taille de l'ASN ou l'ancienneté des informations d'enregistrement. Consulter le routage BGP et l'historique d'un ASN peut aider à comprendre ses habitudes d'annonce, mais cela ne reste qu'une des preuves pour aider au jugement.
Préfixe BGP, ASN d'origine et AS_PATH
La requête BGP affiche les informations du plan de contrôle reçues par un point d'observation spécifique, y compris le préfixe, l'ASN d'origine, l'AS_PATH et l'heure. Lors de la requête d'une seule adresse IP, l'outil peut sélectionner le préfixe le plus long couvrant cette adresse IP. La correspondance du préfixe le plus long est une règle importante dans la recherche de table de transfert : lorsqu'il y a une correspondance plus spécifique dans la table de transfert, le paquet est transmis selon cette entrée ; cela diffère de la sélection du meilleur chemin parmi plusieurs routes candidates pour le même préfixe en BGP. Aucun des deux ne peut fournir directement une liste complète des liens physiques.
L'attribut AS_PATH liste la séquence de systèmes autonomes traversés par la route, mais il ne correspond pas au chemin réel de transmission des paquets dans le plan de données. Les politiques de routage, la préférence locale, la valeur MED, les confédérations BGP et les tunnels MPLS peuvent tous faire diverger le chemin réel des paquets de l'AS_PATH du plan de contrôle. Par exemple, un paquet peut passer par un pair distant qui n'apparaît pas dans l'AS_PATH. Par conséquent, utiliser Recherche de routes BGP pour déterminer l'annonceur actuel d'un préfixe peut aider à évaluer le contrôle de la route, mais ne permet pas de déduire précisément le chemin de trafic de bout en bout.
Si vous avez besoin de consulter l'historique des annonces d'un préfixe, par exemple pour savoir s'il a changé d'ASN d'origine ou si des annonces plus spécifiques ont été faites, vous pouvez vous référer aux données Historique BGP. Les instantanés historiques peuvent montrer l'état des annonces d'un préfixe à un moment donné et les variations de l'AS_PATH, mais l'absence de données historiques peut aussi être due à des points d'observation incomplets ou à des routes non collectées. Toute vue d'un collecteur de routes unique n'est qu'une partie de l'état global du routage Internet et ne peut être considérée comme la vérité complète. En combinant les données de plusieurs points d'observation, on obtient une compréhension plus fiable de la stabilité du routage.
RPKI : Valid, Invalid et NotFound
RPKI (Resource Public Key Infrastructure) autorise un ASN à annoncer un préfixe spécifique en émettant des ROA (Route Origin Authorization), et peut optionnellement spécifier une longueur de préfixe maximale maxLength. Lors de la validation d'origine, le routeur ou l'outil de validation compare le préfixe et l'ASN d'origine de la route BGP avec l'ensemble des VRP (Validated ROA Payload) générés par les ROA valides. Le résultat de la validation se classe en trois états : Valid, Invalid et NotFound.
L'état Valid signifie qu'il existe au moins un VRP dont le préfixe autorisé couvre le préfixe annoncé, dont l'ASN d'origine correspond, et dont la longueur de préfixe est dans la plage autorisée (en tenant compte généralement de maxLength). L'état Invalid signifie qu'il existe un ou plusieurs VRP couvrant ce préfixe, mais que l'ASN d'origine ne correspond pas ou que la longueur de préfixe dépasse la plage autorisée. Selon la RFC 6811, Invalid n'équivaut pas automatiquement à un détournement de route ou à une activité malveillante, car des erreurs de configuration, des mises à jour de ROA en retard ou des erreurs opérationnelles peuvent toutes conduire à un état Invalid.
L'état NotFound signifie qu'aucun VRP ne couvre ce préfixe, généralement parce que le détenteur de la ressource n'a pas créé de ROA, ou que le validateur n'a pas encore obtenu les dernières données ROA. NotFound ne doit pas être interprété comme un signal d'attaque ; il indique simplement que l'autorisation d'origine ne peut pas être déterminée via RPKI. L'utilisation d'un outil Validation RPKI permet de consulter l'état de validation d'un préfixe IP spécifique, les détails des ROA correspondants et l'heure de validation. Les opérateurs doivent enregistrer l'horodatage de chaque validation, car les données RPKI sont dynamiques et l'état d'un préfixe peut changer en fonction de la publication ou de la révocation des ROA.
Pourquoi Valid n'est pas un certificat de sécurité ?
La validation d’origine RPKI vérifie si l’ASN d’origine et la longueur du préfixe d’une route sont autorisés par les données des ROA validés à cet instant. Un résultat Valid n’authentifie pas le reste de l’AS_PATH, ne prouve ni la sécurité des paquets ni la fiabilité des équipements terminaux, et n’évalue pas le comportement des utilisateurs ou la sécurité du contenu. Un réseau malveillant peut disposer d’un ROA valide pour son propre préfixe, obtenir un résultat Valid pour sa route et continuer à mener des activités nuisibles sur son infrastructure. Un résultat Valid pour la route couvrant une adresse IP ne garantit donc ni l’absence d’abus provenant de cette adresse ni la fiabilité du service.
De même, l'état Invalid ne peut pas être directement jugé comme un détournement de route. Les scénarios d'ingénierie courants incluent : un opérateur qui migre un préfixe sans mettre à jour le ROA à temps, ou qui configure incorrectement maxLength, rendant des annonces plus spécifiques non autorisées. Ce sont des problèmes de configuration d'enregistrement de routage, et l'état Valid peut être rétabli en corrigeant le ROA. D'un autre côté, un véritable pirate peut utiliser un préfixe non couvert (c'est-à-dire NotFound) pour faire des annonces, ce qui montre encore plus que l'état en soi ne constitue pas une conclusion de sécurité.
Lors du signalement à un opérateur, il faut conserver l'heure d'observation, le préfixe spécifique, l'ASN d'origine, l'ASN autorisé et le maxLength du VRP couvrant, ainsi que le validateur ou la source de données. Une formulation indicative serait : « À l'heure indiquée, 203.0.113.0/24, origine AS64496, a été validé comme Invalid ; il existe un VRP couvrant, mais aucun enregistrement ne satisfait à la fois l'origine et la longueur. » Ici, des ressources d'exemple de documentation sont utilisées, pas une alerte de routage réelle. Le destinataire doit vérifier l'ensemble complet des correspondances, et ne peut pas ignorer une autre autorisation valide en ne regardant qu'un seul VRP non correspondant.
Pourquoi le pays d'enregistrement et le pays de localisation diffèrent-ils ?
La divergence entre le pays d'enregistrement et le pays de localisation n'indique pas automatiquement une erreur de localisation ou la présence d'Anycast. Les adresses IP sont allouées par les registres Internet régionaux à des organisations multinationales, qui peuvent choisir de s'enregistrer dans le pays de leur siège social, tandis que l'utilisation réelle se fait dans des succursales ou des centres de données du monde entier. Par exemple, une entreprise européenne enregistre toute une plage d'adresses IP aux Pays-Bas, mais les serveurs loués se trouvent à Singapour ; lors d'une requête, le pays d'enregistrement affiche les Pays-Bas, tandis que la latence réseau et les observations de routage pointent vers Singapour. C'est une situation normale, pas une anomalie.
Après qu'un FAI en amont a obtenu une grande ressource, il peut l'allouer à différents clients ou régions, tandis que les enregistrements, les bases de localisation commerciales et les caches des sites web se mettent à jour chacun de leur côté. Les transferts de ressources, les changements d'allocation ou les révisions de données peuvent tous causer des décalages temporels, et on ne peut pas supposer qu'ils se synchroniseront nécessairement après un nombre fixe de semaines ou de mois. Il faut enregistrer l'heure et la source précises de la requête, distinguer l'objet d'enregistrement actuel, les instantanés historiques et les estimations de localisation, et éviter de remplacer la signification d'un champ par celle d'un autre.
Les facteurs de disposition du réseau incluent les CDN, les fournisseurs de cloud et les lignes privées transnationales, qui déploient des adresses du même préfixe dans plusieurs pays. Dans ce cas, aucun « pays d'enregistrement » unique ne peut représenter le point d'entrée réel du trafic. Pour déterminer si une adresse IP fournit des services dans un pays spécifique, il faut combiner le chemin AS dans la route BGP, des mesures actives de ping/traceroute et les informations publiques sur les régions des fournisseurs de cloud. Déduire l'Anycast uniquement à partir de la divergence des pays est une preuve insuffisante.
Quelle est la différence entre Anycast et broadcast ?
L'Anycast permet à plusieurs instances de service d'utiliser la même adresse, le routage envoyant une requête à l'une des instances accessibles ; les déploiements Internet courants annoncent le préfixe portant cette adresse depuis plusieurs emplacements. L'instance choisie dépend des politiques de routage, sans garantie de proximité géographique, de latence minimale ou de charge minimale. Le broadcast, quant à lui, envoie un message à plusieurs destinataires au sein du domaine de diffusion ; les deux sont complètement différents. Pour les pratiques d'ingénierie de l'Anycast, on peut se référer à la RFC 4786.
Pour déterminer l'Anycast, vous pouvez combiner la documentation explicite de l'opérateur concernant cette adresse de service avec des mesures effectuées à plusieurs endroits et à des moments simultanés, ainsi que des identifiants d'instance. Le même ASN peut apparaître sur plusieurs sites Anycast, il n'est donc pas nécessaire que les ASN de destination diffèrent ; des ASN différents ou des chemins traceroute différents ne prouvent pas automatiquement l'Anycast, car les changements de routage, les tunnels et les limitations de mesure peuvent tous influencer les résultats. Vous devez indiquer jusqu'où les preuves peuvent soutenir une conclusion, et ne pas qualifier une adresse uniquement sur la base de quelques étiquettes de pays.
Une erreur courante consiste à considérer les « différences de champs de pays » comme une preuve d'Anycast, par exemple lorsque la même adresse IP est affichée comme étant aux États-Unis dans une base de données commerciale et en Allemagne dans une autre. Cela indique seulement une incohérence des sources de données de géolocalisation, qui peut être due à des problèmes d'enregistrement, de routage ou de mise à jour de base de données, et ce n'est en aucun cas une condition suffisante pour l'Anycast. Tout jugement opérationnel doit clairement distinguer la possibilité de la preuve, et éviter de présenter des hypothèses non vérifiées comme des conclusions.
Cas illustratif : qui sont respectivement le titulaire de l'enregistrement, l'exploitant et le locataire ?
Le scénario suivant est illustratif et ne repose sur aucune mesure réelle. Supposons que vous interrogiez l'adresse d'exemple 192.0.2.10. Le RDAP indique que le pays d'enregistrement est les États-Unis et que l'organisation d'enregistrement est Example Corp, tandis que l'ASN d'origine annoncé par la route BGP appartient à un fournisseur de cloud européen. Cette différence peut s'expliquer par le fait qu'Example Corp loue le bloc d'adresses à un fournisseur de cloud, qui déploie des nœuds périphériques à Francfort et à Tokyo sans mettre à jour les informations d'enregistrement. Sur la base de ces seules informations, vous ne pouvez pas confirmer l'emplacement physique actuel de cette adresse IP ni si l'Anycast est utilisé.
Poursuivons cette hypothèse : deux points de mesure situés près de Francfort et de Tokyo atteignent chacun une instance de service locale et obtiennent des identifiants d'instance différents et vérifiables, alors que la cible de la requête est la même adresse d'exemple 192.0.2.10. Associée à une déclaration Anycast explicite de l'opérateur pour cette adresse, cette configuration peut étayer un jugement de déploiement multi-sites. Ceci décrit uniquement un exemple logique et ne prétend pas qu'une latence inférieure à 10 millisecondes soit atteignable depuis n'importe quel point du globe. Un statut RPKI Valid vérifie uniquement l'autorisation d'origine du préfixe, et ne prouve pas l'emplacement des instances.
Dans ce cas, les inconnues comprennent : l'identité précise du locataire, l'ouverture des ports de service à toutes les régions, le mécanisme de synchronisation d'état entre les instances, et l'existence d'un filtrage de paquets par des réseaux intermédiaires. Le personnel d'exploitation doit consigner ces inconnues telles quelles, au lieu d'utiliser l'étiquette « Anycast » pour masquer le manque de preuves. Une classification n'équivaut pas à un acte malveillant, et une absence de correspondance n'équivaut pas à une attaque ; indiquer clairement les limites est le fondement d'un jugement professionnel.
Pourquoi les enregistrements historiques et les résultats actuels divergent-ils ?
Les événements RDAP sont généralement décrits par des champs tels que eventAction et eventDate, par exemple « registration » ou « last changed » ; certaines interfaces affichent un résumé tel que « updated ». Ces dates décrivent des événements sur l'objet d'enregistrement et ne correspondent pas à l'heure d'un déménagement physique du serveur. La modification de l'adresse e-mail, du statut ou des données administratives peut changer la date de mise à jour, tandis que l'emplacement du service peut aussi changer sans être reflété dans les champs concernés. Vous devez conserver les noms d'événements d'origine et ne pas interpréter uniformément toutes les dates comme des migrations d'adresse.
Le découpage de préfixes et les transferts de ressources sont des causes fréquentes. Lorsqu'un grand bloc /16 est divisé en plusieurs /24, certains sous-blocs peuvent être attribués à d'autres organisations, mais le champ pays de l'enregistrement parent conserve sa valeur d'origine. Dans ce cas, une requête RDAP sur un /24 particulier peut renvoyer la valeur historique du pays parent, tandis que la route BGP montre que ce sous-bloc est désormais annoncé par un ASN d'un autre pays. Des points d'observation différents peuvent aussi créer des incohérences : les bases de données IP commerciales reposent sur des sources et des horaires de collecte différents, et les différences entre instantanés peuvent s'étendre sur plusieurs mois.
L’exemple hypothétique suivant illustre la manière de consigner les éléments. La bonne approche consiste à conserver tous les enregistrements d'origine et à indiquer l'heure de la requête. Par exemple : en janvier 2024, le RDAP indique le Royaume-Uni comme pays ; en juin 2024, le chemin BGP passe par l'Allemagne ; en septembre 2024, un point d'observation obtient un traceroute se terminant aux Pays-Bas. Vous ne pouvez pas simplement dire « cette IP a déménagé aux Pays-Bas », mais plutôt « il existe des différences selon les moments et les points d'observation, qui peuvent impliquer des ajustements de routage ou un retard de mise à jour des bases de données ». Cela préserve les preuves tout en évitant les inférences excessives.
Comment combiner les preuves et conserver les inconnues ?
Un jugement complet sur une requête IP doit être réparti en quatre catégories de preuves. Le contexte d'enregistrement provient du RDAP et du WHOIS, notamment l'organisation d'enregistrement, le pays, la date d'enregistrement, l'adresse e-mail de contact et le statut, mais il ne contient ni localisation physique ni identité de l'utilisateur final. L'état de routage provient de BGP et de RPKI, notamment l'ASN annoncé, le chemin AS, la validité RPKI (Valid, Invalid ou NotFound) et la visibilité ; il reflète uniquement l'accessibilité du plan de contrôle et ne garantit pas le chemin complet du plan de données. L'estimation de localisation provient des bases de données IP commerciales, de la latence et du traceroute, et constitue un jugement probabiliste.
Le comportement direct doit être enregistré indépendamment, par exemple s'il y a eu un balayage actif, une résolution de domaine malveillante ou une réponse sur des ports spécifiques. Une adresse IP enregistrée auprès d'un FAI résidentiel, même si sa géolocalisation correspond à une ville donnée, ne signifie pas que cette adresse IP appartient à un véritable utilisateur domestique, car il peut exister des services de proxy ou d'hébergement. Pour les points clés sur la distinction entre IP résidentielle et IP native, voir IP résidentielle, hébergée chez un FAI ou de datacenter ?. Lorsque la couverture des points d'observation est insuffisante, la même adresse IP peut apparaître comme injoignable dans certaines régions, ce qui ne prouve pas une inaccessibilité mondiale ; voir Réputation d’un sous-réseau /24 : couverture et risques.
Supposons que le pays d'enregistrement soit le Canada, que l'ASN soit géré par un FAI canadien, que le RPKI soit Valid, que les bases de données commerciales estiment Toronto et que certains points de mesure canadiens présentent une faible latence. Vous pouvez indiquer que ces résultats concordent avec un emplacement de service au Canada, mais vous ne pouvez pas les présenter comme une preuve de localisation physique, ni déduire du RPKI que le service fonctionne normalement. L'enregistrement est une donnée, le routage est une observation, la localisation est une estimation, et l'enregistrement comportemental a aussi ses sources et ses limites de mesure ; toutes les conclusions doivent préciser le moment, les conditions et ce qui reste non confirmé.
Questions fréquentes et documents de révision
Question fréquente n° 1 : un changement d'ASN signifie-t-il un changement d'opérateur ? Pas nécessairement. L'ASN représente un domaine de politique de routage ; un grand opérateur peut posséder plusieurs ASN, et une entreprise peut migrer vers un fournisseur de cloud tout en conservant son bloc d'adresses IP d'origine. Vous devez vérifier si le préfixe IP est annoncé par des ASN différents dans la même route BGP, ou s'il y a des changements de chemin AS, et combiner cela avec les informations d'enregistrement pour déterminer si le fournisseur de réseau a réellement changé.
La validation d'origine RPKI ne protège pas contre toutes les attaques de routage et n'authentifie pas l'AS_PATH complet. Une formulation rigoureuse est « la route est Valid, Invalid ou NotFound par rapport à l'ensemble actuel de VRP », et il ne faut pas abréger Invalid en « ROA invalide », car ce ne sont pas les mêmes concepts. Le RDAP n'est pas non plus un outil de localisation personnelle du terminal : même si un objet public contient des informations personnelles ou de contact, il s'agit toujours de données d'enregistrement de ressources, qui ne permettent pas d'identifier la personne qui initie actuellement la requête ni son adresse précise.
Le cadre de révision des tickets doit exiger que le demandeur fournisse : l'heure de la requête (UTC), l'adresse IP ou le préfixe précis, un instantané RDAP/WHOIS, la table de routage BGP ou la source d'observation traceroute, l'état actuel (par exemple échec de connexion ou fuite de route) et la demande spécifique. Le personnel d'exploitation vérifie d'abord les champs d'enregistrement, puis le RPKI et le chemin AS, et enfin consulte la localisation et les mesures actives. L'utilisation de ce cadre réduit les erreurs de jugement telles que « si le champ pays ne correspond pas, c'est qu'il y a eu un piratage ».
