ルールが期待どおりに機能しない場合の、ネットワークファイアウォールの問題をトラブルシューティングするにはどうすればよいですか?
ルールが期待どおりに機能しない場合の AWS ネットワークファイアウォールの問題をトラブルシューティングをしたいと考えています。
簡単な説明
次のシナリオでは、ネットワークファイアウォールのルールが期待どおりに機能しない可能性があります。
- トラフィックはファイアウォールを経由して対称的にルーティングされません。
- ネットワークファイアウォールのルールが正しく設定されていません。
注: ネットワークファイアウォールの問題をトラブルシューティングする前に、次の設定を確認してください。
- ファイアウォールのエンドポイントは、専用のサブネットとルートテーブルにデプロイされます。ファイアウォールのサブネットにはワークロードリソースがあってはなりません。
- ルートテーブルは、ファイアウォールエンドポイントを介してトラフィックをルーティングします。Amazon CloudWatch メトリックス ReceivedPackets をチェックして、ネットワークファイアウォールがパケットを受信したことを確認します。ReceivedPackets メトリックの値がゼロの場合は、ルートテーブルにファイアウォールエンドポイントを指す正しいルートがあることを確認します。
解決策
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。
トラフィックがファイアウォールを経由して対称的にルーティングされない
一元化されたネットワークファイアウォールデプロイモデルでは、検査用仮想プライベートクラウド (VPC) の Transit Gateway アタッチメントの アプライアンスモードをオン にします。
次の AWS CLI コマンドを実行して、アプライアンスモードがオンになっているかどうかを確認します。
aws ec2 describe-transit-gateway-vpc-attachments --filters Name=transit-gateway-attachment-id,Values=tgw-attach-example
次の AWS CLI コマンドを実行して、アプライアンスモードをオンにします。
aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-example --options ApplianceModeSupport="enable"
**注:**前述のコマンド例では、tgw-attach-example をインスペクション VPC の Transit Gateway アタッチメントに置き換えてください。
パブリックサブネットにファイアウォールエンドポイントをデプロイする場合、インターネットゲートウェイの進入ルートテーブルは、ファイアウォールエンドポイントを経由してプライベートサブネットにルーティングする必要があります。プライベートサブネットのルートテーブルは、インターネットトラフィックを同じファイアウォールエンドポイントにルーティングする必要もあります。詳細については、「 インターネットゲートウェイを備えたシンプルなシングルゾーンアーキテクチャ」を参照してください。
マルチ AZ ファイアウォールデプロイ設定では、インターネットゲートウェイの進入ルートテーブルが同じファイアウォールエンドポイントを経由してプライベートサブネットにトラフィックをルーティングする必要があります。また、ルートテーブルはプライベートサブネットと同じアベイラビリティーゾーンにある必要があります。詳細については、「 インターネットゲートウェイを備えたマルチゾーンアーキテクチャ」を参照してください。
ネットワークファイアウォールのルールが正しく設定されていません
ネットワークファイアウォールのルールに関する問題は、ルールの設定方法が原因である可能性があります。
ステートレスルール
トラフィックが両方向に流れるようにするには、入力ルールと出力ルールにステートレスルールを適用する必要があります。着信トラフィックの入力にルールを適用する場合は、応答トラフィックの出力にもルールを適用する必要があります。応答トラフィックの出力にルールを適用する場合は、着信トラフィックの入力にもルールを適用する必要があります。このルール設定は、アクセスコントロールリスト (ACL) に似ています。
次の例は、ステートレスルールを使用して着信 SSH トラフィックを許可する方法を示しています。
| 優先度 | プロトコル | ソース | 宛先 | 送信元ポート範囲 | 宛先ポート範囲 | アクション |
|---|---|---|---|---|---|---|
| 1 | TCP | 0.0.0.0/0 | 10.1.0.0/16 | 0:65535 | 22 | パス |
| 2 | TCP | 10.1.0.0/16 | 0.0.0.0/0 | 22 | 0:65535 | パス |
注: 前の例では、着信 SSH トラフィックは任意の IP アドレスから CIDR 10.1.0.0/16 を介してルーティングされます。
パケットのステートレスデフォルトアクション
フルパケットとフラグメントパケットの両方に対するステートレスのデフォルトアクションを確認してください。デフォルトのアクション設定は、ステートレスルールに一致しない個々のパケットをファイアウォールのステートレスエンジンがどのように処理するかを決定します。フラグメント化されたパケットのステートレスデフォルトアクションを、UDP トランスポートプロトコルを使用する IPv4 パケットフラグメントのみに適用します。
**注:**IPv6 プロトコルはネットワークのフラグメンテーションをサポートしていません。ホストが受信ホストの MTU よりも大きいパケットを送信すると、受信ホストはそのパケットをドロップします。パス上のデバイスは、デバイスの MTU よりも大きいパケットもドロップします。
ステートフルルール
ステートフルルールエンジンがトラフィックを検査するには、ステートレスルールエンジンが両方のトラフィックフロー方向をステートフルルールグループに転送する必要があります。
ネットワークファイアウォールのルールはプライベート IP アドレスを参照する必要がある
プライベートサブネットまたはワークロードにパブリック IP アドレスとプライベート IP アドレスの両方がある場合、ネットワークファイアウォールのルールはプライベート IP アドレスを参照する必要があります。
ルールグループ変数
ステートフルネットワークファイアウォールのルールグループは、変数 HOME\ _NET を使用してファイアウォール検査の範囲を定義します。**HOME\ _NET ** 変数を明示的に指定しない場合、変数はデフォルトでネットワークファイアウォールがデプロイされている VPC CIDR 範囲になります。このデフォルト設定では、ネットワークファイアウォールは VPC 内のソースから送信されるトラフィックを検査します。
一元化されたネットワークファイアウォールをデプロイする場合、ルールグループの HOME\ _NET 変数にリモート VPC を含める必要があります。または、トラフィックの発信元のソース CIDRが含まれている必要があります。詳細については、「 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 のデフォルト設定は、ネットワークファイアウォール 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 接続の正しい設定
次の例では、ドロップ確立 TCP:80 ルールが最初に TCP 接続を確立します。その後、HTTP ホスト名 example.comと一致しないその他のパケットはすべてドロップされます。
drop tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Drop established TCP:80"; flow: from_client,established; sid:172190; rev:1;) pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; priority:10; sid:172191; rev:1;) drop tcp $HOME_NET any -> $EXTERNAL_NET !80 (msg:"Drop outbound non TCP:80 traffic"; sid:172192; rev:1;)
**注:**デフォルトのアクション順序では、定義されたルールに一致しないパケットが自動的に許可されます。
厳密な評価順序では、ルールグループは優先順位の低いものから順に評価されます。各ルールグループのルールは、定義された順序で処理されます。ルールと手動の優先順位の設定が正しいことを確認してください。優先度の低いルールをネットワークトラフィックと一致させないでください。また、厳格なファイアウォールポリシーで選択したデフォルトアクションに基づいてルールを記述してください。
間違った設定によるタイムアウトの発生
次の例では、指定された設定では、ファイアウォールが 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 ウェイハンドシェイクを可能にする正しい設定
次の例では、ネットワークファイアウォールは 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;)
その他のファイアウォールルールの例については、「 ネットワークファイアウォールのステートフルールの例」を参照してください。
関連情報
AWS Network Firewall のルールアクションの定義
