Administro una web corporativa pequeña. Es la primera vez que reviso bien los logs y me he llevado un susto.
Hay miles de peticiones al día: a rutas como /wp-admin, /.env, /phpmyadmin, /.git/config. Y ni siquiera usamos WordPress.
¿Es un ataque dirigido contra nosotros o es así para todo el mundo? ¿Qué hago?
Primero, tranquilos: no es un ataque dirigido contra vosotros, es el ruido de fondo que recibe cualquier dirección expuesta a internet. Los bots escanean rangos de IP constantemente y prueban rutas de vulnerabilidades conocidas. No saben qué es vuestra web ni les importa.
Ahora voy a la parte escéptica, porque decir "normal" no significa que sea "irrelevante". Haced esta distinción:
Ruido automático: peticiones a rutas aleatorias que devuelven 404, desde IPs distintas, con patrones repetitivos. Esto es solo ruido.
Lo que hay que vigilar: los intentos contra rutas que realmente existen en vuestro sitio. Intentos de contraseña seguidos en la página de login, intentos de acceso al panel de administración, manipulaciones de parámetros. Eso significa que alguien ha mirado de verdad vuestra web.
Qué hacer, por orden de importancia: no dejéis el panel de admin público, poned rate limiting a los intentos de login, mantened el software actualizado, haced backups y probad a restaurarlos.
Lo último es lo que más se salta. Un backup no probado no es un backup.
Añado algo técnico desde el lado del SOC.
Intentar bloquear todo este ruido (como meter todas las IPs en una blacklist) suele ser perder el tiempo. Las IPs cambian constantemente, la lista se infla y un día bloqueáis a vuestro propio usuario.
En su lugar, filtrad el ruido para poder ver el incidente real. Método práctico: escribid las peticiones que devuelven 404 en un canal aparte, que en el flujo principal de logs solo queden las que devuelven 200 y 500. Y llevad un contador aparte para los intentos de login fallidos.
Como regla de alerta os recomiendo esto: muchos intentos de login fallidos, desde una sola fuente, en poco tiempo. Ese es el patrón que realmente destaca del ruido y requiere intervención.
Y no olvidéis esto: los incidentes reales más comunes no empiezan por fuerza bruta desde fuera, sino iniciando sesión con una contraseña filtrada. Por eso, además de mirar los logs, es importante activar la verificación en dos pasos.
Os hago una pregunta: decís que es la primera vez que revisáis bien estos logs. ¿Hasta cuánto tiempo atrás podéis mirar?
El problema es este: en la mayoría de servidores, el tiempo de retención de logs es corto por defecto. Cuando ocurre un incidente, todos los que quieren mirar hacia atrás chocan con el mismo muro: no hay logs.
Como alguien que pide pruebas, mi recomendación concreta: comprobad vuestro tiempo de retención de logs y subidlo a al menos noventa días. El coste en espacio es pequeño, pero su valor en un incidente es enorme. Además, guardad los logs en otro sitio, no solo en el propio servidor; si comprometen el servidor, lo primero que borran son los logs.
Doy un dato desde el lado del hosting, no es una estimación, es el patrón que vemos regularmente en nuestro propio panel.
Incluso un dominio recién registrado, sin promocionar, sin enlaces en ningún sitio, empieza a recibir este tipo de intentos automáticos en la primera semana. La razón es simple: los registros de transparencia de certificados son públicos, y los nuevos dominios también se ven ahí.
Así que no existe esa situación de seguridad de "mi web es pequeña, nadie la conoce". Ser pequeño no os hace invisibles, solo reduce la probabilidad de un ataque dirigido.
Soy estudiante, quiero preguntar algo, perdonad si parece una tontería.
¿Por qué estos navegadores buscan el archivo /.env? O sea, ¿qué tiene ese archivo que es tan valioso?
Nada absurdo, es una pregunta muy acertada.
El archivo .env es un archivo de texto que guarda la configuración de la aplicación (environment, o sea, variables de entorno). Suele contener la dirección y contraseña de la base de datos, las claves de servicios de terceros y la clave de cifrado de sesión.
Para un atacante, este archivo significa encontrar la llave en vez de forzar la puerta. Por eso los escáneres lo prueban primero; el coste es una sola petición, el beneficio es todo.
Normalmente este archivo debe estar fuera de la carpeta que sirve el servidor web. En instalaciones incorrectas se queda dentro de la carpeta public y es legible desde el navegador. La misma lógica aplica para /.git/config: si el repositorio del proyecto se publica por error, se puede descargar todo el código fuente.
Es muy fácil comprobarlo: escribe /.env en tu propia dirección y prueba. Si recibes un 404, no hay problema; si ves el contenido, ciérralo ya y cambia todas las claves de ese archivo. Cerrarlo no basta, se asume que ha habido una filtración.
Como equipo de Doki, añadimos una nota, porque este hilo resume bien un tema que se pregunta mucho.
Nosotros también vemos el panorama descrito arriba: cualquier activo expuesto a internet es escaneado, aunque no se anuncie. Por eso recomendamos a nuestros clientes hacer primero un inventario de activos: qué dominios, qué subdominios y qué servidores son realmente nuestros y cuáles siguen activos por olvido.
En la práctica, la puerta abierta más frecuente son los entornos de prueba olvidados. El sistema en producción está bien protegido, pero un servidor de pruebas abierto hace dos años sigue apuntando a la misma base de datos.
Las publicaciones aquí son solo para información general; recomendamos que encarguéis una evaluación con alcance definido para vuestro propio sistema.
Si lo ves como un proceso, el panorama cambia. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.
Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola. Si escribís el resultado aquí, también servirá de ayuda a otros.
De acuerdo, incluso me gustaría recalcarlo. Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.
También me gustaría saber si alguien lo hace de otra manera.
Hay un punto que me genera dudas. Las decisiones apresuradas son las que hay que corregir seis meses después.
Ánimo.
Resumen breve para nuevos usuarios: Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla.
Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro. Ánimo.
Gracias por escribir esto, es lo correcto. Si el permiso y el alcance no están por escrito, que no empiece la prueba.
Esta es mi opinión, no lo escribo como una verdad absoluta.
Llevé mucho tiempo con este asunto. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.
El error cometido por log suele ser reversible, pero caro. Espero que le sea útil.
¿Y cómo resolvieron esto? Intentar hacerlo solo es la vía más cara.
El error cometido por log suele ser reversible, pero caro. Esta es mi opinión no lo escribo como una verdad absoluta.