ルールが期待どおりに機能しない場合の、Network Firewall の問題をトラブルシューティングする方法を教えてください。

簡単な説明

次のシナリオでは、Network Firewall のルールが期待どおりに機能しない可能性があります。

• トラフィックがファイアウォールを経由して対称的にルーティングされていない。
• Network Firewall のルールが正しく設定されていない。

注: Network Firewall の問題をトラブルシューティングする前に、次の設定を確認してください。

• ファイアウォールのエンドポイントが、専用のサブネットとルートテーブルにデプロイされている。ファイアウォールのサブネットにはワークロードリソースがあってはなりません。
• ルートテーブルが、ファイアウォールエンドポイントを介してトラフィックをルーティングしている。Amazon CloudWatch メトリックス ReceivedPackets をチェックして、Network Firewall がパケットを受信したことを確認してください。ReceivedPackets メトリックの値がゼロの場合は、ルートテーブルにファイアウォールエンドポイントを指す正しいルートがあることを確認してください。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI のエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

ファイアウォール経由の対称ルーティングを確認する

一元化された Network Firewall デプロイモデルでは、検査用仮想プライベートクラウド (VPC) の Transit Gateway アタッチメントのアプライアンスモードをオンにします。

1. アプライアンスモードがオンになっているかどうかを確認するには、次のAWS CLI コマンド describe-transit-gateway-vpc-attachments を実行します。

   aws ec2 describe-transit-gateway-vpc-attachments \
       --filters Name=transit-gateway-attachment-id,Values=tgw-attach-example

2. アプライアンスモードを有効にするには、次の AWS CLI コマンド modify-transit-gateway-vpc-attachment を実行します。

   aws ec2 modify-transit-gateway-vpc-attachment \
       --transit-gateway-attachment-id tgw-attach-example \
       --options ApplianceModeSupport="enable"

   注: tgw-attach-example を検査 VPC の Transit Gateway アタッチメント ID に置き換えてください。

パブリックサブネットにファイアウォールエンドポイントをデプロイする場合、インターネットゲートウェイの進入ルートテーブルは、ファイアウォールエンドポイントを経由してプライベートサブネットにルーティングする必要があります。プライベートサブネットのルートテーブルは、インターネットトラフィックを同じファイアウォールエンドポイントにルーティングする必要もあります。詳細については、「Simple single zone architecture with an internet gateway using AWS Network Firewall」(AWS Network Firewall を使用したインターネットゲートウェイを備えたシンプルな単一ゾーンアーキテクチャ) を参照してください。

マルチ AZ ファイアウォールデプロイでは、インターネットゲートウェイの進入ルートテーブルが同じファイアウォールエンドポイントを経由してプライベートサブネットにトラフィックをルーティングする必要があります。また、ルートテーブルはプライベートサブネットと同じアベイラビリティーゾーンにある必要があります。詳細については、「Multi zone architecture with an internet gateway using AWS Network Firewall」(AWS Network Firewall を使用したインターネットゲートウェイを備えたマルチゾーンアーキテクチャ) を参照してください。

正しく設定されていない Network Firewall のルールを修正する

Network Firewall のルールに関する問題は、ルールの設定方法が原因で発生する可能性があります。

ステートレスルール

トラフィックが両方向に流れるようにするには、入力ルールと出力ルールの両方にステートレスルールを適用します。着信トラフィックの入力にルールを適用する場合は、応答トラフィックの出力にもルールを適用する必要があります。応答トラフィックの出力にルールを適用する場合は、着信トラフィックの入力にもルールを適用する必要があります。このルール設定は、アクセスコントロールリスト (ACL) に似ています。詳細については、「Working with stateless rule groups in AWS Network Firewall」(AWS Network Firewall でのステートレスルールグループの使用) を参照してください。

パケットのステートレスデフォルトアクション

