アクセスログの“不審なアクセス”は危険か|正規ボットになりすます自動スキャンの正体と見分け方

一見かわいいロボットの背後に、赤い目とギザギザの歯を持つ悪いロボットがぼわっと浮かぶイラスト。正規のGooglebotを装う自動スキャンの“実は悪い”本性を表す。虫眼鏡(逆引きDNSでの検証)で見破り、秘密ファイルは施錠して守る。

 自社サイトのアクセスログ(サイトへの訪問記録)を開いたら、身に覚えのない大量のアクセス——「/.env」「/.git」といった見慣れないURLへの要求や、GooglebotやClaudeBotを名乗る記録——が並んでいて不安になった、というご相談をよくいただきます。
 これは結論から言うと、その多くは世界中のサイトを無差別に狙う自動スキャンだったりします。

基本的な備えができていれば過度に恐れる必要はないですが、「本物の検索エンジン/AIのボット」と「それになりすました攻撃」を見分ける目は持っておくべきです。

 私はMintSparkで情報処理安全確保支援士として、中小企業のセキュリティ支援を行っています。本記事は、私たちが運営するサイトのアクセスログを実際に分析した一次記録をもとに、「どこの・何を確認すれば安全と判断できるか」を、実際の流れに沿って、専門用語を噛み砕いて解説します。

この記事の要点

  • ログに並ぶ“不審なアクセス”の多くは、世界中を無差別に走査する自動スキャン。特定企業の狙い撃ちとは限りません。
  • 攻撃者はGooglebot・ClaudeBotなど正規ボットの名前(User-Agent)を平気で詐称します。「名乗り」は信用できません。
  • 見分けの決め手は「逆引きDNS」と「1つのIPが複数の正規ボットを名乗っていないか」。そして秘密ファイルを公開領域に置かないことです。
目次

まず、ログを開いたら“変なアクセス”が並んでいた

 最初の一歩は、サーバーの「アクセスログ」(どのIPが・いつ・どのURLに・どう応答したかの記録)を開くことです。実際に見ると、次のような行がずらりと並んでいました。

アクセスログの抜粋(イメージ)。.envや.git/config、wp-config.php.bakなど秘密ファイルへのアクセスが、GooglebotやClaudeBot等の名前を名乗って大量に並ぶ様子。
イメージ画面1

 気づく点は2つあります。ひとつは、.env.git/config/wp-config.php.bak といった、普段は誰もアクセスしない“秘密ファイル”への要求が大量にあること。もうひとつは、それらが Googlebot・ClaudeBot・Amazonbotなど大手ボットの名前を名乗っていること。ここで「乗っ取られたのでは?」と不安になるのは自然です。ですが、慌てて対処する前に、まず“事実”を確認しましょう。

落ち着いて“3つ”を確認したら、問題なかった

 本当に被害があったかどうかは、次の3点を確認すれば判断できます。順に見ていきます。

  1. 応答を集計する——中身が返ってしまった「200」が無いか。あれば情報が漏れた可能性があります。
  2. 発信元IPを逆引きする——正体(どこから来たか)を確かめます。
  3. 秘密ファイルが実在するか確認する——そもそも公開領域に置いていなければ、探されても取られようがありません。
被害確認の様子(イメージ)。応答集計で中身が返った200が0件、発信元IPの逆引きでクラウドの仮想サーバーやスキャン業者と判明、.envやwp-config.php.bakは公開領域に存在しない。
イメージ画面2

 当社サイトで実際に確認した結果はこうでした。約3週間分のログで、この手の“秘密探し”は2,944件・発信元は84個のIPアドレス。しかし応答は403(アクセス拒否)や404(そんなファイルは無い)、500(サーバー側で弾いた)ばかりで、中身が返った「200」は実質ゼロでした。発信元を逆引きすると、Google CloudやAWSの仮想サーバー、脆弱性スキャン業者に行き当たりました。そして、狙われた .env やバックアップはそもそも公開領域に置いていません。——結論、実害なし。「探されても、そこに無い/読めない/届かない」なら、スキャンは空振りに終わります。

 参考までに、①「応答の集計」を自分のサーバーで試すときのコマンド例です(Apache系のアクセスログを想定。ファイル名やログの形式は環境により異なります)。

# ① 応答コード別に件数を集計(ログの形式に依存しにくい方法)
grep -oE '" [0-9]{3} ' access_log | sort | uniq -c | sort -rn

# 秘密ファイル探索(.env / .git / .aws / wp-config.php.bak 等)への応答だけを見る
# → 403・404・500 ばかりなら弾けている。200 があれば「中身が返った」可能性=要確認
grep -aiE '/.env|/.git|/.aws|wp-config.php.' access_log 
  | grep -oE '" [0-9]{3} ' | sort | uniq -c | sort -rn

