L’analyse d’IP est un indice technique contextuel, pas une preuve autonome d’identité. Elle permet de qualifier un événement réseau (origine apparente, opérateur, plage, type d’infrastructure, fenêtre temporelle), mais elle ne permet généralement pas d’attribuer avec certitude une action à une personne physique sans corroborations supplémentaires (journaux opérateur, données d’authentification, saisies forensiques, témoignages, etc.) [3][4][7][15].

Points directeurs:

  • Faits robustes: structure IP (IPv4/IPv6), routage inter-domaines (BGP/ASN), délégation des ressources (IANA/RIR), données d’enregistrement (RDAP/Whois), normalisation des logs et du temps [1][2][3][4][5][6][10][11][12][13][14].
  • Incertitudes majeures: géolocalisation (notamment au niveau ville), CGNAT, VPN/proxy/Tor, cloud/hébergement mutualisé, réattribution dynamique d’adresses [8][9][17][18][19].
  • Conséquence probatoire: l’IP soutient des hypothèses techniques graduées (faible/moyenne/forte), mais n’emporte pas à elle seule l’attribution juridique [7][15][16][20].

—

1) Périmètre et méthode de recherche

1.1 Volume et sélection des sources

  • URLs évaluées: 26
  • URLs retenues/citées: 21
  • Répartition retenue:
  • Sources primaires normatives/institutionnelles: RFC/IETF, IANA, RIR, NIST, ISO, ICANN, Tor Project, Microsoft/AWS (majoritaires)
  • Sources secondaires crédibles: MaxMind (documentation méthodologique fournisseur)

1.2 Critères d’inclusion

  1. Autorité normative ou institutionnelle (IETF, NIST, IANA, RIR, ISO, ICANN, autorités publiques).
  2. Pertinence directe pour l’analyse IP forensique (routage, enregistrements, logs, horodatage, géoloc, anonymisation).
  3. Exploitabilité opérationnelle/probatoire (traçabilité, reproductibilité, limites explicitables).

1.3 Critères d’exclusion

  • Pages non accessibles/404.
  • Contenus marketing sans méthodologie explicite.
  • Sources redondantes sans valeur ajoutée.

1.4 Limites méthodologiques

  • Certaines ressources juridiques (jurisprudence complète) sont difficiles à extraire automatiquement; les principes probatoires sont donc appuyés prioritairement par standards techniques et lignes directrices forensiques [15][16].

—

2) Fondamentaux de l’IP intelligence

2.1 Couche IP et adressage

L’IP intelligence repose d’abord sur le fait qu’une adresse IP est un identifiant de couche réseau (IPv4: RFC 791; IPv6: RFC 8200) [1][2]. Une IP observée dans un log signifie qu’un paquet a été vu avec cette source/destination à un instant donné; cela n’implique pas mécaniquement l’identité de l’utilisateur final.

2.2 BGP, ASN et réalité inter-domaines

Le routage inter-AS est gouverné par BGP-4 (RFC 4271) [3]. L’ASN et les annonces de préfixes fournissent des indices utiles (opérateur, transit, origine apparente), mais exposés à des erreurs/opérations de routage et incidents d’annonce. L’écosystème RPKI (RFC 6480) renforce l’authentification d’origine de route, sans éliminer tous les scénarios d’abus [4].

2.3 Gouvernance des ressources numéros

IANA coordonne globalement adresses et ASN, ensuite délégués aux RIR [5]. Les bases RIR (ARIN, RIPE, APNIC) documentent titularité/allocation/contacts et politiques, utiles pour contextualiser une IP dans son cadre administratif [8][9][10].

2.4 Whois vs RDAP

Whois (RFC 3912) est historique et peu structuré [7]. RDAP (RFC 9082/9083) standardise la requête/réponse JSON, améliore l’automatisation, la cohérence et l’auditabilité des résultats [6][11]. Pour une pratique forensique moderne, RDAP est à privilégier comme base machine-readable.

2.5 Géolocalisation IP: nature du signal

Les geofeeds (RFC 8805, RFC 9092) permettent aux opérateurs de publier une géolocalisation de préfixes, généralement coarse-grained [17][18]. Les fournisseurs commerciaux reconnaissent explicitement l’impossibilité d’une précision parfaite, surtout au niveau ville [19].

—

3) Méthodes d’analyse multi-sources

3.1 Principe: corrélation, pas inférence unique

Une investigation IP robuste assemble:

  • Enregistrements RDAP/Whois [6][7][8]
  • Données DNS (concepts/protocoles DNS) [12][13]
  • Journaux sécurité/système (NIST SP 800-92) [14]
  • Flux réseau (IPFIX/NetFlow) [11]
  • Artefacts forensiques (NIST SP 800-86) [16]
  • Synchronisation temporelle (NTP, RFC 3339) [20][21]

3.2 DNS et passive DNS

