403 Forbidden誤認対策、WAFチューニングサポートのルール追加！WordPressサイトガードの設定

WAFがどのような攻撃を防いでいるのか、誤認で403 Forbiddenを出した行動をWAFチューニングサポートのルールに追加し誤認を減らす・なくす方法をご紹介。

ロリポップ・さくら・へテムルなどのレンタルサーバーを使用していて、WordPress管理画面からの更新で403 Forbiddenが出る原因は、サーバーの使用しているWAF（ウェブ アプリケーション ファイアウォール）ワフの誤認が大半です。

サーバーが導入しているセキュリティが外部攻撃と認識してステータスコード403番であるForbidden：ページの閲覧禁止した状態です。一時的な解決方法は下記。

LINKWordPress403 Forbiddenの原因はWAF！対処し解決する方法！：ロリポップ、さくら、ヘテムルのサーバー

最近は1度403 Forbidden閲覧禁止にした行動に対し、くり返し403を出すので、運営者としてはちょっと迷惑…。外部攻撃を未然に防いでいるWAFについて・誤認を防ぐ方法を紹介します。

攻撃の脅威と、セキュリティWAFの効果

WordPressはオープンソースの人気が高いブログサービスです。そのプログラムに脆弱性：セキュリティ上の穴があれば、情報は一気にが広ります。

• 不正ログイン
• ファイルの改ざん
• データベースの乗っ取り・改ざん
• あなたのサイトを踏み台に、悪意ある攻撃をばらまくなど
• EC（お買い物）サイトの場合はお客様のクレジット情報が盗まれたり…

LINK管理画面から更新で403 ERROR Forbidden！WAFの誤認を初心者向けに、ストーリーにして説明

一般人の私たちより遥かに知識を持った天才であろう攻撃者からの、これら攻撃を未然に防いでくれるのがファイアーウォールWAF、Web上に特化したサーバーが導入しているセキュリティです。

上記の初心者向け説明を、一般的な言葉で言えば下記。

対応する主な脅威（攻撃手法）

• SQLインジェクション
• クロスサイトスクリプティング
• ディレクトリトラバーサル
• OSコマンドインジェクション
• HTTPヘッダインジェクション
• ブルートフォース（ログインアタック等）
• Apache Killer
• hasdos
• ShellShock　等

防御機能

• トラステッド・シグネチャ検査（ブラックリスト、自動更新・手動更新）
• カスタム・シグネチャ検査（ブラックリスト、ホワイトリスト、頻度判定）
• Cookie保護（シグネチャ検査）
• URLデコードエラー検出
• パラメータ数制限

引用元：ホスト型WAF「SiteGuard Lite」｜JP-Secure

これらの攻撃を未然に防いでくれるのがWAFのセキュリティ・パワーです。私の環境でもWAFに守られた経験があります。

LINKWAFがディレクトリトラバーサルの攻撃からWordPress、ブログを守るために出来ること

サーバーのセキュリティWAFを切っていて、攻撃が例えば1年続いていれば確実に突破されていたでしょね＞＜

403誤認対策！WAFチューニングサポート

ロリポップ・さくら・ヘテムルなどのサーバーが使用しているセキュリティWAFを有効にしていると安心度が高い、その凄さは分かってもらえましたよね。

運営者の更新で誤認の403 Forbiddenを出したとき、WAFが検知したログが残る仕組みになってます。そのログに残されたシグネチャをルールに追加すれば、以降その行動（プレビューのクリック・画像の導入・その他の更新など）で誤認の403は出ません。

WAFチューニングサポート、新しいルールの設定

WAFチューニングサポートを『ON』にして『新しいルールを追加』という項目から、シグネチャにWAF除外ルールを追加し保存することで、誤認の403 Forbiddenページを出さない設定にできます。

追加する項目はサーバーにあるWAFのエラーログ。WAF設定のログ参照で確認できる『xss-try-4』を、このシグネチャ欄にコピペして『保存』するだけでxss-try-4のルール除外を.htaccessに書いてくれます。

ロリポップWAFが誤認したシグニチャxss-try-4

