SiteGuard WP PluginのWAFチューニングサポートをConoHa WINGで検証

ConoHa WINGでWordPressを編集した際、保存できたように見えるのに、公開ページへ変更が反映されないことがありました。編集画面を開き直すと、WAFに反応したと思われる部分だけが消えている状態です。

そこで、SiteGuard WP Pluginの「WAFチューニングサポート」を使い、ConoHa WING環境でWAFの除外ルールを管理できるか検証しました。

結論からいうと、ConoHa WINGでも除外ルールの登録と反映はできました。ただし、実際に使うには、ConoHa WINGのWAFログに表示された日本語の内容に対応するシグネチャ名を調べて入力する必要があります。

今回使用した xss-tag-1 も、ConoHa WINGやSiteGuard WP Pluginの管理画面を見ただけでは分かりませんでした。公式案内を確認しても、日本語の表示名と入力すべきシグネチャ名の対応関係は判断できませんでした。

そのため、ConoHa WINGで一つの誤検知へ対応する目的なら、サーバー側のWAFログから直接除外する方が分かりやすく、WAFチューニングサポートを積極的に使う必要性は低いと感じています。

この記事は、ミコトホドのConoHa WING環境で行った検証記録です。WAFの除外は防御範囲を狭めるため、誤検知が確認できた対象だけに限定し、設定前にバックアップを取ってください。

WAFチューニングサポートの検証結果

確認項目	結果
WAFログの自動表示	表示されない。ConoHa WING側で確認が必要
日本語の攻撃内容名	そのままでは登録できない
xss-tag-1の登録	除外ルールとして登録できた
「ルールを適用」した結果	検証環境では.htaccessに除外記述が追加された
機能を無効にして再適用	.htaccessの記述は消え、登録したルールは管理画面に残った

SiteGuard WP Pluginの画面だけで、誤検知の確認から除外まで完結するわけではありません。

ConoHa WING側のWAFログを確認し、そこに表示された内容に対応するシグネチャ名またはシグネチャIDを別に用意する必要があります。

機能自体は動作しましたが、入力すべき名前を利用者が確認しにくいことが、今回の検証で最も大きな問題でした。

WAFチューニングサポートでできること

WAFチューニングサポートは、WAFに遮断された正常な操作を除外するためのルールを、WordPress管理画面から登録・編集・削除する機能です。

ここでいう除外とは、WAFが特定の内容を検知しても、そのルールに当てはまる操作を遮断しないようにする設定です。

ただし、WAFが検知した内容をSiteGuard WP Pluginの画面へ自動で集める機能ではありません。

除外するシグネチャ名またはIDは、サーバー側のWAFログなどで確認します。ルールを追加しただけでは反映されず、一覧画面の「ルールを適用」を実行する必要があります。

WAFチューニングサポートを利用できるかどうかや、ルールがどのように反映されるかは、契約しているサーバーの環境によって変わります。この記事では、ConoHa WINGで実際に確認できた結果を紹介します。

ConoHa WINGにも、WAFログに表示された攻撃内容を直接除外する機能があります。単発の誤検知へ対応するだけなら、ConoHa WING側から除外する方が手順は分かりやすいです。

検証用のscriptタグでWAFを反応させる

今回の検証では、投稿編集画面のカスタムHTMLブロックへ<script>を含む内容を入力し、意図的にWAFが反応する状態を作りました。

ConoHa WINGのWAFログには、「クロスサイトスクリプティング（タグ1）からの防御（<script）」として記録されました。

クロスサイトスクリプティング系の除外ルールを追加すると、WAFが本来遮断すべき攻撃まで通す可能性があります。この記事と同じルールを、検証せず実運用環境へ追加しないでください。

ConoHaの日本語表示名では登録できなかった

最初に、ConoHa WINGのWAFログに表示された「クロスサイトスクリプティング（タグ1）からの防御（<script）」を、そのままSiteGuard WP Pluginのシグネチャ欄へ入力しました。

この状態では登録できず、「シグネチャの指定が正しくありません。」と表示されました。

ConoHa WINGに表示される日本語名は、利用者がログの内容を確認するための説明です。SiteGuard WP Pluginへ登録するときに必要なシグネチャ名とは別のものでした。

つまり、ConoHa WINGの画面に表示された内容を、そのままコピーして登録することはできません。

xss-tag-1で除外ルールを登録できた

