DNS Armor の高度な脅威検出のスタートガイド

1. 概要

Infoblox を活用した DNS Armor は、Google Cloud ワークロードに DNS レイヤのセキュリティを提供するフルマネージドサービスです。高度な脅威検出機能は、運用上の複雑さやパフォーマンスのオーバーヘッドを増やすことなく、攻撃チェーンの最も早い段階である DNS クエリで悪意のあるアクティビティを検出するように設計されています。

この Codelab では、 DNS Armor サービスを構成してテストする手順について説明します。必要なネットワークインフラストラクチャを設定し、脅威検出機能を作成し、DNS 脅威をシミュレートしてサービスをテストします。最後に、ログエクスプローラを使用して脅威ログを分析します。

構築するもの

この Codelab では、次のリソースをプロビジョニングします。

2 つの VPC ネットワーク: network-a と network-b
network-a には、us-east4 リージョンと us-central1 リージョンのサブネットと仮想マシンが含まれます。
network-b には、us-east4 のサブネットと仮想マシンのみが含まれます。
DNS クエリを検査するように構成された DNS Armor の高度な脅威検出機能。

学習内容

VPC や仮想マシンなど、必要なネットワークリソースをプロビジョニングする方法。
高度な脅威検出機能をデプロイし、特定のネットワークを除外する方法。
脅威シミュレーションスクリプトを使用して脅威検出構成を検証する方法。
ログエクスプローラで脅威ログを分析する方法。

必要なもの

Google Cloud プロジェクト
gcloud コマンドラインツールへのアクセス

2. 前提条件

このセクションでは、次のタスクを行います。

Google Cloud プロジェクトが、必要な組織のポリシーの制約を満たしていることを確認します。
ユーザーアカウントに必要な IAM ロールと権限があることを確認します。
この Codelab に不可欠な Google Cloud API を有効にします。
Compute Engine サービスアカウントに roles/logging.viewer IAM ロールを割り当てます。

組織のポリシーの制約

この Codelab を正常に完了するには、プロジェクトに適用されている組織のポリシーの制約を確認してください。特定のポリシーによって、必要なリソースのプロビジョニングが妨げられる可能性があります。次の制約は、この Codelab の構成に影響する可能性があります。

constraints/gcp.resourceLocations: リソースを作成できるリージョンを制限します。この Codelab では us-east4 と us-central1 が必要です。
constraints/compute.vmExternalIpAccess: パブリック IP アドレスを持つ仮想マシンの作成を防ぎます。Codelab の --no-address フラグの使用に従わない場合、設定が妨げられる可能性があります。
constraints/compute.shieldedVm: シールドされた VM の作成を強制します。Codelab の VM 作成コマンドでは指定されていないため、エラーが発生する可能性があります。
constraints/gcp.restrictServiceUsage: 有効にできる Google Cloud API を制限します。compute.googleapis.com、networksecurity.googleapis.com、logging.googleapis.com、monitoring.googleapis.com が許可されていない場合、Codelab がブロックされる可能性があります。

IAM のロールと権限

この Codelab を正常に完了するには、ユーザーに付与されている IAM ロールと権限を確認してください。この Codelab を完了するには、次の IAM ロールと権限が必要です。

Service Usage 管理者 （roles/serviceusage.serviceUsageAdmin）: Codelab に必要な Google Cloud API を有効にする。
Compute ネットワーク管理者 （roles/compute.networkAdmin）: VPC ネットワーク、サブネット、Cloud NAT を作成して管理する。
Compute セキュリティ管理者 （roles/compute.securityAdmin）: 仮想マシンへの SSH アクセスのファイアウォールルールを構成する。
Compute インスタンス管理者（v1） （roles/compute.instanceAdmin.v1）: ラボに必要な仮想マシンを作成して管理する。
IAP で保護されたトンネルユーザー （roles/iap.tunnelResourceAccessor）: Identity-Aware Proxy（IAP）を介して SSH を使用して仮想マシンに接続する。
ネットワークセキュリティ管理者 （roles/networksecurity.admin）: DNS Armor 脅威検出機能を作成して管理する。
ログ閲覧者 （roles/logging.viewer）: ログエクスプローラで脅威ログを表示して分析する。

