AWS Network Firewallを利用してTLS通信先のFQDNを特定&活用する方法

本記事は、Japan AWS Ambassadors Advent Calendar 2023の15日目の記事です。世界のTop of TopであるAWS Ambassadorの方々の神記事が公開されていますので、興味を惹くタイトルの記事があれば是非とも読んでいただけると幸甚です。

TL;DR

• AWS Network FirewallのALERTを活用することで、TLS通信先のFQDNを特定可能
• セキュリティ的な気づきやコスト削減に繋げられる可能性
• 実際に手を動かせるサンプルTerraformコードはGitHubにUpload済

はじめに

AWS Network Firewallはざっくり一言で言うと、マネージドなIPS/IDSです。詳しくはAWS公式ドキュメントWhat is AWS Network Firewall?をご覧ください。
この記事では、AWS Network Firewallを利用してTLS通信先のFQDNを特定し、活用する方法について詳しく解説します。
環境を作成するサンプルTerraformコードをGitHubにアップロードしていますので、実際に手を動かしていただけると幸いです。

Network Firewallを利用してTLS通信先のFQDNを特定する方法

AWS Network Firewallでは、TLS通信内のSNI（Server Name Indication）を利用することで通信先のFQDNを特定することが可能です。

TLS（Transport Layer Security）とは？

TLS（Transport Layer Security）は、インターネット通信を暗号化するプロトコルです。HTTPS通信を始めとする多くのセキュアな通信は、TLSを利用して暗号化されています。
CloudflareさんのSSLとは？| SSLの定義が非常にわかりやすいので、一読いただければと思います。

SNI（Server Name Indication）とは？

SNIは、クライアントがどのドメインのサーバと通信しようとしているかを明示するための技術です。これにより、一つのサーバで複数のドメインをホストする「サーバ名ベースの仮想ホスティング」が可能になります。
CloudflareさんのSNIとは？TLS Server Name Indicationの仕組みが非常にわかりやすいので、一読いただければと思います。
SNIはClientHello中に含まれ、基本的に暗号化されないため、TLS通信においても通信先のFQDNを特定することが可能となっております。

ClientHello中のSNIが暗号化されていない様子

実際にやってみる

GitHubにおいてあるサンプルコードをCloneしたのち、terraform applyを実行することで以下のような構成図の環境が出来上がります。
※Network Firewallのお値段は個人で検証するには高いので、リソースの削除忘れにお気をつけください。

今回は構成図中のEC2からのTLS通信先のFQDNを特定してみましょう。サンプルをdeployした場合、EC2からインターネットへの通信はEC2 --> Network Firewall Endpoint --> NAT Gateway --> IGW --> インターネットの経路で行われます。

ポイント

• ALERTログをCloudWatch Logsに出力するようにしているため、CloudWatch Logs Insightsを利用してTLS通信先のFQDNを特定する
• event.tls.sniフィールドにTLS通信時のSNIが出力される

CloudWatch Logs Insightsのクエリサンプル：

fields event.tls.sni
| stats count(event.tls.sni) as access_count by event.tls.sni
| sort access_count desc
| limit 10

EC2からのテストリクエストの飛ばし方

Terraformを実行すると、実行時に以下のようなoutputが出力されるので、適切なIAMを設定したAWS CLIを利用することでEC2にInstant Connectを利用して接続することが可能となります。

aws ec2-instance-connect ssh --instance-id i-0e0b3818dc665efc7 --connection-type eice

あくまでサンプルですが、以下を実行することでGoogleとAmazonに合計50回リクエストを送ることができます。以下以外でもyum updateを実行するとリポジトリへのアクセスが発生するので、適当な通信を発生させる上では有用かと思います。
※DDoS攻撃とならないにsleepを入れています。

for a in `seq 1 50`; do [ $(( RANDOM % 2 )) -eq 0 ] && curl -sS -o /dev/null "https://www.google.com" || curl -sS -o /dev/null "https://www.amazon.com"; sleep 1; done

CloudWatch LogsとS3のログ振り分け

main.tfのL327あたりに記載のある、resource "aws_networkfirewall_logging_configuration"中のlog_destination_configとして記述してある部分のコメントアウト部分を参考にすることでログの出力先をCloudWatch Logs or S3に簡単に変更することが可能です。
Network FirewallではFLOWログ, ALERTログを別々の出力先にすることが可能です。例えば、FLOWログは量が多いためS3に出力を行いコスト削減を行いつつ、ALERTログはCloudWatch Logs経由でFilterをかけることで通知 or 一定の閾値を設定することでSlackなどへ通知することも可能です。

参考情報として、ALERTログがCloudWatch Logsに出力されるまでおよそ6分半程度かかりました。Network Firewallのログはリアルタイムに出力されず、数分程度のラグがあります。

嬉しいポイント 例1

意図しない通信先へ通信をしていないか？ と言うのを簡単に確認することができます。例えば、以下はTerraformを実行したのちテストリクエストおよびyum updateを実行した後のCloudWatch Logs Insightsの結果です。
ここでは、想定通りの通信先のみ出力されていますが、「youtube.com」などのドメインが記載されている場合、意図しない通信がされていることになります。このように、意図しない通信がされていないかを確認することで、セキュリティ的に新しい気づきを得ることが可能となっております。
※SNIを元に通信先を特定していますので、改ざんされている可能性があることをご留意ください

嬉しいポイント 例2

以下はEC2からS3へのアクセスした後のCloudWatch Logs Insightsの結果です。

アクセス例 コマンド：

touch test && for a in `seq 1 10`; do aws s3 cp ./test s3://aws-netfw-logs-poc-tmt/test && aws s3 rm s3://aws-netfw-logs-poc-tmt/test; done

見ていただいてわかる通り、EC2からS3への通信がNetwork Firewallを経由（EC2 --> Network Firewall Endpoint --> NAT GW --> S3）しています。
VPC内からS3への通信をNetwork Firewallを経由させる意義がない場合が多いと思いますので、「VPC Endpoint（Gateway型）を利用することで通信料金を削減できるのでは？」と言う気付きが得られます。

終わりに

2020年秋にAWS Network Firewallがリリースされてから3年ほど経過しますが、まだまだ情報が少ないと感じているため、少しでも皆様の助けとなるようにとの思いで記事を執筆いたしました。
本記事はJapan AWS Ambassadors Advent Calendar 2023の15日目の記事として公開したものです。日本におけるAWSのTop of Topの皆様の記事が続々とUploadされていますので、カレンダーに遷移していただき、興味を惹くタイトルの記事があれば是非読んでいただけると幸甚です。

また、手を動かしてキャッチアップしたいと言う方はTerraformのコードをGitHubにアップロードしておりますので、是非手を動かしてみてください。余談ですが、AWS re:Invent 2023でGamedayという手を動かしてスコアを競うイベントに参加したのですが、改めて手を動かすことの大切さに気付かされました。

この記事を見てくださった方が少しでもAWSに興味を持ち、世界が今より少しでもより良くなっていくことを心より望みつつ筆を置きます。