AWS Network Firewall 向け Route 53 Resolved IP Validation の紹介: ドメイン名による非ウェブトラフィック制御と SNI スプーフィング防止

ワークロードはほとんどの宛先にドメイン名でアクセスしますが、ファイアウォールが判断に使えるのはトラフィック内で確認できる情報だけです。HTTP と HTTPS の場合、AWS Network Firewall のドメインルールは、クライアントがリクエストに含めた名前を照合対象にしますが、その名前はクライアント側で決められます。SSH や SSH File Transfer Protocol (SFTP) などのプロトコルの接続には、ドメイン名が含まれません。クライアントは名前を DNS ルックアップにのみ使用し、DNS が返した IP アドレスに直接接続します。そのため、これらのプロトコルの Network Firewall ルールでは、時間の経過とともに変化する IP アドレスを使用してきました。また、ウェブトラフィックか非ウェブトラフィックかを問わず、Network Firewall は DNS リゾルバーが返した応答を把握できませんでした。DNS とファイアウォールの間で可視性を共有する仕組みがなかったためです。

AWS は 2026 年 10 月 21 日、AWS Network Firewall 向け Route 53 Resolved IP Validation を追加料金なしでリリースしました。Amazon Route 53 Resolver が各ドメイン名に対して返す IP アドレスを Network Firewall と共有するようになり、Network Firewall は新しいアウトバウンド接続ごとに、その IP アドレスと照合します。このリリースにより、非ウェブトラフィックをドメイン名でフィルタリングできるようになりました。また、TLS インスペクションを有効にしなくても、TLS トラフィックにおける Server Name Indication (SNI) の改ざんを防止できます。

この記事では、この機能の仕組みと、アラートモードで有効化する方法を説明したうえで、一般的な 2 つのユースケースを紹介します。これらはあくまで一例であり、ドメイン名で制御するあらゆるアウトバウンドトラフィックに同じチェックが適用されます。

Amazon Route 53 Resolver は、Route 53 Resolver を使用するように設定された仮想プライベートクラウド (VPC) 内のリソースからの DNS クエリに応答します。Route 53 Resolver は、すべての VPC でデフォルトで利用できます。この機能では、Route 53 Resolver が各ドメイン名に対して返した IP アドレスを解決済み IP キャッシュ (resolved IP cache) に保持します。新しいアウトバウンド接続が開始されると、Network Firewall は宛先アドレスをそのキャッシュと照合します。

1. ワークロードが 10.0.0.2 の Route 53 Resolver に files.partner.example.com を問い合わせます。
2. 最初に Amazon Route 53 Resolver DNS Firewall がクエリをチェックします。ドメインルールでクエリをブロックしたり、アラートを出したりできます。ルールグループが空の場合、クエリはそのまま通過します。
3. Route 53 Resolver は 203.0.113.10 を返し、その応答を解決済み IP キャッシュに記録します。
4. 203.0.113.10 のポート 22 への SFTP 接続が、Network Firewall エンドポイントに到達します。
5. ポリシーが最初のパケットをチェックします。アドレスがキャッシュ内に存在するため、接続は続行されます。
6. Route 53 Resolver が files.partner.example.com に対してこのアドレスを返しているため、ステートフルルールは接続を通過させます。
7. 接続は NAT ゲートウェイとインターネットゲートウェイを経由して外部に出ます。
8. フローログとアラートログに新しいフィールドが記録されます。

この機能は 3 つの要素で構成されています。

• Amazon Route 53 Resolver DNS Firewall ルールグループ – 対象範囲を定義します。このルールグループに関連付けられたすべての VPC で Route 53 Resolver が返した応答が、解決済み IP キャッシュに格納されます。ルールグループは空でも構いません。ルールを追加すると、同じルールグループで DNS クエリ自体もフィルタリングできます。例えば、既知の脅威ドメインのルックアップをブロックできます。このように、DNS Firewall がルックアップを、Network Firewall がその後の接続をチェックすることで、両者が連携して機能します。
• Network Firewall のポリシー設定 – Network Firewall は新しい接続ごとに、ステートフルルールが実行される前に最初のパケットをチェックし、Route 53 Resolver がその宛先アドレスをいずれかのドメイン名に対して返したかどうかを確認します。返していた場合、接続はステートフルルールの評価に進みます。返していない場合、Network Firewall は選択したアクション (アラート、ドロップ、または拒否) を適用します。
• 解決済みドメインルール (resolved-domain rule) – ステートフルルールグループ内のこれらのルールは、宛先アドレスがどのドメイン名に対して解決されたかに基づいて接続を照合するため、あらゆるプロトコルで機能します。ルールには、クライアントがルックアップする名前を使用してください。

