Windwos用のパケットアナライザーが用意されていないので、metabadgerとResource Monitorでどこまで確認できるのか試してみた
2025.08.26どうもさいちゃんです。皆さん、WindowsインスタンスでIMDSv2への移行を検討したことはありますか？
基本的にIMDSv2移行を考える時は下記のような移行計画を立てて、IMDSパケットアナライザーを使ったパケットの調査をすることになると思います。
- 移行対象インスタンスの絞り込み
- 移行対象の検証機インスタンスの中から「MetaDataNoToken」の値が過去数カ月0以上のものを抽出
- 2.で洗い出したインスタンスにIMDSパケットアナライザーを入れて、どのプロセスがIMDSv1を使用しているのか特定
- 対象のプロセスをIMDSv2対応ができるようにアップデートなどで対応
- 対応完了インスタンスから順にIMDSv2移行
しかし、IMDSパケットアナライザーを導入しようとしたところ、Windowsに対応していないことが判明しました。
一見対応しているように見えますが、READMEに従ってインストールを行うとMETABADGERをインストールさせられます。パケットキャプチャはできず、metabadgerとWindowsのResource Monitorのネットワークモニター機能を使用して確認するよう指示されています。
Windows環境でIMDSパケットアナライザーが使用できない場合の代替手段として、metabadgerとResource Monitorを使っていったいどこまで確認ができるのか試してみることにしました。
検証環境と前提条件
Windows環境においてIMDS（Instance Metadata Service）の使用状況を監視する場合、専用のパケットアナライザーツールが標準で提供されていないため、代替手段として以下の組み合わせを使用します
1. metabadger（過去データ分析）
- CloudWatchメトリクスからIMDSv1の使用履歴を取得
- リアルタイムパケット監視は行わず、蓄積されたメトリクスデータを分析
- 複数インスタンスの一括監視が可能
- 見やすいテーブル形式での結果表示
※インストールにはPython、pip、Git、AWS CLIのインストールが必須です
2. Resource Monitor（リアルタイム監視）
- Windowsの標準ツールを使用したネットワーク通信の監視
- 169.254.169.254への通信を行うプロセスの特定が可能
- どのアプリケーションがIMDSにアクセスしているかを確認
注意点： Linuxなどで使用するパケットアナライザーと違い、ログの蓄積はありません。
metabadgerのセットアップ
を参考に、Python、pip、git、AWS CLIをインストールします。
こちらを参考に、Python,pip,git,AWSCLIをインストールする
metabadgerのインストール
> pip3 install --user metabadger
# 長いので一部省略
Successfully installed boto3-1.40.11 botocore-1.40.11 click-8.2.1 colorama-0.4.6 jmespath-1.0.1 metabadger-0.1.11 numpy-2.3.2 pandas-2.3.1 python-dateutil-2.9.0.post0 pytz-2025.2 s3transfer-0.13.1 six-1.17.0 tabulate-0.9.0 tzdata-2025.2 urllib3-2.5.0
metabadgerのインストール場所に移動して動作確認します
C:\Users\Administrator\AppData\Roaming\Python\Python313\Scripts> .\metabadger.exe --help
Usage: metabadger [OPTIONS] COMMAND [ARGS]...
Metabadger is an AWS Security Tool used for discovering and hardening the
Instance Metadata service.
Options:
--version Show the version and exit.
--help Show this message and exit.
Commands:
cloudwatch-metrics Pull CloudWatch Metrics for MetadataNoToken usage
disable-metadata Disable the IMDS service on EC2 instances
discover-metadata Discover summary of IMDS service usage within EC2
discover-role-usage Discover summary of IAM role usage for EC2
harden-metadata Harden the AWS instance metadata service from v1 to v2
IMDSv1通信の検証
別のPowerShellを開いて、複数回IMDSv1でメタデータ情報を取得してみます
> Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/instance-id"
i-xxxxxxxxxxxxxx
> Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/local-ipv4"
10.0.x.xx
Resource Monitorの結果は以下になります。
Resource Monitorでは、PowerShellプロセスがinstance-data.ap-northeast-1.compute.internalへの通信を行っていることが確認できます。
何度か実行してからmetabadgerで確認してみます。
.\metabadger.exe cloudwatch-metrics --region ap-northeast-1
Pulling instances... [####################################] 100%
+---------------------+---------------------+--------------------------------+-------------------------------+
| | instance_id | imdsv1_usage_count_last_hour | instance_tags |
+=====================+=====================+================================+===============================+
| i-07f42e71a6725b258 | i-07f42e71a6725b258 | 28 | ['test-imds-packet-analyzer'] |
+---------------------+---------------------+--------------------------------+-------------------------------+
MetaDataNoTokenの値が増えていることがわかります。
IMDSv2通信の検証
次に、IMDSv2で呼び出してみます。
# トークンを取得（IMDSv2の第1ステップ）
> $token = Invoke-RestMethod -Uri "http://169.254.169.254/latest/api/token" -Method PUT -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"}
# トークンを使ってメタデータを取得（IMDSv2の第2ステップ）
> $instanceId = Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/instance-id" -Headers @{"X-aws-ec2-metadata-token" = $token}
> Write-Host "Instance ID: $instanceId"
Instance ID: i-xxxxxxxxxxxx
Resource Monitorの結果は以下のようになります。
IMDSv2の場合も、Resource MonitorでPowerShellプロセスの通信が確認できます。
何度か実行してからmetabadgerで確認してみます。
> .\metabadger.exe cloudwatch-metrics --region ap-northeast-1
Pulling instances... [####################################] 100%
+---------------------+---------------------+--------------------------------+-------------------------------+
| | instance_id | imdsv1_usage_count_last_hour | instance_tags |
+=====================+=====================+================================+===============================+
| i-07f42e71a6725b258 | i-07f42e71a6725b258 | 28 | ['test-imds-packet-analyzer'] |
+---------------------+---------------------+--------------------------------+-------------------------------+
MetaDataNoTokenはIMDSv1を使っている場合にカウントされるので、値は変わっていません。これは期待通りの結果です。
検証結果
metabadgerの有効性
- CloudWatchメトリクスを基にしたIMDSv1使用状況の把握は確実に機能
- 過去の使用履歴を確認できるため、移行対象の特定には有効
- リアルタイム監視ではないため、即座の問題特定には限界がある
Resource Monitorの有効性と限界
- プロセス特定：IMDSを使用したプロセスの確認は可能
- バージョン判別不可：IMDSv1とv2の区別はできない
- リアルタイム監視のみ：ログの蓄積機能がない
意図的にIMDS通信を発生させている場合であれば、metabadgerでMetaDataNoTokenの値を確認すれば十分です。しかし、実際にはIMDSv1とv2の通信が混在している場合もあります。
Resource MonitorネットワークモニターではIMDSを使用したプロセスの確認はできますが、バージョンの確認まではできません。
v2の場合はトークン発行の手順が発生するため、HTTPヘッダーを確認すれば、バージョンの確認ができるかもしれませんが、Resource Monitorではそこまでの詳細は確認できません。
MetadataNoTokenが検出されたときにResource Monitorを確認しに行くというのは、正直現実的ではありません。
最後に
WindowsにはIMDSパケットアナライザーは対応していないことが確認できました。代わりにmetabadgerとResource Monitorネットワークモニターを活用したパケット確認方法が推奨されていますが、実際には以下の制約があります
Resource Monitorネットワークモニター：リアルタイムでの監視のみ提供、IMDSのバージョンまでは確認不可
metabadger：過去データの分析は可能だが、リアルタイム監視は不可
これらの制約を踏まえ、WindowsインスタンスにおけるIMDSv2への移行では、より実践的なアプローチが必要だと感じました。
次回のブログでは、代替案とWindowsインスタンスにおけるIMDSv2への移行手順について詳しくまとめる予定です。本記事が同様の課題に直面している方の一助となれば幸いです。
