Détecter l’impossible travel sur les connexions

Détecter l’impossible travel sur les connexions

L’impossible travel compare deux authentifications d’une même identité pour déterminer si le déplacement supposé entre leurs origines est physiquement invraisemblable. Le mécanisme apporte de la détection contextuelle, mais paie ce gain en faux positifs : une adresse IP n’est ni une position GPS ni une preuve d’identité, et la traiter comme telle finit toujours par réveiller quelqu’un à tort.

Explication de la marmotte

Ce contrôle ressemble à un vigile qui remarque qu’une même carte d’accès a été utilisée dans deux bâtiments très éloignés presque au même moment. Son rôle est de repérer une situation étrange avant qu’elle ne devienne un problème, sans accuser automatiquement la personne concernée.

→ Lire l’explication complète de la marmotte

Sources d’événements et prérequis d’identité

La détection doit être placée après l’authentification réussie, dans le fournisseur d’identité, ou IdP (Identity Provider), et avant l’émission finale de session lorsque le produit permet une politique synchrone. Si l’IdP ne peut pas appeler un moteur de risque pendant le flux, collecter les événements de connexion dans un pipeline asynchrone et déclencher une réponse de session séparée. Le mode synchrone bloque mieux l’attaque en cours ; le mode asynchrone résiste mieux aux pannes et aux latences. Le choix dépend de la capacité à tolérer une indisponibilité du moteur de risque, pas de la couleur du diagramme vendeur.

Chaque événement doit contenir au minimum :

• un identifiant immuable de sujet, jamais l’adresse électronique seule ;
• un horodatage en temps universel coordonné, avec une précision à la seconde ;
• l’adresse IP source observée par le point qui termine le protocole TLS (Transport Layer Security) ;
• le résultat de l’authentification, la méthode utilisée et l’identifiant de session ;
• le type de client, l’empreinte de terminal si elle existe, et le réseau déclaré ;
• l’identifiant du proxy inverse ou du point d’accès ayant vu la connexion.

Les horloges des IdP, proxies, collecteurs et moteurs de décision doivent être synchronisées par Network Time Protocol, avec une dérive surveillée. Une comparaison de vitesse fondée sur des horodatages flottants produit des alertes imaginaires avec une régularité presque artistique.

Ne jamais faire confiance à X-Forwarded-For depuis Internet. Le proxy frontal doit supprimer toute valeur entrante et écrire une chaîne normalisée, puis l’IdP ne doit accepter cet en-tête que depuis les plages réseau de ces proxies. Sans cette frontière, un attaquant choisit sa géolocalisation en envoyant un texte HTTP. C’est pratique, mais seulement pour l’attaquant.

Conserver les événements bruts dans un système de journalisation centralisé, par exemple un SIEM (Security Information and Event Management), avec intégrité d’écriture et contrôle d’accès. Les règles de collecte, de rétention et de minimisation des données personnelles relèvent aussi de la gouvernance de la sécurité. L’adresse IP et l’historique de connexion sont des données à caractère personnel dans de nombreux contextes : garder la précision nécessaire à la détection, pas un musée exhaustif de chaque déplacement supposé.

Calcul impossible travel et politique de risque

Géocoder l’adresse IP en latitude, longitude, pays, ville estimée, opérateur et ASN (Autonomous System Number). La base doit indiquer sa date de mise à jour et sa source. Les plages mobiles, les services cloud, les réseaux d’entreprise et les sorties VPN (Virtual Private Network) changent fréquemment d’attribution. Une base non mise à jour transforme une politique de sécurité en horoscope géographique.

Calculer ensuite la distance orthodromique entre la dernière connexion fiable et la nouvelle, puis diviser par le temps écoulé. La distance seule ne signifie rien : Paris et Londres séparés par quelques heures peuvent être ordinaires, tandis que deux connexions à quelques kilomètres depuis des réseaux radicalement différents peuvent signaler un détournement de session.

La recommandation est de ne pas bloquer sur le seul seuil de vitesse. Utiliser un score composé :

• vitesse supérieure à un seuil élevé, par exemple 900 km/h après prise en compte d’une tolérance ;
• intervalle inférieur à une durée minimale, par exemple dix minutes ;
• pays ou continent différent ;
• changement d’ASN, de type de réseau ou d’empreinte de terminal ;
• absence d’authentification forte récente ;
• usage connu d’un VPN d’entreprise, d’un relais cloud approuvé ou d’un réseau mobile.

Le compromis central est net : un seuil agressif détecte tôt les vols de session et les identifiants compromis, mais perturbe les utilisateurs légitimes derrière des VPN ou des réseaux mobiles. La position à tenir est donc la suivante : exiger plusieurs signaux pour bloquer, mais alerter sur un signal géographique isolé. L’impossible travel est un multiplicateur de confiance négative, pas un oracle.

