AlienGate に新しいドメインを追加して認証する方法

• 対象読者: AlienGate のワークスペースに新しいウェブサイト・サブドメイン・ホストを初めて登録するすべての方
• 適用範囲: app.aliengate.io — Infrastructure Security → Websites & IPs → ターゲットを追加 (+ Add Target)
• 所要時間: 製品上の操作は約 2 分。これに加えて、テキストファイルを 1 つウェブサーバーへ公開する時間が必要です
• 次に読む記事: 記事 01 — 脆弱性診断の実行方法

このガイドで実現できること

このガイドを終えると、次の状態になります。

• 新しいホストが自分の所有物として認証済みになり、所有権の証明がそのホスト自身の上に公開されている。
• そのホストが Websites & IPs に資産として表示され、アタックサーフェスに計上されている。
• 最初のディスカバリー (探索) パスがすでに実行中。これは認証によって自動的に開始されるもので、利用者が指示する必要はありません。
• Scanner Console でターゲットとして選択し、実際にスキャンできる状態になっている。

なぜ AlienGate はこの手順を求めるのか

能動的な脆弱性スキャンは侵襲的な行為です。クロールを行い、フォームを送信し、ペイロードを送信します。自分が管理していないホストに対してこれを実行することは、地域によっては失礼な行為から違法行為までの範囲に該当します。入力されたホストを無条件にスキャンするプラットフォームは、第三者にとって都合のよい攻撃手段になってしまいます。

そのため AlienGate は、利用者がそのホストを管理していると証明するまでスキャンを実行しません。そして受け付ける証明は、そのサーバーへアクセスできる人だけが実行できる唯一の方法、すなわちそのホスト上にファイルを公開することです。

これは検索コンソールや認証局が同じ理由で採用している仕組みと同一です。所要時間は 2 分程度で、1 つのホストにつき 1 回だけ実施します。

全体の流れ

Websites & IPs → ターゲットを追加 → ホスト名を入力
   ↓
Next Step パネル                 AlienGate がそのホスト用のトークンを発行
   ↓
/.well-known/aliengate-verify.txt にトークンを公開
   ↓
その URL を自分のブラウザーで開いて確認      ← この手順を省略しない
   ↓
Verify ──► Verifying Domain… ──┬─► Domain Verified Successfully!
                               └─► Verification Failed ──► ファイルを修正 ──► Verify Again
   ↓
ホストが Websites & IPs に表示され、最初のディスカバリーパスが自動的に開始
   ↓
スキャン可能に: Scanner Console → スキャン対象 (Scan targets)

ステップ 1 — ターゲットを追加し、Next Step パネルを読む

Infrastructure Security → Websites & IPs (app.aliengate.io/dashboard/manage-targets) を開き、右上の ターゲットを追加 (+ Add Target) をクリックします。登録したいホストを入力します。

AlienGate がそのホスト用の認証トークンを発行し、Next Step パネルを表示します。

3 つのステップが番号付きで示されます。製品の表記は次のとおりです。

トークンはステップ 01 の下にある濃色のフィールドに表示されます。aliengate-verify=2011eef8b74c4498 のような形式で、横に Copy ボタンと Download ボタンがあります。文字列をコピーして自分でファイルを作成しても、用意されたファイルをダウンロードしてそのままアップロードしても構いません。

フィールドの表示は省略されています。 パネル上のトークンは途中で切れて表示されます (aliengate-verify=2011eef…)。見えている文字を手入力せず、Copy または Download を使用してください。

初回で成功するかどうかを左右する点が 2 つあります。

• パスは厳密です。 /.well-known/aliengate-verify.txt、しかもそのホストのルート直下です。/aliengate-verify.txt でも、親ドメイン上の同じパスでもありません。先頭のドットにより .well-known は Unix 系システムで隠しディレクトリとなり、これがデプロイから抜け落ちる最も多い原因です。
• 「HTTP(S) 経由で公開アクセスできる」とは、文字どおり公開を意味します。 ログイン、IP 許可リスト、VPN、親ディレクトリから継承された Deny from all のいずれもあってはなりません。認証を行うのは、セッションも特別扱いも持たないインターネット上の匿名クライアントです。

ステップ 2 — ファイルを公開し、自分の目で確認する

普段静的ファイルを配信している方法 (デプロイ、アップロード、ボリュームマウント、nginx の location ブロック 1 行など) でファイルをサーバーに配置します。そのうえで、Verify を押す前に、ブラウザーでその URL を開きます。

表示されるべきなのは、プレーンテキストのトークンだけです。

この確認は 1 秒で終わりますが、1 回で認証を通すか 3 回やり直すかの分かれ目になります。認証エラーの文面だけでは分からない次のような原因を、ここで発見できます。

• ウェブサーバーがデザイン付きの 404 ページを HTTP 200 で返している — ファイルは「存在する」が、中身はエラーテンプレート。
• HTTPS へのリダイレクト先の証明書を、認証側が受け付けない。
• 拡張子を非表示にしているエディターによって aliengate-verify.txt.txt として保存されている。
• サーバーが .txt に添付ファイルとしての Content-Disposition を設定しているため、インライン表示ではなくダウンロードとして配信されている。
• 親ディレクトリの一覧表示を無効化した設定が、ファイル自体もブロックしている。
• CDN や WAF が、認識できないクライアントにチャレンジページを返している。

