こんにちは！エンタープライズクラウド部クラウドコンサルティング課の日高です。
もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。
今回は、AWS Network Firewall構築の際に設計の助けになればと思い、AWS Network Firewallのパラメーターの内容を記載していきます。
- AWS Network Firewallの概要
- AWS Network Firewallのパラメーター一覧
- Firewall Policyのパラメーター一覧
- Rule Groupのパラメーター一覧
- 補足（AWS Network Firewallのログ設定について）
- まとめ
AWS Network Firewallの概要
AWS Network Firewallを利用すると、ネットワークトラフィックを詳細まで制御できるファイアウォールルールを定義できます。
概念やユースケースについては以下のブログをご覧ください。
AWS Network Firewallのパラメーター一覧
基本設定
IPアドレスタイプ
AWS Network FirewallがサポートするIPアドレスタイプになります。
IPv4・IPv6・DUALSTACK（IPv4 と IPv6 両方をサポートする形式）から指定することができます。
こちらのIPアドレスタイプは、2024年4月現在 作成後変更できない設定なのでご注意ください。
また、IPv6・DUALSTACKにて作成する場合、VPC（サブネット含む）が IPv6 CIDR ブロック のものを指定する必要があります。
カスタマーマネージドキーの利用
AWS Network Firewallのデータの暗号化の際に利用するKMSキーを指定します。
デフォルトだと、AWSマネージドキーが暗号化に利用されます。
AWSマネージドキーは、AWSが作成・管理・使用するKMSキーで、カスタマーマネージドキーは、ユーザーが作成・所有・管理できるKMSキーです。
特に要件がなければ、キーの管理が最小限に抑えられるのでAWSマネージドキーの利用を推奨します。
ただし、「自社のキーを利用する」という会社のポリシーが存在している場合や、キーポリシー（KMSキーへのアクセスを制御するポリシー）などカスタマーマネージドキーでサポートされている機能を利用したい場合は、カスタマーマネージドキーを利用することを検討してください。
※詳しくは以下をご覧ください。
変更保護
削除保護
AWS Network Firewallの誤削除を防止する設定になり、有効と無効から選ぶことができます。（デフォルトでは有効）
削除保護を有効にしているAWS Network Firewallを削除しようとすると、エラーがでて削除することできません。
削除保護を有効にしている AWS Network Firewall を削除するには、設定から削除保護を無効にしてから削除する必要があります。
本番環境で AWS Network Firewallを使用する場合は誤削除を防ぐために有効をお勧めします。
サブネット変更保護
サブネットの関連付けが誤って変更されることを防止する設定になり、有効と無効から選ぶことができます。（デフォルトでは有効）。
サブネット変更保護を有効にしているAWS Network Firewallのサブネットの関連付けを変更しようとすると、エラーがでて変更することできません。
サブネット変更保護を有効にしている AWS Network Firewall のサブネットの関連付けを変更するには、設定からサブネット変更保護を無効にしてから変更する必要があります。
本番環境で AWS Network Firewallを使用する場合は誤った変更を防ぐために有効をお勧めします。
ログ記録
ログタイプ
AWS Network Firewallの通信ログの記録の有効可否の設定になり、Alertログ・Flowログ・両方 を記録することができます。（デフォルトでは無効）
それぞれのログタイプで記録できる内容は以下です。
- Alertログ：ステートフルルールに合致する通信の中でドロップ、アラート、拒否のアクションが設定されたステートフルルールに合致する通信詳細が記録（ステートレスのルールにマッチするトラフィックについてはログに記録されない）
- Flowログ：ステートレスエンジンからステートフルエンジンに転送される通信の概要の情報（送信元IP、送信元ポート、送信先IP、パケット数など）を記録
※詳しくは以下の弊社ブログをご覧ください。
個人的な所感ですが、VPC Flow Logsを有効化している場合は「Alertログ」だけ設定すれば問題ないと感じました。
上記の弊社ブログに詳しい内容は記載していますが、VPCフローログとNFWフローログではほとんど差異がないのと、全てのログを保存するとログ保存料金が高額になってしまうためです。
ログ宛先
ログタイプで記録するログを選択した場合、ログの宛先を設定する必要があります。
ログ宛先として、S3・CloudWatch log group・Kinesis data firehose から選択することができます。
また、ログの出力先としては、アラートログとフローログそれぞれ、Amazon Simple Storage Service (S3) バケット、Amazon CloudWatch ロググループ、Amazon Kinesis Data Firehose の 3 つから選択することができます。
出力先の選択の観点としては以下です。
- Kinesis Data Firehose：リアルタイムにログを処理したりサードパーティの SIEM ソリューションなどに配信する場合
- S3とCloudWatch log groupの選択の観点（メリット・デメリット）は以下にまとめます。
| ログ保存先 | メリット | デメリット | ユースケース（一例） |
|---|---|---|---|
| S3 | ・CloudWatch log group に比べるとログ格納時・保存時共に料金が安い ・生データを配信しやすい |
・マネジメントコンソールからログを手軽に分析したい用途には向かない | ・ログ分析の際に、Amazon Athena や SIEM on Amazon OpenSearch Service を使用する ・S3のデータをオンプレミスのデータ分析基板に送信して分析する |
| CloudWatch log group | ・マネジメントコンソールからログを手軽に分析できる ・CloudWatch Alarm等のCloudWatch系のサービスとの連携が手軽にできる |
・S3に比べるとログ格納時・保存時共に料金が高い | ・ログ分析の際に、CloudWatch Logs Insights を使用する ・運用者がマネジメントコンソールからログを手軽に分析する |
※詳しくは以下をご覧ください
Firewall Policyのパラメーター一覧
ストリーム例外ポリシー
ネットワーク接続が途中で切断された際に、ファイアウォールがどのようにトラフィックを扱うかを設定します。
Drop・Continue・Reject から選択することができます。（デフォルトはDrop）
ざっくり書くと、「Drop」 と 「Reject」 は Network Firewall のステートフルルールのコンテキストを重要視するパラメータで、「Continue」は Network Firewall よりも通信の持続性を重要視するパラメータです。
※ストリーム例外ポリシーについて詳しくは以下の弊社ブログをご覧ください。
1. Drop（デフォルト）
- 特徴
- パケットを単純にドロップする。（ドロップすることで TCP の再送を失敗させ、通信をタイムアウトさせる。）
- タイムアウトした場合にはコネクションは切断となるため、新規コネクションを作成する必要がある。
- 新規コネクションを作成した際には、AWS Network Firewall がコンテキストを完全に保持できるため、正しくルールを適用できる。
- ネットワーク切断が起こるたびに、上記記載のようにコネクションは切断される。
- 利点
- 一時的なネットワーク切断時には、TCP タイムアウトが発生するまで待ち、クライアントやサーバーが自発的にセッションを再開するのを待つことができ、新しいコネクションで完全なコンテキストを用いてNetwork Firewallで検査することができる。
- 適用シナリオ
- 完全なコンテキストを用いて監視が必要な場合。
- クライアントやサーバーが適切なタイムアウト処理を持っている場合に有効。
2. Reject
- 特徴
- パケットをドロップし、さらにTCP RESETを送信する。
- TCP RESET を送信すると、通信はすぐに切断されるため、再送タイムアウトを待たなくて良い。
- ただし、TCP RESET は強制切断なので、アプリケーションとしては意図しない動作をすることがある。
- タイムアウトした場合にはコネクションは切断となるため、新規コネクションを作成する必要がある。ほかは Drop と同様。
- 利点
- TCP RESETにより、クライアントやサーバーにすぐに新しいセッションの開始を促す。これにより、早急にコネクションの再確立が求められるシナリオで有効。
- 適用シナリオ
- 一時的なネットワークの切断時に、クライアントとサーバーのコネクションがタイムアウトするまでに時間がかかることが問題になる場合。
- タイムアウトを待っているコネクションが大量にあり、新しいコネクションを作成できない場合など。
- ただし、一部のアプリケーションではTCP RESETが意図しない動作を引き起こす可能性があるため注意が必要。
3. Continue
- 特徴
- ネットワークの一時的な切断にも関わらず、コネクションを保持（通常と同様にデータを処理）しようとする
- drop はされないので、ネットワークの回復時に再送処理が成功する可能性がある。
- しかし、ステートフルルールでは、SYN / ACK / FIN など、TCP ストリームの通信の流れをファイアーウォール内のテーブルにコンテキストとして残しているため、AWS Network Firewall が行うステートフルルールの処理についてはコンテキスト情報を失っている可能性がある。
- 一時的な切断時には、これらのコンテキストが失われる可能性があり、通信回復時にも正しくルールを適用できない可能性がある。
- 利点
- TCP の再送制御機能を活用し、継続的な通信が求められるシナリオにおいて、コネクションの継続を図る。
- 適用シナリオ
- Active Directoryのような、長時間続くレプリケーションやセッションが重要な役割を果たす場合。ただし、ステートフルルールが完全なコンテキストを失う可能性（＝Network Firewallの検査が不完全になるため、Network Firewallでのセキュリティ担保が不完全になる可能性がある。）があるため、注意が必要。
選択の観点
- Drop：ネットワークの一時的な切断が起きるのは仕方ない。セキュリティが優先で、ステートフルルールには完璧なコンテキストを持たせて処理させたい場合。
- Reject：ネットワークの一時的な切断が起きるのは仕方ない。セキュリティが優先で、ステートフルルールには完璧なコンテキストを持たせて処理させたい。タイムアウトしないアプリケーションがあり、コネクションを持ち続けているため、Network Firewall で切断したい。
- Continue：ネットワークの一時的な切断が深刻な問題になる。切断後にコネクションを作り直しても問題は持続する。
推奨
これらの設定は、ネットワークの特性、アプリケーションの要求、および運用上のニーズに基づいて選択する必要があります。
初期設定としては「Drop」を採用し、実運用を通じて他の選択肢が必要であれば、適宜切り替えることをお勧めします。
※詳しくは以下をご覧ください
ポリシー変数
HOME_NET 変数のオーバーライド値 を指定します。（オプション設定になります）
ポリシー変数で指定したCIDRで、HOME_NET 変数を上書きすることができます。
HOME_NET 変数とは、ルールを使って評価する送信元 IP アドレスのことです。
※ HOME_NET 変数について詳しくは以下の弊社ブログをご覧ください。
使用する場合は、以下の点に注意してください。
- ポリシー変数とルール変数どちらもHOME_NETをオーバーライドしている場合、ルール変数の値が優先される
- ポリシー変数は HOME_NETをまだ定義していないすべてのルールグループに影響する
TLS 検査設定
AWS Network FirewallでTLS通信も検査することができる機能になります。
AWS Network Firewallで復号化→検査（HTTPSのパスをチェックするなど）→暗号化の流れで通信を検査することができます。
TLS 検査設定 を利用する場合、追加料金が必要になります。
また、復号化/暗号化するためレイテンシーは増加します。
※詳しくは以下をご覧ください。
ステートレスデフォルトアクション
ステートレスルールのデフォルトのアクションをパス、ドロップ、ステートフルルールグループに転送から選択することができます。
また、フラグメント化されたパケットと完全なパケットで異なるアクションを使用するよう設定することも可能になります。
要件にもよりますが、基本的にはステートレスルールグループは利用しないで、「ステートフルルールグループに転送」するのがいいかと感じています。
理由としては、ステートレスルールとステートフルルール両方で管理すると管理が煩雑になり運用コストが増加すると考えているからです。
NACLとセキュリティグループを併用する場合を想像していただくとわかりやすいかと思います。
※AWS Network Firewall のルールグループと評価の流れについては、詳しくは以下の弊社ブログをご覧ください。
ステートフルデフォルトアクション
ステートフルデフォルトアクションにて「ルール評価の順序」、「ドロップアクション」、「アラートアクション」を選択することができます。
ルール評価の順序
厳密な順序 ・アクションの順序 から選択することができます。（ルール評価の順序は、Firewall Policy作成時しか指定できないので注意してください）
アクションの順序（以前は 「デフォルトの順序」と呼ばれていました）を選択すると、以下の図のようにアクションが「パス」「ドロップ」「アラート」の順に並べ替えられて評価されます。
「アクションの順序」だとルールの優先度とルールグループの優先度を定義することができないので、基本的に「厳密な順序」を選択いただくことを推奨します。
ルール順序を「厳格な順序」にすると、以下のようなことができるようになります。
- ルールグループ内でルールの優先度をカスタマイズできる
- ファイアウォールポリシー内のルールグループ間で優先度をつけることができる
- 以降で記述する「ドロップアクション」「アラートアクション」を指定できるようになる
※詳しくは以下をご覧ください。
ドロップアクション
どのステートフルルール（複数ルールグループがある場合、すべてのルールグループに合致しない場合）にも一致しないパケットに対して Network Firewall が実行するデフォルトのドロップアクションを以下から選択することができます。
- すべてをドロップ
- TCP接続の許可をステートフルルールで許可していないと、通信が全てドロップされる
- 明示的に許可しない限り、TCPコネクションも拒否される。（明示的に許可した通信だけが通る。もっとも厳格）
- 確立された接続のパケットをドロップ
- コネクション確立後（コネクションの確立はTCPの3ウェイハンドシェイク後）の通信について、ルールグループで定義したルールにマッチしなかった場合はドロップされる
- 明示的に拒否しない限り、TCPコネクションは許可される。
※注意
ドロップアクションで「すべてをドロップ」を選択した場合「ステートフルドメインリストフィルタ」の指定はできません。（正確には設定はできますが、意味がないです。）
「すべてをドロップ」の場合、TCP接続の許可をステートフルルールで許可していないと、通信が全てドロップされるため、「ステートフルドメインリストフィルタ」のルールのみでは通信がドロップされてしまいます。
ステートフル5-tupleとステートフルドメインリストの合わせ技（5-tupleでTCP80/TCP443を通し、ドメインリストで対象ドメインのHTTP・HTTPSを検査する想定）で、HTTP/HTTPSを通すことは可能と思いきや、実態は5-tupleで通しているだけになります。
要するに、5-tupleでTCP80/TCP443を全許可してしまうと、そこでPassしてしまうので、結果的にどのドメインでも通信できてしまうため、「ステートフルドメインリストフィルタ」のルールは適用されません。
つまり「ステートフルドメインリストフィルタ」のルールを適用させたい場合は、ドロップアクションは「すべてをドロップ」以外にする必要があります。
※詳しくは以下の弊社ブログをご覧ください。
アラートアクション
全てのステートフルルールに一致しなかった際にログを記録するかどうかの設定になります。
※ステートフルデフォルトアクションの「ルール評価の順序」を「厳密な順序」にした場合、Firewall Policyのアラートアクションを考える必要があります。
基本的に、ドロップアクションに合わせてアラートアクションを選択することがわかりやすいかと思います。
以下の組み合わせが考えられるかと思います。
- ドロップアクション「すべてをドロップ」×アラートアクション「すべて」
- ドロップアクション「確立された接続のパケットをドロップ」×アラートアクション「確立済み」
Rule Groupのパラメーター一覧
ルールグループ形式
AWS Network Firewallで利用できるルールグループ形式は以下になります。
- ステートレスルール
- ステートレス 5-tuple（タプル ）フィルタ
- ステートフルルール
- ステートフル5-tupleフィルタ
- ドメインリスト
- Suricata 互換ルール文字列
※ルールグループについて詳しくは以下の弊社ブログをご覧ください。
以下に、各ルールグループ形式について箇条書きで記載します。
ステートレス 5-tupleフィルタ
- どのようにトラフィックを検査するかのルールを、NACLのように優先度（評価順）つけて列挙していく
- ルールにマッチしなかった場合のアクションを指定可能（Drop/Pass/ステートフルルールに移行）
- ステートレスであるため、Ingress/Egress両方を設定する
- ルールで指定可能なタイプ
- 送信元・先のIPアドレスによるフィルタリング
- プロトコルとポートによるフィルタリング (HTTPなどプロトコルのみの指定も可能)
- TCPフラグを指定可能
ステートフル5-tupleフィルタ
- どのようにトラフィックを検査するかのルールを、優先度を付けずに列挙していく
- トラフィックをパスするルールが常に優先され、マッチしなかった場合のアクションはDrop固定となる
- ステートフルなので、パスした通信に対する応答ト ラフィックは、自動的にパスされる
- ルールで指定可能なタイプ
- 送信元・先のIPアドレスによるフィルタリング
- プロトコルとポートによるフィルタリング (HTTPなどプロトコルのみの指定も可能)
- IP セット変数とポート変数を定義してルールグループ内のルールに使用可能
ドメインリスト
- Web通信（HTTP/HTTPS）を宛先ドメインベースでフィルタ
- マッチしなかったときのアクションを指定可能（Drop/Pass）
- ワイルドカード指定可能（例： ".example.com”→ example.comのすべてのサブドメインを指定）
- SSL/TLSの場合SNIを見て検査するので、ESNIが使われている通信には適用不可
- ルールで指定可能なタイプ
- 送信先ドメイン・送信元IPアドレス(デフォルトはVPC内)を指定してフィルタリング可能
- プロトコルは http / https から選択可能
Suricata 互換ルール文字列
- Suricataと互換性のあるIPS機能
- ステートフル5-tupleフィルタ、ステートフルドメインリストフィルタはこの機能でも実現可能
- 様々なルールを組み合わせて記載する場合は、こちらに集約してしまうと運用が楽になる評価順が指定可能になるなど、柔軟な制御が可能になり、機能も豊富
- Suricataのシグネチャ作成の知識が必要
- 指定できるルールタイプ
- Suricata 互換 のルールを指定してフィルタリング可能（これでほぼ全ての内容ができる）
- IP セット変数とポート変数を定義してルールグループ内のルールに使用可能
キャパシティー
AWS Network Firewallでは、各ルールグループにキャパシティを割り当てることが必要になります。
※ルールグループ 作成時に割り当てたキャパシティは、後から変更することができません。そのため、後からルールが追加されることも考慮し、少し余裕をもたせた値を設定することをおすすめします。
ルールグループに割り当てられるキャパシティの最大値は30,000ユニットです。
この制限を考慮に入れながら、ファイアウォールポリシーとルールグループの設計を行うことが重要になります。
※Rule Group Capacityの計算方法について詳しくは以下の弊社ブログをご覧ください。
トラフィックの方向
AWS Network Firewallでステートフルルールを設定する際のオプションで、NFWルールの評価対象となるトラフィックの方向を指定できます。
選択肢それぞれの説明は、マネジメントコンソール記載の説明を借りると下記のようになります。
- 転送：送信元に指定したCIDRから送信先に指定したCIDRへのトラフィックのみが評価される
- すべて：送信元に指定したCIDR、送信先に指定したCIDRどちらが発信元になってもトラフィックは評価される
※トラフィックの方向 について詳しくは以下の弊社ブログをご覧ください。
補足（AWS Network Firewallのログ設定について）
今まで紹介したパラメーターで2箇所ログ設定（AWS Network Firewallのログ記録と、Firewall Policyのアラートアクション）を行うものがあったと思います。
少し理解が難しい箇所もあると思うので、こちらの補足に記載をしていきます。
前提としてAWS Network Firewallのログ記録と、Firewall Policyのアラートアクションは、ざっくり書く（詳しい内容は後述します）と以下の使い分けになります
- AWS Network Firewallのログ記録：個別のルールに一致した際にログを記録するかどうかの設定
- Firewall Policyのアラートアクション：全てのステートフルルールに一致しなかった際にログを記録するかどうかの設定
AWS Network Firewallのログ記録
AWS Network Firewallのログ記録は、「個別のルール」に一致した際にログを記録するかどうかの設定と上記に記載させていただきました。
詳細に正しく記載させていただくと以下になります。
- Flowログ：ステートレスエンジンからステートフルエンジンに転送される通信の概要の情報（送信元IP、送信元ポート、送信先IP、パケット数など）を記録
- Alertログ：ステートフルルールに合致する通信の中でドロップ、アラート、拒否のアクションが設定されたステートフルルールに合致する通信詳細が記録（ステートレスのルールにマッチするトラフィックについてはログに記録されない）
AWS公式ドキュメント-ネットワークファイアウォールのログ分析でセキュリティ向上を実現に記載してある上記の図を用いて説明していきます。
- Flowログで取得されるログは、図の赤枠のステートレスエンジンからステートフルエンジンに転送される箇所になります。
- Alertログで取得されるログは、図のオレンジ枠の、ステートフルエンジンのステートフルルールに合致する通信の中でドロップ、アラート、拒否（※）のアクションが設定されたステートフルルールに合致する箇所になります。
※ステートフルルールのアクションがパスの際にもAlertログを取得したい場合、アクションが「パス」のステートフルルールに加え、アクションが「アラート」のステートフルルールも作成する必要があります。
Firewall Policyのアラートアクション
以下、本ブログで紹介した内容の再掲になります。
全てのステートフルルールに一致しなかった際にログを記録するかどうかの設定になります。
※ステートフルデフォルトアクションの「ルール評価の順序」を「厳密な順序 」にした場合、Firewall Policyのアラートアクションを考える必要があります。
基本的に、ドロップアクションに合わせてアラートアクションを選択することがわかりやすいかと思います。
以下の組み合わせが考えられるかと思います。
- ドロップアクション「すべてをドロップ」×アラートアクション「すべて」
- ドロップアクション「確立された接続のパケットをドロップ」×アラートアクション「確立済み」
まとめ
長くなってしまいましたが、AWS Network Firewallのパラメーターをまとめてみました。
本記事を書いていて、過去ブログに何度も助けられました.......
このブログも誰かの助けになれれば幸いです。
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
