WAF（Web Application Firewall）は、Webサイトへ届くHTTP通信をルールと照合し、攻撃と判断した要求を遮断する仕組みです。レンタルサーバーでは管理画面から有効にできることがありますが、スイッチをONにしただけでWebサイトの安全対策が完了するわけではありません。

WAFが検査する範囲と、WordPress更新など別に必要な対策を分けることが大切です。有効化するときは、対象ドメインと現在の設定を記録します。その後に公開ページだけでなく、フォーム送信や記事保存など正規の操作が止まらないことまで確認します。

WAFはWebサイトへ届くHTTP通信を検査する

一般的なファイアウォールは、IPアドレスやポート番号などを基準にネットワーク通信を制御します。WAFはその内側にあるHTTPリクエストのURL・ヘッダー・入力値などを調べます。OWASPの説明では、WAFをHTTPアプリケーションへルールを適用するファイアウォールと位置付けています。

代表的な対象は、SQLインジェクションやクロスサイトスクリプティングのように、Webアプリケーションへ不正な文字列を送る攻撃です。WAFは既知の攻撃パターンと通信を照合し、条件に一致した要求を記録または遮断します。レンタルサーバー側で共通ルールが更新されるサービスなら、自社で一からルールを書く必要はありません。

保護されるのは、WAFを通るWeb通信です。メール、SSH、サーバー管理画面が同じWAFで守られるとは限りません。CDNの前段にWAFがある場合と、Webサーバー内で動く場合でも、ログの場所や保護対象が変わります。

WAFだけでは直せない問題がある

WAFは、WordPress本体やプラグインに残る脆弱性そのものを修正しません。攻撃に使われそうな通信を前段で止める防御層です。WordPress・テーマ・プラグインの更新と、不要な機能の削除は別に続けます。

利用者ごとの閲覧権限や、注文金額を変更できてしまう業務ロジックの欠陥は、通信の文字列だけでは判定できないことがあります。OWASPのテストガイドでも、WAFはSQLインジェクションやXSSには有効な一方、アクセス制御や業務ロジックの問題には効果が限定されると説明されています。

管理者パスワードの漏えい、改ざん済みファイル、端末のマルウェアもWAFだけでは解決できません。二要素認証・バックアップ・ファイル監視・アクセス権限を組み合わせます。「WAFあり」という表示は、安全性を保証する認証ではなく、複数ある対策の一つと考えます。

有効化する前に対象と戻し方を確認する

最初に、どのドメインとサブドメインへWAFを適用するかを確認します。同じ契約内でも、会社サイト・テストサイト・業務システムで設定が分かれることがあります。管理画面の現在値と作業時刻を残し、無効へ戻したときの反映時間もサーバー会社の案内で調べます。

次に、検知だけを行うモードやログ表示があるかを確認します。観察モードを利用できる場合は、先に遮断せず一致した通信を記録し、正常な操作への影響を調べます。利用できない場合は、アクセスが少ない時間帯に有効化し、確認担当者がすぐ戻せる状態で進めます。

WAF設定の変更前に必要なのは、Webサイト全体の復元バックアップだけではありません。設定値・対象・作業者・変更時刻を記録し、WAFだけを元へ戻せる手順を残します。サイト更新とWAF有効化を同時に行わなければ、403などが出たときに原因を切り分けやすくなります。

公開ページより入力を伴う操作を重点的に試す

WAFは入力内容を検査するため、ページを開くだけの確認では誤検知を見つけられません。問い合わせフォームへ通常の文章を入力し、確認画面・送信完了・通知メールまで進めます。ファイル添付がある場合は、業務で使う形式と容量のテストデータも試します。

WordPress管理画面では、記事の保存・画像アップロード・プラグイン設定の更新を確認します。予約やEC機能があるサイトでは、テスト環境で実際の入力経路を再現します。本番でテスト注文を行う場合は、業務データと区別できる内容にし、終了後の処理も決めておきます。

管理者としてログインしているブラウザーだけでなく、ログアウトした状態やスマートフォンからも代表ページを開きます。キャッシュされたページはWAF有効化前の内容を返すことがあるためです。確認したURL・操作・結果を作業記録へ残します。

正常な操作が止まったら該当ルールを絞る

正規のフォーム送信が403になる場合は、WAF全体をすぐ無効にする前に発生時刻とURLを記録します。入力内容・HTTPメソッド・利用者の接続元も、個人情報を含まない範囲で控えます。WAFログにルール番号や検知理由があれば、同じ時刻の記録と照合します。

除外設定が利用できる場合は、対象URLや該当ルールなど必要な範囲だけを調整します。サイト全体を恒久的に除外すると、別のページまで保護を失います。サーバー会社へ相談するときは、再現時刻・対象URL・ルール番号・正規の操作である理由を伝えます。

ログには攻撃文字列・Cookie・クエリ文字列が含まれる可能性があります。全ログをメールへ貼らず、必要部分から認証情報と個人情報を伏せます。調査中に一時的にWAFを無効にした場合は、代替のアクセス制限と再有効化する時刻を決めます。

サイト更新後も検知ログと業務機能を見直す

テーマやプラグインの変更によって、送信されるリクエストの形が変わることがあります。以前は問題のなかったWAFルールでも、新しい入力項目に反応するかもしれません。大きなサイト更新後は、初回有効化と同じフォーム・保存・アップロードを再確認します。

検知件数が多いだけで攻撃が成功したとは限りません。遮断された要求と通過した要求を分け、WebサーバーやWordPressのログも合わせて確認します。反対に、検知がないことも脆弱性がない証明にはなりません。

WAFの運用記録には、対象ドメイン・モード・除外ルール・最終確認日・担当者を残します。除外が増えたときは、現在も必要かを定期的に見直します。WAFを有効に保ちながら、更新と認証とバックアップを別の対策として続けることが、会社サイトの現実的な守り方です。