AWS Network Firewallの深層：ステートレスとステートフルが交差するパケット検査の真実
クラウドネイティブなインフラを設計する際、VPCの境界線で「何を信じ、何を遮断するか」という問いは、SREにとって永遠の命題です。特にAWS Network Firewall（ANFW）を導入する場合、Suricataベースのエンジンがパケットをどう解釈し、どの順序でルールを適用しているのかを正確に把握していないと、パフォーマンスのボトルネックや、予期せぬ通信遮断という「悪夢」に直面することになります。
今回は、パケットレベルの挙動からパフォーマンス最適化まで、ANFWの核心を掘り下げます。
1. パケットの行軍：ステートレスからステートフルへの旅路
ANFWにおけるパケット検査は、二段階の防壁で構成されています。まず最初に叩かれるのが「ステートレスルール」、その後に待ち受けるのが「ステートフルルール」です。
ステートレスの役割：高速なフィルタリングの門番
ステートレスルールは、IPヘッダーやトランスポート層（TCP/UDP）の情報を参照し、単純な一致条件でパケットを即座に破棄または通過させます。ここで重要なのは、「ステートフルに渡すべきか否か」を判断する選別機であるという点です。
- 評価順序: ルールグループに設定した優先度順に適用されます。
- 挙動: 一致しなかったパケットは「デフォルトアクション」に従います。ここで全てを暗黙的に拒否する設定にしていると、ステートフル側にパケットが届く前に通信が死滅します。
ステートフルルール：Suricataエンジンの本領
ステートフルルールは、パケットのコンテキストを保持します。TCPストリームの再構築を行い、ペイロードの内容まで深層検査（DPI）が可能です。ここで注意すべきは、ステートフルルールには「優先順位（Priority）」と「アクション順序（Action Order）」の2つの評価モードがあることです。
- Strict Order: 優先度順に厳格に評価。
- Alert/Pass/Drop Order: Suricataのデフォルトに従い、Alert > Pass > Dropの順に優先。
実務上、複雑なセキュリティポリシーを運用する場合は、意図しない挙動を避けるために Strict Order を強く推奨します。
2. パフォーマンスの限界を突破するチューニング
ネットワークの遅延（RTT）は、パケット検査のたびに蓄積されます。特にTLSハンドシェイクが頻発する環境では、ANFWの介在がミリ秒単位のロスを生みます。これを回避するための技術的アプローチを共有します。
TCPウィンドウとバッファの最適化
ANFWを通過する通信は、仮想的な中間ノードを通過することと同義です。高スループットを維持するためには、インスタンス側のTCPウィンドウサイズを適切に調整する必要があります。
# カーネルパラメータの調整: 高速なネットワークI/Oのためにウィンドウサイズを拡大
# 128MBのバッファを確保（環境に合わせて調整が必要）
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"TLSハンドシェイクとRTTの削減
ANFWの検査負荷を軽減し、かつ通信を高速化するには、TLS False Start や TLS 1.3 の0-RTT活用が鍵となります。また、ANFWのルール定義において、頻繁にアクセスする信頼済みエンドポイントを「ステートレス」側で PASS させてしまい、ステートフル検査のオーバーヘッドをスキップさせる「ホワイトリスト・ファストパス」の設計が、スケーラビリティを左右します。
3. 実践：Suricataルールによる高度なプロトコル検査
単なるIPフィルタリングではなく、アプリケーション層の脆弱性防御を目指すなら、以下のようなシグネチャが現場の戦力となります。
# HTTPヘッダーの不正な埋め込み（HTTP Response Splitting攻撃）を検知
drop http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT Possible HTTP Response Splitting"; content:"|0d 0a|"; http_header; pcre:"/^(Content-Length|Location):/mi"; sid:1000001; rev:1;)
# 特定のドメインへの通信を許可しつつ、TLS SNI情報を検査
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:"api.trusted-service.com"; nocase; sid:1000002; rev:1;)*ポイント*: tls.sni を用いることで、暗号化された通信であっても、接続先のホスト名を正確に識別可能です。これはプロキシサーバを立てずにSNIフィルタリングを行うための、極めてモダンな手法です。
4. 最後に：インフラエンジニアの矜持
ANFWは強力な武器ですが、闇雲にルールを詰め込めば、それはただの「遅延装置」に成り下がります。
1. ステートレスルールで不要なトラフィックを徹底的に間引く。
2. ステートフルルールは「Strict Order」で整合性を担保する。
3. カーネルパラメータまで踏み込み、TCPセッションの生存率を高める。
ネットワークは「魔法」ではなく、物理層からアプリケーション層に至るまでの「積み重ね」です。パケットの旅路を可視化し、VPC内を流れるビットの奔流を制御する楽しさを、ぜひ日々の運用で追求してください。設計の美しさは、必ずやシステムの堅牢性という結果で応えてくれるはずです。
コメント