現在ミコトホドでは、セキュリティ対策としてSiteGuard WP PluginとIP Location Blockを使っています。
どちらもWordPressの防御を強めるためのプラグインですが、守り方は同じではありません。SiteGuard WP Pluginはログイン画面や管理画面まわりの保護に強く、IP Location Blockは国やIPアドレス、アクセス元をもとにした制御に寄ったプラグインです。
この記事では、2つのプラグインの違いをざっくり見たうえで、SiteGuard WP Pluginの中でも気になった「WAFチューニングサポート」を実際に検証した内容を残します。.htaccessへの書き込み、シグネチャ指定、有効・無効を切り替えたときの挙動まで見ているので、同じところが気になっている方は、よければこのまま読み進めてみてください。
なお、この記事はミコトホドで使っているConoHa WING環境での検証記録です。ほかのサーバーでは、WAFログの表示名や除外方法、.htaccess への反映のされ方が違うこともあります。
SiteGuard WP PluginとIP Location Blockは守り方が違う
SiteGuard WP PluginとIP Location Blockは、同じ目的で入れ替えるようなプラグインではありません。
SiteGuard WP Pluginは、ログインページ変更、画像認証、ログインロック、管理ページアクセス制限など、WordPressのログインまわりを守る機能が中心です。一方で、IP Location Blockは、IPアドレスや国・地域などをもとにアクセスを制御する方向のプラグインです。
そのため、「どちらが上か」ではなく、「どこを守りたいか」で見る方が分かりやすいです。
- ログイン画面や管理画面まわりを分かりやすく守りたいなら、SiteGuard WP Pluginが候補になります。
- 国やIPアドレスを使ってアクセス元を絞りたいなら、IP Location Blockが候補になります。
- WAFの誤検知や除外設定まで見るなら、サーバー側のWAF設定との関係も確認が必要です。
WAFは保存エラーとして分かりやすく出るとは限らない
WordPressを運用していると、WAFが原因で保存や設定変更がうまく反映されないことがあります。分かりやすい場合は編集画面にエラーが表示され、その場で「これは保存できていない」と気づけます。
ただ、自分の環境では少しややこしい出方をしました。画面上では保存できたように見えるのに、プレビューや公開ページを確認すると変更が反映されていない。さらに編集画面を開き直すと、WAFに反応したと思われる部分だけが消えていることもありました。
この挙動は、一見するとキャッシュの影響にも見えます。表示が変わらないと、まずキャッシュクリアを試したくなりますが、原因がWAFならキャッシュを消しても解決しません。
保存したはずの内容が反映されない、設定変更後の挙動がおかしい、編集画面を開き直すと内容が消えている。そういうときは、キャッシュだけでなくWAFも疑った方がいいです。
WAFが原因かどうかを確認するには、サーバー側のWAFログを見る必要があります。ログに該当する攻撃内容が残っていれば、どの防御に反応したのかを確認できます。
ただ、WAFログへの反映に少し時間がかかることもあります。急ぎの作業では、一時的にWAFをOFFにして保存し、すぐONへ戻す対応をしたこともありました。
これは緊急回避としては仕方ない場面もありますが、WAFを止めている時間が一瞬でも、セキュリティ上は理想的な対応ではありません。
だからこそ、WAFの誤検知に対して、必要なものだけを除外できる仕組みがあるなら使いやすいはずです。そこで気になったのが、SiteGuard WP Pluginの「WAFチューニングサポート」でした。
WAFチューニングサポートはエラー一覧を表示する機能ではない
SiteGuard WP Pluginには、WAFチューニングサポートという機能があります。
名前だけを見ると、WAFで止められた内容をWordPress管理画面に一覧表示して、そこから簡単に除外できる機能のようにも見えます。正直、自分も最初はそれに近いものを想像していました。
しかし、実際にはそういう機能ではありません。WAFチューニングサポートは、WAFが反応したエラーを自動で集める機能ではなく、自分で確認したシグネチャ名やシグネチャIDを登録して、除外ルールを作るための機能です。
つまり、どの防御に反応したのかは、サーバー側のWAFログで確認する必要があります。
この時点で、ConoHa WINGのWAFログから直接除外する場合とは、かなり使い勝手が違うと感じました。
シグネチャ名・シグネチャIDは、WAFが「どの攻撃パターンに反応したか」を識別するための名前や番号です。WAF除外ルールでは、日本語の説明名ではなく、この識別名を指定する必要があります。
検証にはクロスサイトスクリプティング系のWAFエラーを使った
今回の検証では、ConoHa WING側のWAFログに表示された「クロスサイトスクリプティング（タグ1）からの防御（<script）」を使いました。
検証用として、投稿編集画面に <script> を含む内容を書き込み、あえてWAFが反応する状態を作っています。実際にWAFが反応すると、ConoHa WINGのWAFログには攻撃内容として記録されました。
カスタムHTMLブロックには、以下のようなコードを入力しています。
ConoHaの攻撃内容名をそのまま入力しても登録できなかった
まず、ConoHa WINGのWAFログに表示されていた攻撃内容名を、そのままSiteGuard WP PluginのWAF除外ルールに入力してみました。
今回の場合は、「クロスサイトスクリプティング（タグ1）からの防御（<script）」という表示名です。ConoHa WING側では、このように日本語の攻撃内容名として表示されていました。
この表示名を、SiteGuard WP Pluginのシグネチャ欄へそのまま入力しました。
しかし、この入力では登録できませんでした。SiteGuard側では「シグネチャの指定が正しくありません。」というエラーが表示されます。
つまり、ConoHa WINGのWAFログに表示される日本語の攻撃内容名を、そのままSiteGuard側のシグネチャとして使えるわけではありません。SiteGuard WP Pluginで除外ルールを作るには、SiteGuard側が認識するシグネチャ名を指定する必要があります。
xss-tag-1を指定してWAF除外ルールに追加した
次に、シグネチャ名として xss-tag-1 を指定してみました。すると、SiteGuard WP Plugin側でWAF除外ルールとして登録できました。
今回のConoHa WING側の表示は「クロスサイトスクリプティング（タグ1）からの防御（<script）」です。これをSiteGuard側では、xss-tag-1 というシグネチャ名で指定する必要がありました。
今回のケースでは、「クロスサイトスクリプティング」を「XSS」、「タグ1」を tag-1 として扱う形でした。ただ、この対応関係はConoHa WINGのWAFログ画面だけを見ても分かりません。
日本語の攻撃内容名から、SiteGuard側で使うシグネチャ名を探す必要があります。ここは、WAFチューニングサポートを使ううえでかなり引っかかりやすいところです。
ルールを適用すると.htaccessに除外記述が書き込まれる
SiteGuard WP PluginのWAFチューニングサポートでは、除外ルールを登録しただけでは .htaccess には反映されません。登録後に、一覧画面で「ルールを適用」する必要があります。
今回、xss-tag-1 をWAF除外ルールに追加してから「ルールを適用」し、そのあと .htaccess の内容を確認しました。
すると、.htaccess 内に以下のような記述が追加されていました。
この結果から、WAFチューニングサポートはWordPress管理画面内だけで完結する設定ではなく、.htaccess へWAF除外ルールを書き込む機能だと分かります。
つまり、.htaccess をできるだけ触りたくない運用では、安易に使う機能ではありません。ただ、除外ルールをWordPress側で管理できるという意味では、使い道のある機能だと感じました。
WAFチューニングサポートで便利だった点
実際に使ってみて便利だと感じたのは、登録したWAF除外ルールをWordPress管理画面から確認できることです。
シグネチャ名、対象ファイル名、コメントを一覧で見られるため、どの除外ルールを追加したのかを把握しやすくなります。.htaccess に直接書き込まれた内容だけを見るより、WordPress側に管理画面がある方が確認しやすいです。
また、WAFチューニングサポートを無効にしてから「ルールを適用」すると、.htaccess から SiteGuard_User_ExcludeSig xss-tag-1 を含む除外記述は消えていました。
ただし、SiteGuard WP Plugin側に登録したWAF除外ルール自体は残ります。つまり、必要なときは有効にして .htaccess に反映し、不要なときは無効にして外す、という使い方ができます。
除外ルールを毎回作り直さなくても、WordPress側から反映状態を切り替えられる。この点は、実際に触ってみて便利だと感じました。
WAFチューニングサポートで使いにくかった点
一方で、WAFチューニングサポートは、WAFの誤検知対応を簡単にしてくれる機能とは言いにくいです。
一番使いにくいと感じたのは、正しいシグネチャ名やシグネチャIDを自分で調べて入力する必要があるところでした。WAFで止められた内容が、SiteGuard WP Pluginの画面に自動で一覧表示されるわけではありません。
さらに、ConoHa WINGのWAFログに表示される日本語の攻撃内容名を、そのまま入力しても登録できませんでした。今回のように、「クロスサイトスクリプティング（タグ1）からの防御（<script）」を xss-tag-1 として指定する必要があります。
確認した範囲では、SiteGuard WP Pluginの公式ページに、WAFチューニングサポートで使うシグネチャ名の一覧は見つけられませんでした。シグネチャ名を知っていることが前提になっているのに、その対応関係を確認しにくい点が、WAFチューニングサポートを使いにくいと感じた大きな理由です。
名前から受ける印象よりも、手動で確認する部分が多い機能です。便利ではありますが、初めて触る人が迷わず使えるタイプの機能ではありません。
ConoHa WING環境ではサーバー側のWAFログ確認が必要になる
今回の検証で分かったのは、ConoHa WING環境では、SiteGuard WP PluginだけではWAFの誤検知対応は完結しないということです。
どの防御に反応したのかは、ConoHa WING側のWAFログで確認する必要があります。そこまで確認するなら、ConoHa WING側の画面から直接除外した方が分かりやすい場面もあります。
少なくとも今回の環境では、SiteGuard側にシグネチャ名を手入力して除外するより、ConoHa WING側で確認・除外した方が直感的でした。
一方で、SiteGuard側でWAF除外ルールを管理できること自体には意味があります。登録した除外ルールを一覧で確認でき、必要に応じて有効・無効を切り替えられるためです。
そのため、WAFチューニングサポートは「誰でも簡単に誤検知を解除できる機能」というより、「正しいシグネチャ名を確認したうえで、除外ルールをWordPress側から管理する機能」と考えた方が近いです。
まとめ：WAFチューニングサポートは使えるが、簡単ではない
今回確認したかったのは、SiteGuard WP PluginのWAFチューニングサポートが、実際にどこまで使いやすい機能なのかという点でした。
検証してみると、WAF除外ルールをWordPress側で管理し、必要なときだけ .htaccess に反映できることは分かりました。この仕組み自体は便利です。
ただし、WAFチューニングサポートは、WAFで発生したエラーを自動で一覧表示してくれる機能ではありません。ConoHa WING環境では、WAFログを確認し、正しいシグネチャ名を指定する必要があります。
つまり、WAFチューニングサポートは仕組みを理解して使えば便利ですが、初心者が直感的に使える機能ではありません。WAFログの確認、シグネチャ名の把握、.htaccess への反映まで見る必要があります。
ConoHa WING環境では、WAFの誤検知対応だけを見るなら、サーバー側のWAFログから直接確認・除外した方が分かりやすい場面があります。
それでも、除外ルールをWordPress側で一覧管理し、有効・無効を切り替えたい場合には、WAFチューニングサポートにも使い道があります。
今回の検証では、便利な部分と分かりにくい部分の両方が見えました。セキュリティプラグインは、入れれば終わりではありません。どこを守り、どこを書き換え、どの設定がサーバー側に影響するのか。そこまで見ておかないと、あとで自分が困ることになります。
コメント