Définir une hiérarchie de réponses. Un score faible journalise. Un score moyen impose une authentification multifacteur, ou MFA (Multi-Factor Authentication), résistante à l’hameçonnage si disponible. Un score élevé révoque la session active, refuse l’émission d’un nouveau jeton et crée une alerte corrélable. Le verrouillage total du compte ne doit intervenir qu’après des preuves indépendantes, par exemple changement de facteur MFA, anomalie de terminal et tentative depuis une infrastructure hostile.

Exemple reproductible de calcul géographique

Le script suivant valide le calcul de distance et de vitesse avec deux événements JSON. Il sert à tester les seuils avant intégration dans le moteur de politique. Il ne remplace ni une base de géolocalisation IP ni un stockage d’historique.

impossible_travel.py

# Exécution : python3 impossible_travel.py
# Les coordonnées sont supposées déjà fournies par une base de géolocalisation IP.

import math
from datetime import datetime, timezone

previous = {
    "timestamp": "2026-09-23T08:00:00Z",
    "latitude": 48.8566,
    "longitude": 2.3522,
}

current = {
    "timestamp": "2026-09-23T09:00:00Z",
    "latitude": 40.7128,
    "longitude": -74.0060,
}

def distance_km(a, b):
    radius_km = 6371.0
    lat1, lon1 = map(math.radians, (a["latitude"], a["longitude"]))
    lat2, lon2 = map(math.radians, (b["latitude"], b["longitude"]))
    h = (math.sin((lat2 - lat1) / 2) ** 2
         + math.cos(lat1) * math.cos(lat2)
         * math.sin((lon2 - lon1) / 2) ** 2)
    return 2 * radius_km * math.asin(math.sqrt(h))

start = datetime.fromisoformat(previous["timestamp"].replace("Z", "+00:00"))
end = datetime.fromisoformat(current["timestamp"].replace("Z", "+00:00"))
hours = (end - start).total_seconds() / 3600
speed = distance_km(previous, current) / hours

print(f"distance_km={distance_km(previous, current):.0f}")
print(f"speed_kmh={speed:.0f}")
print(f"impossible_travel={speed > 900 and hours < 24}")

La distance calculée est approximative : une géolocalisation IP peut pointer le siège d’un opérateur plutôt que le terminal. Ajouter une marge fixe de 100 à 300 kilomètres et exclure les intervalles très courts évite de transformer une imprécision de base en incident. Pour un moteur de production, conserver également la confiance de la géolocalisation, pas seulement ses coordonnées.

Exceptions réseau et faux positifs connus

Les réseaux mobiles font basculer une même session entre sorties régionales ou nationales. Les accès satellite, les VPN commerciaux, les navigateurs avec relais de confidentialité et les passerelles de sécurité cloud produisent le même effet. Un changement de pays est plus suspect lorsqu’il s’accompagne d’un changement de terminal et d’une nouvelle méthode MFA que lorsqu’il survient sur une session existante depuis le même appareil.

Maintenir des listes d’exceptions à durée limitée pour les sorties VPN d’entreprise, les bastions et les plages de tests. Une exception doit être portée par un identifiant de réseau, une justification, une date d’expiration et un propriétaire. Exempter un pays entier parce qu’un prestataire y possède une antenne revient à installer une porte coupe-feu en carton, ce qui reste techniquement une porte.

Ne pas exclure aveuglément les adresses de fournisseurs cloud. Les attaquants les utilisent précisément parce qu’elles sont abondantes, jetables et réputées. Une sortie cloud approuvée doit être associée à un usage documenté, un ASN attendu et, idéalement, une authentification de poste ou un certificat de terminal.

La sécurisation des identités complète cette détection : MFA résistante au phishing, politiques de session, contrôle de terminal et révocation sont les contrôles qui rendent l’alerte actionnable. La géolocalisation seule ne prouve ni le vol d’un mot de passe ni la présence physique d’une personne.

Surface d’attaque et limites du mécanisme

Un attaquant peut utiliser un VPN situé près de la victime, compromettre un poste déjà reconnu, voler un cookie de session ou intercepter un jeton d’accès. Dans ces cas, l’impossible travel peut rester silencieux. Il ne détecte pas non plus une attaque lente depuis la même région, ni un abus réalisé par un utilisateur légitime.

Le vol de session demande des contre-mesures distinctes : liaison de session au terminal lorsque possible, durée de vie courte, renouvellement contrôlé des jetons, réauthentification sur action sensible et détection de changement d’empreinte. Révoquer un jeton ne détruit pas nécessairement les sessions déjà établies dans les applications qui ne vérifient pas son statut. Cette propriété doit être testée application par application, pas supposée parce qu’un écran d’administration affiche un bouton rouge.

Protéger aussi le moteur de décision. Une injection d’événements falsifiés peut empoisonner l’historique et faire paraître une connexion hostile normale. Authentifier les producteurs, signer ou acheminer les journaux sur un canal protégé, dédupliquer les événements et refuser les horodatages trop éloignés de l’heure courante. Limiter les requêtes de géolocalisation empêche un déni de service par rafale d’authentifications.

