('

Alleen toegestane HTTP-methoden doorlaten: Nginx blokkeert ongewenste verzoeken met 405/444

\n

Tijdens het tailen van de logs van een webapplicatie komen we soms op dit moment.

\n
    \n
  • Ik dacht dat ik alleen GET / POST / PUT / DELETE gebruikte
  • \n
  • In de logs zie ik een methode die ik nog nooit eerder heb gezien
  • \n
\n

Bijvoorbeeld PROPFIND, een WebDAV-methode, verschijnt in de logs. De app zal het sowieso behandelen als een “niet-ondersteunde methode”. Maar het belangrijkste is dit:

\n

Moet een hardwerkende applicatie zich toch bezig houden met ruis? Het antwoord is meestal “nee”. Daarom is het schoon om alleen toegestane methoden door te laten en de rest in Nginx te blokkeren.

\n
\n

Waarom moet het in Nginx worden geblokkeerd?

\n

Je kunt het op applicatieniveau blokkeren, maar zodra een verzoek de app bereikt, is er al kosten.

\n
    \n
  • WSGI/ASGI wordt aangeroepen
  • \n
  • Middleware, logging, authenticatie draaien deels
  • \n
  • De app-log wordt vervuild, waardoor echte problemen verborgen blijven
  • \n
  • Bij hoge traffic ontstaat onnodige belasting
  • \n
\n

Blokkeer je het in Nginx:

\n
    \n
  • Direct in de eerste lijn → minimale kosten
  • \n
  • App-logs blijven schoon → eenvoudiger beheer
  • \n
  • Aanvalsoppervlak verkleint → onnodige methoden worden geëlimineerd
  • \n
\n

Kort samengevat:

\n
\n

De app bouwt het product, Nginx fungeert als de poortwachter.

\n
\n
\n

Onbekende methoden in de logs zijn meestal geen “normaal gebruik”

\n

PROPFIND is een typische WebDAV-methode.

\n
    \n
  • Een scan die controleert of WebDAV is ingeschakeld
  • \n
  • Als PUT/MKCOL per ongeluk open staat, probeert de scanner verder te gaan
  • \n
  • Een lege User‑Agent of een vage HTTP/1.0‑verzoek komt vaak voor
  • \n
\n

Het belangrijkste punt:

\n

Als onze service die methode niet gebruikt, is het vrijwel zeker geen legitieme traffic. Dus waarom de app laten reageren?

\n
\n

Strategie: een allowlist gebruiken

\n

Nginx als beveiligingsagent die de poort beheert

\n

Het principe is simpel: open alleen wat nodig is, sluit de rest.

\n
    \n
  • Standaard webpagina’s/ statische bronnen: meestal GET en HEAD
  • \n
  • API: alleen POST/PUT/PATCH/DELETE op de noodzakelijke eindpunten
  • \n
\n

Alle andere methoden (bijv. PROPFIND, MKCOL, LOCK) worden volledig geblokkeerd als we ze niet gebruiken.

\n
\n

405 vs 444: welke respons gebruiken?

\n

Blokkering kan op twee manieren:

\n

1) 405 Method Not Allowed

\n
    \n
  • Standaard, duidelijk voor legitieme clients
  • \n
  • Geeft aan dat de methode niet is toegestaan
  • \n
\n

2) 444 (Nginx‑specifiek: geen respons, verbinding sluiten)

\n
    \n
  • Sluit zonder bericht
  • \n
  • Geeft minder hints aan scanners/bots
  • \n
  • Rustig en schoon voor het beheer (verwijdert “ruis”)
  • \n
\n

In de praktijk:

\n
    \n
  • Onzinnige methoden op een publieke site: 444
  • \n
  • Legitieme clients die per ongeluk een fout maken: 405
  • \n
\n
\n

Nginx‑configuratie‑voorbeeld: “alleen toegestane methoden” – twee patronen

\n

Hieronder vind je een startpunt dat je meteen kunt kopiëren.

\n

Patroon A) Standaard: alleen GET/HEAD, API extra toestaan

\n
server {\n    # ... listen/server_name etc. ...\n\n    # 1) Standaard: web/ statische bestanden alleen GET/HEAD\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # of 405\n        proxy_pass http://app;\n    }\n\n    # 2) API: alleen noodzakelijke 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
    \n
  • / is meestal voldoende met alleen GET/HEAD voor pagina’s.
  • \n
  • /api/ vereist vaak OPTIONS vanwege CORS.
  • \n
\n

Patroon B) Alleen “vreemde” methoden expliciet blokkeren (lichtgewicht start)

\n
location / {\n    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }\n    proxy_pass http://app;\n}\n
\n
    \n
  • Verwijdert meteen de meest voorkomende “ruis”‑methoden.
  • \n
  • Op de lange termijn is Allowlist‑methode (Patroon A) veiliger en makkelijker te beheren.
  • \n
\n
\n

Opmerking: if in Nginx kan riskant zijn, maar voor een eenvoudige “direct return” is het gangbaar. Voor strengere controle kun je limit_except gebruiken.

\n
\n
\n

Conclusie: “Alleen toegestane methoden” maakt beheer eenvoudiger

\n

De kern is simpel:

\n
    \n
  • Onbekende methoden zijn meestal geen legitieme traffic
  • \n
  • Door ze naar de app te sturen, ontstaan extra kosten en rommelige logs
  • \n
  • Blokkeer in Nginx met 405/444 en laat alleen de noodzakelijke methoden doorgaan
  • \n
\n

Met één patroon kun je:

\n
    \n
  • Minder belasting op de app
  • \n
  • Schone logs
  • \n
  • Eenvoudiger beheer
  • \n
', '/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png')