※ 当ブログではアフィリエイト広告を利用しています。商品・サービス等の外部リンクにはプロモーションが含まれている場合があります。

【ブログのインデックス登録の問題】アクセス禁止(403)が原因のブロック

日記

2022年9月の上旬に、「Google Search Console」より

  • ブログサイトで新しいページのインデックス登録の問題が検出されました
  • 主な問題:アクセス禁止(403)が原因でブロックされました

といった内容のメールが届きました。

私はこの問題の原因は、契約しているレンタルサーバー(私の場合は「ConoHa WING」)のWAF機能の誤検知だと考えたので、WAFの除外設定をしてみました。

そして、2022年12月の上旬に、この問題が正常に修正されたことが確認できました。

この記事では、「アクセス禁止(403)が原因のブロック」によるブログのインデックス登録の問題について、実際に私が行った修正方法(「ConoHa WING」のWAFの除外設定)や考えについて記述しました。

※「Google Search Console」による問題の修正の検証に時間がかかりすぎた(約3カ月)こともあり、私が行った修正方法は正しくない可能性があります。この修正方法により新たな問題が発生する可能性もありますので、この記事を参考にされる場合は必ず自己責任で行ってください。

問題(エラー)が検出された原因を調べる

「Google Search Console」からの“問題が検出されました”という内容のメールには、[ページのインデックス登録の問題を修正する]というボタンがついていました。このボタンをクリックすると、問題の内容についてさらに詳しく知ることができます。

私は問題が検出されたURLについて調べてみたのですが、そのURLは最近新たに作ったページでも更新したページでもなかったので、問題が検出された原因がわかりませんでした。

そのため、問題(エラー)自体について詳しく調べてみました。

403エラー

「Google Search Console」からのメールによると、「アクセス禁止(403)が原因でブロックされた」ことが主な問題だそうです。

403エラーとは、「閲覧禁止」を表すHTTPステータスコードのひとつです。

ページは存在しているのですが、何らかの理由によりアクセスが禁止されていて、ページが閲覧できないという状態です。

Webサイトにアクセスした際に、「403 Forbidden」という表示がされて、サイトが閲覧できなかった経験がある人もいるかもしれません。

403エラーは、安全性の目的から意図的にアクセスを制限していることもありますが、管理者側のミスで起こっている場合が多数だそうです。

403エラーの原因としては「アクセス権限の設定ミス」「アクセス集中によるサーバーへの負荷防止」「indexファイルがない」などが挙げられますが、私の場合はどれも心当たりがなかったので、「WAF機能の誤検知」が原因ではないかと考えました。

WAF

