NGINX: ¿Cómo lidiar con el tráfico obviamente falso en un servidor que emite una redirección general incondicional?

NGINX: ¿Cómo lidiar con el tráfico obviamente falso en un servidor que emite una redirección general incondicional?

Me encontré con un problema bastante interesante al intentar configurar NGinx. Ejecuto un pequeño servidor web que sirve todo a través de HTTPS con NGinx 1.13.8. Como es típico en dicha configuración, también escucha en el puerto 80 y emite una redirección general para todas las solicitudes allí al puerto 443 con el mismo URI, utilizando el siguiente fragmento de configuración para lograr esto:

location / {
    return 301 https://$server_name$request_uri;
}

Esto por sí solo ha funcionado bien para lo que lo necesito. Sin embargo, comencé a recibir tráfico obviamente falso y fácilmente identificable (períodos aleatorios de aproximadamente 5 minutos en los que obtengo miles de nuevas conexiones de IP aparentemente aleatorias, todas con un prefijo común en el encabezado User-Agent, todas haciendo exactamente la misma solicitud ( HEAD / HTTP/1.1), todos dejan la conexión abierta hasta que se agota el tiempo de espera y nunca siguen la redirección).

Idealmente, me gustaría cerrar estas conexiones tan pronto como se identifiquen para minimizar la cantidad de recursos que desperdician. Actualmente, se me ocurrió este fragmento de configuración modificado para hacerlo:

location / {
    return 301 https://$server_name$request_uri;
}

location = / {
    if ($method = "HEAD") {
        set $drop M;
    }
    if ($http_user_agent ~* "Dalvik/2.1.0 (Linux U ") {
        set $drop "U${drop}";
    }
    if ($drop = "UM") {
        return 444;
    }
}

Sin embargo, esto no parece funcionar (ya que los registros aún muestran estos picos de tráfico que devuelven completamente 301. También probé coincidencias menos específicas (solo coincidencias generales en el encabezado User-Agent, o el método) dentro de la primera ubicación. bloquear, y eso tampoco parece funcionar.

Entonces, tengo dos preguntas:

  1. ¿Por qué esto no funciona?
  2. ¿Existe una mejor manera de manejar este tráfico que no implique potencialmente una inspección profunda de paquetes en el firewall?

información relacionada