Attribuer une adresse IP au bon poste pendant une investigation SOC

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte réseau pointe vers une adresse IP. Avant d’isoler un poste ou d’associer l’activité à un compte, votre SOC doit établir ce que cette adresse représente au moment des faits. Il peut s’agir d’un terminal, d’une sortie Internet partagée, d’un tunnel VPN ou du dernier proxy traversé.

Une investigation solide conserve chaque étape du rapprochement. L’objectif est de pouvoir expliquer pourquoi un équipement est concerné, avec quelles preuves et quelles limites. Voici une méthode opérationnelle indépendante de votre SIEM.

Situer le point d’observation

Commencez par le journal d’origine. Quel équipement a observé la connexion ? De quel côté du pare-feu ou du proxy ? Le champ interprété comme adresse source provient-il de la connexion réseau, d’un en-tête HTTP ou d’un enrichissement ajouté après la collecte ?

Dessinez le trajet utile, même avec quelques mots : poste, passerelle, traduction d’adresse, service distant. Conservez séparément les adresses observées à chaque étape. Remplacer partout l’adresse du proxy par une adresse supposée d’origine ferait disparaître une information nécessaire pour vérifier le raisonnement.

Dans le dossier, inscrivez la question exacte : identifier le poste à l’origine d’une connexion, le compte ayant ouvert une session ou la personne ayant réalisé une action. Chacune exige des preuves supplémentaires.

Retrouver la connexion derrière une adresse partagée

Le partage d’une adresse publique empêche de distinguer plusieurs équipements avec cette seule valeur. La RFC 6302 recommande aux serveurs exposés à Internet de journaliser le port source et un horodatage précis en complément de l’adresse IP. Elle précise aussi le besoin de protocole et de port destination lorsque le service utilise plusieurs transports ou ports. Source : RFC 6302, section 2

Pour votre enquête, recherchez la correspondance dans les logs de traduction disponibles : adresse et port avant traduction, adresse et port après traduction, protocole, destination et période concernée. Les champs nécessaires dépendent du fonctionnement de la passerelle.

Vérifiez que le port désigne bien le côté public ou privé attendu. Deux nombres identiques dans des journaux différents ne suffisent pas à établir une correspondance. Si les données conservées ne permettent pas de départager plusieurs flux, gardez plusieurs candidats et indiquez la pièce manquante. Élargir arbitrairement la fenêtre temporelle peut multiplier les rapprochements erronés.

Reconstituer l’attribution au moment des faits

Pour une adresse interne attribuée dynamiquement, consultez l’historique des baux. La RFC 2131 prévoit qu’une allocation dynamique est limitée dans le temps et permet la réutilisation des adresses. L’attribution actuellement affichée ne démontre donc pas celle qui existait pendant l’incident. Source : RFC 2131, section 1

Notre recommandation : rapprocher l’adresse, le réseau concerné, la période d’attribution et l’identifiant du terminal disponible. Contrôlez les renouvellements, libérations et réattributions. Une adresse privée identique peut exister dans plusieurs réseaux isolés ; son contexte réseau doit accompagner la recherche.

Appliquez la même discipline aux accès VPN : demandez l’historique de la session, l’adresse attribuée dans le tunnel, sa période de validité et le compte authentifié. Un compte partagé ou compromis impose de conserver une réserve sur l’identité de la personne. Une session authentifiée constitue un élément d’enquête, pas une preuve suffisante d’intention.

Vérifier la confiance accordée aux proxys

Pour une application derrière un reverse proxy, distinguez l’adresse de la connexion reçue et celle déclarée dans les en-têtes transmis. La RFC 7239 rappelle que l’en-tête Forwarded peut être modifié par les intermédiaires et par l’émetteur de la requête. Sa présence ne garantit pas son exactitude. Source : RFC 7239, section 8.1

Demandez à l’équipe applicative quels proxys sont maîtrisés, comment ils traitent les valeurs entrantes et si le serveur peut être joint directement. Vérifiez aussi que les échanges entre intermédiaires sont protégés. Documentez la configuration réellement observée avant d’utiliser une adresse déclarée pour attribuer l’activité.

Pour X-Forwarded-For, la documentation MDN recommande de ne fonder les usages de sécurité que sur les valeurs ajoutées par des proxys de confiance. Copier systématiquement la première adresse de la liste dans le dossier ne constitue donc pas une méthode d’attribution fiable. Source : MDN, sécurité de X-Forwarded-For

Chercher une confirmation sur le terminal

Une fois un poste candidat identifié, cherchez une observation indépendante : connexion réseau du terminal, processus associé, session locale ou événement applicatif. Vérifiez la destination, les ports et l’heure, puis conservez les références des événements consultés.

À titre d’exemple, l’événement de connexion réseau de Sysmon fournit des informations permettant de relier une connexion à un processus. La documentation Microsoft précise que cette journalisation nécessite une activation explicite. Son absence ne permet donc pas, à elle seule, d’exclure une activité. Vérifiez d’abord la configuration et la couverture de collecte sur le terminal concerné. Source : Microsoft, Sysmon, événement 3

Présentez enfin la conclusion à son niveau réel : passerelle identifiée, poste corroboré, compte associé ou attribution encore indéterminée. Évitez de transformer une hypothèse sur le poste en affirmation sur une personne.

Tester la méthode avant le prochain incident

Organisez un scénario bénin et autorisé avec deux postes partageant une sortie Internet. Faites générer des connexions connues, puis demandez à un analyste de les attribuer avec les seules données disponibles. Ajoutez ensuite une réattribution d’adresse dans un environnement de test.

Le résultat attendu est une fiche courte : chemin suivi, sources consultées, correspondances établies, candidats exclus et limites restantes. Une enquête non concluante peut révéler précisément quel journal manque.

Pour préparer un échange avec Seculogik, apportez cette fiche et un exemple anonymisé. Elle permettra de discuter des informations utiles à vos décisions SOC et des intégrations à vérifier dans votre environnement, sans présumer que chaque source est déjà disponible.