質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
WordPress

WordPressは、PHPで開発されているオープンソースのブログソフトウェアです。データベース管理システムにはMySQLを用いています。フリーのブログソフトウェアの中では最も人気が高く、PHPとHTMLを使って簡単にテンプレートをカスタマイズすることができます。

Q&A

解決済

1回答

5061閲覧

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

ami15821

総合スコア56

WordPress

WordPressは、PHPで開発されているオープンソースのブログソフトウェアです。データベース管理システムにはMySQLを用いています。フリーのブログソフトウェアの中では最も人気が高く、PHPとHTMLを使って簡単にテンプレートをカスタマイズすることができます。

0グッド

1クリップ

投稿2018/11/02 09:27

編集2018/11/04 23:58

前提・実現したいこと

ワードプレスでページ作成を行なっていると、途中で保存ができない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サーバーのログ情報から必要な情報を検出して設定しないといけない状況です。大変お手数ですがご助力のほどよろしくお願い致します。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

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

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

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

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

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

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

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

投稿2018/11/02 10:22

KazuhiroHatano

総合スコア7802

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ami15821

2018/11/02 13:44

ご回答、ありがとうございます。 すみません、本当に何もわかってないので確認なのですが "WAFのログ"とは、サーバーのコンパネで確認できるWAF設定画面のことでしょうか? waf_detect.log、ではないということでしょうか?(もはや聞くのが怖い状況です...)
KazuhiroHatano

2018/11/02 14:50

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

2018/11/03 02:50

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

2018/11/03 03:02 編集

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

2018/11/03 03:04

https://github.com/pepabo/siteguard_lite-log-parser ここの解説のdetect_nameのとこ見たらわかるんですが WAFの検出にはリクエストの内容(攻撃的コードの含有の可能性とか)に関するものと リクエストそのもの(IP制限、パラメータの量、URLの解析)に関するものがあって 前者にはrule_sig_id(シグネチャID)があって、そのシグネチャを例外とするコードを .htaccessに追記することで検出を回避できますが 後者はそれぞれ違うやり方で回避することになります 繰り返しになりますが、リクエストパラメータ1000以上というのは正常とは思えません リクエストパラメータの肥大はCookieが結構怪しいです 別のブラウザとかでやったら引っかからないとかないですか?
KazuhiroHatano

2018/11/03 03:07

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

2018/11/03 03:22

すみません、本当に初心者なものでRULE_SIGや、RULE_PARAMS_NUMといった言葉に馴染みがなく、よく理解していなく申し訳ないのですが、 >別のブラウザとかでやったら引っかからないとかないですか? 上記、試したら今度はログイン画面で404エラーとなり、ログインができなくなりました.... 原因を調べ中です。 .htaccess内の "RewriteRule ^wp-admin 404-siteguard [L]" の一文を削除 すると解消した、という記事があったので、試してみます。
ami15821

2018/11/03 03:32

.htaccessの内容、修正したらログインできるようになりました。 別のブラウザで記事の更新をしようと試みたのですが、保存ができず、解消されませんでした。
KazuhiroHatano

2018/11/03 03:58

別ブラウザからのアクセスでも同じくRULE_PARAMS_NUMで引っかかるなら リクエストパラメータの肥大はゴミCookieの集積が原因ではなさそうですね 一度引っかかると通常の投稿もできない状態なのでしょうか? それとも特定の操作においてのみ403になるんでしょうか?
ami15821

2018/11/03 23:41 編集

ご助力、感謝いたします。 >一度引っかかると通常の投稿もできない状態なのでしょうか? はい、途中までは保存できるのですが、一度引っかかると保存ができなくなります。 >それとも特定の操作においてのみ403になるんでしょうか? 特定の操作では起きておりません。 昨日からの状況の変化としては 昨日、クライアントが一時的にWAFをOFFにされた際は保存が通常通りできました。画面も保存をした際に表示される403エラーは解消されました。 本日、記事の内容を更新すると途中までは保存ができるのですが、いきなり更新ができなくなります。 おそらくクライアント先でWAFを元の設定に戻したのだと思われます。 更新ボタンを押すと『固定ページを更新しました。』といった案内は管理画面に表示はされます。(更新されていないのですが) 昨日と違うのは、更新をすると403になっていた表示の切り替えが変わらなくなった点です。 長々と長文、失礼いたしました。
KazuhiroHatano

2018/11/03 04:41

普通にWordpressを使っていて、リクエストパラメータが1000を超えてしまうというのはちょっと考えにくいです、ゴミデータが適切に破棄されていないとかの問題があるからそうなっているのだと思うのです REST APIの処理でRULE_SIGで引っかかってるとかなら .htaccessにSiteGuard_User_ExcludeSigを追記して対応するのですが RULE_PARAMS_NUMでひっかかるのは Wordpress側に修正すべきところがあるように思います どれかプラグインを切ったら引っかからなくなるとかないでしょうか?
ami15821

2018/11/03 08:12

>REST APIの処理でRULE_SIGで引っかかってるとかなら .htaccessにSiteGuard_User_ExcludeSigを追記して対応するのですが RULE_PARAMS_NUMでひっかかるのは Wordpress側に修正すべきところがあるように思います なるほど... ではwordpressの設定で何かミスが起きている、ということなんですね。 >どれかプラグインを切ったら引っかからなくなるとかないでしょうか? プラグインを全て切っても解消されませんでした...
KazuhiroHatano

2018/11/03 10:20

設定でミスが起きてるというよりは、 なんかのプラグインか、テーマの処理がよろしくないって感じでしょうか 一度Cookieをクリアしたら一時的にでも回復しますか?
ami15821

2018/11/03 12:04 編集

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

2018/11/03 12:40

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

2018/11/03 14:36 編集

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

2018/11/03 15:34

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

2018/11/03 23:51

連日のアドバイス、痛み入ります。 >とりあえずセッション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でした。 2つ目の『Request Cookies』では ・wp-saving-post こちらのsizeが97でした。
KazuhiroHatano

2018/11/04 03:47

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

2018/11/04 05:19

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問