次の図は、このアーキテクチャを示しています。

図 1. ユースケース 1 の SFTP 接続を、Route 53 Resolver が返した応答と Network Firewall が照合する仕組み

ポリシー設定は、ウェブトラフィックに限らず、すべての接続をチェックします。ハードコードされたアドレスなど、どのクライアントも Route 53 Resolver 経由でルックアップしていない IP アドレスへの接続は、チェックに失敗します。IP アドレスに直接接続するワークロードがある場合は、適用 (エンフォース) する前に、それらのアドレスを [Bypass destination validation IP ranges] (宛先検証をバイパスする IP 範囲) に追加してください。ポリシーのチェックはルールより前に実行されるため、ステートフルなパスルールを作成しても、これらのアドレスをチェックの対象外にすることはできません。また、チェックはアドレス単位で行われます。関連付けられた VPC 内のいずれかのクライアントが名前をルックアップすると、同じアベイラビリティーゾーン内の対象範囲にあるすべてのクライアントについて、そのアドレスがチェックに合格するようになります。詳細については、AWS Network Firewall デベロッパーガイドの「Resolved IP validation in AWS Network Firewall」を参照してください。

この記事の手順を実行するには、以下が必要です。

• Amazon Route 53 Resolver を介した DNS – Network Firewall がチェックできるのは、Route 53 Resolver が返した応答のみです。Resolver エンドポイントまたは Resolver 転送ルールを経由して Route 53 Resolver に到達したクエリも対象になります。
• Route 53 Resolver DNS Firewall ルールグループ – Network Firewall が接続の照合に DNS の応答を使用する VPC に関連付けておく必要があります。
• 解決済みドメインルールを追加する前に有効化したポリシー設定 – ドメインフィルタリング (aws_route_53_resolved_domain キーワード) を使用するルールには、同じファイアウォールポリシーで Route 53 Resolved IP Validation を有効にしておく必要があります。まずアラートモードで設定を有効にしてから、ルールを追加してください。
• サポートされているデプロイモデル – この機能は、クライアントが自身のアベイラビリティーゾーン内のファイアウォールエンドポイントに到達する分散型デプロイ (複数のファイアウォールエンドポイントを使用する構成を含む) と、ファイアウォールを AWS Transit Gateway にネイティブにアタッチした集中型デプロイに対応しています。ルーティングによってクライアントが別のアベイラビリティーゾーンのファイアウォールエンドポイントに送られる場合、そのクライアントの接続はチェックに失敗します。集中型デプロイをネイティブにアタッチされたファイアウォールに移行する方法については、「Why and how to migrate to a Transit Gateway attached AWS Network Firewall」を参照してください。

クライアントは DNS の応答をキャッシュするため、まずアラートモードで開始します。Network Firewall が認識するのは、DNS Firewall ルールグループを VPC に関連付け、ポリシーで選択した後に Route 53 Resolver が返した応答のみです。以前にキャッシュした応答を使い続けているクライアントは、名前を再度ルックアップするまで (通常はキャッシュされたレコードの有効期限が切れるまで) チェックに失敗します。アラートモードなら、何もブロックせずにこの状況を確認できます。クライアントがキャッシュを更新できるよう、アラートモードで約 24 時間運用してください。

