Por dónde me vinieron los golpes al publicar la web

Publiqué una web pensando que nadie iba a fijarse en ella, y a las pocas horas ya tenía visitas que no eran personas. Aquí cuento lo que le llegó desde el primer día, qué hice para pararlo sin ser experto en seguridad y qué haría hoy si volviera a empezar.

Tenía la misma idea que casi todo el mundo: una web pequeña no le interesa a nadie. ¿Quién va a perder el tiempo atacando una página que visitan cuatro gatos? Pues resulta que muchos, y ninguno es un gato.

La web es la que conté en Hice una web con ayuda de la inteligencia artificial: esta misma, la del blog AI Real Cases, con portada, listado de artículos, página "Sobre el proyecto" y un formulario de contacto, hecha con Claude Code y alojada en uno de mis seis VPS, con un servidor web sencillo delante. La publiqué el 3 de marzo de 2026 con el orgullo de quien acaba de colgar un cuadro torcido en el salón.

Lo que no sabía entonces, y es lo primero que quiero que se lleve quien lea esto: los ataques no son personales. Nadie me eligió. Hay robots que recorren internet sin descanso probando fallos conocidos en todas las webs que encuentran, y la mía era simplemente una puerta más en una calle muy larga.

Me enteré casi por casualidad. Al día siguiente de publicar entré a mirar los registros del servidor, que son el diario donde el servidor apunta cada petición que recibe, solo para ver si alguien había entrado. Había cientos de líneas. Yo esperaba cinco.

No entendía la mitad, así que hice lo que hago con casi todo últimamente: se lo pasé a Claude. Copié un trozo del registro, quité antes mi dirección IP y cualquier dato que pudiera identificar a un visitante, y le pedí que me explicara línea por línea qué era cada petición y cuáles le parecían sospechosas. Me lo agrupó en tres montones: buscadores, curiosos y gente buscando puertas abiertas. Luego comprobé a mano algunas de sus conclusiones, porque el asistente también se equivoca, y lo hace con el mismo tono tranquilo cuando acierta que cuando no.

La cronología, más o menos, fue esta:

En volumen, la primera semana conté alrededor de 4.000 peticiones, de las que menos de un 20 % parecían personas de verdad. Ojo, peticiones, no visitantes: una persona que abre una página genera varias. Para separar unos de otros no me fié del agente de usuario, la etiqueta con la que cada visitante dice qué navegador es, porque cualquier bot puede poner la que quiera. Agrupé por dirección y miré el comportamiento: quien carga la página con sus estilos e imágenes y pasa de una a otra a ritmo humano, persona; quien pide diez rutas raras en un segundo, bot. Y a los que decían ser Google o Bing los comprobé por su dirección, que esos buscadores permiten verificar. Es una estimación, no un recuento exacto. Un fragmento del registro, limpio de datos sensibles, para que se vea que no exagero:

203.0.113.45 - - [04/Mar/2026:03:12:08] "GET /wp-login.php HTTP/1.1" 404
203.0.113.45 - - [04/Mar/2026:03:12:09] "GET /.env HTTP/1.1" 404
198.51.100.7 - - [04/Mar/2026:03:14:51] "GET /phpmyadmin/ HTTP/1.1" 404

Mi web no tiene WordPress ni phpMyAdmin. Les daba igual: preguntan por si acaso.

Un bot es cualquier programa que visita webs de forma automática. Y aquí va la primera sorpresa: no todos son malos. Los de Google o Bing son los que te ponen en los buscadores, y sin ellos nadie te encuentra. Luego están los rastreadores de las empresas de inteligencia artificial, que leen tu contenido para entrenar modelos o para responder preguntas. Y por último están los que vienen a buscar fallos, que son los que dan miedo.

En mi web aparecieron los tres tipos: el de Google y el de Bing desde el primer día, varios rastreadores de empresas de inteligencia artificial durante la primera semana y un goteo constante de bots anónimos probando rutas.

Para proteger la web de los bots mucha gente piensa primero en el archivo robots.txt. Es un fichero de texto donde le dices a los bots qué pueden visitar y qué no. El problema es que funciona como un cartel de "por favor": los educados lo respetan y los maliciosos ni lo leen.

Y cuidado con el error contrario. Estuve a punto de bloquear en robots.txt todo lo que no fuera Google, y en la prueba se me escapó una línea que bloqueaba también a Google. Lo vi a tiempo. Mi consejo: antes de bloquear nada, mira las estadísticas unos días y averigua quién te visita de verdad.

El formulario de contacto empezó a recibir basura al tercer día, y a la semana llegaban unos 30 mensajes diarios. Del tipo "mejore el posicionamiento de su web hoy mismo", "oferta exclusiva para su empresa" o directamente un enlace sin más explicación, a veces en idiomas que no identifico.

¿Por qué? Porque el formulario que me hizo la máquina funcionaba perfectamente y no tenía ninguna protección: se la tenía que haber pedido yo, y no lo hice. Cuando la web la escribe un asistente, hace lo que le pides. Si no le pides que proteja el formulario, no lo protege.

Para cortar el spam del formulario de contacto puse varias barreras sencillas:

• Captcha invisible, que comprueba si eres persona sin hacerte buscar semáforos. Usé Cloudflare Turnstile.
• Campo trampa u honeypot (tarro de miel): un campo oculto que una persona nunca ve y que los robots rellenan sin pensar. Si viene relleno, el mensaje se descarta.
• Límite de envíos: no más de tres mensajes por dirección en diez minutos.

