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

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

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

参考：[【ざっくり解説】Route 53 ResolverとResource Access Managerについて3段階で図解説する](https://dev.classmethod.jp/articles/explain-route53-resolver-ram/)

### 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公式)](https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html)

:::note info
ちなみに、Network Firewallでもドメイン名でのアウトバウンドを保護できますが、コストの制限がある場合にはRoute53 Resolver DNS Firewallの方が利用するハードルが低いかと思います（もちろん全く同じ機能というわけではないので一概には言えないですが）。ご参考までに。
:::
参考：[Route 53 の料金(AWS公式)](https://aws.amazon.com/jp/route53/pricing/)
　　　[Network Firewallの料金(AWS公式)](https://aws.amazon.com/jp/network-firewall/pricing/)

## 問題編

というわけで本題。

今回構築するシステムでは外部へのDNSクエリに対して制限が必要だったため、
「**Route53ResolverDNSFirewall**」 を採用しました。

また、検証段階では、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を選択

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

## 解決編

<details><summary>※※折り畳みにしています※※</summary>

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

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

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

:::note warn
VPC内に起動させるCloudShellは2024年にリリースされた新機能ですが、初めて知った方には以下のサイトがわかりやすいです
[[アップデート] CloudShell を任意の VPC 上で起動できる CloudShell VPC environment が提供されました！](https://dev.classmethod.jp/articles/cloudshell-vpc-environment/)
:::

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

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

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

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

</details>

## あとがき

<details><summary>※※折り畳みにしています※※</summary>

結論でいえば

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

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

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

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

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