CR課の前田です。NetworkFirewall（以降、NFWと表記）の動作検証中に躓いたところがあり、「これはトラップだな…」と思ったのでブログにしました。
結論
- 暗黙的拒否を実現しているNFWにおいてアクションが「アラート」のステートフルルール（以降、アラートルールと表記）のみでは通信拒否されます
- アクションが「パス」のステートフルルール（以降、パスルールと表記）も必要です
説明
暗黙的拒否とは？
拒否すべき通信が膨大なため、セキュリティグループのようにホワイトリスト方式で許可対象通信のみを登録したいという時があります。
NFWにおいては下記設定を実施することで暗黙的拒否を実現できます。
- ルールの順序…厳密な順序
- デフォルトのアクション…確立された接続のパケットをドロップ
上記設定を行った上で、パスルールで許可したい通信を指定することでホワイトリスト方式を実現できます。
下記のAWS公式ブログが詳しく解説しているため、ご覧ください。
aws.amazon.com
アラートルールとは？どのような時に必要？
NFWには概要レベルの情報が記録されるフローログと、パケット単位で詳細レベルの情報が記録されるアラートログがあります。（参考：VPCフローログとNetwork Firewallログの内容を比べてみる）
アラートログはアクションが「アラート」「ドロップ」「拒否」のステートフルルールでは出力されるのですが、アクションが「パス」のステートフルルールでは出力されません。
パスされる通信においてもアラートログを出力したい場合に、アラートルールが必要になります。
私が勘違いしていたこと
WAFのカウントモードのようなイメージを勝手に持っており、アラートルールのみ設定しておけばアラートログを出力しつつ通信が許可出来ると考えていましたがこれは誤りでした。
実際にはアラートルールとパスルールのどちらも必要で、かつアラートルールをパスルールよりも上の優先度にしておく必要があります。
AWS公式のブログにも説明が記載されていました。 aws.amazon.com
パスのルールにマッチした通信はアラートログには記録されません。そこで、許可された通信もログに記録する際には、こちらの例のようにパスのルールの前にアラートのルールを記載します。アラートのルールにマッチした通信は、アラートログに "allowed" と記録されますが、ファイアウォールはその後のルール評価を継続するため、通信を許可するためにはパスのルールも必要になります。
検証
検証環境
下図のような検証環境を用意し、vpc.Spoke1、vpc.Spoke2それぞれにEC2を配置してNFWを通るようにルーティングしておきます。
NFWには上述の設定を施し、暗黙的な拒否を実現します。
また、拒否された通信のアラートログを出力したい（※1）ため、「確立された接続のパケットをアラート」も設定しておきます。
下記画像の条件のアラートルールを設定します。パスルールはまだ設定しないでおきます。
フローログとアラートログをCloudWatchの各ロググループへ転送するよう設定します。
※1…「確立された接続のパケットをドロップ」だけでは暗黙的拒否された際のアラートログは出力されません。（参考：ネットワークファイアウォールのログ分析でセキュリティ向上を実現）
また、Network Firewall では、ステートフルルールのデフォルトアクションとしてどのルールにもマッチしなかったパケットをアラートログに記録するように設定することが可能です。デフォルトアクションでドロップされたパケットのログを取得する場合は、こちらのようにファイアウォールポリシー設定の「ステートフルルール評価の順序とデフォルトのアクション」の箇所で「確立された接続のパケットをドロップ」を選択し、アラートアクションの箇所で「確立済み」にチェックを入れます。
検証_アラートルールのみ設定
vpc.Spoke1のEC2（10.0.1.68）からvpc.Spoke2のEC2（10.0.2.68）へpingを飛ばします。アラートルールのみの設定なので暗黙的拒否の対象となり疎通失敗することを確認します。
実際にpingを打ってみました。疎通には失敗しています。
まずはフローログを見てみます。flow_idに「1711559516895713」と記載されているので、これをもとにアラートログを探します。
アラートログには2種類ありました。
1つ目はアラートルールで評価された際に出力されたものです。（実際は拒否されているにも関わらず「allowed」と記載されているのは結構紛らわしいです💦）
2つ目は暗黙的拒否された際に出力されたものとなります。こちらは実態に伴い「blocked」と記載されています。
検証_アラートルール&パスルールを設定
アクション・キーワード以外の項目は同値のパスルールを、アラートログよりも低い優先度で設定します。
尚、項目「キーワード」に設定されている値は「Signature_id」という各ルールに割り振る一意のIDであり、優先度とは別物です。
下図のように、新たに設定されるパスルールによって疎通成功することを確認します。
実際にpingを打ってみたところ、疎通成功していることが確認できました！
アラートルールによって評価されているため、アラートログも出力されています。
感想
前述したようにWAFカウントモードと同じようなものだと勘違いしていたため、先入観を捨ててドキュメント精査することの大切さを再認識しました。
この仕様については少し嫌だなと思っていて、NFWを運用していくことを考えた時、パスルールとアラートルールで管理対象が2倍になるのが大変そうだな…と感じました。
私と同じような勘違いをしている方、もしかしたら少しいるのではないかと思っており今回記事にさせていただきました。お役に立てたら幸いです。
