NGINX: Wie geht man mit offensichtlich betrügerischem Datenverkehr auf einem Server um, der eine bedingungslose, pauschale Umleitung ausgibt?

NGINX: Wie geht man mit offensichtlich betrügerischem Datenverkehr auf einem Server um, der eine bedingungslose, pauschale Umleitung ausgibt?

Beim Versuch, NGinx zu konfigurieren, bin ich auf ein ziemlich interessantes Problem gestoßen. Ich betreibe einen kleinen Webserver, der alles über HTTPS mit NGinx 1.13.8 bereitstellt. Wie es für eine solche Konfiguration typisch ist, lauscht er auch auf Port 80 und leitet alle Anfragen dort pauschal an Port 443 mit derselben URI um. Dazu wird das folgende Konfigurationsfragment verwendet:

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

Das allein hat für das, wofür ich es brauche, gut funktioniert. Allerdings habe ich angefangen, offensichtlich falschen und leicht identifizierbaren Datenverkehr zu erhalten (zufällige Zeiträume von etwa 5 Minuten, in denen ich über tausend neue Verbindungen von scheinbar zufälligen IPs bekomme, alle mit einem gemeinsamen Präfix im User-Agent-Header, alle stellen genau dieselbe Anfrage ( HEAD / HTTP/1.1), alle lassen die Verbindung offen, bis sie abläuft, und alle folgen nie der Umleitung).

Im Idealfall würde ich diese Verbindungen einfach schließen, sobald sie erkannt werden, um die Menge der von ihnen verschwendeten Ressourcen zu minimieren. Derzeit habe ich mir dieses geänderte Konfigurationsfragment ausgedacht, um dies zu erreichen:

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

Dies scheint jedoch nicht zu funktionieren (da die Protokolle immer noch diese Verkehrsspitzen zeigen, die vollständig 301-Weiterleitungen zurückgeben). Ich habe auch weniger spezifische Übereinstimmungen (nur pauschale Übereinstimmungen im User-Agent-Header oder der Methode) innerhalb des ersten Standortblocks versucht, und das scheint auch nicht zu funktionieren.

Ich habe also zwei Fragen:

  1. Warum funktioniert das nicht?
  2. Gibt es eine bessere Möglichkeit, diesen Datenverkehr zu handhaben, die möglicherweise keine Deep Packet Inspection in der Firewall erfordert?

verwandte Informationen