はじめに
ドーモ、はじめまして。ウキタです。先日、AWS Network Firewallを触る機会がありました。そんなに調べなくてもある程度の設定はできるだろうとタカをくくっていたら、ステートレスルール/ステートフルルールのどちらを設定すれば良いのか、何のアクションを選べばいいのか、ルーティング設定したはずなのに通信できないなど...色々と苦戦しました。ネットワークの知識は少しあるので、自分なりに補足を入れながらAWS Network Firewallとそのルールについて解説していきます。ルーティングについては、別の記事で説明する予定です。
このページで説明すること
- AWS Network Firewallについて
- AWS Network Firewallのルールについて
- ステートレスルールグループ
- ステートフルルールグループ
※Suricata互換ルールとドメインルールについては詳しく説明しません。 また、AWSマネージドグループとルーティングに関しては説明しません。
AWS Network Firewallとは
VPC向けのマネージド型ファイアウォールと侵入検知・侵入防止を提供するサービスです。
イメージしやすいように構成図を見てみましょう。
以下は、AWS Network Firewall導入前のInternet GatewayとEC2のシンプルな構成図です。
先ほどの構成にAWS Network Firewallを導入すると、以下のような構成になります。 Internet GatewayとEC2の間にAWS Network Firewall用のサブネットを配置し、そこにあるエンドポイントでトラフィックをフィルタリングすることでVPC内のサブネットを保護します。 保護対象サブネットにエンドポイントを作成することも可能ですが、その場合AWS Network Firewallを通してEC2のトラフィックを検査することができません。 そのため、AWS Network Firewall専用のサブネットを作成する必要があります。
ちなみに、AWSマネージメントコンソールからこのエンドポイントタイプを確認すると、GatewayLoadBalancerとなっているため、AWS Network Firewallは内部的にGateway Load Balancerが使用されています。
AWS Network Firewallのリソース
リソース | 説明 |
---|---|
ファイアウォール | エンドポイントでトラフィックのフィルタリングを行う。 |
ファイアウォールポリシー | VPC内のトラフィックをフィルタリングするためのルールを設定する。 ファイアウォールポリシーに、後述するデフォルトアクションとルールグループを設定することで、トラフィックをフィルタリングできるようになります。 |
ルールグループ |
トラフィックを検査および処理する。
ステートレスルールグループとステートフルルールグループがあります。
また、AWSが提供しているマネージドルールグループがあります。
ファイアウォールポリシーに紐付けることで、ルールグループが適用されます。
マネージドルールグループについては以下AWSドキュメントを参考にしてください。 docs.aws.amazon.com |
AWS Network Firewallがパケットを処理する流れ
各ルールの説明へ入る前に、AWS Network Firewallがパケットを処理する流れについて理解しましょう。
これにはステートレスルールエンジンとステートフルルールエンジンがあり、それぞれ設定されたルールに従いルールエンジンがパケットを検査します。
ステートレスルールエンジンはパケットをパス、ドロップ、またはステートフルルールエンジンに転送します。
ステートフルルールエンジンはパケットをパス、ドロップ、または拒否することができ、さらにアラートを出すことも可能です。
ステートレスルールエンジンでパケットがパスまたはドロップされた場合、そのパケットはステートフルルールエンジンで評価されません。
ドロップと拒否の違いについて
ファイアウォールがパケットをドロップすると、送信元にはその旨が通知されません。 そのため、タイムアウトになるまでTCPコネクションが維持されTCP接続に影響が及びます。 一方、パケットを拒否した場合、ファイアウォールはパケットをドロップした後にTCP RST(リセット)を送信元へ送信します。 これにより、TCPコネクションが切断されるので、送信元は接続できなかったことをすぐに認識できます。 開発ユーザからのアクセスだけであれば、ドロップだとエラーを返すまで時間がかかるので拒否を選択した方がスムーズに開発が進みます。
ステートレスルールグループ
トラフィックの方向を考慮することなく、ステートレスルールエンジンが各パケットを個別に検査します。
ルール"グループ"とあるように、これはルールの集合体です。
ルールグループは複数作成することができます。
ステートレスルールグループとステートレスルールは、共に優先度が高い(優先度の値が小さい)順に評価されます。
ルールに一致するとその時点で処理を停止します。
ステートレスルールでパケットを正常にパスしたいときは、インバウンドとアウトバウンドの両方にルールを作成する必要があります。
例)HTTP接続を許可する場合
優先度 | プロトコル | ソース | 宛先 | 送信元ポート範囲 | 宛先ポート範囲 | アクション |
---|---|---|---|---|---|---|
10 | TCP | 0.0.0.0/0 | 10.0.0.0/16 | 0:65535 | 80 | パス |
20 | TCP | 10.0.0.0/16 | 0.0.0.0/0 | 80 | 0:65535 | パス |
ステートレスデフォルトアクション
フラグメント化されたパケット
MTU*1によりフラグメント化されたパケットに対するアクションを設定する。
すべてのパケットに同じアクションを利用する
フラグメント化されているパケット、されていないパケットに関わらず同じアクションを利用する。完全なパケットとフラグメント化されたパケットに異なるアクションを使用する
フラグメント化されているパケット、されていないパケットで異なるアクションを利用する。
アクションの種類
パス
検査を中止し、パケットをパスする。ドロップ
検査を中止し、パケットをドロップする。ステートフルルールに転送
ステートレスエンジンによる検査を中止し、ステートフルルールエンジンにパケットを転送する。
ステートフルルールグループ
ステートフルルールエンジンは、個々のパケットだけではなくトラフィックフロー全体を評価します。
トラフィックフローがドロップされた後は、そのフローに対して他のルールは適用されません。
ルールグループ形式
標準ステートフルルール
送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、プロトコル、その他のオプションを指定する。ドメインルール(このページでは詳しく説明しません)
ドメイン名のリストとドメインにアクセスしようとするトラフィックに対してアクションを指定する。 ドメインルールはアウトバウンドトラフィックに適用されるので注意しましょう。
When should I use AWS Network Firewall?
(中略)
AWS Network Firewall provides URL, IP address, and domain-based outbound traffic filtering to help you meet compliance requirements, stop potential data leaks, and block communication with known malware hosts.
引用)AWS Network Firewall FAQs, https://aws.amazon.com/jp/network-firewall/faqs/
- Suricata互換ルール(このページでは詳しく説明しません)
Suricata*2ルール構文を指定して高度なルールを指定する。
ステートフルルール評価の順序とデフォルトのアクション
ルールの順序
ステートフルルールグループ作成時にルールの順序を設定する必要があり、一度設定すると後で変更することはできません。
厳密な順序
優先度が高い(優先度の値が小さい)ステートフルルールグループの順に評価される。ステートフルルールに定義されたアクションの順に評価される。アクションの順序
パス、ドロップ、拒否、アラートの順で処理される。それぞれのアクションでは、優先度が高い順から低い順へ処理される。
デフォルトのアクション
厳密な順序を選ぶとこの設定が必要になります。
すべてをドロップ
すべてのパケットをドロップする。確立された接続のパケットをドロップ
3ウェイハンドシェイク*3により確立された状態のパケットのみドロップします。つまり、3ウェイハンドシェイク時のTCPはドロップされません。TCPのルールをわざわざ追加する必要がないので、上位レイヤであるHTTPなどのルール評価に集中することができます。すべてアラート
すべてのパケットに対してアラートログを残す。パケットはドロップしない。確立された接続のパケットをアラート
接続が確立されたパケットに対してアラートログを残す。パケットはドロップしない。
ここで、厳密な順序でHTTP接続を許可したい場合を考えてみましょう。
- "すべてをドロップ"を選んだ場合
HTTPを許可しても3ウェイハンドシェイク時のTCPがドロップされるので、まずTCPを許可する必要があります。 TCP/IP階層モデルでTCPは第3層のトランスポート層、HTTPは第4層のアプリケーション層に位置しています。 HTTPは第3層のTCPを利用して通信しているので、TCPの80ポートによる通信を許可すればHTTPも通信できます。 そのため、HTTPのルールを追加する必要はありません。 本来であればHTTPを開けるべきところをTCPで開けているので、(要件にもよりますが)このアクションの利用はオススメしません。
プロトコル | ソース | 宛先 | 送信元ポート範囲 | 宛先ポート範囲 | アクション |
---|---|---|---|---|---|
TCP | <送信元IPアドレス> | <送信先IPアドレス> | ANY | 80 | パス |
- "確立された接続のパケットをドロップ"を選んだ場合
TCPによる通信はできるので、HTTPのルールを追加すれば良いです。 全ての通信をドロップでは、TCPを開ければHTTPによる通信ができると記載しましたが、こちらはHTTPを許可する必要があります。
プロトコル | ソース | 宛先 | 送信元ポート範囲 | 宛先ポート範囲 | アクション |
---|---|---|---|---|---|
HTTP | <送信元IPアドレス> | <送信先IPアドレス> | ANY | 80 | パス |
結局どの設定を選べば良いのか
ステートレスルールグループかステートフルルールグループか
セキュリティグループのように戻りのトラフィックを自動的に許可したい、アプリケーションレイヤのプロトコル(HTTPやSMTPなど)による制御をしたいのであれば、ステートフルルールグループを使いましょう。より細かな制御をしたい、より低レイヤで制御したいのであれば、ステートレスルールグループを利用しましょう。
厳密な順序かアクションの順序か
AWSが推奨しているので厳密な順序にしましょう。ホワイトリスト方式のように特定のトラフィックのみを許可し、それ以外のトラフィックを拒否するような設定ができます。アクションの順序だとパス、ドロップ、拒否、アラートの順で処理されるので使い勝手が悪いです。
全てをドロップか確立された接続のパケットをドロップか
アプリケーションレイヤのプロトコル(HTTPやSMTPなど)の評価に集中したいのであれば、確立された接続のパケットをドロップにしましょう。ただし、TCPによるアクセスがサーバにくるので、そこが問題となるのであればSuricata互換ルールを使うのが良いでしょう。全てをドロップを選択すると、TCPのポート80番を許可するだけで上位レイヤのHTTP通信が可能になります。しかし、HTTPを許可したわけではないため、実際にHTTPによる通信であるとは限らない点に注意が必要です。
おわりに
今回は、補足を入れながらAWS Network Firewallとそのルールグループについて解説しました。
弊社のユースケさんとコースケさんがAWS Network Firewallのユースケースが欲しいとのことなので、また別の機会に記事にしようと思います。
皆さんが、AWS Network Firewallについて理解した上でルールを設定できるようになると幸いです。
参考)
What is AWS Network Firewall?, https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html
AWS Network Firewallのデプロイモデル, https://aws.amazon.com/jp/blogs/news/networking-and-content-delivery-deployment-models-for-aws-network-firewall/
Hands-on walkthrough of the AWS Network Firewall flexible rules engine – Part 1, https://aws.amazon.com/blogs/security/hands-on-walkthrough-of-the-aws-network-firewall-flexible-rules-engine/
Hands-on walkthrough of the AWS Network Firewall flexible rules engine – Part 2, https://aws.amazon.com/jp/blogs/news/hands-on-walkthrough-of-the-aws-network-firewall-flexible-rules-engine-part-2/