ファイアウォールポリシーで、完全なパケットとフラグメント化されたパケットの両方に対するステートレスデフォルトアクションを確認します。デフォルトのアクション設定によって、ステートレスルールに一致しない個々のパケットをファイアウォールのステートレスエンジンがどのように処理するかが決まります。フラグメント化されたパケットのステートレスデフォルトアクションを、UDP トランスポートプロトコルを使用する IPv4 パケットフラグメントのみに適用します。詳細については、「Firewall policy settings in AWS Network Firewall」(AWS Network Firewall のファイアウォールポリシー設定) を参照してください。

注: IPv6 プロトコルはネットワークのフラグメンテーションをサポートしていません。ホストが受信ホストの MTU よりも大きいパケットを送信すると、受信ホストはそのパケットをドロップします。パス上のデバイスは、デバイスの MTU よりも大きいパケットもドロップします。

ステートフルルール

ステートフルルールエンジンがトラフィックを検査するには、ステートレスルールエンジンが両方のトラフィックフロー方向をステートフルルールグループに転送する必要があります。詳細については、「Network Firewall stateless and stateful rules engines」(Network Firewall のステートレスルールエンジンとステートフルルールエンジン) を参照してください。

Network Firewall のルールはプライベート IP アドレスを参照する必要がある

プライベートサブネットまたはワークロードにパブリック IP アドレスとプライベート IP アドレスの両方がある場合、Network Firewall のルールはプライベート IP アドレスを参照する必要があります。

ルールグループ変数

ステートフル Network Firewall のルールグループは、変数 HOME_NET を使用してファイアウォール検査の範囲を定義します。HOME_NET 変数を明示的に指定しない場合、変数はデフォルトで Network Firewall がデプロイされている VPC CIDR 範囲になります。このデフォルト設定では、Network Firewall は VPC 内のソースから送信されるトラフィックを検査します。

一元化された Network Firewall をデプロイする場合、ルールグループの HOME_NET 変数にリモート VPC を含めるか、トラフィックの送信元となるソース CIDR を含める必要があります。詳細については、「Stateful domain list rule groups in AWS Network Firewall」(AWS Network Firewall のステートフルドメインリストルールグループ) を参照してください。

VPC 全体ではなく特定のプライベートサブネットからのトラフィックのみを検査するには、HOME_NET 変数にソースサブネット CIDR のみが含まれている必要があります。次の例では、HOME_NET 変数にはソースサブネット CIDR が含まれています。

"RuleVariables": {
        "IPSets": {
           "HOME_NET": {
             "Definition": [
               "10.0.0.0/16",
               "10.1.0.0/16",
               "192.168.2.0/24"
             ]
           }
        }
    }

DescribeRuleGroup API を使用してステートフルルールグループの詳細を確認します。RuleVariables オブジェクトが応答に含まれていない場合、ファイアウォールルールグループはデフォルト設定を使用します。HOME_NET のデフォルト設定は、Network Firewall VPC CIDR に設定されています。

ルール評価順序

TCP を使用するアプリケーションでは、アプリケーションがリクエストを送信する前に 3 ウェイハンドシェイクを完了する必要があります。ファイアウォールが接続で最初に認識するパケットは、送信元からの TCP SYN です。競合するルールによって下位レベルの TCP パケットがブロックされると、3 ウェイハンドシェイクは成功せず、アプリケーションがタイムアウトします。

例えば、ドメインリストルールグループは HTTP リクエストの Host ヘッダーを使用してホスト名を検出します。また、TLS ハンドシェイクではサーバー名表示 (SNI) 拡張を使用します。HTTP リクエストと TLS ネゴシエーションを行うには、最初にポート 80 (HTTP) と 443 (HTTPS) での最初の 3 ウェイ TCP ハンドシェイクが完了する必要があります。

アプリケーション層とトランスポート層の両方を含むルールを使用する場合は、アプリケーションが必要とする TCP ポートでトラフィックを許可します。ルール評価順序を見直して、前述のルールがトラフィックと一致していることを確認します。

