Cuando publicas un sitio web nuevo, lo primero que recibes no son visitantes humanos. Son bots. Decenas, a veces cientos al día, llegan probando rutas que no existen — /wp-admin, /.env, /phpmyadmin, /admin/login.php — para ver si caen en algo conocido.
No es porque tu sitio sea importante. No es porque alguien te tenga en el punto de mira. Es porque toda la internet pública está siendo barrida 24 horas al día, todos los días, por procesos automáticos que no distinguen entre el blog de un fotógrafo y el panel de una empresa cotizada. Buscan lo mismo en todos: una puerta que alguien olvidó cerrar.
La barrera para atacar nunca ha sido tan baja
Hace diez años, atacar un sitio web requería conocimientos. Hoy, cualquier persona puede descargar en segundos un conjunto de herramientas que automatizan el trabajo: nmap, nikto, sqlmap, wpscan, dirb… listas con miles de rutas conocidas, scripts pre-hechos para todas las vulnerabilidades de WordPress de los últimos diez años, plantillas para fuerza bruta.
Y con la última oleada de modelos de lenguaje, la pieza que faltaba — la interpretación de los resultados, la decisión de qué probar a continuación — también está al alcance de quien no sepa programar. Lo que antes requería un perfil técnico hoy lo puede hacer cualquiera con curiosidad y una tarde libre.
El resultado es directo: hay más atacantes potenciales, atacando más rápido, sobre más objetivos. Y los objetivos, en su mayoría, siguen sin enterarse.
Qué busca exactamente ese tráfico hostil
Si miras los registros de un servidor expuesto durante 24 horas, lo que aparece es bastante repetitivo:
- Rutas de WordPress — incluso si tu sitio no lo usa.
/wp-login.php,/xmlrpc.php,/wp-admin/admin-ajax.php. Los bots prueban porque es barato y porque el mundo está lleno de WordPress mal mantenidos. - Ficheros sensibles olvidados —
.env,.git/config,backup.sql,config.bak,database.zip. Un único hallazgo y el atacante obtiene credenciales, código fuente o la base de datos completa. - Paneles de administración por defecto —
/admin,/administrator,/manager,/phpmyadmin. Si el panel responde, viene fuerza bruta. - Inyecciones a ciegas — parámetros como
?id=1' OR '1'='1contra cualquier formulario. No saben qué CMS usas, prueban payloads genéricos. - Identificación de tecnologías — cabeceras
Server, ficheros estáticos típicos, errores 500 reveladores. Cualquier dato sirve para saber qué exploits aplicar.
Nada de esto requiere que tu sitio sea conocido. Solo requiere que esté online.
La asimetría del problema
El atacante automatiza. Lanza un script contra diez mil dominios y, si uno responde, gana. El coste por intento es prácticamente cero.
El defensor, en cambio, casi nunca automatiza. Si gestionas un sitio sin ayuda externa, lo más probable es que ni siquiera mires los logs del servidor — y si lo haces, te encuentras con miles de líneas mezclando peticiones legítimas con basura automatizada. Distinguir señal de ruido a mano no escala.
Esa es la asimetría: una de las partes opera a la velocidad de la máquina, la otra a la velocidad de un humano leyendo texto. Mientras esa desigualdad se mantiene, el tiempo siempre juega a favor del atacante.
Lo que sí puedes hacer (sin convertirte en sysadmin)
La solución no es estudiar seguridad. La solución es poner al defensor en condiciones de igualdad: que también automatice. Que reconozca peticiones hostiles, bloquee user-agents conocidos, banee IPs que repiten patrones de ataque, y limite el daño antes de que llegue a tu código.
No tiene por qué ser caro. Tampoco tiene que ser complejo. Las piezas básicas son:
- Un filtro de entrada que rechace las peticiones obviamente maliciosas antes de que toquen tu aplicación.
- Un registro de tráfico que separe humanos, bots verificados (Google, Bing) y peticiones sospechosas — en una vista que puedas leer en 30 segundos.
- Una lista de bloqueo de IPs ya identificadas como hostiles, mantenida automáticamente.
- Alguna forma de aviso cuando aparezca algo fuera de lo normal — para no tener que entrar al panel todos los días.
Con eso ya tienes resuelto la mayor parte del problema. El resto son los ataques dirigidos, que son una conversación distinta y, sinceramente, mucho menos frecuentes que el ruido de fondo continuo.
Conclusión
Si tu sitio está online, está siendo escaneado. Eso no va a cambiar — es la nueva normalidad de la web pública. Lo que sí puede cambiar es lo que pasa cuando ese tráfico llega: si entra sin filtro hasta tu código o si se queda en la puerta.
La diferencia entre un sitio comprometido y un sitio seguro raras veces es el talento del atacante. Casi siempre es si el defensor se molestó en cerrar la puerta antes de irse a dormir.