Nur erlaubte HTTP-Methoden durchlassen: unerwünschte Anfragen mit Nginx 405/444 abschneiden

Beim Tailen der Logs einer laufenden Web-Applikation stößt man manchmal auf solche Situationen:

  • Ich dachte, ich nutze nur GET / POST / PUT / DELETE.
  • Im Log taucht plötzlich eine unbekannte Methode auf.

Beispielsweise kann PROPFIND, ein WebDAV-Befehl, im Log erscheinen. Die App wird das ohnehin als „nicht unterstützte Methode“ behandeln, aber das ist nicht das Wesentliche.

Muss die Applikation wirklich mit dem Lärm umgehen? Die Antwort ist meist „Nein“. Deshalb ist es sauber, nur die erlaubten Methoden durchzulassen und den Rest bereits in Nginx abzuschneiden.

Warum gerade in Nginx blockieren?

Man könnte die Blockierung auch auf Applikationsebene durchführen. Doch sobald die Anfrage die App erreicht, sind bereits Kosten entstanden:

  • WSGI/ASGI-Einstieg
  • Middleware/Logging/Authentifizierung laufen teilweise
  • App-Logs werden unübersichtlich, echte Probleme gehen unter
  • Bei hohem Traffic summiert sich die unnötige Last

Im Gegensatz dazu bringt eine Blockierung in Nginx:

  • Sofortiges Beenden an der Front → minimale Kosten
  • Saubere App-Logs → einfachere Wartung
  • Reduzierte Angriffsfläche → unnötige Methoden werden gar nicht erst verarbeitet

Kurz gesagt:

Die App baut das Produkt, Nginx ist der Türsteher.

Seltene, fremde Methoden im Log sind meist keine legitimen Anfragen

PROPFIND ist ein typisches Beispiel.

  • Scans, um zu prüfen, ob WebDAV aktiviert ist
  • Wenn PUT/MKCOL versehentlich offen ist, wird versucht, weiterzugehen
  • User-Agent kann leer sein oder es tauchen grobe HTTP/1.0-Patterns auf

Der Kernpunkt:

Wenn unser Service diese Methode nicht nutzt, ist das sehr wahrscheinlich kein legitimer Traffic. Dann muss die App nicht erst antworten.

Strategie: Allowlist (Erlaubnisliste) anwenden

Nginx als Sicherheitswache

Prinzip: Nur das Notwendige öffnen, alles andere schließen.

  • Standard-Webseiten/Statik: meist reichen GET und HEAD
  • API: nur auf den benötigten Endpunkten POST/PUT/PATCH/DELETE erlauben

Alle übrigen Methoden (z. B. PROPFIND, MKCOL, LOCK) blockieren, wenn wir sie nicht brauchen – das ist langfristig am einfachsten zu betreiben.

405 vs 444: Welche Antwort wählen?

Es gibt zwei Hauptansätze.

1) 405 Method Not Allowed

  • Standard und leicht verständlich
  • Klare Meldung an legitime Clients, die versehentlich die falsche Methode nutzen

2) 444 (Nginx-spezifisch: Verbindung ohne Antwort schließen)

  • Ohne Rückmeldung abbrechen
  • Scanner/Bots erhalten weniger Hinweise
  • Ruhiger und sauberer aus Sicht des Betriebs („Lärm verbergen“)

In der Praxis:

  • Für öffentliche Web-Anfragen mit sinnlosen Methoden: 444
  • Für legitime Clients, die Fehler machen könnten: 405

Nginx-Konfiguration: Zwei Muster zum „Nur erlaubte Methoden durchlassen“

Die folgenden Beispiele sind so gestaltet, dass sie sofort kopiert und angepasst werden können.

Muster A) Standard: GET/HEAD, API mit zusätzlichen Methoden

server {
    # ... listen/server_name usw. ...

    # 1) Standard: Web/Statik nur GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # oder 405
        proxy_pass http://app;
    }

    # 2) API: Nur benötigte Methoden
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
  • / ist in der Regel nur für Seitenaufrufe gedacht – GET/HEAD reicht.
  • /api/ benötigt wegen CORS oft auch OPTIONS.

Muster B) Nur „fremde“ Methoden explizit blockieren (leichter Einstieg)

location / {
    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }
    proxy_pass http://app;
}
  • Entfernt sofort die häufigsten störenden Methoden.
  • Langfristig ist jedoch das Allowlist-Muster (A) sicherer und wartungsfreundlicher.

Hinweis: if-Anweisungen in Nginx werden oft als riskant bezeichnet. Für einfache „return“-Bedingungen sind sie in der Praxis aber üblich. Für strengere Regeln kann limit_except verwendet werden.

Fazit: „Nur erlaubte Methoden durchlassen“ erleichtert den Betrieb

Die Kernaussage ist einfach:

  • Fremde Methoden sind meist kein legitimer Traffic.
  • Wenn sie bis zur App kommen, entstehen Kosten und unübersichtliche Logs.
  • Daher blockiert Nginx nicht erlaubte Methoden mit 405/444.

Mit einem dieser Muster:

  • weniger Last auf der App
  • saubere Logs
  • deutlich einfacherer Betrieb