xss-tag-1は、WAFが検知した内容を区別するために使われる識別用の名前です。

ConoHa WINGでは攻撃内容が日本語で表示されますが、SiteGuard WP Pluginへの登録には、この日本語とは別の識別用の名前が必要でした。

今回の検証では、シグネチャ名へxss-tag-1を指定しました。こちらはエラーにならず、WAF除外ルールとして登録できました。

ただし、今回の日本語表示名とxss-tag-1の対応関係は、ConoHa WINGのログ画面やSiteGuard WP Pluginの設定画面だけでは確認できませんでした。

公式案内も確認しましたが、今回の日本語表示から対応するシグネチャ名を探せる一覧や、具体的な確認手順は見つけられませんでした。

xss-tag-1を知っていれば登録できます。しかし、その名前を知らない利用者が自力でたどり着くのは難しく、WAFチューニングサポートを使ううえで最も分かりにくい部分です。

xss-tag-1は、今回の検証で使用した名前です。別の操作や別の誤検知では異なる名前が必要になるため、この記事の値をそのまま登録しないでください。

ルールの適用で.htaccessに反映された

xss-tag-1を登録したあとに「ルールを適用」を実行すると、検証時のConoHa WING環境では.htaccessにSiteGuard_User_ExcludeSig xss-tag-1を含む記述が追加されました。

機能を無効にしてから再び「ルールを適用」すると、この除外記述は.htaccessから消えました。

ただし、管理画面に登録したルール自体は残ります。機能を再び有効にして適用すれば、登録済みの除外ルールをもう一度反映できます。

ここで説明している.htaccessへの反映は、検証時のConoHa WING環境で確認した結果です。ほかのサーバーでも、同じ画面や同じ反映方法になるとは限りません。

ConoHa WINGではサーバー側から直接除外する方が分かりやすい

ConoHa WINGでは、「サイト管理」から「サイトセキュリティ」「WAF」と進み、ログに記録された攻撃内容を直接除外できます。

こちらは、ログに表示された項目から除外操作を進められます。SiteGuard WP Pluginのように、日本語の表示名とは別のシグネチャ名を調べて入力する必要はありません。

WAFチューニングサポートには、除外ルールをWordPress側で一覧管理し、反映状態を切り替えられる利点があります。

しかし、肝心のシグネチャ名を確認できなければ、設定画面が用意されていても利用者だけでは先へ進めません。

複数の除外ルールをWordPress側でまとめて管理したい場合には利用価値があるかもしれません。ただし、それも正しいシグネチャ名が分かっていることが前提です。

ConoHa WINGで一つの誤検知へ対応する目的なら、サーバー側のWAFログから直接除外する方が分かりやすく、WAFチューニングサポートを使う必要性は低いと判断しました。

どちらの方法でも、除外範囲を必要以上に広げないことが重要です。SiteGuard側では対象ファイル名も指定できるため、実運用で登録する場合は、誤検知が起きた対象まで絞る必要があります。

まとめ｜動作はしたが、ConoHa WINGでは使いやすい機能ではなかった

SiteGuard WP PluginのWAFチューニングサポートは、ConoHa WINGでも除外ルールを登録し、反映できました。

ただし、WAFの検知内容を自動で表示する機能ではありません。ConoHa WING側でWAFログを確認し、対応するシグネチャ名またはIDを用意して登録する必要があります。

今回の検証では、ConoHa WINGに表示された日本語の攻撃内容名はそのまま登録できず、xss-tag-1を指定すると登録できました。

「ルールを適用」したあとの.htaccessへの反映と、機能を無効にしたときに除外記述が削除されることも確認しています。

機能そのものは動いています。しかし、今回使用したxss-tag-1は、ConoHa WINGやSiteGuard WP Pluginの画面を見ただけでは分かりませんでした。

設定欄が用意されていても、入力すべき名前を利用者が確認できなければ、使いやすい機能とはいえません。

一方、ConoHa WINGでは、WAFログに表示された項目から直接除外できます。一つの誤検知へ対応するだけなら、こちらの方が手順を理解しやすく、除外状態の確認や解除もしやすいです。

今回の検証では、WAFチューニングサポートがConoHa WINGで動作することは確認できました。ただし、一般的なWordPress利用者が積極的に使う必要性は低く、ConoHa WINGではサーバー側から直接除外する方が現実的だというのが最終的な判断です。