自分が管理していないネットワーク上のブラウザーからトークンを読めるなら、認証側も読めます。 それがこのテストの本質です。社内ネットワークや VPN 経由での確認では何も証明できません。モバイル回線のスマートフォンか、VPN を切ったシークレットウィンドウで確認してください。

ステップ 3 — 認証する

Next Step パネルに戻り、Verify をクリックします。

AlienGate が Verifying Domain… ("We're checking your verification file. This may take a moment." — 認証ファイルを確認しています。少しお待ちください) を表示します。プログレスバーと Verifying ownership via HTML file… というサブテキストが表示され、途中で誤りに気づいた場合のために Cancel ボタンがあります。

トークンが一致しない場合は Verification Failed が表示され、Cancel と Verify Again が選べます。ファイルを修正して再度チェックを実行してください。トークンは試行のたびに変わることはないため、コピーし直す必要はありません。

成功すると次の表示になります。

Domain Verified Successfully! ("shop.0-day.jp has been verified and added to your attack surface." — shop.0-day.jp は認証され、アタックサーフェスに追加されました)。Done をクリックします。右上に Domain created successfully のトーストが表示されます。

ファイルはそのまま残してください。 削除するよう指示する表示はありません。削除すると、次回プラットフォームが確認した際にホストの認証が通らなくなります。/.well-known/aliengate-verify.txt はサイトの一部として扱い、デプロイのたびに配信され続けるようにしてください。

ステップ 4 — Websites & IPs の変化を読む

資産一覧が再読み込みされ、新しいホストが表示されます。

変化したのは 3 点で、分かりやすいのはそのうち 1 つだけです。

1. ホストが一覧に追加されている。 行が追加され、プライマリドメイン配下の Exposed Service として分類されます。No technologies detected、脆弱性 0 Safe、No SSL issues と表示されます。

2. Subdomains のカウントは増えたが、Verified Domains は増えていない。 画面では Subdomains が 3 から 4 になる一方、Verified Domains は 1 のままです。すでに保有しているドメインのサブドメインを認証した場合、それはサブドメインとして計上され、2 つ目の認証済みドメインにはなりません。プラン上の上限を管理している場合は把握しておくとよい点です。

3. 自動的にスキャンが始まっている。 ホスト名の下に Scanning now · 0% と表示されます。認証が完了すると、ディスカバリーパスが即座に開始されます。利用者が指示する必要も、待つ必要もありません。

新規行の初期値は検出結果ではありません。 No technologies detected や 0 Safe は、プラットフォーム上に 4 秒前に生まれたホストの状態を表しているにすぎません。いま始まったパスがフィンガープリントを埋めていきます。

ステップ 5 — この自動パスが何であり、何でないかを理解する

Scanner Console を開くと、ライブのセキュリティターミナルで実行中の様子を確認できます。

[i] 2 job(s) active.
[Subdomain Finder] shop.0-day.jp — Extracting subdomains from Certificate Transparency Logs.
[Web Application Scan] shop.0-day.jp — 0%

12:58:50  [+]  Engines online — 2 job(s) dispatched.
12:58:50  [i]  Streaming live telemetry from the scan engine.
12:58:51  [~]  shop.0-day.jp · waiting for a scan slot

Subdomain Finder のジョブが自動パスです。これは偵察 (reconnaissance) であり、証明書透明性 (Certificate Transparency) ログから名前を抽出して、そのホスト配下に何が存在するかを把握します。製品上は "Reconnaissance — observations, not vulnerabilities" (偵察 — 脆弱性ではなく観測情報) に分類されており、この表記は正確です。

これは脆弱性スキャンではありません。 アプリケーションをクロールせず、何もテストせず、ログインの内側は当然見ません。このパスしか実行されていないホストに検出結果が出ないのは当然であり、それはセキュリティ上の状態について何も意味しません。

この点は、初めて使うときに戸惑いやすい挙動の説明にもなります。認証の直後に自分でエンジンを 1 つ起動すると、ターミナルには 2 jobs active と表示され、自分のジョブはディスカバリーパスの後ろで waiting for a scan slot (スキャン枠の待機中) となります。これは不具合ではなくキューが正常に機能している状態です。全体の進捗率は両者の平均であるため、エンジンごとのプログレスバーを見てください。

次に行うこと

これでホストは Scanner Console で選択できるターゲットになりました。ここから先は次のとおりです。

• 記事 01 — 脆弱性診断の実行方法 — スキャンタイプを選び、新しいターゲットを選択して実行し、結果を読み解きます。
• 記事 04 — 認証付きスキャンを実行する方法 — ホストにログイン機能がある場合はこちらが本命です。実際のアプリケーションの攻撃対象領域の大半はサインインページの内側にあり、セッションを持たないスキャナーは公開部分だけを見て「問題なし」と報告してしまいます。
• 記事 03 — AlienGate のスキャンはどの IP アドレスから送信されますか？ — ホストがファイアウォールや WAF の背後にある場合は、実行前にスキャナーのアドレスを許可してください。許可しないと、スキャンは「問題なし」ではなくブロックされた結果になります。

トラブルシューティング

リファレンス

認証ファイル

認証によって自動実行されるもの・されないもの

各画面の場所