| 状況 | 発生事象 |
|---|---|
| HTTPS通信用のTLS証明書(慣例的に「SSL証明書」と呼称)を発行する | 証明書情報がCertificate Transparency Log(CT Log)に登録される |
| CT Logに登録される | 第三者が誰でも検索・取得可能な状態になる |
| CT Logを監視する攻撃botがドメインを発見する | 当該ドメインに対してHTTPアクセスを開始する |
以下のすべてが対象となる。
- 本番サイト
- ステージング環境
- 内部向けにのみ共有されたページ
- SNS等で外部公開していないサイト
- ドメイン設定および証明書発行の直後
- 公開後も定期的に発生する
特定パスへの決め打ちアクセスを行う。例として以下のパスがある。
/.env/.gitignore/admin/index.php.bak
事例として、本来のアクセスが27件であるサイトに対しbotアクセスが1,620回発生したケースがある。
- HTTPSでサイトを公開する際にはTLS証明書の発行が必要となる。
- 証明書発行時に「透明性レポート」としてCT Logが記録される。
- CT Logは公開され、誰でも検索可能。
- 例:
inventivehq.com/tools/security/certificate-transparency-lookupで任意のドメインに紐づくサブドメイン一覧を取得できる。 - CT Logに登録されるのは「正当に証明書を発行した」という宣言であり、当該ドメインが外部からアクセス可能かは別問題である。
- TLS証明書の発行が無料化・自動化されている。
- インフラ事業者がCLIや管理画面経由で証明書発行を自動化しているケースが多い。
- 利用者が証明書発行を意識せずにHTTPS公開状態となる。
- アクセス数に応じて課金される従量課金型インフラを使用している場合、bot由来のアクセスにより課金額が増加する。
公開直後はセキュリティ設定が未完了であったり、不要ファイルが残存している可能性がある。攻撃bot到来時に以下のような状態であった場合、情報が漏洩する。
- 管理画面の認証情報がデフォルト値(例:
admin/password)のまま放置されている - 開発用サーバで画面上にログが出力される設定のまま放置されている
.gitignoreの設定漏れにより.env等の機密ファイルがデプロイされている
- 攻撃側は自動ツールを実行して放置するのみであり、コストはほぼ発生しない。
- 個別サイトを標的にしているわけではなく、CT Log由来で発見された全ドメインに対して網羅的に実行している。
- 攻撃目的のスキャンbot以外にも、Meta社や各種AIサービスのクロールbotによる大量アクセスでクラウド利用料金が増加する事例も報告されている。
- dev/stg環境には本番ドメインとは別のドメインを使用する。
- ドメイン名は機械的に推測されにくいもの(コードネーム等)を使用する。
- 理由: 機械的に推測できる場合、攻撃bot側があてずっぽうでアクセスを試みる可能性がある。
- 開発中のサービスに独自ドメインを割り当てる場合、サイト全体にBasic認証またはIP制限を適用する。
- 効果: botは初回リクエストで応答が得られない場合、攻撃を継続せず離脱する。
- 本番サーバにアップする前に、コーディングエージェント等のAIに対し安全性をレビューさせる。
- Cloudflare等のWAFを導入し、海外からのアクセスを遮断する(国内向けサービスの場合)。
- bot的挙動の遮断機能も利用可能だが、完全ではない。
- 補足的対策: WAFを前段に配置しても、後段サーバのIPアドレスが既に漏洩している場合、直接アクセスが可能となる。この場合、特定のWAF由来HTTPヘッダが存在しないリクエストを後段サーバ側で遮断する設定を行う。
- 自前で証明書を発行可能な場合、
*.example.com形式のワイルドカード証明書を発行する。 - 効果: CT Logには
*のみが記録され、個別のサブドメインは記録されない。 - 注意:
dev.やstg.等の一般的なサブドメイン名はあてずっぽうでアクセスされる可能性がある。
- インフラ事業者がワイルドカード運用しているドメインで運用する。
- 例:
*.workers.dev、*.asia-northeast1.run.app - Cloud Runの新規インスタンスに対してこの種のスキャンが即座に来た事例は確認されていない。
- 技術的にはCT Logへの登録を回避することは可能。
- 実務上、CT Logに登録されていない証明書を使用するとブラウザでエラーが表示される。
- そのため、外部公開を目的とするサイトでは登録回避は採用できない。
- 内部向けに限定する場合は採用可能。
- 「SSL証明書」は慣例的な呼称で、正確には「TLS証明書」である。
- HTTPSでアクセス可能なサーバを公開した時点で、攻撃botの到来は不可避である。
- 内部向けサーバであっても、セキュリティ対策を省略することはできない。