Guides · Enquêter sur une IP

J'ai trouvé une IP inconnue dans les logs de mon serveur. Que faire ?

Écrit par Aldo · threat hunter en blue team
Dernière mise à jour le 9 novembre 2026 · 11 min de lecture

Vous ouvrez votre log d'accès pour chercher autre chose, et la voilà : une adresse jamais vue, qui visite votre site à quatre heures du matin. Voici comment savoir, en une dizaine de minutes, si elle mérite qu'on s'y attarde.

Commençons par ce qui rassure. Un serveur exposé sur internet reçoit du trafic automatisé toute la journée, généralement bien avant qu'une personne ne le trouve. Les robots d'exploration indexent les pages. Des projets de recherche scannent toutes les adresses d'internet pour cartographier ce qui existe. D'autres scripts essaient les mêmes quelques portes sur des millions de sites, en espérant qu'une soit restée ouverte. Voir des adresses inconnues est normal. La question n'est jamais « cette IP est-elle mauvaise ? » mais « qu'a-t-elle tenté, et est-ce que ça a marché ? »

Trouver les lignes

WordPress ne tient pas de journal des visiteurs. La trace se trouve dans le log d'accès de votre serveur web, et son emplacement dépend de votre hébergement :

• Hébergement mutualisé avec cPanel : Métriques → Accès bruts (Metrics → Raw Access) permet de télécharger le log de chaque domaine. Avec Plesk, ouvrez Sites Web & Domaines → Logs.
• Votre propre serveur (VPS) : les emplacements par défaut sont /var/log/nginx/access.log pour nginx, /var/log/apache2/access.log pour Apache sous Debian et Ubuntu, et /var/log/httpd/access_log sous Red Hat, Fedora et apparentés. Votre hébergeur a pu les changer ; le fichier de configuration du serveur fait foi.
• Windows avec IIS : C:inetpublogsLogFilesW3SVC1 (le numéro est l'identifiant de votre site).

Pour extraire toutes les lignes d'une adresse sous Linux ou macOS, cherchez-la suivie d'une espace. Sans l'espace, une recherche de 203.0.113.4 trouverait aussi 203.0.113.45 :

grep -F '185.220.101.1 ' /var/log/nginx/access.log
zgrep -F '185.220.101.1 ' /var/log/nginx/access.log.*.gz   # jours précédents, compressés

Pour voir quelles adresses viennent le plus souvent, comptez le premier champ :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Sous Windows, PowerShell fait la même recherche :

Select-String -Path 'C:inetpublogsLogFilesW3SVC1*.log' -Pattern '185.220.101.1' -SimpleMatch

IIS écrit ses champs dans un autre ordre qu'Apache et nginx ; la ligne #Fields: en haut de chaque fichier indique quelle colonne contient l'adresse du client (c-ip).

Est-ce vraiment l'adresse du visiteur ?

Vérifiez ce point avant tout. Si votre site est derrière un CDN ou un proxy comme Cloudflare, votre serveur enregistre peut-être l'adresse du CDN pour chaque requête, et non celle du visiteur. Si les mêmes quelques adresses apparaissent sur toutes les lignes et qu'elles appartiennent à votre CDN, c'est le CDN que vous voyez. Votre serveur doit lire l'adresse d'origine dans l'en-tête ajouté par le CDN (CF-Connecting-IP chez Cloudflare, par exemple ; le module mod_remoteip d'Apache et le module real_ip de nginx s'en chargent). D'ici là, bloquer une IP sur le serveur bloquerait le CDN, et tout le monde avec.

Lire une ligne

La plupart des serveurs Apache et nginx utilisent le format « combined ». Voici une ligne de l'exemple ci-dessous, découpée en parties :

185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

185.220.101.1

L'adresse qui s'est connectée à votre serveur. Pour une requête web aboutie, elle est difficile à falsifier, mais elle peut appartenir à un VPN, à Tor ou à un serveur cloud plutôt qu'à la personne derrière.

- -

Identité et nom d'utilisateur. Presque toujours vides.

[05/Nov/2026:09:31:07 +0000]

Quand c'est arrivé, avec le décalage horaire.

"POST /wp-login.php HTTP/1.1"

Ce qui a été demandé. POST envoie des données, ici un identifiant et un mot de passe.

200

La réponse de votre serveur. C'est le champ le plus important de la ligne.

6832

Octets renvoyés.

"-"

Référent : la page qui menait ici. Envoyé par le client, il peut donc dire n'importe quoi.

"Mozilla/5.0 …"

User agent : ce que le client prétend être. Lui aussi envoyé par le client, donc lui aussi non prouvé.

Retenez ce dernier point : l'adresse est un indice, le user agent une simple déclaration.

Un exemple concret : une matinée sur un petit blog WordPress

Ces douze lignes représentent une demi-heure typique sur un petit blog. Nous avons remplacé l'adresse du seul lecteur ordinaire par une adresse de documentation (203.0.113.45, réservée aux exemples) : aucune personne réelle n'apparaît ici. Les autres adresses appartiennent à des infrastructures publiques.

203.0.113.45 - - [05/Nov/2026:09:14:02 +0000] "GET /2026/10/back-up-your-photos/ HTTP/1.1" 200 18342 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
203.0.113.45 - - [05/Nov/2026:09:14:03 +0000] "GET /wp-content/themes/twentytwentyfive/style.css HTTP/1.1" 200 4120 "https://example.com/2026/10/back-up-your-photos/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
66.249.66.1 - - [05/Nov/2026:09:15:40 +0000] "GET /2026/09/router-settings/ HTTP/1.1" 200 21004 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
167.94.138.35 - - [05/Nov/2026:09:17:11 +0000] "GET / HTTP/1.1" 200 15233 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /.env HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /wp-config.php.bak HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:56 +0000] "GET /wp-content/uploads/2026/11/cache.php HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:09 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:12 +0000] "POST /xmlrpc.php HTTP/1.1" 200 4272 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:15 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
40.77.167.10 - - [05/Nov/2026:09:40:28 +0000] "GET /robots.txt HTTP/1.1" 200 67 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Nous avons collé le log dans l'analyse de journaux d'iplover. Elle a trouvé six adresses et comparé les cinq publiques aux listes publiques de notre serveur ; le log lui-même est resté dans le navigateur. Voici le tableau de résultats affiché le 9 novembre 2026 :

