AWS Network Firewall デフォルトdrop action変更

AWS Network Firewallの デフォルトdrop actionの変更 「server-directed only」で何が改善されたのか 2026/8/28 品川会#8 ムカイヤマ ※本スライドの内容は個人の見解であり、所属組織とは無関係です。

自己紹介 ムカイヤマ ・所属：SIer(AWSの設計構築) - オンプレからAWSの移行 - 脆弱性対応 ・好きなAWSサービス： System Manager、AWSサポート ・2026 Japan AWS Jr. Champions 登壇資料を上記に アップロードしています。 最後のスライドでもQR提示します。 ※本スライドの内容は個人の見解 であり、所属組織とは無関係です。

アジェンダ 01 AWS Network Firewallの基本 02 Stateful デフォルトアクションの変更 03 TCPセグメンテーションの仕組み 04 2026年6月のアップデート内容 05 影響範囲と対応が必要なケース 06 まとめ

本日お話すること・お話ししないこと お話しすること お話ししないこと ・drop actionの 変更内容とその背景 ・TCPセグメンテーション との関係 ・既存環境で確認すべき ポイント ・Network Firewallの 詳細な構築手順 ・他社／他FWサービスとの比較

AWS Network Firewallとは VPC向けのマネージドファイアウォール ドメイン名（HTTP Host / TLS SNI）によるアウトバウンド通信の制御が可能 要素 役割 Firewall（本体） VPCのサブネットに配置するファイアウォールエンドポイント Firewallポリシー ステートレス／ステートフルルールグループをまとめる単位 ポリシールール （ルールグループ） 実際の許可・拒否条件（IP、ポート、ドメイン等）

Stateful デフォルトアクションの変更 ステートフルルールに合致しなかった通信に適用するデフォルトアクション bidirectional server-directed only 旧デフォルト 新デフォルト（2026年6月22日〜） ・クライアント→サーバー ・サーバー起点 ・サーバー→クライアント （サーバー→クライアント） 両方向のTCPパケットが対象 のトラフィックのみが対象

TLS ClientHelloとPQCによる肥大化 ClientHello = TLSハンドシェイクの最初のメッセージ 従来の鍵交換 PQCハイブリッド鍵交換 X25519 X25519Kyber768 / X25519MLKEM768 鍵交換データが小さく 鍵交換データが大きく ClientHelloは1500バイト以内に ClientHelloが1500バイトを 収まることが多い 超えやすい （OpenSSL 3.5+、Go 1.23+等）

TCPセグメンテーションが起きるとどうなるか ClientHello（MSS:1460バイト超） セグメント1 セグメント2 SNIを含まない SNIを含む 1つのメッセージが複数のTCPセグメントに分割されて送信される MSS(1460バイト) = MTU(1500バイト) – IPヘッダ(20バイト) – TCPヘッダ(20バイト) =実際にTCPが運べるデータの最大量(TCPセグメンテーションの閾値)

SNIとは何か SNI = Server Name Indication TLS ClientHello の拡張フィールドに含まれる、接続先ドメイン名の情報 一つのIPアドレスで複数のドメイン名のサーバー証明書を運用できる Network Firewallはこのフィールドを読み取り、ドメインベースのルールと照 合して通信を許可・拒否する

Network Firewallの分割パケット処理フロー OSI参照モデル: 第4層（接続確立・再構築）→ 第7層（SNI評価） 1 TCP 3-way Handshake（接続の確立） クライアントと宛先間でL4のTCP接続が確立。 ステートフルルールの判定基準となるセッションが作成される 2 分割されたTLS ClientHelloの受信 PQC対応等でMSS（1460バイト）を超えたClientHelloが、 複数のTCPセグメントに分割されて到着する 3 TCP Stream Reassembly（再構築） Network Firewall（Suricataエンジン）が受信したTCPセグメントを ストリームとしてバッファし、元の完全なClientHelloを復元する 4 SNI抽出とステートフルルール評価 復元されたClientHelloからSNI（ドメイン名）を読み取り、 ドメインリストやTLSルールに基づき許可／拒否を判定する

パケット分割時の影響 項目 通常時 分割時 セグメント数 1つ 2つ以上 SNIの位置 セグメント内に含まれる 2つ目以降のセグメントに出現 1つ目のセグメントの中身 TCPヘッダ + ClientHello全体 （SNI含む） TCPヘッダ + ClientHello前半 （SNIなし） ファイアウォールの判定 SNIを検知しドメインルールと照合可能 1つ目だけを見ると SNIを検知できない Network Firewallが正当なパケットを意図せずドロップしてしまうことがある

2026年6月22日のアップデート内容 新規作成されるすべてのファイアウォールポリシーにおいて、デフォルト のステートフルアクションが「server-directed only」に変更 背景 旧デフォルトのbidirectionalは、 正当なサーバー→クライアントのパケットを意図せずドロップし、 原因特定が難しい断続的な接続障害を引き起こしていた

変更前後の比較 変更前（bidirectional） 変更後（server-directed only） ・正当なパケットを誤ドロップ ・サーバー起点のみ対象 ・断続的な接続障害が発生 ・断続的な接続障害を回避 ・TLS時に正規通信もブロック ・再構成中の誤ドロップも軽減

影響範囲と対応が必要なケース ケース 対応 新規作成するポリシー 自動的にserver-directed onlyが適用される 特別な対応は不要 既存のポリシー 自動的には変更されない 挙動は変わらないため切替を検討 bidirectionalの維持が 必要なケース（PQC対応等） TCPドロップルールに to_server フラグを追加、または Suricataルールに ssl_state:client_hello を追加

まとめ 1 デフォルトのdrop actionが変更された 2 新規ポリシーは server-directed only が自動適用される 3 既存ポリシーは自動変更されないため、必要に応じて見直しを

参考リンク AWS Network Firewall updates default drop action for improved connection reliability https://aws.amazon.com/about-aws/whats-new/2026/06/aws-network-firewallupdates-default-drop-action/ AWS What's New（2026年6月22日） Managing evaluation order for Suricata compatible rules https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricatarule-evaluation-order.html AWS Network Firewall Developer Guide Enhance TLS inspection with SNI session holding in AWS Network Firewall https://aws.amazon.com/blogs/security/enhance-tls-inspection-with-sni-sessionholding-in-aws-network-firewall/

• https://aws.amazon.com/about-aws/whats-new/2026/06/aws-network-firewall-
• https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-
• https://aws.amazon.com/blogs/security/enhance-tls-inspection-with-sni-session-

Thank You! ご清聴ありがとうございました。 資料は下記に公開しています。 https://www.docswell.com/user/mkymdk ※本スライドの内容は個人の見解であり、 所属組織とは無関係です。

• https://www.docswell.com/user/mkymdk