こんにちは。カスタマーサクセス部の山本です。
夏らしい気温になってきて、半袖を着る機会も増えていきそうですね。
綺麗な川を見ると飛び込みたくなります。
実際にもう 10回ぐらい飛び込んだりもしました。

低い山にも雪の残っていた 5月の初旬に「AWS Network Firewall が Suricata HOME_NET 変数の上書きに対応」というアップデートがありました。
AWS Network Firewall が Suricata HOME_NET 変数の上書きに対応

私も2022年に案件で困ったことが 2 回ほどあり、AWS サポートに機能要望を 2回ほど挙げていました。
アップデートが来て嬉しかったものの、5, 6月がとても忙しく、今週になってようやく試してみることができました。

具体的には、以下のブログで触れていた部分が改善されています。

AWS マネージドルールグループの注意点 (重要)

AWSマネージドルールでは「HOME_NET」変数 (=フィルタリングするときに「送信元」になるCIDR 範囲)を変更することはできません
「HOME_NET」変数には AWS Network Firewall を配置した VPC の CIDR が入ります
そのため Transit Gateway などを用いて監査VPC に集約した通信をフィルタリングしている場合には注意が必要です
「HOME_NET」変数 (=送信元のCIDR 範囲) が監査 VPC の CIDR 範囲になってしまうため正常にフィルタリング出来ません
その場合は自身で Suricata互換の侵入防止 (IPS) ルール (ステートフル) を作成する必要があります
(通信元となるコンポーネントが AWS Network Firewall を配置した VPC と同じ VPC にいないと使えません)

引用元：
blog.serverworks.co.jp

簡単に書くと・・・
AWS マネージドルールの HOME_NET 変数は、AWS Network Firewall のエンドポイントを配置した VPC の CIDR になってしまいます。そのため、AWS Network Firewall を集約構成にすると、HOME_NET 変数の CIDR は集約(監査)用 VPC となってしまい、他の VPC からの通信を評価できない。ということですね。「AWSマネージドルールを適用したつもりが、実はできてなかった。」ということも起きそうな気がします。

アップデート内容をもう少し補足します

AWS Network Firewall は以下の 3つの要素で構成します。

Firewalls
Firewall policies
Network Firewall rule groups

ネットワークファイアーウォール(Firewalls)を作成すると、VPC内にファイアーウォールエンドポイントが 1つできて、ファイアーウォールポリシー(Firewall policies)が 1つ紐付きます。
ファイアーウォールポリシー(Firewall policies)には、ルールの適用方法や評価順序を指定します。そして、適用するルールグループ (Network Firewall rule groups) を複数紐づけることができます。
適用するルールグループ(Network Firewall rule groups) には、具体的な検知ルール（5タプルルール、ドメインリスト等）を記述します。
ルールグループ(Network Firewall rule groups) にはルールを使って評価する送信元 IP アドレス (HOME_NET)を指定可能です。
送信元 IP アドレス (HOME_NET)の指定の仕方は、以下があります。

Default
- Firewall Endpoint を配置した VPC の CIDR
Defined
- 自分で定義する Cidr範囲

ルールグループの作成画面だと以下の箇所です。

Default というのは、ルールグループ (Network Firewall rule groups) の入れ物であるファイアーウォールポリシー(Firewall policies)に定義する HOME_NET 変数のことで、今までは変更不可でした。
本アップデートで、変更可能になりました。 🎉

AWS マネージドルールを使用する際には、送信元 IP アドレス (HOME_NET)に Defined （自分で定義）を指定することができません。
必然的に、AWS マネージドルールを適用する送信元 IP アドレスは、Default （Firewall Endpoint を配置した VPC の CIDR）になります。
本アップデートで、Default を変更可能になったため、集約構成で AWS マネージドルールを使用できるようになりました。

イメージ図：

アップデートを試してみる。

前提環境

以下の構成で試してみました。
「監査用VPC」と「VPC 1」にある EC2 が、「監査用VPC」にある NAT Gateway を使用して、インターネットに向けて通信します。
その際に、行きの通信と帰りの通信で「監査用VPC」にある Network Firewall Endpoint を通ります。
「VPC 1」の EC2 は Transit Gateway 経由で「監査用VPC」に通信します。

CIDR は以下です。

「監査用VPC」の CIDR は 10.0.0.0/16
「VPC 1」の CIDR は 172.16.1.0/24

HOME_NET 変数に上記の CIDR 2つを入れて、AWS マネージドルールで評価できるか見てみます。

HOME_NET 変数の変更方法

ファイアーウォールポリシー（Firewall policies）の作成時に指定する場所があります。（一番下の policy variables）

既存のファイアーウォールポリシー（Firewall policies）では、以下の場所から変更できます。（一番下の policy variables）

1行毎に CIDR を 1つ追加します。

実験

amazon.com へのアクセスを拒否するドメインリストルールを作成します。

ファイアーウォールポリシー（Firewall policies）の HOME_NET 変数を変えてみます。
最初は、「VPC 1」の CIDR と「監査用VPC」の CIDR を両方 HOME_NET 変数に入れます。

10.0.0.0/16
172.16.1.0/24

「VPC 1」「監査用VPC」の EC2 で想定通りアクセス拒否になりました。

以下は alert ログです。

次に、「監査用VPC」の CIDR のみを HOME_NET 変数に入れます。

10.0.0.0/16

「監査用VPC」の EC2 は、想定通りアクセス拒否になりました。
また、「VPC 1」の EC2 は想定通りアクセス可能でした。

以下は alert ログです。（「監査用VPC」の EC2 のみアクセス拒否になったためログが存在）

HOME_NET 変数に任意のIPv4アドレスを意図して 0.0.0.0/0 を指定してはいけない

HOME_NET 変数にたくさんのCIDR を指定するのを避けるために、 0.0.0.0/0 を指定してみました。

結果、Session Manager に繋がらなくなりました。EC2 が NAT Gateway 経由で SSM のエンドポイントに通信できなくなりました。

ログも出ないようです。

その後、本国の AWS の方から緊急のメールが届き、「0.0.0.0/0 は不適切な値なので、対象の Network Firewall が壊れました。適切な値に修正してください。」とのことでした。
関係者の方、お騒がせしました。🐱
以下ドキュメントを案内されました。（0.0.0.0/0 は駄目とは書いてないものの、そういう仕様なようです。）

For Policy variables enter one or more IPv4 or IPv6 addresses in CIDR notation to override the default value of Suricata HOME_NET. If your firewall is deployed using a centralized deployment model, you might want to override HOME_NET with the CIDRs of your home network. Otherwise, Network Firewall uses the CIDR of your inspection VPC.

Creating a firewall policy - AWS Network Firewall