「WAF を入れておけば大丈夫」という説明を目にすることがある。しかし WAF（Web Application Firewall）もレート制限も、サイトの手前でリクエストを選り分ける仕組みであって、サイトの中にある弱点そのものを直すものではない。この記事では、WAF とレート制限が何をしているのか、得意なこと・苦手なこと、導入後に見落としやすい点を整理する。そのうえで、脆弱性への対処としては更新までの時間を稼ぐ手段と位置づけて考える。製品や契約によって機能は大きく異なるため、ここでは一般的な考え方に絞る。
WAF とは何か：サイトの手前に立つ「受付」
WAF は、ブラウザなどから届いたリクエストの中身を見て、通すか・止めるかを決める仕組みだ。サイトの入口に受付を置くイメージに近い。
置かれる場所はいくつかある。
- クラウド型（CDN などの手前）: サイトに届く前の段階で選り分ける。事業者のネットワーク側で動く
- サーバー側の機能: レンタルサーバーが標準で用意していることがある。契約や管理画面の設定で有効・無効が決まる
- プラグイン型: WordPress の中で動く。PHP が動き始めた後に判断するため、置かれる位置は上の2つより内側になる
どこに置かれるかで、見えるものと防げる範囲が変わる。自分のサイトでどれが動いているかは、まず把握しておきたい。
レート制限とは何か：回数で線を引く
レート制限は、リクエストの内容ではなく回数を見る。同じ接続元から一定時間に何回アクセスしたか、で通すかどうかを決める。
典型的な使いどころは、ログイン画面（wp-login.php）への繰り返し試行や、短時間に大量のアクセスを送りつけて負荷をかける行為への備えだ。内容が正当なパスワード入力に見えても、回数が不自然なら止められる。
WAF（内容を見る）とレート制限（回数を見る）は、別の観点の仕組みだ。製品によっては両方が一体になっている。
得意なこと
- 既知のパターンに合致する、明らかに不審なリクエストの遮断: よく知られた型のリクエストは、受付の段階で止められる
- ログイン試行の繰り返しの抑制: 回数で線を引くことで、機械的な試行の効率を下げられる
- アクセスログのノイズの削減: 日常的な探索の多くが入口で止まれば、ログが読みやすくなる。読み方はアクセスログの読み方の記事で扱った
- 更新までの猶予をつくる場合がある: 脆弱性が公表された直後、提供元がその悪用を止めるルールを配信することがある（「仮想パッチ」と呼ばれる）。ルールの有無や配信時期は製品と脆弱性ごとに異なり、保証されているわけではない
苦手なこと
次のものは、受付で選り分けるだけでは防ぎにくい。
- 正規のリクエストに見えるもの: 正しい形式で、権限のある操作のように届くものは、内容だけでは見分けられないことがある。サイト側の設計上の弱点を突くものがこれにあたる
- 盗まれた認証情報での正規ログイン: 本物のIDとパスワードで入られると、受付からは通常の利用者に見える
- 配布元が汚染された更新: 信頼している配布経路から届くものは、そもそも疑われにくい。サプライチェーン攻撃の記事で触れた類型だ
- すでにサイトの中に置かれてしまったもの: 入口の守りは、入った後のことには作用しない。疑われるときは初動の記事の順序で進める
- WAF を通らない経路: クラウド型の場合、サーバー本体へ直接つながる経路が開いていると、受付を素通りされる可能性がある。「WAF の手前にあるはず」という前提が、実際の構成で成り立っているかを確認したい
導入後に起きやすいつまずき
守りを強めるほど、正当な利用者を止めてしまう副作用も出やすい。
- 誤検知（フォールスポジティブ）: 編集画面での保存、REST API の呼び出し、画像のアップロード、決済や外部サービスからの通知などが、不審なものとして止まることがある。サイトの動作が突然おかしくなったとき、原因が WAF だったという例は珍しくない
- 共有された接続元での巻き添え: 同じ会社や施設のネットワークからのアクセスは、外から見ると同じ接続元に見えることがある。レート制限を厳しくすると、複数人の正当な利用が一緒に止まる
- 接続元の判定のずれ: CDN やプロキシを経由する構成では、サイト側が見ている「接続元」が、実際の利用者ではなく中継点になってしまうことがある。回数を数える対象がずれると、制限が効かない、あるいは全員が一緒に止まる、といった状況になる。構成に合わせた設定が必要だ
- 「検知のみ」で様子を見る選択: 多くの製品には、止めずに記録だけする運用がある。いきなり遮断に切り替えず、まず何が引っかかるかを見るほうが、誤検知に気づきやすい
動作を確かめるときの見方
設定したあとは、期待どおりに動いているかを確認する。ここでは読み取りだけの確認を挙げる。
- アクセスログで、止められた応答（403 や 429 など）の増減を見る: 設定の前後で、どの程度の件数が止められているかが分かる。HTTP ステータスの意味はHTTPステータスコードの記事で整理した
- 管理画面の通常操作を試す: 投稿の保存、画像のアップロード、プラグインの設定変更など、普段の作業が通るか
- ログに「止めた」記録が残る設定か: 後から振り返れるようにしておく
自分のサイトで外から攻撃を試すような確認は、事業者の規約に反したり、他の利用者へ影響したりするおそれがある。確認は、ログと通常操作の範囲で行うのが無難だ。
更新との関係：時間を稼ぐものであって、代わりにはならない
WAF やレート制限は、弱点そのものを取り除かない。弱点が残っている限り、受付をすり抜ける形のリクエストが成立する可能性は残る。ルールが追いつかない期間や、ルールの対象外の弱点もある。
だから位置づけは、次のように整理できる。
- 更新（パッチ）: 弱点を取り除く。やるべきこと
- WAF・レート制限: 更新までの間の被害を減らす可能性がある、追加の層
更新の時期の考え方は公開から悪用までの時間の記事、使っていないプラグインを減らす棚卸しはプラグイン削除の記事で扱った。守りを重ねることと、更新を怠らないことは両立させる。
限界と、知っておきたいこと
- 製品の機能・ルールの内容・更新頻度は、提供元と契約で大きく異なる。「入れた」ことと「自分のサイトが守られている」ことは別だ
- ルールが追いつかない弱点や、誤って止めてしまうケースはなくならない
- 「遮断の記録が少ない」ことは、攻撃が来ていないことの証明にはならない
まとめ
- WAF は内容、レート制限は回数を見て、サイトの手前で通すか止めるかを決める
- 既知の不審なリクエストやログイン試行の繰り返しには強いが、正規に見えるもの・盗まれた認証情報・配布元の汚染・すでに中にあるものには効きにくい
- 導入後は誤検知と接続元の判定のずれに注意し、まず記録のみで様子を見る選択もある
- 位置づけは、更新までの時間稼ぎとなりうる追加の層。更新の代わりにはならない
守りは一枚で完結させず、更新・棚卸し・権限の整理・バックアップと組み合わせて考えたい。