1. DNS Firewall ルールグループを作成し (空でも構いません)、Network Firewall が接続の照合に DNS の応答を使用する VPC に関連付けます。手順については、「Creating a rule group and rules」を参照してください。
2. 既存の DNS Firewall ルールグループを使用する場合は、そのルールグループがこれらの VPC にのみ関連付けられていることを確認してください。関連付けられたいずれかの VPC で返された応答は、ファイアウォールがチェックするすべてのクライアントに対して有効になるためです。チェック対象のクライアントは、ステップ 6 の [Source IP ranges] (送信元 IP 範囲) で設定します。
3. Amazon Virtual Private Cloud (Amazon VPC) コンソールの [Network Firewall] で [ファイアウォールポリシー] を選択し、ファイアウォールが使用しているポリシーを選択します。[トラフィック検査] タブの [Route 53 Resolved IP validation] セクションで [編集] を選択し、[Enable Route 53 Resolved IP validation] (Route 53 解決済み IP 検証を有効にする) を選択します。
4. [アクション] で [アラート] を選択します。[DNS Firewall rule group] (DNS Firewall ルールグループ) で、ステップ 1 または 2 のルールグループを選択します。
5. [DNS expiry exception policy] (DNS 有効期限切れ時の例外ポリシー) では、確立済みの接続について、そのエントリが解決済み IP キャッシュで期限切れになった場合の動作を選択します。[Continue] (続行) では接続が維持され、[Drop] (ドロップ) では TCP リセットを送信せずに接続が停止され、[Reject] (拒否) では TCP リセットで接続が停止されます。ファイル転送など長時間実行されるセッションが途中で切断されないよう、[Continue] をお勧めします。ただし、セキュリティ要件に合ったオプションを選択してください。
6. [Source IP ranges] で、チェック対象のクライアントを指定します。指定しない場合、Network Firewall はファイアウォールの VPC と、ファイアウォールにアタッチされた追加の VPC 内のクライアントをチェックします。トランジットゲートウェイにアタッチされたファイアウォールにトラフィックを送信するスポーク VPC など、クライアントが他の VPC にある場合は、その CIDR 範囲を入力してください。入力しないと、Network Firewall はそれらのクライアントの接続をチェックしません。IP アドレスで許可する宛先は [Bypass destination validation IP ranges] に追加します。最後に [保存] を選択します。

次のスクリーンショットは、これらの手順を示しています。

図 2. アラートモードで有効化された Route 53 Resolved IP Validation

アラートモードでは、Network Firewall はチェックに失敗した接続をブロックせず、チェック自体のアラートも書き込みません。チェックの結果は、フローログ内の各接続の route53_resolved_ip フィールドに記録されます。値が true の場合は、Route 53 Resolver がその宛先アドレスをいずれかのドメイン名に対して返したことを意味します。値が false の場合は返していないことを意味し、適用時にはその接続がブロックされます。同じフィールドは、ルールまたはポリシーのデフォルトアクションがその接続に対して書き込むアラートログレコードにも含まれます。なお、パスルールは alert; キーワードがない限り、アラートログレコードを書き込みません。Amazon CloudWatch の DnsUnresolvedFlows メトリクスはチェックに失敗した接続を、DnsAzUnavailableFlows はこの機能をサポートしていないアベイラビリティーゾーンからの接続をカウントします。次のアラートログレコード (一部省略、値は例) は、Route 53 Resolver が返したアドレスへの接続について、アラートを出すデフォルトアクションが書き込んだものです。

{
  "firewall_name": "egress-firewall",
  "availability_zone": "us-east-1a",
  "event": {
    "event_type": "alert",
    "src_ip": "10.0.1.10",
    "dest_ip": "203.0.113.10",
    "dest_port": 123,
    "proto": "UDP",
    "app_proto": "ntp",
    "route53_resolved_ip": true,
    "verdict": {
      "action": "alert"
    },
    "alert": {
      "action": "allowed",
      "signature_id": 3,
      "signature": "aws:alert_established action"
    }
  }
}

次のレコードは、アラートモードで記録された TLS 接続のものです。この接続は許可されたドメイン名を提示しましたが、Route 53 Resolver がそのドメイン名に対して返していないアドレスに向かったため、ユースケース 2 のポリシーのデフォルトアクションによってブロックされました。

{
  "firewall_name": "egress-firewall",
  "availability_zone": "us-east-1a",
  "event": {
    "event_type": "alert",
    "src_ip": "10.0.1.10",
    "dest_ip": "198.51.100.7",
    "dest_port": 443,
    "proto": "TCP",
    "app_proto": "tls",
    "tls": {
      "sni": "api.partner.example.com"
    },
    "route53_resolved_ip": false,
    "verdict": {
      "action": "drop"
    },
    "alert": {
      "action": "blocked",
      "signature": "aws:alert_established_app_layer_to_server action"
    }
  }
}

[アクション] を [ドロップ] または [拒否] に切り替える前に、チェックに失敗している接続が想定どおりのものであること、IP アドレスで許可する宛先がバイパス範囲に含まれていることを確認してください。[拒否] は TCP リセットを送信するため、ブロックされた TCP クライアントはタイムアウトを待たずに直ちに失敗します。適用後、ブロックされた接続はアラートログではなくフローログに記録され、route53_resolved_ip の値は false になります。監視すべきメトリクスとログフィールドについては、「Monitoring and troubleshooting resolved IP validation」を参照してください。