Con Cloudflare delante, el servidor ve la dirección de Cloudflare y no la del visitante, así que hay que leer la real de la cabecera que añade Cloudflare, y solo cuando la petición viene de verdad de Cloudflare; si no, cualquiera puede inventársela. Con IPv6 pasa lo contrario: una misma persona puede usar muchas direcciones, así que el límite se aplica al bloque entero y no a cada dirección suelta. Y el formulario rechaza los envíos cuya cabecera de origen no es mi propio dominio.

Sobre el captcha, dos cosas que miré después. Comprobé que el formulario se puede enviar solo con el teclado y con un lector de pantalla, porque un captcha que deja fuera a una persona ciega es peor que el spam. Y que Turnstile no es la única opción: hay otras, como hCaptcha o Friendly Captcha, y si no quieres depender de un tercero, el campo trampa y el límite de envíos ya paran mucho.

Y un aviso que me aplico a mí mismo: no abras los enlaces que llegan en esos mensajes, por muy amables que parezcan. Basta un clic distraído para que el problema deje de ser la bandeja de entrada.

Esto es lo que más me inquietó al principio. Los bots probaban rutas típicas de administración (wp-login, admin, phpmyadmin), buscaban ficheros de configuración olvidados como .env, que es donde a veces se guardan contraseñas, y, en el servidor, intentaban entrar por SSH, el acceso remoto a la máquina, probando usuarios y contraseñas en bucle: root, admin, test, ubuntu y compañía.

La frecuencia, unas 1.500 tentativas de acceso por SSH al día y un par de cientos de peticiones a rutas de administración. Ninguno llegó a nada: el servidor solo acepta entrar con llave, no con contraseña, bloquea durante un rato a quien falla varias veces seguidas, y las rutas que buscaban no existen.

No me ha pasado, pero sí me senté a pensar qué haría si me hubieran entrado, y lo dejo escrito porque en ese momento uno no piensa con claridad. Es el plan para una web hackeada:

1. Cambiar todas las contraseñas: alojamiento, panel, base de datos, correo, accesos remotos.
2. Desconectar la web o ponerla en mantenimiento si está perjudicando a los visitantes.
3. Avisar al proveedor del alojamiento.
4. Restaurar una copia limpia de antes del ataque, no borrar solo lo que se ve, porque quien entra suele dejar puertas traseras para volver.
5. Buscar por dónde entraron y cerrarlo, o se repetirá.
6. Si en la web había datos personales de clientes, consultar cuanto antes si hay que notificarlo a la Agencia Española de Protección de Datos. El RGPD (artículo 33) da 72 horas desde que conoces la brecha, salvo que sea improbable que suponga un riesgo para las personas; si el riesgo es alto, el artículo 34 obliga además a avisar a los afectados. No es algo para dejar para el lunes.

Lo cuento como plan. Espero seguir contándolo así.

Esta es la lista práctica de seguridad de la página web que apliqué, con lo que me costó en tiempo:

El cambio de puerto es lo de menos: quita ruido de los registros porque muchos robots solo prueban el puerto de siempre, pero no protege nada por sí solo. Lo que protege es entrar solo con llave, tener el sistema actualizado y bloquear a quien insiste. Y no doy más detalle de puertos, rutas ni configuraciones porque la web sigue en marcha.

Sobre el HTTPS, una aclaración que a mí me costó entender: el candado del navegador solo significa que la conexión va cifrada. No hace segura la web. Es como un sobre cerrado: nadie lee la carta por el camino, pero la carta puede ser una estafa.

El cortafuegos web (WAF, por sus siglas en inglés) es un servicio que se pone delante de la web y filtra lo que llega antes de que toque tu servidor. Puse Cloudflare.

Por último, le pedí a Claude que revisara el código de la web buscando problemas de seguridad. Encontró la clave del servicio de correo del formulario escrita a la vista dentro del código y un formulario que no limpiaba lo que recibía. Lo arreglé. Pero ojo: pedirle la revisión está bien; fiarse a ciegas de que no ha encontrado nada más, no.

Las cifras cambiaron bastante:

• Spam en el formulario: de unos 30 al día a uno o dos a la semana.
• Intentos de acceso que llegan al servidor: de 1.500 al día a menos de 100, porque muchos se quedan en el cortafuegos.

Hubo efecto secundario, claro. Un conocido me escribió diciendo que no podía enviar el formulario desde la red de su oficina: el límite de envíos lo estaba tratando como sospechoso. Tuve que aflojarlo. También recibí un par de avisos del cortafuegos que resultaron ser falsas alarmas.

Ahora reviso los registros y las alertas una vez por semana, diez minutos, y las actualizaciones y una restauración de prueba una vez al mes.

Si mañana publicaras tu primera web, esto es lo que te diría, en corto:

1. Ten una copia de seguridad reciente, guardada fuera del servidor, y sabe restaurarla. Pruébalo una vez.
2. Protege el formulario desde el principio. Si lo hace un asistente, pídeselo expresamente.
3. Contraseñas largas y verificación en dos pasos en todo lo que la admita.
4. Mira los registros la primera semana, aunque no los entiendas: pídele a la inteligencia artificial que te los explique.

Lo demás se va añadiendo. Lo que he aprendido es que la seguridad de una web no es algo que se compra una vez y se olvida. Es una costumbre de mantenimiento, como pasar la ITV al coche, pero bastante más a menudo. Y ninguna de esas costumbres exige ser experto: exige acordarse.