Nessus 脆弱性スキャンラボ — Azure

専用のTerraformデプロイ済みNessusスキャナーを使用して、稼働中のAzure Active Directoryラボ環境に対して実行した完全な脆弱性管理ライフサイクル — スキャン、発見、修正、検証。

このラボが実証すること

既存のAzure ADラボ環境に専用のUbuntu 24.04スキャナーVMをデプロイし、ドメインコントローラー、ファイルサーバー、ドメイン参加クライアントに対して未認証ベースラインスキャンと認証付きスキャンを実行し、結果を分析して、PowerShellによるレジストリハードニングでHigh重要度の検出結果（CVE-2013-3900）を修正し、再スキャンで修正を検証しました。これは、エンタープライズの脆弱性管理プログラムが継続的に実行している完全なワークフローです。

この検出件数の大幅な増加こそが、認証付きスキャンの存在意義そのものです。このラボで修正したHigh重要度のCVE-2013-3900検出結果は、未認証スキャンではまったく見えないローカルチェックです。

アーキテクチャ

Subnet-Servers上に配置された専用NESSUS01スキャナーアプライアンス。3台すべてのWindowsターゲットへの認証付きスキャンパスを備えています。管理プレーンには管理ワークステーションからのSSHトンネル経由でのみ到達可能 — ポート8834が公開されることはありません。

このスキャナーは、Enterprise Azure Infrastructure Automationシリーズの既存ラボVNetに参加し、独自のリモートステートを持つ独立したTerraform構成としてデプロイされます。

私が下した設計判断:

• ターゲットへのNessusインストールではなく、専用スキャナーVMを採用。 エンタープライズスキャナーは、ターゲットへの妨げのない経路を持つ独立したネットワークアプライアンスとして配置されます。ターゲットでもあるホストからスキャンすると、結果が汚染されます。
• 既存インフラに対するTerraformデータソース。 スキャナー構成は、既存のVNetとサブネットを複製するのではなくdataブロック経由で参照し、ステートは独自のnessus-scanner.tfstateキーに分離されているため、コアラボのステートに触れることなくスキャナーの作成・破棄が可能です。
• Nessus Web UI（ポート8834）は公開されない。 NSGは管理IPからのSSH（22）のみを許可し、SSHトンネル（ssh -L 8834:localhost:8834）経由でUIにアクセスします。管理プレーンの露出は、スキャナーアプライアンスが侵害される最も一般的な経路です。
• SSHキー認証のみ — ed25519キーペアを使用し、スキャナーではパスワード認証を無効化。

フェーズ0 — 事前セキュリティレビュー（スキャンするものを実践せよ）

何かをデプロイする前に、既存のNSGルールを監査しました。そして、このラボがまさに検出するために存在する類の設定ミスを発見しました。RDPルールがソース*（インターネット上の任意のIP）を許可していたのです。

事前監査: az network nsg listクエリにより、Allow-RDP-3389が任意のソース（*）に開放されていることが判明。

先に進む前に、これを現在のパブリックIPに限定しました:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

修正後の同じルール — ソースが単一の管理IPに制限された。

スキャナーを向ける前に自分の環境の露出を発見して修正することは、「ツールを実行する」から「セキュリティを行う」へのマインドセットの転換です。

フェーズ1 — Terraformでスキャナーをデプロイ

5つのリソース（パブリックIP、NSG、NIC、NSG関連付け、Ubuntu VM）を2分足らずでデプロイ:

terraform apply: 5追加、0変更、0破棄。出力にはそのまま使えるSSHコマンドが含まれる。

その後、SSHで接続し、ヘッドレスNessus Essentials 10.12.1のインストールを実行:

キーベース認証によるNESSUS01への最初のSSH接続 — Ubuntu 24.04が10.0.1.8で稼働、ヘッドレスNessusインストールの準備完了。

フェーズ2 — 未認証ベースラインスキャン

最初のスキャンは資格情報なし — これがネットワークセグメント上の攻撃者に見えるものです。

3台すべてのホスト（10.0.1.5、10.0.1.6、10.0.1.7）を対象としたBasic Network Scan。

ベースライン結果: 3ホスト全体で35件の検出結果、Auth列はFailを示す — Nessusはログインできず、すべての結果は外部からの観察のみによるもの。

フェーズ3 — 認証付きスキャン