Route 53 Resolved IP Validation のリリース前は、SFTP などドメイン名を含まないプロトコルの Network Firewall ルールでは IP アドレスを使用していました。この機能により、これらのトラフィックをドメイン名で許可できるようになりました。この例では、ワークロードが TCP ポート 22 の SFTP で、files.partner.example.com のパートナーにファイルを送信します。パートナーは、この名前に対応するアドレスをいつでも変更できます。SSH、MySQL、その他の非ウェブプロトコルでも同じ方法を使用できます。このルールは標準ステートフルルールとして作成します。手順は次のとおりです。

1. [Network Firewall] で [Network Firewall ルールグループ] を選択し、[ルールグループを作成] を選択します。[ステートフルルールグループ] と [標準ステートフルルール] を選択し、ポリシーで使用しているルール評価順序を選択します。
2. [ルールを追加] を選択します。[プロトコル] で [TCP] を選択します。[送信先ポート] に 22 と入力します。[ドメインフィルタリング] に files.partner.example.com と入力します。[アクション] で [パス] を選択します。
3. ルールグループを作成し、ファイアウォールポリシーに追加します。

図 3. パートナーのドメイン名を対象とした、TCP ポート 22 の SFTP 用パスルール

ルールをコードとして管理する場合、同等の Suricata ルールは次のとおりです。このルールでは、許可された接続をファイアウォールがログに記録するように、alert; キーワードを追加しています。コンソールで作成したルールには、このキーワードは含まれません。

pass tcp any any -> any 22 (alert; msg:"Allow TCP/22 to files.partner.example.com"; aws_route_53_resolved_domain:"files.partner.example.com"; sid:1;)

パートナーがサーバーを新しいアドレスに移行すると、次回の DNS の応答で、そのアドレスが解決済み IP キャッシュに追加されます。IP リストを管理する必要はありません。なお、キャッシュは以前の応答を DNS の有効期間 (TTL) よりも長く保持するため、古いアドレスもしばらくはチェックに合格する場合があります。

SNI スプーフィングとは、クライアントが TLS リクエストで許可されたドメイン名を提示しながら、実際には別のサーバーに接続する手法です。これを防止するには、従来はトラフィックを復号する TLS インスペクションが必要でした。Route 53 Resolved IP Validation を使用すると、TLS インスペクションなしでこれを防止できます。この例では、ワークロードが HTTPS で api.partner.example.com のパートナー API を呼び出します。ポート 443 の TLS トラフィックは、Route 53 Resolver がその名前に対して返したアドレスにのみ到達するようにする必要があります。ユースケース 1 と同様に、標準ステートフルルールグループにパスルールを作成します。どのルールによっても通過が許可されないトラフィックは、ファイアウォールポリシーのデフォルトアクションによってすべてドロップされます。手順は次のとおりです。

1. [Network Firewall] で [Network Firewall ルールグループ] を選択し、[ルールグループを作成] を選択します。[ステートフルルールグループ] と [標準ステートフルルール] を選択し、[厳密な順序] を選択します。
2. [ルールを追加] を選択します。[プロトコル] で [TLS] を選択します。[送信先ポート] に 443 と入力します。[ドメインフィルタリング] に api.partner.example.com と入力します。[アクション] で [パス] を選択します。
3. ルールグループを作成し、ファイアウォールポリシーに追加します。
4. ファイアウォールポリシーでは、厳密なルール順序を使用します。ステートフルデフォルトアクションには、[Application drop established (server-directed only)] (確立済み接続をアプリケーション層でドロップ、サーバー方向のみ) と [Application alert established (server-directed only)] (確立済み接続をアプリケーション層でアラート、サーバー方向のみ) を選択します。アラートアクションにより、ドロップアクションがブロックした内容がログに記録されます。これらのデフォルトアクションをお勧めする理由については、AWS Security Services Best Practices ガイドの「Firewall policy configuration」を参照してください。

図 4. パートナーのドメイン名を対象とした、ポート 443 の TLS 用パスルール

ルールをコードとして管理する場合、同等の Suricata ルールは次のとおりです。

pass tls any any -> any 443 (aws_route_53_resolved_domain:"api.partner.example.com"; sid:2;)

