Skip to content

Instantly share code, notes, and snippets.

@kobitoDevelopment
Last active May 6, 2026 02:10
Show Gist options
  • Select an option

  • Save kobitoDevelopment/ed979c8ee324615f40188e8f51272817 to your computer and use it in GitHub Desktop.

Select an option

Save kobitoDevelopment/ed979c8ee324615f40188e8f51272817 to your computer and use it in GitHub Desktop.

HTTPSサイト公開直後のbotによる大量アクセスの原因と対策

1. 状況と発生事象

1.1 発生する状況

状況 発生事象
HTTPS通信用のTLS証明書(慣例的に「SSL証明書」と呼称)を発行する 証明書情報がCertificate Transparency Log(CT Log)に登録される
CT Logに登録される 第三者が誰でも検索・取得可能な状態になる
CT Logを監視する攻撃botがドメインを発見する 当該ドメインに対してHTTPアクセスを開始する

1.2 攻撃の対象範囲

以下のすべてが対象となる。

  • 本番サイト
  • ステージング環境
  • 内部向けにのみ共有されたページ
  • SNS等で外部公開していないサイト

1.3 攻撃の発生タイミング

  • ドメイン設定および証明書発行の直後
  • 公開後も定期的に発生する

1.4 攻撃botの具体的動作

特定パスへの決め打ちアクセスを行う。例として以下のパスがある。

  • /.env
  • /.gitignore
  • /admin
  • /index.php.bak

事例として、本来のアクセスが27件であるサイトに対しbotアクセスが1,620回発生したケースがある。

1.5 CT Logの仕組み

  • HTTPSでサイトを公開する際にはTLS証明書の発行が必要となる。
  • 証明書発行時に「透明性レポート」としてCT Logが記録される。
  • CT Logは公開され、誰でも検索可能。
  • 例: inventivehq.com/tools/security/certificate-transparency-lookup で任意のドメインに紐づくサブドメイン一覧を取得できる。
  • CT Logに登録されるのは「正当に証明書を発行した」という宣言であり、当該ドメインが外部からアクセス可能かは別問題である。

1.6 問題が認知されにくい背景

  • TLS証明書の発行が無料化・自動化されている。
  • インフラ事業者がCLIや管理画面経由で証明書発行を自動化しているケースが多い。
  • 利用者が証明書発行を意識せずにHTTPS公開状態となる。

2. 結果として何が起こるか

2.1 経済的影響

  • アクセス数に応じて課金される従量課金型インフラを使用している場合、bot由来のアクセスにより課金額が増加する。

2.2 セキュリティ上の影響

公開直後はセキュリティ設定が未完了であったり、不要ファイルが残存している可能性がある。攻撃bot到来時に以下のような状態であった場合、情報が漏洩する。

  • 管理画面の認証情報がデフォルト値(例: admin/password)のまま放置されている
  • 開発用サーバで画面上にログが出力される設定のまま放置されている
  • .gitignore の設定漏れにより .env 等の機密ファイルがデプロイされている

2.3 攻撃側のコスト構造

  • 攻撃側は自動ツールを実行して放置するのみであり、コストはほぼ発生しない。
  • 個別サイトを標的にしているわけではなく、CT Log由来で発見された全ドメインに対して網羅的に実行している。

2.4 関連する事象

  • 攻撃目的のスキャンbot以外にも、Meta社や各種AIサービスのクロールbotによる大量アクセスでクラウド利用料金が増加する事例も報告されている。

3. 対策

3.1 開発・ステージング環境のドメイン分離

  • dev/stg環境には本番ドメインとは別のドメインを使用する。
  • ドメイン名は機械的に推測されにくいもの(コードネーム等)を使用する。
  • 理由: 機械的に推測できる場合、攻撃bot側があてずっぽうでアクセスを試みる可能性がある。

3.2 Basic認証・IP制限の適用

  • 開発中のサービスに独自ドメインを割り当てる場合、サイト全体にBasic認証またはIP制限を適用する。
  • 効果: botは初回リクエストで応答が得られない場合、攻撃を継続せず離脱する。

3.3 AIによる事前確認

  • 本番サーバにアップする前に、コーディングエージェント等のAIに対し安全性をレビューさせる。

3.4 WAFの導入

  • Cloudflare等のWAFを導入し、海外からのアクセスを遮断する(国内向けサービスの場合)。
  • bot的挙動の遮断機能も利用可能だが、完全ではない。
  • 補足的対策: WAFを前段に配置しても、後段サーバのIPアドレスが既に漏洩している場合、直接アクセスが可能となる。この場合、特定のWAF由来HTTPヘッダが存在しないリクエストを後段サーバ側で遮断する設定を行う。

3.5 ワイルドカード証明書の利用

  • 自前で証明書を発行可能な場合、*.example.com 形式のワイルドカード証明書を発行する。
  • 効果: CT Logには * のみが記録され、個別のサブドメインは記録されない。
  • 注意: dev.stg. 等の一般的なサブドメイン名はあてずっぽうでアクセスされる可能性がある。

3.6 ワイルドカード運用されている事業者ドメインの使用

  • インフラ事業者がワイルドカード運用しているドメインで運用する。
  • 例: *.workers.dev*.asia-northeast1.run.app
  • Cloud Runの新規インスタンスに対してこの種のスキャンが即座に来た事例は確認されていない。

4. CT Logへの登録回避について

  • 技術的にはCT Logへの登録を回避することは可能。
  • 実務上、CT Logに登録されていない証明書を使用するとブラウザでエラーが表示される。
  • そのため、外部公開を目的とするサイトでは登録回避は採用できない。
  • 内部向けに限定する場合は採用可能。

5. 補足事項

  • 「SSL証明書」は慣例的な呼称で、正確には「TLS証明書」である。
  • HTTPSでアクセス可能なサーバを公開した時点で、攻撃botの到来は不可避である。
  • 内部向けサーバであっても、セキュリティ対策を省略することはできない。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment