AWS Network Firewall の Reject と Alert のドメインリストを Allow と組み合わせ、ルールの評価順序ごとに確かめてみた

はじめに

テクニカルサポートの 片方 です。
AWS Network Firewall のドメインリストルールグループは、Allow と Deny に加えて、Reject（TCP リセットを返す）と Alert（ログに記録する）を選べます。ドメインリストルールグループのドキュメントは、アクション順序のポリシーでは Allow が追加する drop ルールが Reject と Alert より先に効くとして、この組み合わせを避けるよう勧めています。

そこで、この組み合わせで次の 3 点を確かめました。

• Reject のドメインへの curl が、リセットではなくタイムアウトになるか
• Alert のログが出なくなるか
• 厳格な順序にすると、結果が変わるか

Allow・Reject・Alert の 3 つのドメインリストルールグループを、アクション順序と厳格な順序のポリシーにそれぞれ入れました。ファイアウォールの内側の Amazon EC2 インスタンスから同じ curl を実行して、終了コードとアラートログを比べました。

構成

次のリソースを AWS CLI で作りました（東京リージョン）。

aws.amazon.com は、許可リストの .amazonaws.com に一致しないので、リストに無いドメインとして使いました。

先に結論から

• curl の結果は、アクション順序でも厳格な順序でも同じでした。Allow のドメイン（example.com）は 200 です。Reject のドメイン（example.net）は HTTPS が終了コード 35、HTTP が 56 で、即時に失敗しました。Alert のドメイン（example.org）とリストに無いドメイン（aws.amazon.com）は、15 秒のタイムアウト（28）でした。
• アクション順序でも、Reject のドメインには TCP リセットが返りました。HTTPS の Reject と Alert のドメインには、Allow の drop のログ（not matching any TLS allowlisted FQDNs）と、それぞれ Reject と Alert のログが、同じ接続・同じ時刻で 2 件ずつ記録されました（2 回とも）。
• HTTP の Alert のドメイン（example.org）のログは、厳格な順序では取得できました。アクション順序では、2 回とも、最後の curl の約 75 秒後に取得したログに含まれていませんでした。
• 厳格な順序では、Allow の drop のログは出ませんでした。代わりに、デフォルトアクション aws:alert_established のログが、遮断した接続に続くパケットまで記録されました（約 75 秒後に取得した時点で 34 件。アクション順序の 1 回目は 7 件）。

やってみた

次の順に進めました。

1. ルールグループ・ポリシー・ファイアウォールを作る
2. アクション順序のポリシーで curl する
3. 厳格な順序のポリシーに差し替えて curl する
4. アクション順序に戻して、もう 1 回 curl する

1. ルールグループ・ポリシー・ファイアウォールを作る

ルールグループは、次のような JSON を create-rule-group に渡して作りました（厳格な順序用の Reject のルールグループの例）。

{"RulesSource":{"RulesSourceList":{"Targets":[".example.net"],"TargetTypes":["TLS_SNI","HTTP_HOST"],"GeneratedRulesType":"REJECTLIST"}},"StatefulRuleOptions":{"RuleOrder":"STRICT_ORDER"}}

ルールグループとポリシーを作ってから、create-firewall でファイアウォールを作りました。describe-firewall の Status が READY、ConfigurationSyncStateSummary が IN_SYNC になるまで、約 6 分でした。

その後、SyncStates に出るエンドポイント ID を、2 つのルートテーブル（クライアントサブネットとインターネットゲートウェイ）のルートのターゲットに設定しました。最後に、update-logging-configuration でアラートログの出力先を設定しました。

2. アクション順序のポリシーで curl する

最初に関連付けたのは、アクション順序のポリシーです。

egress-client では、次のスクリプトで 8 つの URL に 1 回ずつアクセスし、HTTP のステータスコード、所要時間、curl の終了コードを記録しました。再試行はしません。

for u in https://example.com/ https://example.net/ https://example.org/ https://aws.amazon.com/ http://example.com/ http://example.net/ http://example.org/ http://aws.amazon.com/; do
  out=$(curl -s -o /dev/null --max-time 15 --retry 0 -w '%{http_code} %{time_total}s' "$u"); rc=$?
  printf '%s %-26s http_code/time=%s exit=%s\n' "$(date -u +%T)" "$u" "$out" "$rc"
done

curl の結果は、次のとおりでした（画像の A）。

example.net の即時の失敗が TCP リセットによるものであることは、同じ結果になった手順 4 の回に、curl -v のメッセージとログの verdict から確かめました。
アラートログは、最後の curl の約 75 秒後に filter-log-events で 1 回だけ取得しました。取得した時点で 7 件でした（画像の上半分）。

Reject の example.net には、次の 2 件が記録されています。

• Allow が追加した drop のログ（sid=3 の not matching any TLS allowlisted FQDNs）
• Reject のログ（sid=1 の matching TLS rejectlisted FQDNs）

2 件は flow_id が同じで、timestamp もマイクロ秒まで同じでした。Alert の example.org にも、Allow の drop のログと Alert のログ（action=allowed、matching TLS alertlisted FQDNs）の 2 件が、同じ形で出ました。リストに無い aws.amazon.com は、Allow の drop のログだけです。HTTP の example.net も、同じ組み合わせ（sid=6 と sid=2）でした。

HTTP の example.org と aws.amazon.com のログは、取得した中にありませんでした。同じ秒に始まった HTTP の example.net のログは、取得できています。ログ配信のタイミングのページの記述では、CloudWatch Logs への配信には平均 3〜6 分かかり、それより遅れることもあります。今回の取得は、その目安より前の約 75 秒後でした。

ルールのアクションのページの記述では、ドメインリストの Allow に一致しないパケットは、検査が打ち切られて遮断され、アラートログを設定していればログに記録されます。今回のログでは、この drop のログと同じ接続・同じ時刻に、Reject や Alert のルールのログも記録されていました。

ドメインリストルールグループのページの記述では、ドメインリストルールグループを保存すると、ドメインリストとターゲットの種類から Suricata 互換のルールが生成されます。Network Firewall の開発者ガイドは、2026 年 10 月時点で日本語の URL を開いても英語の内容が表示されるので、英語のページから引用します。

Suricata 互換のルールでは、drop や alert のルールに一致した後も、ほかのルールの評価が続きます。

https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-action.html

Matching a drop or alert rule for a packet doesn't necessarily mean the end of rule processing for that packet. The engine continues evaluating other rules for matches. For example, if there's a drop match that drops a packet, the packet can still go on to match an alert rule that generates alert logs.

3. 厳格な順序のポリシーに差し替えて curl する

describe-firewall で UpdateToken を取り、associate-firewall-policy で厳格な順序のポリシーに差し替えました。ConfigurationSyncStateSummary は PENDING を経て、約 2 分で IN_SYNC になりました。作業端末からの SSH は、ssh-admin-pass-strict の pass ルールで、そのまま使えました。

厳格な順序では、Allow のドメインリストによる拒否が効きません。

https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html

For Allow, the firewall denies traffic of the specified protocol type that does not match the domain specifications. This denial applies only when the firewall policy uses default action order. Under strict order, this denial does not apply.

そのため、厳格な順序のポリシーには、デフォルトアクションに aws:drop_established を設定しています。評価順序のページも、ドメインリストを厳格な順序で使うときは Drop established を選ぶよう勧めています。その理由として、ドメインリストで pass か drop かを判断するには、確立した接続が必要なことを挙げています。

curl の結果は、アクション順序のときと同じでした（画像の C）。example.net は HTTPS が 35、HTTP が 56 で即時に失敗しました（Reject のログの verdict は tcp-reset）。example.org と aws.amazon.com は、15 秒のタイムアウトです。

アラートログは、同じく約 75 秒後に取得した時点で 34 件でした（画像の下半分）。Allow の drop のログ（not matching any ... allowlisted FQDNs）はありませんでした。example.net の Reject のログと、example.org の Alert のログは、HTTPS と HTTP で 1 件ずつ出ました。
残りの 30 件は、デフォルトアクションの aws:alert_established action のログです。SNI や Host が付いたものが 11 件、付いていないものが 19 件でした。

SNI や Host が付いた 11 件の内訳は、次のとおりです。TCP リセットを返した example.net の接続でも、確立後のパケットが aws:alert_established で記録されていました。

• example.net：HTTPS 1 件、HTTP 1 件
• example.org：HTTPS 4 件、HTTP 1 件
• aws.amazon.com：HTTPS 4 件

付いていない 19 件は、flow_id が次の接続と同じで、遮断した接続に続くパケットのログです。

• example.org：HTTPS 9 件、HTTP 6 件
• aws.amazon.com：HTTPS 4 件

HTTP の aws.amazon.com のログは、厳格な順序でも、取得した中にありませんでした。

example.org と aws.amazon.com のログは、verdict がどれも drop でした。pass に当たるルールが無いので、aws:drop_established で確立後のパケットが落とされ、タイムアウトになったと考えています。

4. アクション順序に戻して、もう 1 回 curl する

アクション順序のポリシーに戻して、同じ curl を実行しました。curl の結果は 1 回目と同じでした（画像の E）。取得した時点のログは 5 件で、HTTPS のログの組み合わせは 1 回目と同じです。HTTP の 3 つのドメインのログは、どれも含まれていませんでした。
この回に、curl -v で終了コード 35 と 56 のメッセージを確かめました。HTTPS が OpenSSL SSL_connect: Connection reset by peer in connection to example.net:443、HTTP が Recv failure: Connection reset by peer です。アクション順序でも、TCP リセットが返っています。

次は、この回に取得した Reject のログから、alert・verdict・tls・aws_metadata の部分を抜き出したものです（アカウント ID は伏せています）。verdict には、クライアント側（to_client）に tcp-reset を送ったことが記録されています。

"alert": {"severity": 1, "signature_id": 1, "rev": 1, "signature": "matching TLS rejectlisted FQDNs", "action": "blocked", "category": ""},
"verdict": {"action": "drop", "reject-target": "to_client", "reject": ["tcp-reset"]},
"tls": {"sni": "example.net", "version": "TLS 1.3", ...},
"aws_metadata": {"resource_arn": "arn:aws:network-firewall:ap-northeast-1:<アカウント ID>:stateful-rulegroup/blocked-domains-reject-ao"}