パスルールが照合するのは、TLS リクエスト内の名前ではなく宛先アドレスです。ポート 443 の TLS トラフィックが通過するのは、Route 53 Resolver が api.partner.example.com に対してその宛先アドレスを返した場合のみです。コンテンツ配信ネットワーク (CDN) の背後にあるなど、パートナーのアドレスが他のドメイン名にも使われている場合は、それらのドメイン名宛てのトラフィックも通過します。TLS リクエストにパートナーの名前が含まれていることも条件にするには、同じルールに SNI の完全一致条件として tls.sni; content:"api.partner.example.com"; startswith; endswith; nocase; を追加します。

startswith と endswith を指定しない場合、content による照合では、その名前を含むあらゆる SNI が受け入れられます。

パートナーの名前を提示しながら別のアドレスに向かう接続は、パスルールに一致しません。Route 53 Resolver がそのアドレスを一度も返していない場合は、ルールが実行される前に、ポリシー設定の適用アクションによって接続がブロックされます。アラートモードでは、ポリシー設定は接続をブロックせずにルールの評価へ進めますが、パスルールに一致しないため、ステートフルデフォルトアクションによって接続がドロップされます。そのアラートログレコードでは、前述の 2 番目の例のように、route53_resolved_ip が false になります。一方、Route 53 Resolver が別のドメイン名に対してそのアドレスを返していた場合、接続はポリシーのチェックに合格します。ただし、パスルールに一致しないため、その後ステートフルデフォルトアクションによって接続がドロップされ、そのレコードでは route53_resolved_ip が true になります。

次のベストプラクティスに従うことをお勧めします。

• DNS を Route 53 Resolver に限定する – クライアントがチェックを回避できないように、Network Firewall で、他のリゾルバーへのアウトバウンドの DNS (UDP および TCP ポート 53) に加え、DNS over HTTPS (DoH) や DNS over TLS (DoT) もブロックします。Route 53 Resolved IP Validation だけでは、このブロックは行われません。いずれかのクライアントが dns.google などのパブリックリゾルバーの名前をルックアップすると、そのリゾルバーのアドレスはチェックに合格してしまいます。
• これらの VPC で DNS Firewall ルールを維持する – Route 53 Resolved IP Validation がチェックするのは、DNS ルックアップの後に続く接続であり、DNS クエリ自体ではありません。DNS Firewall は AWS マネージドドメインリストを使用して既知の脅威ドメインのルックアップをブロックできます。また、その高度なルールグループでは、DNS トンネリングなど、DNS クエリを介したデータの流出を検出できます。
• 小規模から始める – ドメインフィルタリングは一度に少数のルールに追加し、結果に問題がないことを確認してから対象を広げます。ドメイン許可リストのパターンについては、「Allow rules and domain allowlisting」を参照してください。
• フローログ、アラートログ、詳細モニタリングを有効にする – 解決済み IP のチェックに失敗した接続は、アラートログではなく、フローログ (route53_resolved_ip: false) と DnsUnresolvedFlows メトリクスに表示されます。また、alert; キーワードのないパスルールは、アラートログレコードを書き込みません。

Route 53 Resolved IP Validation は現在、AWS Network Firewall と Amazon Route 53 Resolver DNS Firewall を利用できるすべての商用 AWS リージョン (AWS GovCloud (米国) リージョンと中国リージョンを除くリージョン) で、追加料金なしでご利用いただけます。リージョンの一覧については、「AWS Capabilities by Region」を参照してください。ルールのない DNS Firewall ルールグループには、DNS Firewall の料金は発生しません。ルールを追加すると、DNS Firewall の標準料金が適用されます。詳細については、「AWS Network Firewall の料金」と「Amazon Route 53 の料金」を参照してください。

この記事では、Route 53 Resolved IP Validation の仕組みと、アラートモードで有効化する方法を紹介しました。Network Firewall は、各接続の宛先を、Amazon Route 53 Resolver が DNS クエリに対して返した IP アドレスと照合するようになりました。この照合によって可能になる代表的な例として、SFTP、SSH、データベースなどの非ウェブトラフィックをドメイン名でフィルタリングすることと、TLS インスペクションを使わずに SNI スプーフィングを防止することの 2 つがあります。まずはアラートモードで機能を有効にし、結果を確認してから適用してください。詳しい手順については、「Getting started with resolved IP validation」を参照してください。