Nur erlaubte HTTP‑Methoden durchlassen: Nginx blockiert unerwünschte Anfragen mit 405/444 [ r1 ]

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

Beim Tailen der Logs einer laufenden Web‑Applikation trifft man manchmal auf diese Situation.

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

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

Muss die Applikation wirklich mit dem Lärm umgehen?\nDie 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, ist bereits Kosten entstanden.

\n
• WSGI/ASGI Einstieg
\n
• Middleware/Logging/Authentifizierung laufen teilweise
\n
• App‑Logs werden unübersichtlich
\n
• Bei hohem Traffic summiert sich die unnötige Last
\n

Im Gegensatz dazu:

\n
• Sofortiges Beenden an der Front → minimale Kosten
\n
• Saubere App‑Logs → einfachere Wartung
\n
• Reduzierter Angriffsvektor → unnötige Methoden werden gar nicht erst verarbeitet
\n

Kurz gesagt:

\n

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

\n

Seltene, fremde Methoden im Log sind meist keine legitimen Anfragen

PROPFIND ist ein typisches Beispiel.

\n
• Scanning, um zu prüfen, ob WebDAV aktiviert ist
\n
• Bei versehentlicher Aktivierung von PUT/MKCOL wird versucht, weiterzugehen
\n
• User‑Agent kann leer sein oder ein rudimentäres HTTP/1.0‑Pattern
\n

Der Kernpunkt: Wenn unsere Service diese Methode nicht nutzt, ist es kaum legitimer Traffic.\nDann muss die App nicht erst antworten.

Strategie: Allowlist (Erlaubnisliste) anwenden

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

\n
• Standard‑Webseiten/Statik: meist reicht GET und HEAD
\n
• API: Nur die benötigten Endpunkte mit POST/PUT/PATCH/DELETE erlauben
\n

Alle übrigen Methoden (z.\u202fB. PROPFIND, MKCOL, LOCK) blockieren, wenn wir sie nicht brauchen – das ist die einfachste Betriebsweise.

405 vs 444: Welche Antwort wählen?

Es gibt zwei Hauptansätze.

1) 405 Method Not Allowed

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

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

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

In der Praxis wird oft folgendes gewählt:

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

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‑Spezialzugriff

server {\n    # ... listen/server_name usw. ...\n\n    # 1) Standard: Web/Statik nur GET/HEAD\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # oder 405\n        proxy_pass http://app;\n    }\n\n    # 2) API: Nur benötigte Methoden\n    location /api/ {\n        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }\n        proxy_pass http://app;\n    }\n}\n

\n
• / ist in der Regel nur für Seitenaufrufe gedacht – GET/HEAD reicht.
\n
• /api/ benötigt wegen CORS oft auch OPTIONS.
\n

Muster B) Nur „fremde“ Methoden explizit blockieren (leichtes Start‑Muster)

location / {\n    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }\n    proxy_pass http://app;\n}\n

\n
• Entfernt sofort die häufigsten störenden Methoden.
\n
• Langfristig ist jedoch das Allowlist‑Muster (A) sicherer und wartungsfreundlicher.
\n

\n

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

\n

Fazit: „Nur erlaubte Methoden durchlassen“ erleichtert den Betrieb

Die Kernaussage ist einfach:

\n
• Fremde Methoden sind meist kein legitimer Traffic.
\n
• Durch das Senden an die App entstehen Kosten und unübersichtliche Logs.
\n
• Daher blockiert Nginx die nicht erlaubten Methoden mit 405/444.
\n

Durch die Anwendung eines dieser Muster:

\n
• Die App‑Ressourcen werden weniger belastet.
\n
• Die Logs bleiben sauber.
\n
• Der Betrieb wird deutlich einfacher.
\n