En resumen: Los ataques automatizados a servidores web se producen en oleadas: unos programas rastrean internet en busca de servidores accesibles, los clasifican por rasgos externos y prueban de forma masiva vulnerabilidades conocidas como PHP2Shell. El tamaño de la empresa no importa. Ofrecen protección un PHP parcheado, una superficie de ataque pequeña y una supervisión que advierta rápido de los aciertos.
El punto de partida: «¿Quién iba a interesarse por nuestro sitio web?»
Esta pregunta la oímos a menudo tras PHP2Shell, sobre todo de las empresas más pequeñas. La respuesta honesta: probablemente nadie personalmente. Pero en vulnerabilidades de este tipo tampoco hace falta. Los ataques los ejecutan programas que no buscan nombres, sino oportunidades.
El BSI (Oficina Federal alemana para la Seguridad de la Información) contaba en PHP2Shell con una explotación rápida y a gran escala. Cloudflare informó de intentos de ataque y de que los atacantes modificaban sus patrones para eludir las reglas de protección. Ambas cosas encajan con lo que ocurre de forma habitual con las vulnerabilidades críticas en software muy extendido.
Cómo se desarrollan los ataques automatizados a servidores web
Las campañas automatizadas suelen seguir un patrón parecido. El siguiente resumen describe las fases de forma general, sin detalles del ataque:
| Fase | Qué ocurre | Qué ayuda contra ello |
|---|---|---|
| Buscar | los programas examinan grandes rangos de direcciones o directorios públicos, como los registros de certificados, en busca de servidores web accesibles | pocos sistemas accesibles públicamente, inventario de todas las direcciones |
| Clasificar | se evalúan las respuestas: servidor web, versión de PHP, CMS, rutas típicas | ocultar las indicaciones de versión, eliminar archivos innecesarios |
| Probar | se prueban de forma masiva vulnerabilidades conocidas, a menudo sin clasificación previa | PHP actual, reinicio, WAF como capa adicional |
| Asentarse | si tienen éxito, se deja una puerta trasera, por ejemplo una webshell o una tarea cron | permisos de escritura restringidos, sin ejecución de PHP en las carpetas de subida |
| Explotar | el servidor se usa, por ejemplo, para spam, minería de criptomonedas, redirecciones o robo de datos | supervisión de procesos, archivos y conexiones salientes |
Lo importante es la tercera fila. Muchas campañas ni siquiera se molestan en clasificar los servidores con precisión de antemano. Simplemente prueban todo lo que es accesible. Por eso pasar desapercibido no protege por sí solo.
Por qué los ataques llegan en oleadas
Las campañas automatizadas rara vez se ejecutan una vez y nunca más. Lo típico es un patrón en oleadas. La primera oleada llega poco después de conocerse una vulnerabilidad, a menudo todavía con herramientas poco maduras. Llegan más oleadas cuando los atacantes mejoran sus herramientas o las adaptan a las reglas de protección. Cloudflare observó justo eso con PHP2Shell: patrones de ataque modificados para eludir las reglas.
Para usted significa: un servidor que ha superado ileso la primera oleada no es seguro de forma permanente mientras no esté parcheado. Y un servidor recién montado es objetivo desde el momento en que es accesible. Quien, por ejemplo, hace emitir un nuevo certificado TLS hace visible el nombre en los registros públicos de certificados, que también evalúan los escáneres. Por eso, un sistema nuevo solo debería conectarse a la red cuando ya esté actualizado.
Por qué las pequeñas empresas están igual de afectadas
Para los ataques automatizados no cuenta el valor de un objetivo individual, sino la cantidad. El servidor de un pequeño negocio ofrece capacidad de cálculo, un dominio con buena reputación, un envío de correo y a veces datos de clientes. Para los atacantes es suficiente.
A ello se suma que las empresas más pequeñas suelen no tener una TI propia que aplique las actualizaciones de inmediato. Sus servidores siguen siendo vulnerables más tiempo y por eso aparecen con más frecuencia en las listas de resultados de los escáneres. Quien parchea primero desaparece de esas listas.
Otro punto es la cadena de suministro. Muchos sitios web pequeños están en servidores de agencias o de pequeños proveedores de alojamiento, en los que funcionan docenas de proyectos de clientes a la vez. Para los atacantes, un servidor así es especialmente rentable, porque un solo acierto afecta a muchos sitios web al mismo tiempo. Su riesgo depende entonces no solo de su propio cuidado, sino también del de su proveedor de servicios.
Los escaneos en sus registros son normales y no son una prueba de intrusión. Un ataque exitoso se manifiesta en otros indicios: archivos nuevos, procesos ajenos, cuentas desconocidas, conexiones salientes inusuales.
Qué puede comprobar usted mismo
Un vistazo a los registros muestra con qué intensidad se escanea su servidor. Los siguientes comandos solo leen y no modifican nada:
# Las diez direcciones con más peticiones en el registro de acceso actual
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Peticiones respondidas con «no encontrado», por frecuencia
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# ¿Revela el servidor su versión de PHP en la cabecera?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Muchas peticiones a rutas inexistentes son el ruido típico de los escaneos. Debería estar más atento si a esas peticiones siguen de repente respuestas exitosas, si en las carpetas de subida se invocan archivos que usted no conoce o si el usuario del servidor web lanza procesos que normalmente nunca lanza. Hasta ahora no hay indicadores de detección confirmados específicamente para PHP2Shell, por lo que la valoración se basa en esas anomalías de comportamiento. Cómo analizar los registros con más detalle lo describe la guía Analizar los registros del servidor web. Si la tercera consulta muestra una versión de PHP, merece la pena el ajuste expose_php = Off; los antecedentes figuran en Ocultar las indicaciones de versión.
Las capas de protección en el orden correcto
- Actualizar PHP y reiniciar: sin este paso, todas las demás medidas son un parche provisional.
- Reducir la superficie de ataque: desconectar o proteger con inicio de sesión los sitios web no utilizados, los sistemas de pruebas y los microsites antiguos.
- Reglas en el borde: un cortafuegos de aplicaciones web con un conjunto de reglas mantenido, por ejemplo el OWASP Core Rule Set con ModSecurity, frena una parte de los intentos.
- Frenar los intentos repetidos: herramientas como Fail2ban bloquean las direcciones que generan muchísimos errores. Contra los escaneos distribuidos esto ayuda solo de forma limitada.
- Supervisar: vigilar los procesos del usuario del servidor web, los archivos PHP nuevos y las conexiones salientes, para que un acierto no pase desapercibido durante semanas.
¿Cómo ayuda PHP SOS en concreto?
- Registrar la superficie de ataque: averiguamos cuáles de sus sistemas son accesibles desde fuera y qué revelan sobre sí mismos.
- Parchear y reforzar: actualizamos PHP, reiniciamos y reducimos indicaciones de versión, permisos de escritura y servicios innecesarios.
- Reglas y bloqueos: configuramos reglas WAF y mecanismos de bloqueo adecuados a su aplicación.
- Supervisión continua: avisamos de procesos, archivos y conexiones anómalos antes de que un acierto se convierta en incidente.
Cómo es esto en el funcionamiento permanente lo describe Monitorización de seguridad para servidores web.
Conclusión
Los ataques automatizados no preguntan a quién pertenece un servidor. Solo preguntan si es vulnerable. La mejor respuesta es poco espectacular: parchear rápido, ofrecer poco, mirar con atención. Quien lo hace seguirá siendo escaneado, pero ya no será encontrado.
Preguntas frecuentes
¿Son las pequeñas empresas objetivo de ataques automatizados?
Sí. Los escaneos automatizados examinan los servidores accesibles sin fijarse en quién los administra. Que detrás haya un grupo empresarial o un taller artesanal da igual para el software. Lo decisivo es si el servidor parece vulnerable.
¿Cómo reconozco escaneos en mis registros?
Son típicas muchas peticiones a rutas que no existen en su sitio web, a menudo desde direcciones cambiantes y con identificadores llamativos. Esas entradas son normales y no prueban todavía un ataque exitoso, pero muestran que su servidor está siendo examinado.
¿Ayuda ocultar la versión de PHP?
A los escáneres les resulta algo más difícil clasificar su servidor de forma dirigida, y es un ajuste básico razonable. Pero no protege de ataques que simplemente prueban en todos los servidores. La actualización sigue siendo obligatoria.
¿Puedo impedir por completo los escaneos?
No. Todo servidor accesible públicamente es escaneado con regularidad. El objetivo no es impedir los escaneos, sino lograr que no encuentren nada: software actualizado, poca superficie de ataque y una supervisión que avise de las anomalías.