El escaneo, visto desde el servidor web

Un barrido de rutas pide muchas direcciones que probablemente no existen, a un ritmo constante y sin que nada lo haya llevado hasta ellas: no hay una página anterior que enlace a esas rutas. En el registro se ve como una ristra de respuestas 404 (no encontrado) sobre rutas muy distintas, con un hueco regular entre peticiones. Es la huella de lo que ATT&CK recoge como escaneo activo de vulnerabilidades y de listas de palabras (T1595.002 y T1595.003).

No todo lo que pide muchas rutas es un barrido. Un rastreador de buscador también pide muchas rutas distintas, pero casi todas existen y devuelven 200, y suele empezar por el archivo que dice qué rutas no debe visitar. Y un cliente con un marcador viejo puede dar cinco 404 seguidos, pero a una sola ruta, con pausas de persona entre uno y otro. Ni el volumen por sí solo ni el agente de usuario deciden: el agente lo escribe el programa, y puede decir lo que quiera.

Con un resumen por origen se resuelve en un vistazo. Tres orígenes tienen muchas rutas distintas o muchos 404, pero solo uno cumple las dos cosas a la vez: casi todo lo que pidió no existía y casi nada se repitió. El rastreador del buscador tiene tantas rutas como peticiones, pero casi todas respondieron 200; el cliente del marcador viejo tiene casi todos los 404, pero de una sola ruta repetida.

Un barrido de veinte rutas con veinte respuestas negativas no pasó nada. Un barrido de veinte rutas con un solo 200 es otra historia: ese 200 es lo único que importa de todo el episodio, porque dice que el sitio entregó algo que el visitante no debía poder pedir. Las respuestas 403 (prohibido) son el caso intermedio: la ruta existe, pero el servidor no la entregó.

Los archivos que un barrido busca no son al azar: copias de seguridad, volcados de base de datos, repositorios de código, paneles de administración y archivos de configuración de la aplicación, que suelen guardar usuarios y contraseñas de otros sistemas. Lee las rutas de ese origen con sus estados y encuentra la única que el servidor sí entregó.

El archivo que respondió 200 pesó 1 186 bytes: lo bastante para contener las credenciales de la base de datos y de otros servicios que la tienda usa. Bloquear al origen que lo pidió parece lo natural, y es insuficiente: el que lo descargó ya lo tiene, y cualquier otro que lo pida mañana desde otra dirección también lo obtendrá mientras siga publicado.

La respuesta tiene un orden. Primero, quitar el archivo del alcance del servidor web (o bloquear esa ruta en el proxy, mientras se mueve). Segundo, tratar como expuesto todo secreto que contenía: se cambian. Tercero, revisar en el registro quién más lo pidió con éxito y desde cuándo. Bloquear al origen es lo último y lo menos importante.