# 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.

* 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 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? {#sec-b5d4f5f6dfc2}

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

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

Im Gegensatz dazu:

* **Sofortiges Beenden an der Front** → minimale Kosten
* **Saubere App‑Logs** → einfachere Wartung
* **Reduzierter Angriffsvektor** → 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 {#sec-7f5126fc3fdf}

`PROPFIND` ist ein typisches Beispiel.

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

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

---

## Strategie: Allowlist (Erlaubnisliste) anwenden {#sec-84ef31ae1a20}

![Nginx als Sicherheitswache](/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png)

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

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

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

---

## 405 vs 444: Welche Antwort wählen? {#sec-967ed2222242}

Es gibt zwei Hauptansätze.

### 1) 405 Method Not Allowed {#sec-c79f33550d87}

* 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) {#sec-fe4e18cb7c1d}

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

In der Praxis wird oft folgendes gewählt:

* 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“ {#sec-3c7629273a8a}

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

### Muster A) Standard: GET/HEAD, API‑Spezialzugriff {#sec-42bc13636133}

```nginx
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 (leichtes Start‑Muster) {#sec-fa0b2940f799}

```nginx
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, aber bei einfachen „return“‑Bedingungen sind sie in der Praxis üblich. Für strengere Regeln kann `limit_except` verwendet werden.

---

## Fazit: „Nur erlaubte Methoden durchlassen“ erleichtert den Betrieb {#sec-35fe67d750b5}

Die Kernaussage ist einfach:

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

Durch die Anwendung eines dieser Muster:

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