Deux colonnes, deux questions. Catégorie dit pour quoi l'adresse est connue : robot d'exploration, scanner, Tor, fournisseur cloud. Type de réseau dit à quel genre de réseau elle appartient, d'après les listes publiques. « Non identifié » signifie seulement qu'aucune liste ne la couvre ; ce n'est pas un verdict sur l'adresse.

Les listes changent tous les jours : si vous refaites l'exemple plus tard, un résultat peut différer. Voici ce que chaque groupe signifie pour ce site.

Le lecteur : 203.0.113.45

Deux requêtes à une seconde d'intervalle : un article, puis la feuille de style du thème, avec Google comme référent et un user agent Chrome ordinaire. C'est une personne qui a cherché, cliqué et lu. Dans votre propre log, l'adresse d'un vrai visiteur apparaîtrait comme celle d'un fournisseur d'accès. Rien à faire.

Les robots d'exploration : 66.249.66.1 et 40.77.167.10

Googlebot a récupéré un article, Bingbot a lu robots.txt. L'analyse de journaux a trouvé ces deux adresses dans les listes publiées par les moteurs de recherche, c'est pour cela qu'elle les nomme ; elle ne se fie jamais au seul user agent. Vous pouvez confirmer Googlebot vous-même avec deux requêtes DNS, comme le recommande Google : la recherche inverse doit se terminer par googlebot.com, google.com ou googleusercontent.com, et la recherche directe de ce nom doit renvoyer la même adresse.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

Si vous préférez qu'un robot passe moins souvent, dites-le dans robots.txt. Bloquer les vrais moteurs de recherche vous retire de leurs résultats.

Le scanner : 167.94.138.35

Censys scanne tout internet et rend les résultats consultables par les équipes de sécurité et les chercheurs. Il a demandé votre page d'accueil et il est reparti. C'est du bruit, pas une attaque. Vous pouvez bloquer les scanners si ces lignes vous agacent, mais ils ne mettent pas votre site en danger.

L'imposteur : 3.5.140.1

Voilà la ligne qui doit vous faire regarder à deux fois. Le user agent dit Googlebot, mais l'adresse appartient à Amazon Web Services, pas à Google. Les robots de Google ne tournent pas sur le cloud d'Amazon. N'importe qui peut écrire « Googlebot » dans un user agent.

Regardez ensuite ce qu'il voulait : /.env, /wp-config.php.bak et un fichier .php dans le dossier uploads. C'est une liste de courses de secrets : les fichiers .env et les copies de sauvegarde de wp-config.php contiennent souvent des mots de passe de base de données et des clés, et un fichier PHP dans uploads serait une porte dérobée laissée plus tôt par quelqu'un. Les trois ont reçu un 404. Il n'y avait rien, donc rien n'a été pris.

