Comprobar mi conexión

Guías · Investigar una IP

He encontrado una IP desconocida en los logs de mi servidor. ¿Qué hago?

Abres el log de accesos buscando otra cosa y ahí está: una dirección que nunca has visto, llamando a tu web a las cuatro de la madrugada. Así puedes saber, en unos diez minutos, si merece que le des una segunda vuelta.

Empecemos por lo tranquilizador. Un servidor en internet recibe tráfico automático todo el día, normalmente mucho antes de que lo encuentre una persona. Los rastreadores indexan páginas. Proyectos de investigación escanean todas las direcciones de internet para hacer un mapa de lo que hay. Otros scripts prueban las mismas pocas puertas en millones de webs, esperando que alguien se haya dejado una abierta. Ver direcciones que no conoces es normal. La pregunta nunca es «¿esta IP es mala?», sino «¿qué intentó y le salió bien?».

Encuentra las líneas

WordPress no guarda un registro propio de visitantes. El rastro está en el log de accesos de tu servidor web, y dónde está depende de tu hosting:

Para sacar todas las líneas de una dirección en Linux o macOS, búscala con un espacio detrás. Sin el espacio, buscar 203.0.113.4 también encontraría 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   # días anteriores, comprimidos

Para ver qué direcciones aparecen más, cuenta el primer campo:

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

En Windows, PowerShell hace la misma búsqueda:

Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' -Pattern '185.220.101.1' -SimpleMatch

IIS escribe sus campos en otro orden que Apache y nginx; la línea #Fields: al principio de cada archivo te dice qué columna es la dirección del cliente (c-ip).

¿Es de verdad la dirección del visitante?

Compruébalo antes que nada. Si tu web está detrás de una CDN o un proxy como Cloudflare, tu servidor puede estar registrando en cada petición la dirección de la CDN, no la del visitante. Si en todas las líneas aparecen las mismas pocas direcciones y son de tu CDN, estás mirando la CDN. Tu servidor tiene que leer la dirección original de la cabecera que añade la CDN (en Cloudflare es CF-Connecting-IP; en Apache lo hace mod_remoteip y en nginx el módulo real_ip). Hasta entonces, bloquear una IP en el servidor bloquearía la CDN, y a todos tus visitantes con ella.

Lee una línea

La mayoría de servidores Apache y nginx escriben el formato «combined». Esta es una línea del ejemplo de más abajo, separada en sus partes:

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
La dirección que se conectó a tu servidor. En una petición web completa es difícil de falsificar, aunque puede ser de una VPN, de Tor o de un servidor en la nube y no de la persona que está detrás.
- -
Identidad y nombre de usuario. Casi siempre vacíos.
[05/Nov/2026:09:31:07 +0000]
Cuándo pasó, con la diferencia de zona horaria.
"POST /wp-login.php HTTP/1.1"
Qué pidió. POST envía datos, aquí un usuario y una contraseña.
200
La respuesta de tu servidor. Es el campo más importante de la línea.
6832
Bytes enviados de vuelta.
"-"
Referer: la página que enlazaba aquí. Lo envía el cliente, así que puede decir cualquier cosa.
"Mozilla/5.0 …"
User agent: lo que el cliente dice ser. También lo envía el cliente, así que tampoco prueba nada.

Quédate con esto último: la dirección es una prueba, el user agent es una afirmación.

Un ejemplo real: una mañana en un pequeño blog de WordPress

Estas doce líneas son media hora típica en un blog pequeño. Hemos cambiado la dirección del único lector normal por una dirección de documentación (203.0.113.45, reservada para ejemplos), así que aquí no aparece ninguna persona real. Las demás direcciones son infraestructura pública.

El log de ejemplo (12 líneas)
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)"

Pegamos el log en el comprobador de logs de iplover. Encontró seis direcciones y comprobó las cinco públicas con las listas públicas de nuestro servidor; el log se quedó en el navegador. Esta es la tabla de resultados que mostró el 9 de noviembre de 2026:

