WAF(Web Application Firewall)は、Webサイトへ送られる通信の内容を調べ、攻撃の疑いがあるリクエストを止める機能です。例えば、入力欄からデータベースへ不正な命令を送るSQLインジェクションなどへの対策になります。
レンタルサーバーに付属していれば、管理画面で有効にできる場合があります。ただし、WAFがあるだけですべての攻撃を防げるわけではありません。正常なフォーム送信まで止まることもあるため、守る範囲と誤検知の両方を知っておくと扱いやすくなります。
WAFは通信の中身を見る
一般的なファイアウォールがIPアドレスやポート番号などを基準に通信を制御するのに対し、WAFはURL、ヘッダー、送信された入力値など、Webアプリケーションへの通信を調べます。OWASPの解説も、このHTTP通信へルールを適用する役割を説明しています。
フォームの入力に攻撃で使われる文字列が含まれていれば、アプリケーションへ届く前に遮断できる場合があります。サービスによっては検知だけを記録する設定もあります。利用者が一からルールを書く方式と、サーバー会社が用意・更新するルールを使う方式は、必要な管理作業が異なります。
保護の対象は、そのWAFを通る通信です。WebサイトのWAFを有効にしても、メールやSSH、契約管理画面まで同じ機能で守られるとは限りません。CDN上のWAFを使う場合も、CDNを経由せず元のサーバーへ接続できる構成では、別の入口が残ることがあります。
WordPressの更新とは役割が違う
WAFは、不具合のあるプラグインを修正する機能ではありません。攻撃に使われる通信を前段で減らすもので、WordPress本体やテーマ、プラグインの更新は別に必要です。
また、漏れたパスワードで正しくログインされた場合や、本来見せてはいけない情報をアプリケーションが表示してしまう場合は、文字列の検査だけで防げるとは限りません。認証や閲覧権限、入力処理そのものの対策も関係します。
営業目的の問い合わせも同様です。正しい形式で入力された営業文面を、WAFが業務上不要だと判断してくれるわけではありません。フォームの迷惑投稿対策とは、役割を分けて考える方が良いです。
正常な操作が止まることもある
WAFのルールは、攻撃だけに完全に一致するとは限りません。記事にコードの例を書いたり、フォームへ特定の記号を入力したりしたときに、正常な操作が攻撃に似て見えることがあります。これが誤検知です。
有効化した後は、ページの表示だけでなく、記事の保存や通常のフォーム送信まで試すと影響を見つけやすくなります。決済や予約があるサイトなら、実取引を発生させないテスト方法で確認します。テーマなどの更新と同時にWAF設定も変えると、問題が出たときに原因を分けにくくなります。
設定後に403などが出ても、それだけでWAFが原因とは断定できません。アクセス権限や別の制限でも同じ応答になるため、発生時刻とURLに対応するWAFログが手掛かりになります。
誤検知は対象を絞って調整する
正常な送信を止めた記録が見つかったら、ルール番号や対象URLをもとに調整します。URL単位やルール単位の除外が使えるかはサービスによって異なります。自分で範囲を絞れない場合は、時刻・URL・行っていた操作をサポートへ伝えると調べやすくなります。
サイト全体を無効にし続けると、問題のなかったページまで保護を失います。一時停止が必要な場合も、停止する範囲と期間を限定し、調整後に再び有効にする前提で扱います。入力内容やログを共有する際は、パスワードや個人情報をそのまま送らないでください。
検知件数が多いことと、被害が発生したことも別です。遮断できた通信が大量に記録されることはあります。反対に、記録がないことも安全の証明ではありません。WAFは更新や認証管理を補う対策であり、正常な操作を残しながら使うことが重要です。