Google Cloud API

必要な Google Cloud API がプロジェクトで有効になっていることを確認してください。

1. 必要な API を有効にするには、Cloud Shell で次の gcloud コマンドを実行します。

gcloud services enable compute.googleapis.com \
networksecurity.googleapis.com \
logging.googleapis.com \
monitoring.googleapis.com

**2. API が有効になっていることを確認するには、Cloud Shell で次の gcloud コマンドを実行します。

gcloud services list --enabled

Compute Engine サービスアカウント

テストスクリプトには、Cloud Logging から脅威ログを読み取る権限が必要です。スクリプトはデフォルトの Compute Engine サービスアカウントを使用する VM から実行されるため、このサービスアカウントに roles/logging.viewer IAM ロールを割り当てる必要があります。

1. 環境変数を設定するには、Cloud Shell で次のコマンドを実行します。

export PROJECT_ID=$(gcloud config get-value project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

**2. Compute Engine SA にログ閲覧者のロールを付与する。Cloud Shell で次の gcloud コマンドを実行します。

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
--role="roles/logging.viewer"

3. 基本的な環境設定

このセクションでは、次のタスクを行います。

カスタムサブネットを使用して VPC ネットワーク（network-a と network-b）を作成します。
network-a と network-b の両方で、インターネット下り（外向き）用に Cloud Router と Cloud NAT を構成します。
network-a と network-b の両方で、IAP の IP 範囲から VM への SSH アクセスを許可するファイアウォールルールを作成します。
パブリック IP アドレスなしで、network-a と network-b の両方に Linux 仮想マシンをプロビジョニングします。

VPC とサブネットを作成する

1. us-east4 リージョンと us-central1 リージョンに network-a とそのサブネットを作成する 。Cloud Shell で次の gcloud コマンドを実行します。

gcloud compute networks create network-a --subnet-mode=custom

gcloud compute networks subnets create subnet-a-use4 \
--network=network-a \
--range=10.10.0.0/24 \
--region=us-east4

gcloud compute networks subnets create subnet-a-usc1 \
--network=network-a \
--range=10.10.1.0/24 \
--region=us-central1

**2. us-east4 リージョンに network-b とそのサブネットを作成する。Cloud Shell で次の gcloud コマンドを実行します。

gcloud compute networks create network-b --subnet-mode=custom

gcloud compute networks subnets create subnet-b-use4 \
--network=network-b \
--range=10.20.0.0/24 \
--region=us-east4

インターネット下り（外向き）を構成する

1. network-a 用に Cloud Router と Cloud NAT を作成する 。これにより、パブリック IP を持たない VM のインターネット下り（外向き）が可能になります。

gcloud compute routers create router-a-use4 \
--network=network-a \
--region=us-east4

gcloud compute routers nats create nat-a-use4 \
--router=router-a-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4

gcloud compute routers create router-a-usc1 \
--network=network-a \
--region=us-central1

gcloud compute routers nats create nat-a-usc1 \
--router=router-a-usc1 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-central1

**2. network-b 用に Cloud Router と Cloud NAT を作成する。これにより、パブリック IP を持たない VM のインターネット下り（外向き）が可能になります。

gcloud compute routers create router-b-use4 \
--network=network-b \
--region=us-east4

gcloud compute routers nats create nat-b-use4 \
--router=router-b-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4

ファイアウォールルールを構成する

1. network-a 用にファイアウォールルールを作成する 。これにより、IAP の IP 範囲からの SSH アクセスが可能になります。Cloud Shell で次の gcloud コマンドを実行します。

gcloud compute firewall-rules create allow-ssh-iap-a \
--network=network-a \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20

**2. network-b 用にファイアウォールルールを作成する。これにより、IAP の IP 範囲からの SSH アクセスが可能になります。Cloud Shell で次の gcloud コマンドを実行します。

gcloud compute firewall-rules create allow-ssh-iap-b \
--network=network-b \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20

仮想マシンを作成する

1. network-a に Linux VM を作成する

gcloud compute instances create vm-a-use4 \
--zone=us-east4-c \
--network=network-a \
--subnet=subnet-a-use4 \
--no-address \
--scopes=cloud-platform

gcloud compute instances create vm-a-usc1 \
--zone=us-central1-a \
--network=network-a \
--subnet=subnet-a-usc1 \
--no-address \
--scopes=cloud-platform

**2. network-b に Linux VM を作成する

gcloud compute instances create vm-b-use4 \
--zone=us-east4-c \
--network=network-b \
--subnet=subnet-b-use4 \
--no-address \
--scopes=cloud-platform

4. DNS 脅威検出機能を作成する

このセクションでは、次のタスクを行います。

脅威検出機能を作成する。
脅威検出機能を一覧表示する。
リソースを記述する。

VPC、サブネット、仮想マシンがプロビジョニングされたので、次のステップでは DNS 脅威検出機能を作成します。

1. gcloud beta network-security dns-threat-detectors create コマンドを使用して脅威検出機能を作成する 。--excluded-networks フラグを使用して network-b を除外します。

gcloud beta network-security dns-threat-detectors create my-dns-threat-detector \
--location=global \
--provider=infoblox \
--excluded-networks=projects/$PROJECT_ID/global/networks/network-b

**2. 脅威検出機能を一覧表示するして、作成を確認します。

gcloud beta network-security dns-threat-detectors list --location=global

3. リソースを記述する して、network-b が excludedNetworks に正しくリストされていることを確認します。

gcloud beta network-security dns-threat-detectors describe my-dns-threat-detector --location=global

出力例:

createTime: '2025-08-06T17:06:30.297586089Z'
excludedNetworks:
- projects/dns-armor-demo-project/global/networks/network-b
name: projects/dns-armor-demo-project/locations/global/dnsThreatDetectors/my-dns-threat-detector
provider: INFOBLOX
updateTime: '2025-08-27T01:14:09.666357239Z'

5. 設定をテストする

このセクションでは、次のタスクを行います。

VM に SSH 接続する。
VM に Git をインストールする。
Infoblox 脅威検出シミュレータリポジトリのクローンを作成する。
スクリプトを実行して、生成された出力を分析する。

VM からエミュレートされた悪意のある DNS クエリを生成して、設定を検証します。network-a からのクエリのログエントリが表示されますが、network-b. からはログが生成されません。

1. vm-a-use4 に SSH 接続する 。Cloud Shell で次の gcloud コマンドを実行します。

gcloud compute ssh vm-a-use4 --zone=us-east4-c

**2. VM に Git をインストールする。

sudo apt-get install git -y

3. Infoblox 脅威検出シミュレータリポジトリのクローンを作成する 。

git clone https://github.com/infobloxopen/ib-threat-detection-simulator

4. ディレクトリをシミュレータのディレクトリに変更する 。

cd ib-threat-detection-simulator/threat_detection_simulator/

5. スクリプトを実行して、生成された出力を分析する 。

注: このスクリプトは、既知の悪意のあるドメインまたは疑わしいドメインにクエリを送信して、さまざまな DNS ベースの脅威をシミュレートします。テストとデモンストレーションのみを目的として設計されています。

このツールは、指定されたドメインのリストに対してローカルの dig コマンドを実行して、DNS クエリトラフィックを生成します。主な目的は、悪意のある DNS アクティビティをシミュレートすることです。
デフォルトの高度な分析モードでは、標準的なフィッシングやマルウェア、高度な脅威など、さまざまなカテゴリの脅威を再現します。
これらの高度なシミュレーションには、Mylobot および Suppobox マルウェアファミリーに関連付けられた実際のドメイン生成アルゴリズム（DGA）ドメインへのクエリが含まれ、DNS トンネリング（DNST）攻撃もエミュレートされます。

スクリプトとシミュレートする脅威の詳細については、GitHub リポジトリをご覧ください。

スクリプトを実行可能にします。

chmod +x run.sh

スクリプトを実行します。

./run.sh info basic

6. 出力例

次のスクリーンショットは、network-a の VM からのスクリプト出力の一部を示しています。出力は、脅威の 100% が検出されたことを示しています。

次のスクリーンショットは、network-b の VM からのスクリプト出力の一部を示しています。出力は、脅威の 0% が検出されたことを示しています。これは、脅威検出機能の作成時に network-b が除外されたため、想定どおりです。

7. SSH セッションを終了して、Cloud Shell に戻る 。

exit

6. ログエクスプローラで脅威ログを表示する

生成された脅威ログは、テストスクリプトの実行後にログエクスプローラで確認できます。これは、脅威ログが Cloud Logging に書き込まれるためです。

ログエントリの例

このセクションでは、検出された DNS 脅威のログエントリの例を示します。これには、ソース IP、クエリされたドメイン、脅威カテゴリなど、DNS Armor によってキャプチャされた詳細情報が含まれます。分析するログの構造と内容を理解するための参考資料として使用してください。

{
  "insertId": "1izjkneb44",
  "jsonPayload": {
    "partnerId": "Infoblox",
    "detectionTime": "2025-08-08T01:49:54.092250101Z",
    "dnsQuery": {
      "authAnswer": false,
      "rdata": "random.malicious-domain.com.\t300\tIN\ta\t196.251.118.39",
      "protocol": "UDP",
      "projectNumber": "1234567890",
      "responseCode": "NOERROR",
      "queryType": "A",
      "location": "us-east4",
      "sourceIp": "10.10.0.2",
      "queryName": "random.malicious-domain.com.",
      "vmProjectNumber": "1234567890",
      "vmInstanceId": "01234567899876543210",
      "destinationIp": "",
      "queryTime": "2025-08-08T01:49:53.712692495Z"
    },
    "threatInfo": {
      "severity": "HIGH",
      "confidence": "HIGH",
      "threatDescription": "",
      "category": "EmergentDomain",
      "threatId": "Suspicious_EmergentDomain",
      "type": "Suspicious",
      "threatIndicator": "izumisv1.cc",
      "threatIndicatorType": "FQDN",
      "threat": "Suspicious",
      "threatFeed": "suspicious-noed"
    }
  },
  "resource": {
    "type": "networksecurity.googleapis.com/DnsThreatDetector",
    "labels": {
      "resource_container": "projects/1234567890",
      "id": "",
      "location": "us-east4"
    }
  },
  "timestamp": "2025-08-08T01:49:54.092250101Z",
  "severity": "INFO",
  "logName": "projects/dns-armor-demo-project/logs/networksecurity.googleapis.com%2Fdns_threat_events",
  "receiveTimestamp": "2025-08-08T01:49:55.290965780Z"
}

ログエクスプローラでログを表示する

1. Google Cloud コンソールで Monitoring[Monitoring] セクションに移動し、Logs explorer[ログエクスプローラ] を選択します。

**2. すべての DNS Armor 脅威ログをフィルタするには、次のクエリを使用します。これにより、DNS 脅威検出機能のリソースタイプに基づいてログがフィルタされます。

resource.type="networksecurity.googleapis.com/DnsThreatDetector"

3. us-east4 リージョンのログをフィルタするには、ロケーションのフィルタを追加します。このクエリでは、us-east4 リージョンで検出された脅威のみが表示されます。

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
resource.labels.location="us-east4"

4. ソースネットワークでログをフィルタするには、DNS クエリのソース IP アドレスに基づいてログをフィルタし、特定の VPC ネットワークから発生した脅威を確認します。

network-a（サブネット 10.10.0.0/24 と 10.10.1.0/24）のログを表示するには:

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
(jsonPayload.dnsQuery.sourceIp:"10.10.0." OR jsonPayload.dnsQuery.sourceIp:"10.10.1.")

network-b（サブネット 10.20.0.0/24）のログを表示するには:

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
jsonPayload.dnsQuery.sourceIp:"10.20.0."

7. クリーンアップ

今後の課金を避けるため、この Codelab で作成したリソースを削除します。クリーンアップコマンドを実行するときは、VM のシェルを終了して Cloud Shell に戻ってください。

1. VM を削除します。

gcloud compute instances delete vm-a-use4 --zone=us-east4-c --quiet

gcloud compute instances delete vm-a-usc1 --zone=us-central1-a --quiet

gcloud compute instances delete vm-b-use4 --zone=us-east4-c --quiet

**2. ファイアウォールルールを削除します。

gcloud compute firewall-rules delete allow-ssh-iap-a --quiet

gcloud compute firewall-rules delete allow-ssh-iap-b --quiet

3. Cloud NAT ゲートウェイを削除します。

gcloud compute routers nats delete nat-a-use4 --router=router-a-use4 --region=us-east4 --quiet

gcloud compute routers nats delete nat-a-usc1 --router=router-a-usc1 --region=us-central1 --quiet

gcloud compute routers nats delete nat-b-use4 --router=router-b-use4 --region=us-east4 --quiet

4. Cloud Router を削除します

gcloud compute routers delete router-a-use4 --region=us-east4 --quiet

gcloud compute routers delete router-a-usc1 --region=us-central1 --quiet

gcloud compute routers delete router-b-use4 --region=us-east4 --quiet

5. サブネットを削除します。

gcloud compute networks subnets delete subnet-a-use4 --region=us-east4 --quiet

gcloud compute networks subnets delete subnet-a-usc1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-b-use4 --region=us-east4 --quiet

6. DNS 脅威検出機能を削除します。

gcloud beta network-security dns-threat-detectors delete my-dns-threat-detector --location=global --quiet

7. VPC を削除します。

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. 完了

おめでとうございます！DNS Armor 脅威検出機能の構成、デプロイ、テストが完了しました。Google Cloud 環境を DNS ベースの脅威から保護する実践的な経験を積むことができました。

この Codelab では、次のことを行いました。

複数の VPC、サブネット、仮想マシンを使用してネットワーク環境をプロビジョニングしました。
Cloud NAT を使用して、プライベート VM のインターネット下り（外向き）を構成しました。
DNS Armor 脅威検出機能をデプロイし、特定のネットワークを除外する方法を学習しました。
DNS 脅威をシミュレートし、脅威検出構成を検証しました。
ログエクスプローラで脅威ログを分析して、悪意のある DNS アクティビティを特定して理解しました。

DNS Armor の高度な脅威検出のスタートガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

1. 概要

構築するもの

学習内容

必要なもの

2. 前提条件

組織のポリシーの制約

IAM のロールと権限

Google Cloud API

Compute Engine サービス アカウント

3. 基本的な環境設定

VPC とサブネットを作成する

インターネット下り（外向き）を構成する

ファイアウォール ルールを構成する

仮想マシンを作成する

4. DNS 脅威検出機能を作成する

5. 設定をテストする

6. ログ エクスプローラで脅威ログを表示する

ログエントリの例

ログ エクスプローラでログを表示する

7. クリーンアップ

8. 完了

次のステップ

リファレンス ドキュメント

DNS Armor の高度な脅威検出のスタートガイド

Compute Engine サービスアカウント

ファイアウォールルールを構成する

6. ログエクスプローラで脅威ログを表示する

ログエクスプローラでログを表示する

リファレンスドキュメント