【wordpress】WAFを有効にしても403エラーにならないようにする方法につきまして

Question

前提・実現したいこと

ワードプレスでページ作成を行なっていると、途中で保存ができない403エラーが発生しました。
サーバー元にWAFを一時的に無効にして頂いたら保存ができるようになったのですが、WAFを有効にしても保存ができるようにしたいです。

シグネチャがどこの箇所なのか分かれば、プラグイン「SiteGuard」で設定できるようです。

該当のソースコード

waf_detect.log

sig_id
1541126842.00000    761 000.104.143.136 TCP_MISS/000 68929 POST http://sample-net.co.jp/CMS/wp-admin/post.php - DIRECT/150.60.156.37 application/x-www-form-urlenc DETECT-STAT:WAF:RULE_PARAMS_NUM/PART_REQBODY/1000:::: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:1541126842.004720.24:
1541127600.00000    428 000.104.143.136 TCP_MISS/000 68929 POST http://sample-net.co.jp/CMS/wp-admin/post.php - DIRECT/150.60.156.37 application/x-www-form-urlenc DETECT-STAT:WAF:RULE_PARAMS_NUM/PART_REQBODY/1000:::: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:1541127600.824789.33:
1541133813.00000    481 000.104.143.136 TCP_MISS/000 68929 POST http://sample-net.co.jp/CMS/wp-admin/post.php - DIRECT/150.60.156.37 application/x-www-form-urlenc DETECT-STAT:WAF:RULE_PARAMS_NUM/PART_REQBODY/1000:::: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:1541133813.119938.74:
1541134616.00000    592 000.104.143.136 TCP_MISS/000 68929 POST http://sample-net.co.jp/CMS/wp-admin/post.php - DIRECT/150.60.156.37 application/x-www-form-urlenc DETECT-STAT:WAF:RULE_PARAMS_NUM/PART_REQBODY/1000:::: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:1541134616.749688.47:
1541134623.00000    406 000.104.143.136 TCP_MISS/000 68929 POST http://sample-net.co.jp/CMS/wp-admin/post.php - DIRECT/150.60.156.37 application/x-www-form-urlenc DETECT-STAT:WAF:RULE_PARAMS_NUM/PART_REQBODY/1000:::: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:1541134623.359678.46:

試したこと

プラグイン「SiteGuard」のWAF除外ルール 追加画面に『検出したシグネチャ名、または、シグネチャIDを指定してください。複数指定する場合は、改行で区切ってください。』と書かれているので、waf_detect.logに記述がある sig_idの欄に記載のある"1541126842.004720"を設定しようとしたら、エラーが表示されて保存ができませんでした。

補足情報（FW/ツールのバージョンなど）

サーバーがロリポップなどのメジャーなサーバーでなく、サーバーのコントロールパネルにログインする方法はクライアントの意向でできないので、FTPサーバーのログ情報から必要な情報を検出して設定しないといけない状況です。大変お手数ですがご助力のほどよろしくお願い致します。

Answer 1

SiteGuardで引っかからないようにするには
htaccessに例外を追記する形で対応することになると思うんですが
追加すべきコードはWAFのログに出てます

WAFのログ見ないと正直かなりしんどいです

Wordpressって何かとWAFに引っかかりやすいです
特に新エディタはもうめちゃくちゃ引っかかりまくります

styleタグstyle属性、class、matchなどの予約語
関数の実行としても解釈可能な表記
外部ドメインにリンクしているurl()表記
もうとにかくいろんなものが引っかかります

多分どこが引っかかってるか特定できれば
例外追加のコードはGoogle先生に聞けば見つかるとは思います

しかしかなりの作業になるはずです

WAFのログを見れれば答えが書いてるものを
地道な調査で時間かけて見つけ出そうなんてのは
なかなか精神が死にます…

Comments

[ami15821]

ご回答、ありがとうございます。
すみません、本当に何もわかってないので確認なのですが
"WAFのログ"とは、サーバーのコンパネで確認できるWAF設定画面のことでしょうか？

waf_detect.log、ではないということでしょうか？(もはや聞くのが怖い状況です...)

[KazuhiroHatano]