Exploitation, rotation et reprise

Conserver l’historique de dernière connexion fiable par sujet dans un stockage disponible et cohérent. En cas de perte de ce stockage, ne pas recalculer un historique fictif : basculer temporairement vers MFA renforcée et journalisation accrue. Un mode dégradé doit être explicite, surveillé et limité dans le temps.

Versionner les règles, les seuils et les listes d’exceptions. Chaque alerte doit exposer les événements comparés, la distance, le temps, les signaux additionnels, la version de règle et la décision prise. Sans ces éléments, l’investigation se résume à débattre avec une boîte noire, activité très populaire mais peu productive.

Les clés ou secrets d’accès aux bases de géolocalisation, au SIEM et aux interfaces de programmation doivent être stockés dans un gestionnaire de secrets, avec rotation et droits minimaux. Superviser le taux d’événements incomplets, la fraîcheur de la base IP, le volume d’exceptions actives, les erreurs de géocodage et la proportion de défis MFA. Une chute brutale d’alertes peut signaler une amélioration, ou un collecteur mort. Le collecteur mort gagne souvent le concours.

🐝 Ce qui arrive si on s’en passe

Sans détection d’impossible travel, un accès à un compte depuis une origine incohérente avec une authentification récente passe inaperçu. Le signal qui aurait révélé qu’une même identité se connecte depuis deux lieux trop éloignés dans un intervalle trop court n’existe pas, et un identifiant volé utilisé en parallèle de son propriétaire légitime ne déclenche aucune alerte contextuelle. La conséquence est une fenêtre de détection perdue : un détournement de session ou de mot de passe qui aurait pu être repéré avant l’action malveillante continue sans être questionné. Cette détection reste imparfaite, car une adresse IP n’est ni une position exacte ni une preuve d’identité et produit des faux positifs, mais son absence supprime un indice utile parmi les premiers disponibles. Sans lui, la traçabilité des connexions anormales repose sur des signaux plus tardifs, souvent postérieurs aux dégâts.

🦫 Explication de la marmotte 🍫

À chaque connexion réussie, le système enregistre qui s’est connecté, quand, depuis quelle adresse Internet et avec quel appareil ou réseau. L’adresse Internet est ensuite associée à une zone géographique estimée. Cette estimation n’est pas exacte : elle peut désigner le réseau d’un opérateur plutôt que la position réelle de la personne.

Lorsqu’une nouvelle connexion arrive, le système cherche la dernière connexion considérée comme fiable pour le même compte. Il calcule la distance entre les deux zones et le temps écoulé. Si le déplacement demanderait une vitesse irréaliste, le système ajoute un risque. Il ne doit pas décider sur ce seul élément, car un réseau mobile, un réseau privé d’entreprise ou un service de confidentialité peut faire apparaître une personne dans un autre pays.

La décision combine donc plusieurs faits : changement d’appareil, changement de réseau, pays inhabituel et absence de seconde preuve d’identité récente. Un risque moyen demande une vérification supplémentaire. Un risque élevé peut empêcher une nouvelle connexion et fermer les sessions existantes, si les applications savent réellement les invalider.

Les journaux doivent être protégés, car de faux journaux peuvent tromper le calcul. Les règles, les exceptions temporaires et les données de localisation doivent aussi être surveillées. Si le stockage de l’historique tombe en panne, le système ne doit pas inventer de résultat : il demande davantage de vérifications jusqu’au retour du service.

À lire aussi

• Exécuter un threat hunting à partir d'une hypothèseGuide pas-à-pas pour préparer, exécuter et pérenniser un exercice de threat hunting fondé sur une hypothèse vérifiable.
• Configurer une détection open source avec WazuhGuide pratique pour centraliser les journaux, installer Wazuh et détecter les premières tentatives d’accès suspectes sans SIEM commercial.
• Réagir aux premières minutes d’un incident suspectéChecklist opérationnelle pour isoler une anomalie, alerter les bonnes personnes et préserver les premières preuves avant une réponse à incident spécialisée.
• Courtiers d'accès initial et marché des zero-day, détecter en amontComment l'économie de l'attaquant (courtiers d'accès initial, marché gris et noir des vulnérabilités zero-day) éclaire la détection mieux qu'une signature supplémentaire.

Pages voisines

La citent

• CCCS Canada et ACSC Australie dans les Five Eyes
• Comment attribuer techniquement une cyberattaque
• Comment former contre le phishing sans culpabiliser
• Que révèle un journal d’accès après une fuite
• Sécuriser badges RFID, NFC et serrures connectées en entreprise

Détecter l’impossible travel sur les connexions

Elle cite

• ⇄Lien dans les deux sens :Gérer la durée de vie des jetons OAuth
• Déployer FIDO2 pour comptes à privilèges
• Faille Facebook Voir en tant que 2018 et vol de jetons d'accès

⇄ : les deux pages se citent l’une l’autre.