('

許可されたHTTPメソッドだけを通す：ノイズリクエストはNginxで405/444で切る

\n

運用中にウェブアプリケーションのログを tail すると、時折こんな瞬間が訪れます。

\n
    \n
  • 私は GET / POST / PUT / DELETE のみを使っていると信じていた
    • \n
  • ログには初めて見るメソッドがちらりと入っている
    • \n
\n

例えば PROPFIND などの WebDAV メソッドがログに現れます。アプリは「サポートしていないメソッド」として処理しますが、重要なのはこれです。

\n

本当にアプリにノイズまで処理させる必要があるのでしょうか？\n答えは通常「いいえ」です。そこで 許可されたメソッドだけを通し、残りは Nginx で前段で切る ことがきれいです。

\n
\n

なぜ Nginx でブロックするのか

\n

アプリレベルでブロックすることも可能です。しかしリクエストがアプリに届く瞬間にすでにコストが発生します。

\n
    \n
  • WSGI/ASGI エントリ
    • \n
  • ミドルウェア/ロギング/認証ロジックの一部が走る
    • \n
  • アプリログが汚れ、真の問題が埋もれる
    • \n
  • トラフィックが増えると不要な負荷が蓄積
    • \n
\n

対照的に Nginx でブロックすると：

\n
    \n
  • 最前段で即座に終了 → コスト最小
    • \n
  • アプリログがクリーン → 運用が楽になる
    • \n
  • 攻撃面が縮小 → 不要なメソッド自体を除外
    • \n
\n

一言でまとめると。

\n
\n

アプリは製品を作り、Nginxは門番の役割を果たす。

\n
\n
\n

ログに時折見える奇妙なメソッドはほとんど「正常使用」ではない

\n

PROPFIND などの DAV メソッドは「見た目が正しそう」な代表例です。

\n
    \n
  • WebDAV 機能が開いているか粗く確認するスキャニング
    • \n
  • 設定ミスで PUT/MKCOL などが開いていると次のステップへ進もうとする
    • \n
  • User-Agent が空、または HTTP/1.0 のように粗く投げるパターンもよく見られる
    • \n
\n

核心はこれ一つです。

\n

私たちのサービスがそのメソッドを使わないなら、正常トラフィックである理由はほぼない。\nその場合、アプリまで送って親切に応答する必要はありません。

\n
\n

戦略はシンプル：Allowlist（許可リスト）で運用する

\n

nginxというセキュリティオフィサーが出入り口を管理するイメージ

\n

原則は「必要なものだけを開き、残りは閉じる」です。

\n
    \n
  • 一般ウェブページ/静的リソース：通常 GET、HEAD で十分
    • \n
  • API：必要なエンドポイントにのみ POST/PUT/PATCH/DELETE を限定的に許可
    • \n
\n

そしてそれ以外のメソッド（例：PROPFIND、MKCOL、LOCK など）\n私たちが使わないなら全てブロック する方向が運用的に最も楽です。

\n
\n

405 vs 444：どの応答で切るか

\n

ブロックには大きく二つの方法があります。

\n

1) 405 Method Not Allowed

\n
    \n
  • 標準的で理解しやすい
    • \n
  • 正常クライアントが誤ったメソッドで来たときに「だめだ」と明確に知らせる
    • \n
\n

2) 444（Nginx専用：応答なしで接続終了）

\n
    \n
  • 何も言わずに切る
    • \n
  • スキャナー/ボットにヒントを与えない
    • \n
  • 運用観点で静かできれい（「ノイズは消す」）
    • \n
\n

実戦ではこう使い分けます。

\n
    \n
  • 公開ウェブで意味のないメソッド：444で静かに切る
    • \n
  • 正常クライアントがミスしやすいパス：405で明確に案内
    • \n
\n
\n

Nginx 設定例：許可メソッド以外を切る 2 つのパターン

\n

以下は「コピー＆ペーストで始めやすい」形で示しています。

\n

パターン A) 基本は GET/HEAD のみ、API は追加許可

\n
server {\n    # ... listen/server_name など ...\n\n    # 1) 基本：ウェブ/静的は GET/HEAD のみ許可\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # または 405\n        proxy_pass http://app;\n    }\n\n    # 2) API：必要なメソッドのみ許可\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
  • / はページ閲覧中心なので GET/HEAD だけで十分なケースが多い。
    • \n
  • /api/ は CORS のため OPTIONS が必要になることもあるので一緒に許可。
    • \n
\n

パターン B) 「奇妙なメソッド」だけを選んで明示的にブロック（軽い開始）

\n
location / {\n    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }\n    proxy_pass http://app;\n}\n
\n
    \n
  • 直ちに運用で見られるノイズメソッドを切る方式。
    • \n
  • ただし長期的には Allowlist（パターン A） の方が安全で管理しやすい。
    • \n
\n
\n

参考：if は Nginx で乱用すると危険だと言われることがありますが、\nこうした「即時 return の単純条件」は実務でかなり頻繁に使われます。\nより厳格にしたい場合は limit_except を使う方法もあります。

\n
\n
\n

結論：許可したものだけを通すことで運用が楽になる

\n

要点はシンプルです。

\n
    \n
  • 奇妙なメソッドはほとんど正常トラフィックではない
    • \n
  • アプリまで送るとコストが発生し、ログが汚れる
    • \n
  • だから Nginx で許可メソッドだけを残し、残りは 405/444 で切る
    • \n
\n

このパターンを一つ適用するだけで：

\n
    \n
  • アプリリソースが少なくて済む
    • \n
  • ログがきれいになる
    • \n
  • 運用がずっと楽になる
    • \n
', '/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png')