Network Firewall×Transit Gateway構成でドメインリストの通信制限をかける

AWS
Network

2024.07.31

この記事を書いたメンバー：

榊原慶太

Network Firewall×Transit Gateway構成でドメインリストの通信制限をかける

BeeXの榊原です。今回はNetwork FirewallとTransit Gatewayを用いて、AWSからインターネットに出る通信についてドメイン名フィルタリングを実装したので詳細を記載します。以降はNetwork FirewallはNFW、Transit GatewayはTGWと記載します。

前提

・東京リージョンのAZ-aで実施
・NFWのルールの順序では「厳密な順序」を使用
・ステートフルルールのみ使用（ステートレスルールは使わない）
・構成は以下の通り

構築してみた

量が膨大になるのでNFW部分のみ記載します。

①NFWルールグループを作成

以下の通り作成します。
・ドメインリスト：「.google.com」
・検査するトラフィックとアクション：HTTPS、許可
・送信元IP：スポークVPCのCIDR（172.20.0.0/16）

これでNFWのルールの順序では「厳密な順序」を使用する際、HTTPSで「xxx.google.com」にアクセスかつ送信元が172.20.0.0/16の通信のみパスされます。「.google.com」の冒頭の「.」は忘れやすいのでご注意ください。

（自動翻訳）
ドメインワイルドカードを使用する名前。最初の「.」で指定します。たとえば、.example.com は example.com と一致し、abc.example.com や www.example.com などの example.com のすべてのサブドメインと一致します。（AWS公式ドキュメント「Stateful domain list rule groups in AWS Network Firewall」より引用）

また、余談となりますがここでの送信元IPとはステートフルドメインリストルールグループのHOME_NETルールグループ変数を指します。以下はAWSコンソール画面の説明の抜粋です。

送信元 IP リストを使用して、特定の IP 範囲からのネットワークトラフィックを検査します。これは、ステートフルドメインリストルールグループの HOME_NET ルールグループ変数です。
(省略)
Network Firewall がデプロイされている VPC の CIDR 範囲であるデフォルト設定を使用するには、テーブルのすべてのアドレスを削除します。

➁NFWファイアウォールポリシーを作成

以下の通り作成します
・ステートレスデフォルトアクション：ステートフルルールグループに転送
・ステートフルルールのデフォルトのアクション(ドロップ)：確立された接続のパケットをドロップ
・ステートフルルールのデフォルトのアクション(アラート)：確立された接続のパケットをアラート
・ステートフルルールグループ：①で作成したNFWルールグループ
個人的にこの周辺のパラメータの名前が難解だったので余裕があれば別途記事にします。

③NFWを作成

作成するVPCとサブネットを指定し、➁で作成したNFWポリシーを紐づけます。その他の「変更に対する保護」や、カスタマーマネージドキーを用いる設定は今回は施しません。

これで指定したサブネット内にGWLB型のエンドポイントが作成されます。

④ルートテーブルを変更する

最後にNFWを配置しているVPC内サブネットのルートテーブルを編集しましょう。下のように設定すれば準備完了です。

動作検証

EC2にアクセスしてcurlコマンドをうってみます。
結果は以下のようになりました。許可したgoogle.comへのHTTPS接続のみがパスされました。

# 許可していない beex-inc.oom へのHTTPS接続は通らない
$ curl -H "Cache-Control: no-cache" https://www.beex-inc.com/
# 通らないので出力なし

# 許可した google.com へのHTTPS接続は通る
$ curl -H "Cache-Control: no-cache" https://www.google.com
<!doctype html><html itemscope="" （以下省略）

# 許可していない google.com へのHTTP接続は通らない
sh-4.2$ curl -H "Cache-Control: no-cache" http://www.google.com
# 通らないので出力なし

余談 ~ルートを間違えると大変なことに!?~

※こちらはあくまで投稿時点の検証結果です。実装の際はご自身の環境で十分にご検証ください。
今回ルートを間違えて記載すると、ドメイン許可のルールが機能しなくなる恐れがあると検証結果が出たので記載します。最初私は以下の構成で検証を行っていました。

一番右端、NATGWが配置してあるサブネットのルートテーブル、最下段をご覧ください。TGWが指定されています。このとき往路は構成図のリソースを全て通過します。一方で復路のNATGWに戻ってきた通信はFWepをスキップしてTGWアタッチメントに紐づいたENIへ飛ばされます。このような場合、FWは想定通りの機能をするのでしょうか。FWのルールはこれまでと同じく、厳密な順序かつ.google.comに対してHTTPSのみ接続を許可しています。この状態でcurlコマンドを確認してみます。

# 許可していない beex-inc.oom へのHTTPS接続が通ってしまう！！
$ curl -H "Cache-Control: no-cache" https://www.beex-inc.com/
<!DOCTYPE html>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
（以下省略）

# 許可した google.com へのHTTPS接続は当然通る
$ curl -H "Cache-Control: no-cache" https://www.google.com
<!doctype html><html itemscope="" （以下省略）

# 許可していない google.com へのHTTP接続が通ってしまう！！
sh-4.2$ curl -H "Cache-Control: no-cache" http://www.google.com
<!doctype html><html itemscope=""  （以下省略）

なんと、大変なことに許可していないドメインへのHTTP or HTTPS接続が通ってしまいます。アラートログを確認しても特に異常があった等の出力はされません。最初この状況に陥った時は混乱しましたが、AWSの公式ページで以下のような記述を見つけました。

（自動翻訳）
次のシナリオでは、ネットワークファイアウォールルールが期待どおりに機能しない可能性があります。
・トラフィックはファイアウォールを介して対称的にルーティングされません。
・ネットワークファイアウォールルールが正しく設定されていません。

（AWS re:Post「How do I troubleshoot issues with Network Firewall when a rule isn't working as expected?」より引用）

この記述をみてルートテーブルを本記事のメイン構成（NATGWのルートテーブルの172.20.0.0/16をFWのエンドポイントに向くように設定）と同じにしたところ、想定通りに動きました。皆さんも十分にご注意ください。また、今回は単一AZでしたが、使用するAZが複数にまたがる場合はTGWのアプライアンスモードを有効にすることをお忘れなく。