SecurCheckCentre Cyber

SOC · BGP · RPKI

Comment analyser une adresse IP suspecte lors d’une investigation informatique ?

Secur Cloud ·

Une connexion inconnue ou un pic de trafic dans les logs constitue un point de départ, pas une preuve d’intrusion. Pour analyser une adresse IP suspecte, il faut contextualiser l’infrastructure observée puis rapprocher les résultats des événements de votre système d’information.

Ce guide explique comment utiliser un analyseur d’adresse IP et d’ASN pour lire le WHOIS, examiner le routage BGP et interpréter RPKI. Une géolocalisation administrative seule ne suffit pas à décider d’un blocage.

1. Décoder l’attribution administrative : le WHOIS

  1. L’organisation déclarée

    Les registres Internet régionaux renseignent l’attribution des blocs IPv4 et IPv6. Le RIPE NCC couvre notamment l’Europe, le Moyen-Orient et une partie de l’Asie centrale. Le détenteur déclaré peut être un opérateur, un hébergeur ou une organisation : il n’est pas nécessairement l’utilisateur de l’adresse au moment de l’incident.

  2. Le contact abuse

    Recherchez le contact de signalement publié lorsqu’il est disponible. Vérifiez son périmètre et préparez un signalement factuel avec date, fuseau horaire, IP source et destination, ports et extraits de logs utiles. L’absence de contact dans le résultat peut refléter une limite de la source, pas une intention malveillante.

  3. Les limites du pays et de la géolocalisation

    Le pays du registre est une information administrative, pas une localisation certaine du serveur ou de l’appelant. Cloud, VPN, proxy, NAT et adresses partagées compliquent l’attribution. Ne confondez pas propriétaire du bloc, opérateur du service et auteur de l’action.

2. Analyser le routage public : ASN et BGP

  1. Identifier l’ASN d’origine et le préfixe

    Un numéro de système autonome (ASN) identifie un réseau appliquant une politique de routage. L’ASN d’origine observé dans BGP annonce le préfixe contenant l’IP. Il ne décrit pas à lui seul le chemin réellement emprunté par votre connexion ni l’identité de la machine source.

  2. Comparer WHOIS et BGP sans conclure trop vite

    Une différence entre détenteur administratif et ASN d’origine peut être normale : délégation, hébergement, transit ou annonce pour un client. Un changement inattendu mérite une comparaison avec l’historique, les autorisations et d’autres observations. Une incohérence seule ne démontre pas un détournement de préfixe.

  3. Corréler avec l’activité observée

    Une IP de VPS ou de VPN n’est pas une preuve d’attaque. Examinez les tentatives de connexion, la fréquence, les ports, les réponses applicatives et les autres IoC. La visibilité BGP dépend aussi des collecteurs et des dates de mesure ; une route absente d’une source peut être visible ailleurs.

3. Interpréter la validation d’origine RPKI

Les ROA autorisent un ASN à annoncer certains préfixes. La validation d’origine compare l’annonce à ces autorisations ; elle ne valide pas tout le chemin AS et ne garantit pas qu’une connexion est légitime.

  1. Valid : origine autorisée

    Au moins une autorisation couvrante correspond à l’ASN d’origine et permet la longueur du préfixe annoncé, dans la limite de maxLength. Cela valide l’origine de la route au regard des données disponibles, pas la sûreté de l’hôte ou de son trafic.

  2. Invalid : origine ou longueur incompatible

    Une autorisation couvre le préfixe, mais aucune ne permet la combinaison origine/longueur observée. Une mauvaise configuration ou un changement non répercuté peut l’expliquer, comme un détournement. Faites confirmer la cause avant d’attribuer une intention.

  3. Not Found / Unknown : pas d’autorisation couvrante

    La validation ne trouve pas d’autorisation couvrante dans les données consultées. Ce statut ne prouve ni fraude ni innocuité. Distinguez-le d’une source indisponible ou d’un échec de requête, qui ne permet pas de conclure sur le statut RPKI.

4. Garder des traces exploitables à un instant T

Le bouton « Copier le JSON » de RIPE IP permet de conserver le rapport, son horodatage de consultation et l’état des sources. Archivez-le avec les logs d’origine, le fuseau horaire, l’IP, les ports et le contexte de l’alerte. Les données de registre ou de routage peuvent avoir leur propre date de collecte : une consultation actuelle ne reconstitue pas automatiquement l’état au moment d’un incident passé.

Documentez les informations manquantes et le raisonnement qui conduit à une escalade ou à un filtrage. Évaluez les effets sur les services partagés avant de bloquer un préfixe ou un ASN entier. Une recherche IP et ASN apporte du contexte, pas une attribution certaine de l’attaquant.

Déployer SecurCheck Entreprise pour accompagner vos administrateurs réseau

Références techniques