Errata:
Haía olvidado hacer un reload de la configuración después de cambiar el
código de error de 404 a 444 (un código interno que simplemente cierra
la conexión sin devolver una página con el código de error)
Ahora los intentos raros que mencioné no caen en el archivo error.log,
siguen apareciendo en el access log, pero ahora el tamaño de la
respuesta es cero:
115.230.127.237 - - [04/Sep/2015:16:53:24 -0400] "GET
http://zc.qq.com/cgi-bin/common/attr?id=260714&r=0.9130018667336710
HTTP/1.1"
444 0 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1;
Trident/5.0; 360SE)"
Aqui tienen otro ejemplo de entrada sospechosa que está cayendo en el
error.log:
2015/09/04 14:02:46 [error] 59274#59274: *14 FastCGI sent in stderr:
"Primary script unknown" while reading response header from upstream,
client: 219.143.252.242, server: _, request: "GET
/myadmin/scripts/setup.php HTTP/1.1", upstream:
"fastcgi://unix:/var/run/php5-fpm.sock:", host: "<ipdelhost>"
Analizando las trazas, parece que hay redes desde donde se ejecutan
scripts que se programan para su ejecución a intervalos que cambian, es
decir, pueden ser 4 intentos cada 15 minutos y luego 4 más cada 53
minutos, y así sucesivamente, como para evitar caer en reglas del tipo
fail2ban que tengan intervalos de tiempo cortos.
En fin, mi inquietud persiste:
Acaso existen medidas adicionales que puedan tomarse en la propia
configuración de Nginx para minimizar el riesgo de tales intentos de
explotar posibles vulnerabilidades?
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