Assurez-vous que ça reste vrai. Demandez ces chemins vous-même et vérifiez que la réponse est un 404 ou un 403, jamais un 200 :

curl -I https://example.com/.env
curl -I https://example.com/wp-config.php.bak

Le devineur de mots de passe : 185.220.101.1

Quatre requêtes POST en huit secondes, trois vers /wp-login.php et une vers /xmlrpc.php. C'est quelqu'un qui essaie des mots de passe. Le point d'accès XML-RPC est très prisé, car une seule requête peut transporter de nombreux essais.

Toutes les réponses étaient des 200, et c'est une bonne nouvelle. Quand une connexion WordPress échoue, la page de connexion s'affiche de nouveau avec une erreur, et cette page est un 200. Une connexion réussie reçoit une redirection vers le tableau de bord, qui apparaît dans le log comme un 302. Pas de 302, pas d'entrée.

L'adresse est un relais de sortie Tor, partagé par beaucoup de monde. La bloquer arrêterait ces quatre requêtes, mais la tentative suivante arrive simplement d'une autre sortie, ou d'un serveur cloud. Le Tor Project rappelle lui-même que certains utilisateurs de Tor peuvent être des visiteurs légitimes de votre site. La vraie solution est de votre côté, un peu plus bas.

Verdict pour cette matinée : personne n'est entré. Deux choses méritent tout de même d'être corrigées : renforcer la connexion, et vérifier que les fichiers secrets sont vraiment inaccessibles.

Si vous voyez ceci, faites cela

Le même raisonnement vaut pour n'importe quelle ligne. Trouvez la ligne du tableau qui correspond à ce que vous voyez :

Renforcer la connexion

Les essais de mots de passe ne s'arrêtent jamais : rendez-les inutiles plutôt que d'essayer de bloquer chaque adresse.

• Utilisez un mot de passe long et unique pour chaque compte qui peut se connecter, à commencer par les administrateurs.
• Activez l'authentification à deux facteurs pour les administrateurs. WordPress ne l'inclut pas, il faut donc une extension.
• Limitez les tentatives de connexion, idéalement sur votre CDN ou votre serveur web, ou avec une extension de sécurité.
• Si rien de ce que vous utilisez n'a besoin de XML-RPC (certaines extensions, comme Jetpack, et certaines applications anciennes en ont besoin), désactivez-le ou bloquez /xmlrpc.php.

Quand bloquer une adresse a du sens

Bloquer vaut la peine pour une source unique et persistante qui gaspille des ressources, comme un serveur cloud qui martèle votre site. C'est une défense faible contre tout le reste, car les bots changent d'adresse librement. Si vous en bloquez une, voici comment. (Le cadre Copier une liste de blocage de l'analyse de journaux écrit ces lignes pour vous, pour les catégories que vous cochez.)

Apache 2.4, dans la configuration du site ou dans .htaccess :

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

nginx, dans le bloc server :

deny 203.0.113.45;

Derrière Cloudflare ou un autre CDN, bloquez plutôt au niveau du CDN (Cloudflare appelle cela IP Access Rules ou règles personnalisées du WAF ; les noms des menus changent de temps en temps). Votre serveur ne voit que les adresses du CDN, sauf si vous l'avez configuré pour lire celle du visiteur.

Ce qu'une adresse IP ne peut pas vous dire

Une adresse désigne un réseau, pas une personne. Elle peut être partagée par des milliers de personnes derrière un même fournisseur, un VPN ou Tor. Elle peut appartenir à quelqu'un d'autre la semaine prochaine. Sa localisation est une estimation, souvent la ville la plus proche du fournisseur. Ne traitez donc pas une adresse comme une identité, et n'essayez pas de retrouver quelqu'un à partir d'elle. Nos guides sur ce qu'on peut faire avec une adresse IP et sur la question de savoir si une IP révèle un domicile expliquent pourquoi.

Si une adresse continue de vous attaquer, le bon interlocuteur est le réseau qui la gère. La recherche IP affiche le titulaire et son adresse de signalement d'abus, tirés des registres officiels. Attendez-vous à une réponse pour des abus persistants depuis un serveur, pas pour un scan isolé. Si vous avez perdu des données ou de l'argent, portez aussi plainte auprès de la police ou de la gendarmerie ; la plateforme Cybermalveillance.gouv.fr peut vous orienter.