アクセス元IPは自分のIPアドレスのものだけを追記するので、使用中のIPアドレス確認｜CMANなどでIPを確認してくださいね。

.htaccessに追記された広告は下記。

#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_START
<IfModule mod_siteguard.c>
        SiteGuard_User_ExcludeSig xss-try-4
</IfModule>
#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_END

xss-try-4が除外ルールとなってるワケです。管理画面でコピペするだけでWAFの誤認からまぬがれるのは、運営者にとってスペシャル機能かも…。

WAFはセキュリティ面のメリットが大きい反面、誤認が面倒。これで誤認が1つ減りますね。

追記：投稿画面からプレビューをクリックしたとき、WAFの誤認によるシグネチャsqlinj-55・xss-tag-1が検出されたので追加しました。

#SITEGUARD_PLUGIN_SETTINGS_START
#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_START
<IfModule mod_siteguard.c>

SiteGuard_User_ExcludeSig xss-tag-1

SiteGuard_User_ExcludeSig sqlinj-55

SiteGuard_User_ExcludeSig xss-try-4

</IfModule>
#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_END
#SITEGUARD_PLUGIN_SETTINGS_END

『誤認の403 Forbidden』は、WAFのエラーログで見ることができます。

403ページが出たらレンタルサーバーでWAF設定をオフにした後『ログ参照』を見て、コードをサイトガードのこの設定のルールに書き込めば、WAFの誤認は減ります。

WAFの誤認、どうにかならないかとサーバーに聞いたら、.htaccessに書けば問題なし。と言われました。.htaccessに抵抗があるなら、オススメ設定です！

ただプラグイン同士のエラーなどで、サイトガードプラグインを削除したら、設定したルールも消えます（対処法は後述）。

ファイル名の追加について

誤認による403の行動は例えばpost.phpファイルからの誤認のみ解除。などファイル単位でルールを追加することも可能です。

ただそれを行ったとき、WAFの誤認の解除しただけなのに500エラーが続出し、404エラーまで出た経験もあります。なぜそうなったのかは不明ですが、エラーの対処ができるなら設定して見ても良いかも知れません…。

さらにWAF誤認の除外ルールに追加したファイルでも誤認を繰り返したので、あまり良い印象はありませんが。。魅力はあるけど、設定が反映しないのは困りものと言う個人的印象です。

LINKSiteGuardプラグインWAFチューニングサポート！403から500 ERRORさらに404のエラー三昧メモ。中級者向けかな？

サイトガードプラグインを削除しても、WAFチューニングサポートの設定が初期化されないようにする方法

プラグインを削除したり停止したとき、サイトガードの設定がすべて初期化されます…。再度設定をするのが面倒なので、再設定しなくても良い方法をご紹介。

1. 思い切って、WAFチューニングサポートをOFFに！
2. 下記コード、灰色部分を削除。
3. 赤部分を1行あける
4. .htaccessの編集を保存。

#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_START
<IfModule mod_siteguard.c>

SiteGuard_User_ExcludeSig xss-tag-1

SiteGuard_User_ExcludeSig sqlinj-55

SiteGuard_User_ExcludeSig xss-try-4

</IfModule>
#==== SITEGUARD_SG_WHITE_LIST_SETTINGS_END
#SITEGUARD_PLUGIN_SETTINGS_END

これで誤認の403エラーは出てません。

• シグネチャが増えたら前後に改行し追記

SiteGuard_User_ExcludeSig ここにシグネチャ

• これでプラグインを停止・削除してもシグネチャが消えてません。
• ヤレヤレでっす┐(´∀｀)┌

SiteGuard WP Pluginのほか設定は、ON・OFFの切り替えだけで反映するので良いけど、コレはめんどうですからね。

さいごに

サーバーが導入しているWAFのセキュリティは、悪質な攻撃に対してかなり有効です。ただ誤認があるだけで、それを除外すれば快適に使うことは可能です。

もっといい方法もあっても、初心者的にはハードルが高いものになります。

より安心・より簡単にWordPressを脅威から守ってもらいながら、この方法は良いを導入して快適に運営できることを願ってます＾＾

それでは、かうたっくでした！