Dirección IPLíneasCategoríaTipo de red
185.220.101.14Nodos de salida de TorNodo de salida de Tor
3.5.140.13Nube y hostingHosting, nube o centro de datos
203.0.113.452Privadas o reservadasDirección privada o reservada (no comprobada)
66.249.66.11GooglebotNo identificado
167.94.138.351Escáneres de internetNo identificado
40.77.167.101BingbotNo identificado

Dos columnas, dos preguntas. Categoría dice por qué se conoce la dirección: un rastreador, un escáner, Tor, un proveedor de nube. Tipo de red dice a qué clase de red pertenece, según las listas públicas. «No identificado» ahí solo significa que ninguna lista la cubre; no es un juicio sobre la dirección.

Las listas cambian a diario, así que si repites el ejemplo más adelante algún resultado puede ser distinto. Esto es lo que significa cada grupo para este sitio.

La lectora: 203.0.113.45

Dos peticiones con un segundo de diferencia: un artículo del blog y luego la hoja de estilos del tema, con Google como referer y un user agent normal de Chrome. Es una persona que buscó, hizo clic y leyó. En tu log, la dirección de una visita real aparecería como un proveedor de internet. Nada que hacer.

Los rastreadores: 66.249.66.1 y 40.77.167.10

Googlebot descargó un artículo y Bingbot leyó robots.txt. El comprobador encontró ambas direcciones en las listas que publican los buscadores, por eso los llama por su nombre; nunca se fía solo del user agent. Puedes verificar Googlebot tú mismo con dos consultas DNS, como recomienda Google: la búsqueda inversa debe terminar en googlebot.com, google.com o googleusercontent.com, y la búsqueda directa de ese nombre debe devolver la misma dirección.

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

Si prefieres que un rastreador venga menos, díselo en robots.txt. Bloquear a los buscadores de verdad te saca de sus resultados.

El escáner: 167.94.138.35

Censys escanea todo internet y deja los resultados a disposición de equipos de seguridad e investigadores. Pidió tu página de inicio y se fue. Es ruido, no un ataque. Puedes bloquear escáneres si te molestan las líneas, pero no ponen en riesgo tu web.

El impostor: 3.5.140.1

Esta es la línea que te debería hacer mirar dos veces. El user agent dice Googlebot, pero la dirección es de Amazon Web Services, no de Google. Los rastreadores de Google no funcionan en la nube de Amazon. Cualquiera puede escribir «Googlebot» en un user agent.

Ahora mira lo que buscaba: /.env, /wp-config.php.bak y un archivo .php dentro de la carpeta de subidas. Es una lista de la compra de secretos: los archivos .env y las copias de seguridad de wp-config.php suelen contener contraseñas de la base de datos y claves, y un archivo PHP en uploads sería una puerta trasera que alguien dejó antes. Las tres peticiones recibieron 404. No había nada, así que no se llevaron nada.

Asegúrate de que siga así. Pide tú esas rutas y comprueba que la respuesta es 404 o 403, nunca 200:

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

El que prueba contraseñas: 185.220.101.1

Cuatro peticiones POST en ocho segundos, tres a /wp-login.php y una a /xmlrpc.php. Alguien está probando contraseñas. El punto de acceso XML-RPC es de los favoritos porque una sola petición puede llevar muchos intentos.

Todas las respuestas fueron 200, y eso es buena noticia. Cuando falla un inicio de sesión en WordPress, vuelve a mostrarse la página de acceso con un error, y esa página es un 200. Un acceso correcto se responde con una redirección al escritorio, que en el log aparece como 302. Sin 302, no hay entrada.

La dirección es un nodo de salida de Tor, compartido por mucha gente. Bloquearla pararía estas cuatro peticiones, pero el siguiente intento llegaría sin más desde otro nodo, o desde un servidor en la nube. El propio Tor Project recuerda que algunos usuarios de Tor pueden ser visitantes legítimos de tu web. La solución duradera está de tu lado, y la tienes más abajo.

