À qui appartient l'adresse ? Attribuer une IP avant de lire sa localisation dans le tri SOC

Résumé

Les alertes d'identité comme le voyage impossible, la localisation inhabituelle ou la connexion depuis un nouveau pays reposent sur une seule inférence : la localisation associée à une adresse IP est l'endroit où se trouvait l'utilisateur. Cette inférence est souvent fausse, et elle se trompe dans les deux sens. Un VPN d'entreprise, un proxy de sécurité ou un opérateur mobile place un utilisateur légitime dans une ville où il n'a jamais mis les pieds, ce qui produit des faux positifs. Un attaquant qui relaie une session volée par un hébergement loué près de la victime a l'air local, ce qui produit des faux négatifs. Cette note décrit la règle que nous appliquons au tri : avant de lire la géographie d'une adresse, établir qui l'exploite. Elle donne les catégories que nous utilisons, les sources passives qui répondent à la question, et un exemple construit sur des adresses de documentation que chacun peut rejouer.

D'où vient la localisation

Un journal de connexion n'enregistre pas l'endroit où se tenait une personne. Il enregistre l'adresse source de la connexion, et la localisation affichée à côté vient d'une base de géolocalisation qui associe des plages d'adresses à des lieux. Ces bases sont des estimations. Leurs fournisseurs publient des rayons de précision, et l'estimation correspond souvent à la localisation déclarée du réseau ou à l'endroit où son trafic rejoint internet. Ni l'une ni l'autre ne dit où se trouve un utilisateur donné.

Pour une ligne haut débit à domicile, l'estimation est en général assez proche. Pour la plupart des infrastructures qu'un utilisateur en entreprise traverse réellement, elle décrit l'infrastructure.

Pourquoi la géographie trompe

Plusieurs situations ordinaires éloignent la localisation apparente de l'utilisateur :

• Un VPN d'entreprise en tunnel complet fait sortir toutes les connexions par le concentrateur de la société : un utilisateur en déplacement à l'étranger apparaît au siège, et un utilisateur chez lui apparaît là où le concentrateur est hébergé.
• Les proxys de sécurité cloud et les services d'accès zero trust font sortir le trafic par le point de présence le plus proche du fournisseur, qui peut se trouver dans un autre pays.
• Les opérateurs mobiles font passer les données par un petit nombre de passerelles, si bien qu'un téléphone peut apparaître à des centaines de kilomètres de l'endroit où il se trouve.
• Un appareil en double pile peut utiliser une adresse IPv4 et une adresse IPv6 à quelques minutes d'intervalle, et les deux peuvent être géolocalisées différemment. Un seul portable a alors l'air de voyager.

Le cas inverse est celui qui coûte le plus. Les kits de phishing de type adversary in the middle relaient la connexion de la victime depuis le serveur qui fait tourner le kit, et ce serveur est souvent un hébergement loué. Un attaquant qui choisit un fournisseur disposant d'un centre de données dans le pays de la victime produit une connexion dont la localisation paraît normale. Un tri qui ne vérifie que le pays la refermerait.

La règle : attribuer d'abord

Chaque adresse d'une alerte reçoit une catégorie de propriétaire avant que quiconque lise sa localisation. Nous utilisons ces catégories :

Seule la catégorie FAI résidentiel ou professionnel permet une lecture géographique de l'utilisateur. Pour toutes les autres, le champ de localisation décrit une machine ou un réseau, et une analyse qui le traite comme la position d'une personne est fausse, quel que soit le verdict final.

Une catégorie hébergement ou anonymiseur ne prouve pas non plus une attaque. Des développeurs se connectent depuis des postes de travail cloud et certains utilisateurs paient un VPN. Elle déplace la question de « où était l'utilisateur » vers « pourquoi cet utilisateur s'authentifierait-il depuis un serveur », une meilleure question, à laquelle l'utilisateur ou son responsable peut répondre.

Les sources passives qui répondent

L'attribution se fait sans toucher à l'adresse elle-même :

• Votre propre inventaire des plages de sortie : pools VPN, passerelles proxy et NAT, et les plages publiées des services de sécurité auxquels vous êtes abonné. C'est la source la plus utile, et celle qui manque le plus souvent.
• RDAP (le successeur de WHOIS), pour le titulaire enregistré de la plage et le nom de son réseau.
• Le numéro de système autonome qui annonce le préfixe, qui distingue un opérateur mobile d'un hébergeur plus vite que le nom du titulaire.
• Le DNS inverse, quand il existe, pour les conventions de nommage comme les noms de passerelles d'un opérateur ou les noms d'instances d'un fournisseur cloud.
• Les listes publiques de nœuds de sortie Tor.

Nous ne scannons pas, ne pingons pas et ne nous connectons pas à une adresse tirée d'une alerte. Ce serait sonder activement une infrastructure que nous n'avons aucune autorisation de toucher, et un attaquant qui contrôle le serveur le verrait.

Un premier tri minimal ne demande rien de plus que la bibliothèque standard de Python. Il sépare ce que vous savez déjà (l'espace interne et vos propres sorties) de ce qui demande encore une recherche RDAP et ASN :

import ipaddress

# Votre propre inventaire. Ces plages sont des exemples tirés de la RFC 5737.
EGRESS = {
    "corporate egress": ["198.51.100.0/28"],
    "security service egress": ["203.0.113.64/26"],
}
INTERNAL = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "fc00::/7"]

