1

I've come across a rather interesting problem trying to configure NGinx. I run a small web server that serves everything over HTTPS with NGinx 1.13.8. As is typical for such a configuration, it also listens on port 80 and issues a blanket redirect for all requests there to port 443 with the same URI, using the following config fragment to achieve this:

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

This by itself has worked just fine for what I need it for. However, I've started getting some obviously bogus and easily identifiable traffic (random periods of about 5 minutes where I get upside of a thousand new connections from seemingly random IP's, all with a common prefix in the User-Agent header, all making exactly the same request (HEAD / HTTP/1.1), all leaving the connection open until it times out, and all never following the redirect).

Ideally, I'd like to just close these connections as soon as they are identified to minimize the amount of resources they waste. Currently, I've come up with this modified configuration fragment to do so:

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;
    }
}

However, this doesn't appear to work (as the logs still show these spikes of traffic entirely returning 301's. I've also tried less specific matching (just blanket matches on the User-Agent header, or the method) inside the first location block, and that doesn't appear to work either.

So, I've got two questions:

  1. Why doesn't this work?
  2. Is there a better way to handle this traffic that doesn't potentially involve deep packet inspection in the firewall?
  • I don't know with your server, but in lighttpd, one could make a conditional in the conf file to reduce the timeout to 1 second when the problematic pattern is found. As a workaround, you could handle the default / document with php (if you aren't already) and issue an exec (iptables ... -j REJECT --reject-with tcp-reset) to enforce end of connection. – Zdenek Jun 20 '18 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.