同じ接続の Allow の drop のログ（sid=3）の verdict も、tcp-reset でした。Alert の example.org の 2 件の verdict は、どちらも drop でした。

確認してみた

注意書きとの関係

はじめにで触れた注意書きは、次のとおりです。

https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html

We recommend that you avoid combining Reject or Alert domain list rule groups with Allow domain list rule groups. When this combination of rule groups is defined in a firewall policy that uses default action ordering, the default drop rule added by the Allow rule group will take effect before the Reject and Alert rules.

今回の構成では、アクション順序でも Reject のドメインに TCP リセットが返り、HTTPS の Alert のドメインのログも出ました。Allow の drop のログと Reject のログは、同じ接続・同じ時刻で記録され、どちらの verdict も tcp-reset でした。curl から見える結果と、HTTPS の Reject と Alert のログは、順序の設定では変わりませんでした。
違いが出たのは、HTTP の example.org です。アクション順序の 2 回とも、Alert のログも Allow の drop のログ（sid=6）も、取得した中にありませんでした。厳格な順序では、同じ約 75 秒後の取得で Alert のログが出ています。どちらの順序でも、取得は約 75 秒後の 1 回だけで、ドキュメントの配信の目安（平均 3〜6 分）より前でした。

今回試したのは、ドメインリストルールグループ 3 つとクライアント 1 台の構成です。各 URL への curl は 1 回ずつ（アクション順序は 2 回）です。

2 つの順序でログの見え方が違う

アクション順序では、HTTPS の 3 ドメイン（example.net・example.org・aws.amazon.com）に、Allow の drop のログが 1 件ずつ出ました。どのドメインが許可リストに無くて落とされたかを、このログから読み取れました。
厳格な順序では、aws:drop_established で落とされた通信が、デフォルトアクションの aws:alert_established でログに出ました。遮断した接続に続くパケットまで記録されるので、件数は多くなりました。

評価順序のページの記述では、Alert established は、確立した接続のパケットにだけ ALERT のログを記録し、パケットは落としません。また、ロギングのページの記述では、アラートログに出るのは、アクションが DROP、ALERT、REJECT のステートフルルールに一致した通信です。

削除のとき

ロギング設定を空にしてから delete-firewall を実行すると、InvalidRequestException で「Unable to fulfill request because the following related VPC endpoint(s) still exist in route table(s)」が返りました。2 つのルートテーブルから、エンドポイントを指すルートを消してから実行すると DELETING になり、約 3 分で消えました。

ファイアウォールの削除のページは、削除の前提として、ファイアウォールを参照するルートテーブルから外すことと、ロギング設定を無効にすることを挙げています。

ファイアウォールポリシーを削除した直後にルールグループを削除すると、「Unable to delete the object because it is still in use」で失敗しました。ポリシーが一覧から消えてから実行し直すと、削除できました。

SSH を通すための設定

アクション順序では、pass ルールの無いポリシーのままでも SSH が通りました（手順 2 と 4 で、SSH で入って curl を実行できています）。ドメインリストルールグループのページの記述では、Allow のドメインリストが拒否するのは、指定したプロトコル（今回は HTTP と HTTPS）の通信です。

厳格な順序では、aws:drop_established で確立後のパケットが落とされるので、ssh-admin-pass-strict の pass ルールで SSH を通しました。

まとめ

はじめにで挙げた 3 点について、今回の構成では、curl から見える結果はアクション順序と厳格な順序で同じでした。アクション順序で Allow と組み合わせても、Reject のドメインには TCP リセットが返り、HTTPS の Alert のドメインのログも出ました。
一方で、アクション順序では、Reject と Alert のログに、Allow の drop のログが同じ接続で重なって記録されました。HTTP の Alert のドメインのログも、約 75 秒後の取得には 2 回とも含まれていませんでした。厳格な順序の回では、drop のログは重ならず、HTTP の Alert のログも取得できています。Alert のログを監視に使う場合は、ドキュメントの勧めどおり、アクション順序でこの組み合わせを使うのは避けるのがよいと判断しました。

厳格な順序で Drop established と Alert established を組み合わせると、遮断した接続 1 つにつき、続くパケットのログも残ります。今回は、アクション順序の 1 回目の 7 件に対して、34 件でした。ログの件数が増える前提で、保存先と監視の設定を考えておくのがよいと考えます。
本ブログが誰かの参考になれば幸いです。

参考資料

• Stateful domain list rule groups in AWS Network Firewall - AWS Network Firewall
• Defining rule actions in AWS Network Firewall - AWS Network Firewall
• Managing evaluation order for Suricata compatible rules in AWS Network Firewall - AWS Network Firewall
• Logging network traffic from AWS Network Firewall - AWS Network Firewall
• Timing of AWS Network Firewall log delivery - AWS Network Firewall
• Deleting a firewall in AWS Network Firewall - AWS Network Firewall

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました