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

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 {#sec-7f5126fc3fdf}

`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 {#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 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? {#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:

* 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 mit zusätzlichen Methoden {#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 (leichter Einstieg) {#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. 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 {#sec-35fe67d750b5}

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