Le DNS permet de reconstruire des relations nom↔IP dans le temps (résolutions successives, TTL, changements d’infrastructure). En pratique, la valeur probante dépend de la conservation des journaux et de la qualité temporelle.

3.3 NetFlow/IPFIX et télémétrie

IPFIX normalise l’export de métadonnées de flux (qui parle à qui, quand, combien), utile pour corréler événements et trajectoires réseau [11]. C’est puissant pour la chronologie, plus limité pour identifier une personne.

3.4 Horodatage, fuseaux, normalisation

Les dérives d’horloge et fuseaux incohérents créent des faux alignements. Bonnes pratiques: conserver UTC, offset explicite (RFC 3339) et preuve de synchro NTP [20][21].

—

4) Détection VPN/proxy/Tor/hébergement et limites

4.1 Tor

La détection d’une sortie Tor peut s’appuyer sur la liste officielle des nœuds de sortie au moment pertinent [22]. Fait établi: l’IP de sortie Tor n’identifie pas l’émetteur initial, mais le dernier relais visible.

4.2 Cloud et hébergement

La présence d’une IP dans des plages cloud publiques (AWS/Azure) indique un hébergement probable (IaaS/PaaS), non une identité utilisateur [23][24]. Le niveau d’assurance est « infrastructure », pas « personne ».

4.3 VPN/proxy commerciaux

Les bases « anonymizer » sont utiles pour le triage, mais comportent faux positifs/négatifs, latence de mise à jour et couverture incomplète [19]. Le résultat doit être qualifié comme probabilité opérationnelle, non certitude.

—

5) Précision géographique: city-level, radius, causes d’erreurs

5.1 Ce qui est généralement défendable

  • Pays/région opérateur: souvent plus robuste que la ville.
  • Ville/coordonnées: dépend du fournisseur, du type d’accès (mobile, résidentiel, entreprise), de la granularité des données.

5.2 Causes d’erreurs fréquentes

  1. Réattribution dynamique d’IP par FAI.
  2. CGNAT et partage d’IP entre nombreux abonnés.
  3. Points de présence distants (backhaul mobile, transit international).
  4. Usage VPN/proxy/Tor.
  5. Données fournisseurs obsolètes.

5.3 Rayon de confiance

RFC 8805/9092 encadrent des approches de géoloc « coarse » et signalent implicitement la prudence sur la granularité [17][18]. En expertise, il faut exprimer un intervalle de confiance plutôt qu’une localisation « ponctuelle ».

—

6) Attribution technique vs attribution juridique

6.1 Attribution technique (ce que l’IP permet)

L’IP permet d’attribuer un événement à:

  • un préfixe,
  • un ASN/opérateur,
  • une fenêtre temporelle,
  • parfois un service d’hébergement/anonymisation.

6.2 Attribution juridique (ce que l’IP ne suffit pas à établir)

L’IP seule n’établit généralement pas l’auteur matériel. Les cadres incident/forensic (NIST 800-61, 800-86) convergent vers une approche par corpus de preuves et chaîne d’intégrité [15][16].

6.3 Risques de faux positifs

  • Confusion entre titulaire d’abonnement et utilisateur réel.
  • Environnements partagés (entreprise, campus, Wi-Fi invité).
  • Compromission d’hôte relais.
  • Journalisation incomplète ou horodatage défaillant.

—

7) Chaîne de possession et reproductibilité (forensique)

7.1 Exigences minimales

  • Collecte documentée (source, date/heure UTC, outil/version, opérateur).
  • Préservation de l’intégrité (hachage, scellés logiques, contrôle d’accès).
  • Journal d’audit des transformations.
  • Dossier de reproductibilité (scripts, paramètres, exports bruts).

Ces principes s’alignent avec ISO/IEC 27037 et les guides NIST forensics/log management [14][16][25].

7.2 Reproductibilité analytique

Toute conclusion doit être rejouable: mêmes données d’entrée, même pipeline, même résultat (ou justification des écarts). Sans cela, la force probatoire baisse substantiellement.

—

8) Cadre probatoire pratique: ce qu’on peut / ne peut pas affirmer

8.1 Assertions généralement recevables (si bien documentées)

  1. « L’IP X appartenait au préfixe Y/ASN Z à la date T » [3][5][6].
  2. « Cette IP était cohérente avec une infrastructure cloud/Tor/proxy à T » [22][23][24].
  3. « Les logs corrélés (A, B, C) montrent une séquence technique compatible avec l’hypothèse H » [11][14][16].

8.2 Assertions à éviter sans corroboration forte

  1. « Cette IP prouve que la personne P est l’auteur. »
  2. « La géolocalisation ville est certaine. »
  3. « L’absence de signal VPN/Tor prouve l’absence d’anonymisation. »

8.3 Formulation recommandée en rapport

