Route53 Resolver DNS Firewallで検知したクエリの正体

タイトルにもある通り、Route53 Resolver DNS Firewallで想定していないDNSクエリを検知した事象について、せっかくなのでプチ謎解き形式で記そうと思います（？）
割と局所的な話ですが、よろしければお付き合いください。

前提

Route 53 Resolverとは

VPC内にデフォルトで存在するフォワーダーとしての機能を持つ仮想的なDNSサーバー

参考：【ざっくり解説】Route 53 ResolverとResource Access Managerについて3段階で図解説する

Route53 Resolver DNS Firewallとは

VPCからRoute 53 Resolver(Amazon Provided DNS)を通過するアウトバウンド DNS クエリを保護するサービス
主な構成要素と概要は以下

1. DNS Firewall ルールグループ

   • 特定のDNSクエリを許可(Allow)またはブロック(Block)するアクションを持つルールのコレクション
   • ルールグループをVPCに関連付けることで、VPCのDNS Firewallフィルタリングが有効になる

2. DNS Firewall ルール

   • DNS Firewall ルールグループ内の DNS クエリに対するフィルタリングルールを定義する
   • 各ルールでは、それぞれドメインリストを1つ、また、リスト内のドメイン仕様に一致するドメインを持つ DNS クエリに対して実行するアクションを指定する
   • 一致するクエリ、またはリスト内のドメインのクエリタイプの許可(Allow)、ブロック(Block)、またはアラート(Alert)を送信できる

3. ドメインリスト

   • DNSフィルタリングで使用するドメインを定義する
   • アクセスを許可(Allow)するドメイン、アクセスを拒否(Block)するドメイン、またはその両方の組み合わせを指定できる
   • 独自のドメインリストを作成したり、AWSが管理するドメインリストを使用できる

参考：Route 53 Resolver DNS Firewall の仕組み(AWS公式)

ちなみに、Network Firewallでもドメイン名でのアウトバウンドを保護できますが、コストの制限がある場合にはRoute53 Resolver DNS Firewallの方が利用するハードルが低いかと思います（もちろん全く同じ機能というわけではないので一概には言えないですが）。ご参考までに。

参考：Route 53 の料金(AWS公式)
　　　Network Firewallの料金(AWS公式)

問題編

というわけで本題。

今回構築するシステムでは外部へのDNSクエリに対して制限が必要だったため、
「Network Firewall」との比較の末、コストへの影響が比較的少ない「Route53ResolverDNSFirewall」と「Network ACL」、「セキュリティグループ」を併用する構成をとりました。

また、検証段階では、Allow用ドメインリストに記載した下記のドメイン以外のクエリがVPC内から外部に対して発生した際にはALERTメールを発砲したかったため、DNS Firewallのアラート(Alert)を検知する「EventBridgeルール」と連携する「SNS」を作成しました。

• 外部APIドメイン
• *.amazonaws.com.
• amazonaws.com.

そして、構築が完了し検証が始まった頃、
「cdn.amazonlinux.com.」宛のクエリが発生している、と度々ALERTメールが届くようになりました。
さて、このDNSクエリを発生させた犯人は一体どのサービスでしょうか。。。！

①AWS Fargate
　本システムでの用途：アプリケーションを搭載　
　※OSはLinuxを選択
②AWS Lambda
　本システムでの用途：日次のDB処理に利用　
　※ランタイムはJava17を選択
③AWS Batch
　本システムでの用途：年次のDB処理に利用　
　※オーケストレーションタイプはFargate、ランタイムプラットフォームはLinuxを選択

「cdn.amazonlinux.com」が何に使われる接続先かは訳あってあとがきで記します

解決編

※※折り畳みにしています※※

まず、ALERTメールが届いているタイミングを確認したところ、不定期に一日4,5回ほどメールが届いていることがわかりました。
そのため、定期的な実行を設定している②AWS Lambda ③AWS Batchは容疑者（？）から外れました。
※検証のため、イレギュラーに実行しているということも今回のタイミングでは無いようでした。

というわけで、①AWS Fargateが犯人であることを疑い、ALERTメールに記載されているSourceIpを基にEC2コンソールにてENIで検索をかけてみました。が、ヒットせず。。。！
念のため、ECSコンソールにてタスクの起動時間を確認しましたが、数日前に起動してからタスクの再起動がかかった様子もなく、少なくともここ数日届いているALERTメールのSourceIpは①AWS Fargateが原因ではないことがわかりました。

もう迷宮入りかとあきらめかけたその時、もう一つVPC内に立ち上がるリソースを思い出しました。
それは　「　④VPC内に起動させるCloudShell　」　です。。。
※よくみると、問題編で①②③のどれかが犯人とは言っていません←　
※用途としては、Fargateからの通信をVPC内で模擬するときの検証として使用していたとのことでした。

VPC内に起動させるCloudShellは2024年にリリースされた新機能ですが、初めて知った方には以下のサイトがわかりやすいです
[アップデート] CloudShell を任意の VPC 上で起動できる CloudShell VPC environment が提供されました！

というわけで、CloudTrailにてALERTメールが届いた時間帯のイベント履歴を確認したところ、CloudShell 環境が作成されたときに発生するcreateEnvironmentが記録されている時刻とALERTメールが届いた時刻がぴったり一致していていることがわかりました。。！

念のため、AWS Supportにも問い合わせたところ、VPC内CloudShellの起動時に「cdn.amazonlinux.com」へのDNSクエリが発生していることが確認取れました。
クエリログを出力すればコンソールでも確認できるかと思います。

諸々確認が取れたので「cdn.amazonlinux.com.」をAllow用のドメインリストに追記して一件落着！！！

【注意事項】
「cdn.amazonlinux.com」を追加したドメインリストと紐づけるルールでは、
[ドメインリダイレクト設定]というパラメータを「すべて検査(デフォルト)」から
「信頼リダイレクトドメイン」に変更する必要があるとのことです。
本記事では理由までは記載しないですが、気になる方は調べてみてください。
ヒントはdigです。
参考：DNS Firewallのルール設定

あとがき

※※折り畳みにしています※※

結論でいえば

「VPC内CloudShellは起動時にcdn.amazonlinux.com.へのDNSクエリが発生するよ」

の一文で終わりなのですが、
「今年リリースされた新機能が関連する事象だったこと」と
「このような事象が起きた場合にどのような確認方法があるか」
という部分がどなたかの参考になればと思い記事にしてみました。

ちなみに、解決編で色々書きましたが、
今回のケースでは 「cdn.amazonlinux.com.」の用途を調べると一発で
①AWS Fargate②AWS Lambda③AWS Batchが犯人ではないと判断することができます。

実は、「cdn.amazonlinux.com.」 は仮想化基盤で使用するAmazon Linux 2023 イメージをダウンロードするために使用される接続先（参考：AL2023 VM イメージをダウンロードする）なのですが、
今回の①AWS Fargate②AWS Lambda③AWS Batchは実はすべてAmazonLinux2で起動します。
問題編にもヒントとしてさらっと各サービスが起動するOSやランタイムを記していました。
参考：Fargateが起動するOS
　　　Lambdaが起動するOS

さて、こんなに長くなる予定ではなかったのですがいかがだったでしょうか！
好評でしたらまた同じような形式で学んだことを記してみようと思います。

最後まで読んでいただきありがとうございました！またの機会に！！

本記事のタグで犯人がバレないように[CloudShell]という記載を消そうかと思いましたが、それでは検索に引っかかりづらいと思ったのであえて残しました。タグで気づかれた方は鋭い👏