デフォルトのアクション順序では、評価中に他のルールがトラフィックをブロックしていないことを確認してください。ルールに flow キーワードを使用すると、上位レベルのアプリケーションプロトコルが識別される前に、下位レベルのプロトコルパケットと照合されるのを防ぐことができます。

ルール設定の例を確認する

TCP トラフィックのルール設定が正しくない

次の例では、すべてのアウトバウンド TCP 接続をブロックし、example.com への HTTP リクエストのみを許可するようにルールが誤って設定されています。すべての TCP トラフィックがドロップされるため、ソースクライアントは HTTP アプリケーションリクエストを送信できません。

pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Drop outbound TCP traffic"; sid:172192; rev:1;)

TCP 接続の正しい設定

次の例では、"Allow TCP" ルールが最初に TCP 接続を確立します。次に、"Allowed HTTP domain" ルールにより HTTP ホストの example.com への接続を許可します。"Drop all other HTTP domains" ルールは残りの HTTP トラフィックをブロックし、"Default Egress TCP Drop" ルールは HTTP アプリケーション層のトラフィックを除く他のすべての TCP トラフィックをブロックします。

pass tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Allow TCP"; flow: not_established; sid:172190; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)
drop http $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Drop all other HTTP domains"; sid:172192; rev:1; flow: to_server;)
drop tcp $HOME_NET any -> any any (app-layer-protocol:!http; msg:"Default Egress TCP Drop"; flow:to_server; sid:172193;)

注: **example.com ** をターゲットドメインに置き換えてください。

Allow TCP (sid:172190) ルールは、ポート 80 で TCP 接続を確立することを許可します。このルールでは、flow: not_established キーワードを使用して初期接続セットアップを許可します。Allowed HTTP domain (sid:172191) ルールは、HTTP ホストヘッダーを検査することで example.com への HTTP トラフィックを許可します。Drop all other HTTP domains (sid:172192) ルールは flow: to_server キーワードを使用して example.com 以外のドメインへの HTTP トラフィックをブロックします。Default Egress TCP Drop (sid:172193) ルールは、app-layer-protocol:!http キーワードを使用して、アプリケーション層プロトコルとして HTTP を使用しないすべての TCP トラフィックをブロックします。

デフォルトのアクション順序では、定義されたルールに一致しないパケットが自動的に許可されます。

厳密な評価順序では、ルールグループは優先順位の低いものから順に評価されます。各ルールグループのルールは、定義された順序で処理されます。ルールと手動の優先順位の設定が正しいことを確認してください。優先度の低いルールをネットワークトラフィックと一致させないでください。厳格なファイアウォールポリシーで選択したデフォルトアクションに基づいてルールを記述してください。詳細については、「Managing evaluation order for Suricata compatible rules in AWS Network Firewall」(AWS Network Firewall での Suricata 互換ルールの評価順序の管理) を参照してください。

間違った設定によるタイムアウトの発生

次の例では、指定された設定では、ファイアウォールが HTTP アプリケーションレベルのリクエストを検出する前に、デフォルトですべての TCP トラフィックがドロップされます。この設定では、予期しないタイムアウトが発生します。

Default Action: Drop all
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

TCP 3 ウェイハンドシェイクを可能にする正しい設定

次の例では、Network Firewall は TCP 3 ウェイハンドシェイクの完了を許可し、example.com ドメインの HTTP トラフィックのみを許可します。

Default Action: Drop established
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

その他のファイアウォールルールの例については、「Examples of stateful rules for Network Firewall」(Network Firewall のステートフルルールの例) を参照してください。

関連情報

Deployment models for AWS Network Firewall (AWS Network Firewall のデプロイモデル)

Defining rule actions in AWS Network Firewall (AWS Network Firewall のルールアクションの定義)

Domain list inspection for traffic from outside the deployment VPC (デプロイ VPC 外部からのトラフィックのドメインリスト検査)