Employer des niveaux de confiance:

  • Élevé: corroborations convergentes multi-sources + intégrité temporelle.
  • Moyen: convergence partielle + incertitudes explicites.
  • Faible: signal isolé (IP seule, géoloc seule, base commerciale seule).

—

9) Playbook opérationnel (cabinet d’expertise)

  1. Scoping: définir question probatoire exacte (quoi prouver/refuter).
  2. Préservation immédiate: figer logs, métadonnées, horodatages, hashes.
  3. Normalisation temporelle: UTC, offsets, preuve NTP.
  4. Enrichissement IP: RDAP/Whois + ASN/BGP + historiques DNS.
  5. Qualification d’infrastructure: Tor/cloud/proxy/VPN (avec timestamp exact).
  6. Corrélation croisée: logs applicatifs, réseau, auth, endpoint.
  7. Évaluation d’incertitude: faux positifs plausibles, alternatives explicites.
  8. Rédaction probatoire: faits observés vs interprétations séparés.
  9. Reproductibilité: annexer méthode, requêtes, versions d’outils, exports.
  10. Revue contradictoire interne: test de robustesse et objections anticipées.

Livrables recommandés:

  • Chronologie horodatée (UTC).
  • Tableau « preuve → conclusion → niveau de confiance ».
  • Annexe technique reproductible.

—

10) Distinction explicite: faits établis vs incertitudes

Faits établis (haute robustesse)

  • Les protocoles et mécanismes IP/BGP/RDAP/IPFIX/NTP sont normalisés [1][2][3][6][11][20].
  • Les RIR/IANA structurent l’allocation des ressources IP/ASN [5][8][9][10].
  • Les guides forensiques imposent collecte/préservation/documentation [14][16][25].

Incertitudes structurelles (irréductibles ou coûteuses à réduire)

  • Lien direct IP → individu.
  • Précision fine de géoloc (notamment city-level) [17][18][19].
  • Détection exhaustive de l’anonymisation (VPN/proxy/Tor).

—

Références

  1. RFC 791 — Internet Protocol — https://www.rfc-editor.org/rfc/rfc791
  2. RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — https://www.rfc-editor.org/rfc/rfc8200
  3. RFC 4271 — A Border Gateway Protocol 4 (BGP-4) — https://www.rfc-editor.org/rfc/rfc4271
  4. RFC 6480 — An Infrastructure to Support Secure Internet Routing — https://www.rfc-editor.org/rfc/rfc6480
  5. IANA Number Resources — https://www.iana.org/numbers
  6. RFC 9082 — RDAP Query Format — https://www.rfc-editor.org/rfc/rfc9082
  7. RFC 3912 — WHOIS Protocol Specification — https://www.rfc-editor.org/rfc/rfc3912
  8. ARIN — Whois/RDAP — https://www.arin.net/resources/registry/whois/rdap/
  9. RIPE NCC — RIPE Database — https://www.ripe.net/manage-ips-and-asns/db/
  10. APNIC Whois Guide — https://www.apnic.net/manage-ip/using-whois/guide/
  11. RFC 7011 — IPFIX Protocol Specification — https://www.rfc-editor.org/rfc/rfc7011
  12. RFC 1034 — Domain Names: Concepts and Facilities — https://www.rfc-editor.org/rfc/rfc1034
  13. RFC 1035 — Domain Names: Implementation and Specification — https://www.rfc-editor.org/rfc/rfc1035
  14. NIST SP 800-92 — Guide to Computer Security Log Management — https://csrc.nist.gov/pubs/sp/800/92/final
  15. NIST SP 800-61 Rev.2 — Computer Security Incident Handling Guide — https://csrc.nist.gov/pubs/sp/800/61/r2/final
  16. NIST SP 800-86 — Integrating Forensic Techniques into Incident Response — https://csrc.nist.gov/pubs/sp/800/86/final
  17. RFC 8805 — A Format for Self-Published IP Geolocation Feeds — https://www.rfc-editor.org/rfc/rfc8805
  18. RFC 9092 — Finding and Using Geofeed Data — https://www.rfc-editor.org/rfc/rfc9092
  19. MaxMind — Geolocation Accuracy (knowledge base) — https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy
  20. RFC 5905 — NTPv4 Specification — https://www.rfc-editor.org/rfc/rfc5905
  21. RFC 3339 — Date and Time on the Internet: Timestamps — https://www.rfc-editor.org/rfc/rfc3339
  22. Tor Project — Exit Addresses — https://check.torproject.org/exit-addresses
  23. AWS — Public IP ranges JSON — https://ip-ranges.amazonaws.com/ip-ranges.json
  24. Microsoft — Azure IP Ranges and Service Tags — https://www.microsoft.com/en-us/download/details.aspx?id=56519
  25. ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence — https://www.iso.org/standard/44381.html

Articles qui pourraient vous intéresser