def first_pass(ip: str) -> str:
    addr = ipaddress.ip_address(ip)
    for label, nets in EGRESS.items():
        if any(addr in ipaddress.ip_network(n) for n in nets):
            return label
    if addr.is_loopback or addr.is_link_local or any(addr in ipaddress.ip_network(n) for n in INTERNAL):
        return "internal"
    return "external: attribute holder and ASN before reading the location"

if __name__ == "__main__":
    assert first_pass("10.1.2.3") == "internal"
    assert first_pass("198.51.100.5") == "corporate egress"
    assert first_pass("203.0.113.70") == "security service egress"
    assert first_pass("192.0.2.140").startswith("external")
    assert first_pass("8.8.8.8").startswith("external")
    print("ok")

L'espace interne est comparé à une liste explicite plutôt qu'à is_private : en Python, is_private renvoie aussi vrai pour les plages de documentation de la RFC 5737, et classerait en « internal » les adresses externes de l'exemple ci-dessous. Le contrôle d'inventaire passe en premier pour la même raison : une correspondance dans votre inventaire doit l'emporter sur une règle générique.

Exemple

Les adresses ci-dessous viennent des plages de documentation de la RFC 5737 et tiennent lieu d'adresses réelles. Le scénario est synthétique et construit pour être rejoué.

Une plateforme d'identité lève une alerte de voyage impossible pour un utilisateur :

Lue par la localisation, 18 minutes pour plus de 700 km, c'est impossible, et l'alerte paraît solide. Attribuée d'abord, elle se lit autrement. La seconde adresse tombe dans la plage de sortie du proxy de sécurité de l'entreprise, dont le point de présence pour cette région est à Amsterdam, et la première appartient à un FAI résidentiel français. L'utilisateur a ouvert son portable chez lui sur la ligne du FAI, puis l'agent du proxy s'est connecté et la connexion suivante est sortie par le fournisseur. Le verdict est un faux positif probable, avec une confiance moyenne tant que l'appareil et les identifiants de session ne confirment pas que les deux connexions viennent de la même machine.

Voici une seconde alerte, pour un autre utilisateur, levée pour une propriété de connexion inhabituelle, avec une localisation qui n'inquiète personne :

L'utilisateur travaille à Paris, et un contrôle de localisation referme celle-ci. L'attribution montre que la plage appartient au centre de données d'un hébergeur, et aucun inventaire n'explique pourquoi cet utilisateur s'authentifierait depuis un serveur. Le verdict reste ouvert : il faut vérifier la session pour une réutilisation de jeton, demander à l'utilisateur s'il a utilisé un poste de travail cloud, et comparer la connexion avec son appareil habituel. La localisation du journal était exacte et n'a joué aucun rôle dans le verdict.

L'écrire dans le verdict

L'attribution n'aide que si elle figure dans le rapport. Nous tenons un court tableau de chaque adresse de l'alerte avec sa catégorie, la source de l'attribution et l'heure de la recherche, et nous le gardons séparé de la liste des indicateurs de l'attaquant. Un verdict qui mentionne une localisation sans la catégorie de propriétaire de l'adresse est incomplet, tout comme un verdict à moins de confiance haute qui ne dit pas ce qui la ferait monter.

Limites

• Un inventaire des sorties vieillit. Les fournisseurs de proxy ajoutent des points de présence et les pools VPN changent. Une adresse absente de l'inventaire retombe sur RDAP et l'ASN, ce qui est plus lent et moins sûr.
• Les catégories d'ASN se brouillent aux marges. Certains opérateurs vendent accès mobile et hébergement sous un même numéro, et les services de proxy résidentiel font passer le trafic d'attaquants par de vraies lignes domestiques, qui tomberaient dans la seule catégorie que nous jugeons géographiquement significative.
• L'attribution dit qui exploite une adresse. Elle ne dit pas qui l'a utilisée. L'identité de l'appareil, les identifiants de session et le témoignage de l'utilisateur restent les preuves pour cela.
• La rétention des journaux borne ce qui peut être vérifié. Une connexion antérieure que la plateforme ne conserve plus ne peut pas servir de référence, et son absence ne prouve rien.

Check-list

1. Tenez un inventaire de vos plages de sortie, y compris celles des services de sécurité auxquels vous êtes abonné.
2. Donnez à chaque adresse d'une alerte une catégorie de propriétaire avant de lire sa localisation.
3. Ne lisez la localisation comme position de l'utilisateur que pour les adresses de FAI résidentiel ou professionnel.
4. Traitez une source hébergement ou anonymiseur comme une question à instruire, même quand le pays est le bon.
5. Attribuez passivement : inventaire, RDAP, ASN, DNS inverse, listes Tor publiques. Ne sondez jamais l'adresse.
6. Mettez le tableau d'attribution dans le verdict, à part des indicateurs de l'attaquant.

eHVB-IT est un cabinet français de cybersécurité (tri d'alertes SOC, sécurité applicative, ingénierie de détection). Contact : contact@ehvb-it.fr

← Toutes les notes de recherche