それなりのサーバーなら、コントロールパネルのWAFの設定の近くにログのリンクがあって、いつどこからのアクセスの何が引っかかったかを一覧できるようになっていて、親切なサーバーならその上にそれを例外としたい場合に.htaccessに追加するコードを出してくれてます
質問文のwaf_detect.logの検出はパラメータ数の上限値の制限（1000）に引っかかってるってことらしいですが、この検出にsig_idはないです
これを引っかからないようにするには上限値を変えるとかって感じでしょうか

しかしまあ、パラメータ1000以上って正常でない気もします、Cookieが雪だるま式に増えていくようなことでもしてるんでしょうか？

[ami15821]

ご回答、ありがとうございます。
すみません、sig_idの記述が該当ソースに含まれていなかったので、追記しました。

プラグイン「SiteGuard」のWAF除外ルール 追加画面に『検出したシグネチャ名、または、シグネチャIDを指定してください。複数指定する場合は、改行で区切ってください。』と書かれているのですが、『シグネチャID』とはもしかしてwaf_detect.logに記述がある sig_idのことでしょうか？

[ami15821]

試しに"1541126842.004720"のsig_id？を設定しようしたのですが、『エラー: シグネチャの指定が正しくありません。』と表示されました。

[KazuhiroHatano]

https://github.com/pepabo/siteguard_lite-log-parser

ここの解説のdetect_nameのとこ見たらわかるんですが
WAFの検出にはリクエストの内容（攻撃的コードの含有の可能性とか）に関するものと
リクエストそのもの（IP制限、パラメータの量、URLの解析）に関するものがあって
前者にはrule_sig_id(シグネチャID)があって、そのシグネチャを例外とするコードを
.htaccessに追記することで検出を回避できますが
後者はそれぞれ違うやり方で回避することになります

繰り返しになりますが、リクエストパラメータ1000以上というのは正常とは思えません
リクエストパラメータの肥大はCookieが結構怪しいです
別のブラウザとかでやったら引っかからないとかないですか？

[KazuhiroHatano]

このwaf_detect.logにシグネチャIDはありません、
RULE_SIG ではなくRULE_PARAMS_NUMで引っかかってるからです

[ami15821]

すみません、本当に初心者なものでRULE_SIGや、RULE_PARAMS_NUMといった言葉に馴染みがなく、よく理解していなく申し訳ないのですが、

>別のブラウザとかでやったら引っかからないとかないですか？
上記、試したら今度はログイン画面で404エラーとなり、ログインができなくなりました....
原因を調べ中です。

.htaccess内の "RewriteRule ^wp-admin 404-siteguard [L]" の一文を削除　すると解消した、という記事があったので、試してみます。

[ami15821]

.htaccessの内容、修正したらログインできるようになりました。

別のブラウザで記事の更新をしようと試みたのですが、保存ができず、解消されませんでした。

[KazuhiroHatano]

別ブラウザからのアクセスでも同じくRULE_PARAMS_NUMで引っかかるなら
リクエストパラメータの肥大はゴミCookieの集積が原因ではなさそうですね

一度引っかかると通常の投稿もできない状態なのでしょうか？
それとも特定の操作においてのみ403になるんでしょうか？

[ami15821]

ご助力、感謝いたします。

>一度引っかかると通常の投稿もできない状態なのでしょうか？
はい、途中までは保存できるのですが、一度引っかかると保存ができなくなります。

>それとも特定の操作においてのみ403になるんでしょうか？
特定の操作では起きておりません。

昨日からの状況の変化としては
昨日、クライアントが一時的にWAFをOFFにされた際は保存が通常通りできました。画面も保存をした際に表示される403エラーは解消されました。
本日、記事の内容を更新すると途中までは保存ができるのですが、いきなり更新ができなくなります。
おそらくクライアント先でWAFを元の設定に戻したのだと思われます。
更新ボタンを押すと『固定ページを更新しました。』といった案内は管理画面に表示はされます。(更新されていないのですが)　昨日と違うのは、更新をすると403になっていた表示の切り替えが変わらなくなった点です。

長々と長文、失礼いたしました。

[KazuhiroHatano]

普通にWordpressを使っていて、リクエストパラメータが1000を超えてしまうというのはちょっと考えにくいです、ゴミデータが適切に破棄されていないとかの問題があるからそうなっているのだと思うのです

REST APIの処理でRULE_SIGで引っかかってるとかなら
.htaccessにSiteGuard_User_ExcludeSigを追記して対応するのですが
RULE_PARAMS_NUMでひっかかるのは
Wordpress側に修正すべきところがあるように思います