WAF(ワフ)とは「Web Application Firewall(ウェブ・アプリケーション・ファイアウォール」の略で、様々なサイバー攻撃からWebサイトを守る、セキュリティ対策の機能のことです。

WAFは強力なセキュリティ機能なため、正常な通信を誤って不正と判断して遮断してしまう場合もあります。

例えば、WAFが管理者の動作を不正アクセスと誤認してしまうと、「閲覧できません(Forbidden access)」などのエラーが表示されて特定のページにアクセスできなくなることがあります。

このようにWAFが誤検知した場合は、WAFの設定を変更する必要があります。

WAFの除外設定

WAFが誤検知した場合は、WAFの除外設定をすると解決することがあります。

除外設定をすることで、不正アクセスと誤認している正常なアクセスが遮断されなくなります。

※ 注意 ※ WAFが不正アクセスと誤検出している、正常なアクセスのみを除外設定してください。攻撃情報が不明なアクセスについては、ハッカーからの攻撃の可能性があるので、除外設定しないように気をつけましょう。

WAFの除外設定の方法(ConoHa WING)

私が契約しているレンタルサーバーは「ConoHa WING(コノハウィング)」なので、ConoHa WINGのコントロールパネルからWAFの設定を変更しました。

ConoHa WINGでWAFの除外設定をする方法は、以下のとおりです。

※詳細なWAFの除外設定の方法は、契約しているレンタルサーバーのホームページなどでご確認ください。

WAFの除外設定の方法(ConoHa WING)

  1. 契約しているレンタルサーバーである「ConoHa WING」のコントロールパネルへログインする(ログイン後、左上あたりにある「WING」が黒色になっている場合は、[WING]をクリックして「WING」を青色にする)
  2. 左側にあるメニューから[サイト管理]をクリック
  3. サイト管理画面の左側にある[サイトセキュリティ]をクリック
  4. 上部にある[WAF]をクリック
  5. 「表示切替」で「ログ」を選択すると、WAFによりブロックされたWebサイトへの攻撃情報が表示されるので、「日時」や「攻撃元IPアドレス」などを確認して除外設定してよいものかを判断する(「攻撃元IPアドレス」が「自分のパソコンなどのIPアドレス」になっている場合は、WAF機能が自分のアクセスを不正アクセスだと誤検知しているため、基本的には除外設定しても大丈夫です)
  6. 除外設定したいログの左に表示されている[除外]ボタンをクリックする
  7. 「対象の攻撃を除外しますか?」というメッセージが表示されるので、内容を確認してから[はい]をクリック。※攻撃情報が不明なログについては、ハッカーからの攻撃の可能性があるので、除外しないこと!
  8. ログの左に表示されていた[除外]ボタンが[除外解除]ボタンに変わったら、完了!

攻撃元IPアドレス

上述の「WAFの除外設定の方法(ConoHa WING)」の5番目で、私の場合は攻撃情報のログが複数表示されました。問題が検出されたと考えられる日のログについては、ほとんどが「攻撃元IPアドレス」=「自分のパソコンのIPアドレス」でしたが、1つだけ不明なIPアドレスが紛れていました。

「攻撃元IPアドレス」=「自分のパソコンのIPアドレス」のログについて1つだけを除外設定してみたところ、不明な攻撃元IPアドレスを含む、他のログも除外されてしまいました。

不明な攻撃元IPアドレスについては除外してよいかわからなかったため、この時はすぐに、先程の除外設定を行ったログについて元通りに戻す操作をしました。すると、他のログの左側にあるボタンについても「除外解除」から「除外」に戻り、除外設定をする前の状態に戻すことができました。

ちなみに、「攻撃内容」については、どれも「その他」になっていました。

不明な攻撃元IPアドレス

色々と調べてみたところ、不明な攻撃元IPアドレスの正体は、クローラーからのアクセスではないかと考えられました。

クローラーとインデックス登録

クローラー(Crawler)とは、Webサイトを定期的に巡回して情報を収集するプログラム(ロボット)のことです。

クローラーの主な目的は、収集した情報を解析・データベース化(インデックス)して、検索エンジンの検索順位を決めて検索結果を表示することです。

代表的なクローラーは、Googleの「Googlebot」です。

GooglebotはWebサイトを巡回して、キーワード検索に関する情報を集めて、インデックス登録をしています。Googlebotがサイト内のWebページをインデックス登録することで、Googleの検索結果上にページが表示されるようになります。

クローラーからのアクセスかを調べる

不明な攻撃元IPアドレスが、クローラーからのアクセスによるものだと確実に調べる方法もあるようです。しかし、その方法は私には難しそうだったので、日時から推測することにしました。

方法は以下の通りです。

  1. 問題検出時に「Google Search Console」から届くメールに、[ページのインデックス登録の問題を修正する]というボタンがあるので、そのボタンをクリック
  2. 「Google Search Console」のページに移動する
  3. 下部にあるURLにカーソルを合わせたら出てくる虫眼鏡アイコン[URLを検査]をクリック
  4. 「前回のクロール」という日時を確認

私の場合は、「前回のクロール」という日時が、「不明な攻撃元IPアドレス」による攻撃の日時と一致していました。そのため、WAFの除外設定をしていいと考えて、実行しました。

問題の修正の検証に時間がかかった原因についての考察

今回、問題の検出から問題の修正が確認できるまでに、約3カ月かかりました。

問題の検出についてのメールが届いた日に、修正(WAFの除外設定)は終わらせたので、「Google Search Console」の検証に時間がかかったことになります。

約3カ月という時間がかかった原因については、単純に「Google Search Console」の検証が遅かったということも考えられますが、それ以外についても考察してみました。

作業の順番を間違えた

「Google Search Console」から問題の検出についてのメールが届いたら、問題を修正した後、「Google Search Console」に修正の検証をしてもらわないといけません。

本来であれば、以下のように1→2→3→4→5という順番で作業をする必要があります。

  1. 「Google Search Console」から問題の検出についてのメールが届くので確認する
  2. 問題の原因を調べ、問題を修正する(今回の場合であれば、WAFの除外設定をする)
  3. 「Google Search Console」に問題の修正について検証を開始してもらう
  4. 「Google Search Console」から“〇〇を検証しています”という内容のメールが届くので確認する(進捗状況を確認することも可能)
  5. 「Google Search Console」から問題が修正されたという内容のメールが届くので確認する

しかし、今回の私の作業は1→3→4→2→5という順番になってしまいました(作業の順番がおかしくなった理由は後述)。

作業の順番を間違えたことが原因で、問題の修正の検証に時間がかかってしまった可能性が考えられます。

問題の原因を間違えた

今回の問題の原因は、WAF機能の誤検知だと私は考えましたが、もしかしたら間違っていたという可能性があります。

よくわからないけれど、何かがきっかけとなり、時間がかかったけれども運よく問題が修正されたという可能性が考えられます。

「Google Search Console」が検出する問題の中には、修正作業(上述の「作業の順番を間違えた」の2番目)をしなくても修正されるエラーもあります。

今回の「アクセス禁止(403)が原因のブロック」によるブログのインデックス登録の問題については、

  • 初めて見る問題(エラー)だったこと
  • 2時間ほど修正方法を調べてもよくわからなかったこと
  • 修正作業をしなくても修正されるエラーがあること

などから、修正作業もせずに「Google Search Console」の検証を開始してしまいました。

検証を開始したものの、その後も4時間ほど修正方法についてさらに調べてみました。すると、WAF機能の誤検知が問題の原因かもしれないと思ったので、WAFの除外設定をしました。そのため上述のように、作業の順番がおかしくなってしまいました。

まとめ

「アクセス禁止(403)が原因のブロック」によるブログのインデックス登録の問題は、インデックス登録するために(検索結果上にWebページが表示されるように)サイトを巡回していたクローラーのアクセスを、WAF機能が不正アクセスと判断して遮断してしまったことによって発生する可能性が考えられます。

クローラーのアクセスを遮断しないように、契約しているレンタルサーバーからWAFの除外設定をすることで、問題が修正できるかもしれません。

ブログ関係のその他の記事

コメント