# ② 気になる発信元IPを逆引き → 出たホスト名を正引きして元IPに戻るか確認(FCrDNS)
host 203.0.113.45
host <逆引きで出たホスト名>

 結果が 403・404・500 ばかりなら、弾けているので安心です。もし 200 が混じっていたら、その秘密ファイルの中身が読めてしまった可能性があります。その場合は、次の初動対処を行ってください。

もし「200」が返っていたら(簡易の初動対処)

  1. そのファイルを今すぐ公開領域から外す:.env やバックアップ等を、Webから見えない場所へ移動、または削除します。
  2. 読まれた前提で、認証情報を変更する:そのファイルに書かれていたパスワード・APIキー・データベース接続情報を、直ちに新しいものに切り替えます(ローテーション)。一度でも200で返っていれば、取得された前提で動くのが安全です。
  3. 同じパスをサーバー設定で遮断する:以後アクセスできないよう、.htaccess 等で拒否します。
  4. 影響範囲を確認し、迷えば専門家へ:何が読めたか・悪用の痕跡がないかを確認します。範囲が広い、または不安な場合は早めにご相談ください。

正体は“無差別スキャン”——なぜ大手ボットを名乗るのか

 この手のアクセスは、特定の会社を狙った標的型攻撃とは限りません。実態は、クラウド上の仮想サーバーやスキャン業者が、世界中のサイトに同じ“定番リスト”を機械的に投げているものです。約3週間、毎日数百件のペースで続いていたことからも、狙い撃ちではなく“背景ノイズ”だと分かります。

 やっかいなのは、彼らがGooglebotやClaudeBotの名前(User-Agent)を平気で詐称することです。検知や遮断をすり抜け、正規のアクセスに紛れるための偽装です。だからこそ、次の「見分け方」が要になります。

「本物のボット」と「なりすまし」を見分ける4つの視点

本物のボットとなりすましを逆引きDNS(FCrDNS)で見分ける図。名乗りは詐称できるため、逆引きと正引きで照合し、googlebot.com等に解決して元IPに戻れば本物、無関係なVPSやスキャン業者なら偽物。

 ログにClaudeBotやGooglebotの名前が並んでいても、鵜呑みにしてはいけません。User-Agent(ユーザーエージェント=ブラウザやボットの“名乗り”)は、誰でも自由に書き換えられるからです。本物かどうかは、次の4点で確かめます。

 ① 逆引きDNSで運営元を確かめる(最も確実)。 IPアドレスから運営元のホスト名を逆引きし、さらにそのホスト名を正引きして元のIPに戻るかを確認します(この二重確認を「正引き確認付き逆引き=FCrDNS」と呼びます)。本物のGooglebotは googlebot.comgoogle.comgoogleusercontent.com のいずれかに解決されます。Googleはこの確認手順と公式のIPアドレス範囲を公開しており、「User-Agentは詐称され得るので、逆引き+正引き、または公式IP範囲で確認せよ」と明記しています(出典:Google公式)。GoogleやAnthropicなど主要な運営元は同様の検証手段を用意しています。逆引き先がVPS事業者の汎用ホスト名やスキャン業者名なら、なりすましです。

 ② 「1つのIPが複数の正規ボットを名乗る」なら、なりすまし確定。 本物のGooglebotとClaudeBotが同じIPアドレスから出ることは、原理的にありえません。当社ログでも、1つのIPが Googlebot → ClaudeBot → Amazonbot → GPTBot… と次々に名前を変えていました。これは正体を隠すための偽装の“動かぬ証拠”です。

 ③ アクセス先の“性質”を見る。 本物の検索エンジンやAIのボットは、公開されている記事やページを辿ります。一方、.envcredentials.git を探し回るのは、コンテンツ収集ではなく“秘密探し”であり、スキャナ特有の振る舞いです。

 ④ 名乗り(User-Agent)だけを信用しない。 繰り返しますが、名乗りは詐称できます。「ClaudeBotだから安心」ではなく、①〜③で裏を取ります。実際、公式には存在しない名前(例:Claude-Web)を騙るケースもありました。

あなたのサイトを“空振り”にさせる守り方

 同じスキャンは、あなたのサイトにも日々来ています。被害の分かれ目は「探されたファイルが、そこに“無い/読めない/届かない”か」。次の基本を押さえれば、大半は空振りに終わります。中小企業でも、多くはサーバーやCMSの設定で対応できます。

