フォーラムへの返信
-
投稿
-
全体対応していただき 感謝です。
支障のあった投稿や記事修正も 500エラーなしで出来るようになりました。
WAF移行前は「SiteGuard_User_ExcludeSig ip(xxx.xxx.xx.xxx)」で対応していたため、気が付かなかったのかもしれません。
ありがとうございます。アドバイスいただいた内容を試すのとあわせて、そもそもの原因であるエラーがなぜ出るのか調べてみました。
・記事が投稿及び修正できない原因がわかりました。
どうやら記事内に半角ハイフンが2つ以上続いたもの — があると、WAFが検知して投稿時と記事修正時に500エラーが出ることを確認しました。
使っているphpスクリプトの固有の事柄なんだろうと思います。PHPが8.3から8.4になったことも関係あるんでしょうか？WAFのエラーログ（要点）
ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf”] [line “32”]
[id “200003”]
[msg “Multipart parser detected a possible unmatched boundary.”]・これを回避するために.htaccessに「SecRuleRemoveById 2000003」と設定すれば、記事投稿及び修正のときに500エラーは出ず投稿・修正ができる。
・記事投稿及び修正しやすくするために、自己IPのアクセスをWAFの検知から除外するような.htaccessの記述
アドバイスいただいた正規表現での以下の記述を試してみました。
<IfModule mod_security2.c>
SecRuleRemoveByMsg “xxx\.xxx\.xx\.xxx”
</IfModule>結果は「除外しないWAFと同じエラーログ内容」で、投稿時と記事修正時に500エラーが出ることを確認しました。残念です。
WAFのエラーログ（要点）※上記と同じ内容でした。
ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf”] [line “32”]
[id “200003”]
[msg “Multipart parser detected a possible unmatched boundary.”]週末で時間があったので いろいろと調べてみましたが、そもそも半角ハイフンを2つ以上 記事で使わなければ支障ないことがわかりました。
普通に修正できる記事の多いなかで、500エラーで修正できない記事があるのが不思議だったのでスッキリしました。
.htaccessの記述で IPで除外できないのが心残りですが、既存の記事を修正する際 エラーが出た場合は IDで除外すればいいので支障ありません。うまく要点を整理できていないかもしれませんが、調べた結果をご報告しました。
これまでのアドバイス 感謝申し上げます。
今後ともよろしくお願いいたします。申し訳ありません。タイプミスです。
SecRuleRemoveByMsg “xxx.xxx.xx.xxx”
上記の半角スペース入りで検証していますが、記事修正をすると「500サーバエラー」が出ます。
その際のエラーログの一部は以下のとおりです。
[Wed Jul 02 18:00:08.645181 2025] [:error] [pid 3779361:tid 3779429] [remote xxx.xxx.xx.xxx:13408] [client xxx.xxx.xx.xxx] ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf”] [line “32”] [id “200003”] [msg “Multipart parser detected a possible unmatched boundary.”]
phpのスクリプトをWAFが検知しているらしいのですが、以下のようにIDで除外すると記事修正できるので、とりあえず問題はありません。
SecRuleRemoveById 200003
IPアドレスによるWAF検知除外についてですが・・・
<IfModule mod_security2.c>
SecRuleRemoveByMsg“xxx.xxx.xx.xxx”
</IfModule>SecRuleRemoveByMsg でいろいろ試してみましたが、私の環境では「.htaccess」では思うようにはいきませんでした。
ダブルクォーテーションを外してみたり、固定IPを正規表現で試してみたりしたのですが、試行錯誤だけではままならず降参しました。
ご助言に感謝いたします。おかげさまでご紹介いただいたサイトでいろいろ勉強になりました。
https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#secruleremovebyid
ID の場合はアスタリスクでの全除外以外に、以下のようにレンジで控えめ検知除外できることもその一つです。
SecRuleRemoveById “200000-299999”
先々よい方法が見つかりましたらご教示ください。
今後ともよろしくお願いいたします。お忙しい中 アドバイスありがとうございます。
>IPアドレスによる除外は対応していません。
了解しました。
下記の記述で .htaccess をアップしても500エラーが出ませんでしたので、一定期間これで様子をみてみます。
意図したような動作が確認できましたら ご報告したいと思います。
<IfModule mod_security2.c>
SecRuleRemoveByMsg “xxx.xxx.xx.xxx”
</IfModule>サーバ切替に伴うWAFの変更（自己IPの除外記述）について
サーバ切替前のWAFでは、以下の記述で自己IPのみ除外して、結構便利に使っていました。
<IfModule mod_siteguard.c>
SiteGuard_User_ExcludeSig ip(xxx.xxx.xx.xxx)
</IfModule>切替後のWAFでは、ID除外ではなく 上記と同じような以下の記述でも自己IPだけを除外できますでしょうか。
500エラーが出なくなったので試しているのですが、機能しているのかどうかイマイチ判断できずにいます。
<IfModule mod_security2.c>
SecRuleRemoveById ip(xxx.xxx.xx.xxx)
</IfModule>これでいいものかどうか、アドバイスいただければ幸いです。
よろしくお願いします。新フォーラムになって初めての投稿です。
>サーバーの設定変更などで検索エンジンにヒットしなくなるような要因はありますでしょうか？
サーバーのスペックが極端に下がったこと以外は 通常考えられないはずですし、イエティサーバーのVPS変更が近々あるようなお知らせもありますが、現時点でのスペック変更はされていないと思います。
・VPSをSAKURAからKAGOYAに変えるかも
https://ie-t.net/information/kagoya-vps/サーバーを移転してサイトのURLが変わったのであれば よくあることですし、対処法を掲載しているサイトも多数ありますのでお調べください。
サーバーを移転していないのであれば、Google Search Console に サイトマップを登録すれば、それなりの情報はとれると思います。
・Google Search Console
https://search.google.com/search-console/about?hl=ja以下のサイトで紹介されていますが、貴殿がアップしているHPの代表的な「検索語句」で貴殿のドメインに絞って検索してみてはいかがでしょう。
貴殿のサイトの検索語句 site:●●●.ie-t.net
というふうに。
なにがしかヒットする場合は 検索結果ページから消えていないということですし、結果順位の問題なのかもしれません。
・「Google検索でヒットしなくなった」14の原因と復活させる方法
https://lucy.ne.jp/bazubu/no-hit-49701.htmlということで、検索ページから消えていないのであればコントロールパネルでの設定云々とは関係ないと思います。
長くなりますが、私が実際に経験したことを2つ程ご紹介します。
・外部のCSS（リセットCSSなのですが）をページが呼び出していて、それを提供する外部サイトにトラブルがあって CSSを呼び出せない場合
この場合はページが開かなかったり、開いてもページのデザインが崩れたりします。
長く続けば検索順位も下がるとは思いますが、その場合は閲覧者だけでなくページ設置者自身もわかりますし、通常は短時間で復旧するので これはないと思います。
・設置者以外を拒否する.htaccess を誤ってアップしていた場合
これはページ設置者はアクセスできるので、私もしばらく気が付きませんでした。まさかではありますが。※新フォーラムへの投稿練習を兼ねて返信させていただきました。
参考になれば幸いです。