認証付きスキャンは、内部脆弱性管理におけるエンタープライズ標準です。Remote Registryサービスを有効化し、Domainプロファイルで必要なファイアウォールルールグループを開放して、Windowsターゲットを準備しました:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

FS01でのターゲット準備 — RemoteRegistryが自動開始で実行中、WMIとFile & Printer SharingルールがDomainプロファイルで有効化。

スキャンでは、エンタープライズが要求するセキュリティオプションでWindows資格情報を構成しました: 資格情報を平文で送信しない、NTLMv2のみを使用。

Windows資格情報の構成 — ドメインLAB、NTLMv1無効、平文資格情報送信無効、スキャン用にRemote Registry自動開始を有効化。

認証付きスキャンの結果: 64件の検出結果 — まったく同じ3ホストに対する未認証ベースラインから83%の増加。

重要度順に並べた検出結果。High重要度のWinVerifyTrustローカルチェックが表示されている — 未認証スキャンでは検出する手段がなかった検出結果です。

フェーズ4 — High重要度の検出結果を分析: CVE-2013-3900

プラグイン#166555がDC01とFS01の両方で**WinVerifyTrust署名検証（CVE-2013-3900）**を検出しました — CVSS v3基本スコア8.8、Tenable VPR 9.0。EnableCertPaddingCheckレジストリ値が存在せず、攻撃者がAuthenticode署名を無効化することなく署名済み実行ファイルに悪意のあるコンテンツを追加できる状態になっていました。

完全な検出結果分析: プラグイン出力は10.0.1.5と10.0.1.6でレジストリ値が欠落していることを確認。Solutionセクションに正確な修正手順が記載されている。

この検出結果が重要な理由: これは**設定による緩和（mitigation-by-configuration）**型の脆弱性です。Microsoftが修正をオプトイン方式にしたため、パッチは存在しません。CVE公開から13年後の2026年時点でも、新しいWindows Server 2025イメージにはこの値が欠落した状態で出荷されていました。これはまさに、認証付きスキャンと構成管理だけが検出できる種類の問題です。

フェーズ5 — 修正と検証

プラグインのSolutionセクションに従って、影響を受けたホストに修正を適用しました — 64ビットとWow6432Nodeの両方のレジストリパスでEnableCertPaddingCheck = 1を設定 — その後、再スキャン前に両方のキーを検証:

New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

Get-ItemPropertyで修正の適用と検証を実行 — 両方のレジストリパスがEnableCertPaddingCheck : 1を返す。

そして、ほとんどの人が省略するステップ — 検証の再スキャンです。スキャナーが検出結果の消滅を確認するまで、チケットはクローズできません:

検証スキャン（History: 2）: High重要度のCVE-2013-3900検出結果は解決済み。残る最高重要度はMedium。

発見 → 分析 → 修正 → 検証。ループ完了。

実証されたスキル

仕事にとって重要な理由

脆弱性管理は、事実上すべてのセキュリティオペレーション、クラウドセキュリティ、GRCの役割における中核機能です。このラボは仕事全体をカバーしています — スキャナーを実行するだけでなく、その配置を安全に設計し、ターゲットを正しく準備し、結果のノイズからシグナルを見分け、修正を実行し、それが機能したことを証明します。未認証と認証付きの比較、そして検証の再スキャン。この2つが、実践者とツールのオペレーターを分けるものです。

評価レポート

完全なプロフェッショナル成果物 — エグゼクティブサマリー、方法論、CVE-2013-3900の詳細な検出結果分析、残留リスクの処理方針、優先順位付けされた推奨事項 — をPDFとして利用できます:

Vulnerability-Assessment-Report.pdf

Nessus Essentialsにはレポートエクスポート機能が含まれていないため、この成果物はスキャンデータから独立して作成されました — これ自体が、無料版には含まれていない評価レポート作成スキルです。

関連ラボ

このスキャナーは、私のEnterprise Azure Infrastructure Automationシリーズで構築した環境にデプロイされます:

• ラボ1 — Terraformインフラ
• ラボ2 — Active Directory
• ラボ3 — NTFSファイルサーバー & RBAC
• ラボ4〜6 — Azure RBAC

このリポジトリには機密情報は保存されていません — スキャナーはSSHキー認証のみを使用し、スキャン資格情報はNessusコンソールに直接入力され、コードにコミットされることはありません。