無差別スキャンを空振りにさせる3層の守りの図。秘密ファイルを公開領域に置かない(探しても無い)・設定ファイルの権限を絞る(あっても読めない)・危険パスをサーバーで遮断+WAF+最新化(そもそも届かない)。

スキャンを“空振り”にさせる基本の守り

  • 秘密ファイルを公開領域に置かない:.env・データベースのバックアップ・鍵ファイルは、Webから見える場所に置かない。バックアップは公開フォルダの外へ。
  • 設定ファイルの権限を絞る:WordPress等をお使いなら、設定ファイル(wp-config.php 等)は「本人だけが読める」権限にする。
  • 隠しファイル・危険パスをサーバー側で遮断:.env や .git への直接アクセスは、サーバー設定(Apacheなら.htaccess等)で拒否する。
  • アップロード領域でのプログラム実行を禁止:画像置き場に紛れ込んだプログラムファイルが動かないようにする。
  • WAFを有効化(WAF=不正なアクセスのパターンを検知して遮断する仕組み)。多くのレンタルサーバーで設定するだけで使えます。
  • PHPなどのソフトを最新に保つ:古いバージョンには既知の弱点がある。

 最後の「最新に保つ」は特に重要です。今回のスキャンには、古いPHPの設定を悪用してコードを実行しようとする攻撃(CVE-2012-1823)も含まれていました。これはPHPを「CGI」という古い方式で動かしている場合の弱点で、当社は現行方式(PHP-FPM)で運用しているため成立しませんでした。米CERT/CCも、この弱点はApacheのmod_phpやnginx+php-fpm構成では影響しないとしています(出典:CERT/CC VU#520827)。ここでも「古い構成を避け、最新に保つ」ことがそのまま守りになります。

「WordPressだから狙われる」の誤解

  • 使っているCMS(WordPress等)の種類は、URLの作りなどから自動で判別されます。種類を隠しても守りにはなりません。
  • ただし「バージョン情報」は別で、隠すべき:WordPress本体やPHPのバージョンが分かると、そのバージョン固有の既知の弱点を狙われやすくなります。readme.htmllicense.txtの公開停止や、ページに埋め込まれる generatorメタタグ(例:WordPress 6.x)の除去で、バージョンを露見させないようにしましょう。あわせてログインID露出(REST API)や xmlrpc.php も塞ぎます。これらは当社の無料診断でも「WordPressの攻撃面」として確認している項目です。
  • 狙われるのは「露出した秘密ファイルや設定の不備」であって、WordPress自体ではありません。世界で最も使われているCMSなので、スキャナの“定番リスト”に含まれるだけです。
  • やるべきは「隠す」ことではなく、秘密を公開領域に置かない・危険パスを遮断する・最新に保つという中身の対策です。

過信は禁物

  • ここで挙げた対策は「被害の入口を大きく減らす」ものですが、あらゆる攻撃を防ぐ“万能薬”ではありません。ログの定期確認と、ソフトの更新を続けることが前提です。
  • 逆に言えば、基本を押さえておけば、日々飛んでくる無差別スキャンの大半は空振りに終わります。まずは足元の“置き場所・権限・遮断設定”から見直しましょう。

まとめ

 ログに並ぶ“不審なアクセス”の多くは、世界中を無差別に狙う自動スキャンで、名乗り(Googlebot等)は当てになりません。困ったら、①応答を集計して「200」が無いか、②発信元を逆引きして正体を確かめる、③秘密ファイルが公開領域に無いか——この3点を確認すれば、落ち着いて判断できます。そして日頃は、秘密を公開しない・危険パスを遮断する・最新に保つ、という基本を押さえること。これだけで、毎日飛んでくるスキャンの大半は“空振り”に終わります。

 「自社サイトに、外から見える弱点(なりすましメール対策・HTTPS・WordPressの設定漏れなど)がないか」は、URLを入れるだけ・登録不要で無料診断できます。ログの見方や具体的な遮断設定まで相談したい方は、情報処理安全確保支援士が30分の無料相談でご案内します。あわせて、中小企業のセキュリティ診断とは?無料でできるチェック項目と進め方もご覧ください。

参考・出典: Google「Verify Google crawlers and fetchers(Googleのクローラー確認方法。User-Agentは詐称され得るため逆引き+正引き、または公式IP範囲で確認)」(Google 公式ドキュメント)/CERT/CC「PHP-CGI query string parameter vulnerability(VU#520827・CVE-2012-1823。Apache mod_php/nginx+php-fpm構成は非該当)」(CERT Coordination Center
※本文中の件数・発信元IP数・応答内訳は、当社運営サイトのアクセスログ(約3週間分)を実測・集計した一次データです。ログ画面の図はダミーデータによるイメージです(実在のIP・ホスト名ではありません)。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次