どれかプラグインを切ったら引っかからなくなるとかないでしょうか？

[ami15821]

>REST APIの処理でRULE_SIGで引っかかってるとかなら
.htaccessにSiteGuard_User_ExcludeSigを追記して対応するのですが
RULE_PARAMS_NUMでひっかかるのは
Wordpress側に修正すべきところがあるように思います
なるほど...
ではwordpressの設定で何かミスが起きている、ということなんですね。

>どれかプラグインを切ったら引っかからなくなるとかないでしょうか？
プラグインを全て切っても解消されませんでした...

[KazuhiroHatano]

設定でミスが起きてるというよりは、
なんかのプラグインか、テーマの処理がよろしくないって感じでしょうか

一度Cookieをクリアしたら一時的にでも回復しますか？

[ami15821]

再度Cookieをクリアしましたが、解消しませんでした...

[KazuhiroHatano]

とりあえず、リクエストパラメータが多すぎると言われてるのだから、ブラウザで実際どんなリクエストを投げてるのを見る方がいいかもしれませんね、ブラウザの検証でネットワークを見て、投稿保存時にpost.phpにどんなリクエスト投げてるのか見てみてください、
異常な数のcookieを投げてるようでなければPOSTパラメーターってことなんでしょうが、正直1000を超えるPOSTパラメータを持つ投稿ってのが想像つかないです

[ami15821]

度々の質問となり、申し訳ありません。
検証の確認場所の認識が合っているのか、確認させてください。

管理画面の更新後、保存ができていない画面でクロームの検証→『Network』でpost.phpの『cookie』のタブを確認すると、『Request Cookies』という項目があるのですが、"post.phpにどんなリクエスト投げているのかの確認箇所"の観るべき箇所は合っているでしょうか？
検討ハズレな箇所をお伝えしていたら、申し訳ありません。
大変お手数となっておりますが、ご助力のほどよろしくお願いいたします。

[KazuhiroHatano]

そこです、あってます、そこのcookieの数が異常じゃないかの確認です
とりあえずセッションIDとかアナリティクス用のIDとかアクセス時間とか
色々送ってるものがあると思いますが多分20個ぐらいまでが正常ラインかなって思います

[ami15821]

連日のアドバイス、痛み入ります。

>とりあえずセッションIDとかアナリティクス用のIDとかアクセス時間とか
色々送ってるものがあると思います
>多分20個ぐらいまでが正常ライン
上記、どこの箇所なのか明確でないので、申し訳ありませんが列挙させて頂きます。

『Request Cookies』という項目が2点ございまして、
1つ目の『Request Cookies』では
・wordpress_数字の羅列
・wordpress_logged_in_数字アルファベットの羅列
・wordpress_test_cookie
・wp-saving-post
・wp-settings-1
・wp-settings-time-1
上記のトータルのsizeが534でした。

２つ目の『Request Cookies』では
・wp-saving-post
こちらのsizeが97でした。

[KazuhiroHatano]

403が出た時にpost.phpに送ってるリクエストのCookieがそれだけなら特に異常な数ってわけじゃなさそうですね、それでは投稿自体のパラメータの数ってことになるんでしょうが、そんな投稿の内容というのがわからないです、とてつもなく膨大な数のカスタムカテゴリやタグがあったり複雑なカスタムフィールドを使ってるとかなのでしょうか？
うちもWAFの入ったサーバー使っていて、WordPressでおよそ表示にさえ支障をきたすレベルの一斉更新のフォームを作ったりもしましたが、それでもRULE_PARAMS_NUMに引っかかったことがなかったので、フォームから投げたリクエストのパラメータがCookieもなしに1000を超えるというのは正直想像がつかないのです…
もしかしたらサーバーへの接続方法とか別の要因があるのかもしれないですがこれ以上は全く門外漢なので…

[ami15821]

ご回答、ありがとうございます。
色々行なってきましたが、私ができることはここまでなのかもしれません。

あまりよくないですが、クライアントに作業するときだけWAFを切ってもらうか、コンパネの検出したシグネチャ名、または、シグネチャIDを教えてもらって設定するのごちらかが、おそらくもっとも今現実的な解決方法なのではと、考えております。