Veredicto de la mañana: no ha entrado nadie. Aun así, conviene arreglar dos cosas: reforzar el acceso y confirmar que los archivos secretos de verdad no están accesibles.

Si ves esto, haz esto

El mismo razonamiento sirve para cualquier línea. Busca la fila que corresponde a lo que tienes delante:

Lo que ves en el logQué significaQué hacer
Páginas normales, 200, el user agent de un navegador, un buscador como refererUna visitaNada.
Un rastreador que el comprobador llama por su nombre (Googlebot, Bingbot y similares)Un buscador real o un bot conocidoNada. Usa robots.txt para limitarlo.
«Googlebot» o «bingbot» en el user agent, desde una dirección que no es suyaUn falso rastreadorTrátalo como cualquier bot desconocido. Bloquéalo si molesta.
Peticiones de /.env, copias de seguridad, phpmyadmin y parecidas, todas 404Un escáner buscando descuidosComprueba que esas rutas también te dan 404 a ti. Por lo demás, nada.
El mismo tipo de petición respondida con 200Un archivo secreto era legibleActúa ya. Da por hecho que se copió: cambia todas las contraseñas y claves que contenía (contraseña de la base de datos, salts de WordPress, claves de API) y luego borra el archivo.
Muchos POST a /wp-login.php o /xmlrpc.php, respondidos con 200Intentos de contraseña fallidosRefuerza el acceso (más abajo).
Un POST a /wp-login.php respondido con 302, desde una dirección que no reconocesAlguien ha iniciado sesiónRevisa en Usuarios si hay cuentas que no creaste, cambia todas las contraseñas de administrador, usa Cerrar el resto de sesiones en tu perfil y busca plugins o temas cambiados hace poco.
Un 200 para un archivo .php dentro de /wp-content/uploads/Quizá una puerta trasera ya instaladaEn uploads nunca debería haber PHP. Da la web por comprometida: pide ayuda a tu hosting y restaura una copia que sepas que está limpia.
Cientos de peticiones por minuto desde una misma red, y la web va lentaUn bot agresivoLimítalo en tu CDN o cortafuegos, o bloquea el rango.

Refuerza el acceso

Los intentos de contraseña no terminan nunca, así que haz que no sirvan de nada en vez de perseguir cada dirección:

Cuándo sí tiene sentido bloquear una dirección

Bloquear compensa con una única fuente insistente que gasta recursos, como un servidor en la nube que machaca tu web. Contra todo lo demás es una defensa débil, porque los bots cambian de dirección cuando quieren. Si decides bloquear una, así se hace. (La sección Copiar una lista de bloqueo del comprobador te escribe estas líneas para las categorías que marques.)

Apache 2.4, en la configuración del sitio o en .htaccess:

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

nginx, dentro del bloque server:

deny 203.0.113.45;

Detrás de Cloudflare u otra CDN, bloquea en la CDN (Cloudflare lo llama IP Access Rules o reglas personalizadas del WAF; los nombres de los menús cambian de vez en cuando). Tu servidor solo ve las direcciones de la CDN, salvo que lo hayas configurado para leer la del visitante.

Lo que una dirección IP no puede decirte

Una dirección apunta a una red, no a una persona. Pueden compartirla miles de personas detrás de un mismo proveedor, una VPN o Tor. La semana que viene puede ser de otra persona. Su ubicación es una estimación, a menudo solo la ciudad más cercana del proveedor. Así que no trates una dirección como una identidad, ni intentes localizar a nadie a partir de ella. Nuestras guías sobre qué se puede hacer con una dirección IP y sobre si una IP revela tu domicilio explican por qué.

Si una dirección te ataca una y otra vez, el contacto útil es la red que la gestiona. La búsqueda de IP muestra el titular y su dirección de abusos, sacados de los registros oficiales. Espera respuesta ante abusos repetidos desde un servidor, no por un escaneo aislado. Si has perdido datos o dinero, denúncialo también a la Policía Nacional o a la Guardia Civil; el 017 de INCIBE te orienta gratis.

Fuentes

Documentos oficiales que usamos para comprobar los datos de esta guía.