WordPressのセキュリティプラグインとして、SiteGuard WP PluginとIP Location Blockを確認しました。
どちらもWordPressの防御を強めるためのプラグインですが、守り方は同じではありません。
SiteGuard WP Pluginは、ログイン画面や管理画面まわりの保護に強いプラグインです。一方で、IP Location Blockは、国やIPアドレス、アクセス元をもとにした制御に寄ったプラグインです。
この記事では、まずSiteGuard WP PluginとIP Location Blockをざっくり比較します。
そのうえで、SiteGuard WP Pluginの中でも気になった「WAFチューニングサポート」について、実際に検証した内容を残します。
SiteGuard WP PluginとIP Location Blockは守り方が違う
SiteGuard WP PluginとIP Location Blockは、どちらもWordPressのセキュリティ対策として使われるプラグインです。
ただし、同じ目的で入れ替えるようなプラグインではありません。
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を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）」という表示名です。
この表示名を、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側の画面だけを見ても分かりませんでした。
日本語の攻撃内容名から、SiteGuard側で使うシグネチャ名を推測する必要があります。
ルールを適用すると.htaccessに除外記述が書き込まれた
SiteGuard WP PluginのWAFチューニングサポートでは、除外ルールを登録しただけでは実際の設定として反映されません。
一覧画面で「ルールを適用」ボタンを押す必要があります。
今回、xss-tag-1 を登録してルールを適用したあと、.htaccessの内容を確認しました。
すると、.htaccess内に以下のような記述が追加されていました。
この結果から、WAFチューニングサポートはWordPress管理画面内だけで完結する設定ではなく、.htaccessへWAF除外ルールを書き込む機能だと確認できました。
つまり、.htaccessをできるだけ触りたくない運用では、安易に使う機能ではありません。
一方で、登録済みの除外ルールをSiteGuard側で有効・無効にできる点は便利です。
無効にすると.htaccessから除外記述は消えた
WAFチューニングサポートを無効にしてから「ルールを適用」すると、.htaccess内の除外記述は削除されました。
今回の検証では、SiteGuard_User_ExcludeSig xss-tag-1 を含むSiteGuard側の除外記述が、.htaccessから消えることを確認しています。
ただし、SiteGuard WP Plugin側に登録した除外ルール自体は残ります。
つまり、必要なときは有効にして「ルールを適用」し、不要なときは無効にして「ルールを適用」することで、.htaccessへの反映を切り替えられます。
この点は便利でした。除外ルールを毎回作り直さなくても、WordPress側から有効・無効を切り替えられるためです。
WAFチューニングサポートで便利だった点
実際に使ってみて便利だと感じたのは、登録したWAF除外ルールをWordPress管理画面から確認できることです。
シグネチャ名、対象ファイル名、コメントを一覧で確認できるため、どの除外ルールを追加したのかを把握しやすくなります。
また、WAFチューニングサポートを無効にして「ルールを適用」すると、.htaccessから除外記述を外せる点も便利でした。
除外ルール自体はSiteGuard WP Plugin側に残るため、必要なときだけ有効にして使うことができます。
WAFチューニングサポートで使いにくかった点
一方で、WAFチューニングサポートは、WAFの誤検知対応を簡単にしてくれる機能とは言いにくいです。
WAFで止められた内容が、この画面に自動で一覧表示されるわけではありません。
除外ルールを作るには、サーバー側のWAFログなどを確認し、正しいシグネチャ名やシグネチャIDを自分で指定する必要があります。
さらに、ConoHa WINGのWAF履歴に表示される日本語の攻撃内容名を、そのまま入力しても登録できませんでした。
今回のように、「クロスサイトスクリプティング（タグ1）からの防御（<script）」を xss-tag-1 と読み替える必要があります。
確認した範囲では、SiteGuard WP Pluginの公式ページに、WAFチューニングサポートで使うシグネチャ名の一覧は見つけられませんでした。シグネチャ名を知っていることが前提になっているのに、その対応関係を確認しにくい点が、WAFチューニングサポートを使いにくいと感じた大きな理由です。
そのため、WAFチューニングサポートは、名前から受ける印象よりも手動で確認する部分が多い機能だと感じました。
ConoHa WING環境ではサーバー側のWAFログ確認が必要になる
今回の検証で分かったのは、ConoHa WING環境では、結局サーバー側のWAFログ確認が必要になるということです。
SiteGuard WP PluginのWAFチューニングサポートは、WAFで反応した内容を自動で拾ってくれる機能ではありません。
どの防御に反応したのか、どのシグネチャを除外すればよいのかは、自分で確認する必要があります。
その確認先として、ConoHa WINGのWAFログを見ることになります。
ただ、ConoHa WING側のWAFログを確認するのであれば、その画面から直接除外した方が分かりやすい場面もあります。
少なくとも今回の環境では、SiteGuard側にシグネチャ名を手入力して除外するより、ConoHa WING側のWAFログから確認・除外した方が直感的でした。
ただし、SiteGuard側でWAF除外ルールを管理できること自体には意味があります。
登録した除外ルールを一覧で確認でき、必要に応じて有効・無効を切り替えられるためです。
そのため、WAFチューニングサポートは「誰でも簡単に誤検知を解除できる機能」というより、「正しいシグネチャ名を理解したうえで、除外ルールをWordPress側から管理する機能」と考えた方が近いです。
まとめ：WAFチューニングサポートは使えるが、簡単ではない
SiteGuard WP PluginとIP Location Blockは、どちらもWordPressのセキュリティ対策として使えるプラグインです。
ただし、守る場所や考え方は同じではありません。
SiteGuard WP Pluginはログイン画面や管理画面まわりの保護に強く、IP Location BlockはIPアドレスや国・地域をもとにしたアクセス制御に寄ったプラグインです。
今回特に確認したかったのは、SiteGuard WP PluginのWAFチューニングサポートでした。
検証の結果、WAFチューニングサポートで登録した除外ルールは、ルール適用によって .htaccess に書き込まれることを確認しました。
また、WAFチューニングサポートを無効にしてルールを適用すると、.htaccess から除外記述が消えることも確認できました。
この点は便利です。登録した除外ルールをSiteGuard側に残したまま、必要なときだけ .htaccess に反映できます。
一方で、WAFチューニングサポートは、WAFで発生したエラーを一覧で表示してくれる機能ではありません。
ConoHa WINGのWAF履歴に表示される日本語の攻撃内容名を、そのまま入力しても登録できませんでした。
今回の検証では、「クロスサイトスクリプティング（タグ1）からの防御（<script）」に対して、xss-tag-1 というシグネチャ名を指定する必要がありました。
つまり、SiteGuard WP PluginのWAFチューニングサポートは、仕組みを理解して使えば便利です。
ただし、WAFログの確認、シグネチャ名の把握、.htaccessへの反映確認まで必要になるため、初心者が直感的に使える機能とは言いにくいです。
ConoHa WING環境では、WAFの誤検知対応だけを見るなら、サーバー側のWAFログから直接確認・除外した方が分かりやすい場面があります。
ただ、除外ルールをWordPress側で一覧管理し、有効・無効を切り替えたい場合には、WAFチューニングサポートにも使い道があります。
今回の検証では、便利な部分と分かりにくい部分の両方が見えました。
セキュリティプラグインは、入れれば終わりではありません。どこを守り、どこを書き換え、どの設定がサーバー側に影響するのかを確認して使う必要があります。
コメント