2025/10/8 クラスメソッド株式会社 のんピ AWS Network Firewallの 設計/運⽤の勘所 

⾃⼰紹介 2 ● 2017年 前職(SIer)⼊社 インフラエンジニア ○ 仮想化基盤および⾃社DCの運⽤保守 ○ ⾦融機関のインターネット系システムの構築 ● 2019年 クラウドメインの部署へ異動 ○ 主に基幹システムの⼤規模AWS移⾏を担当 ● 2021年 クラスメソッド⼊社 SA ○ AWSコスト最適化⽀援 ○ 1,000万PV超のECサイトリプレース⽀援 ○ 300TBファイルサーバーの移⾏⽀援 ● 所属 ○ クラウド事業本部コンサルティング部 ● 名前（ニックネーム） ○ ⼭本涼太 (のんピ) ● 好きなAWSサービス ○ Amazon FSx for NetApp ONTAP ○ AWS Transit Gateway ○ AWS CDK ● 趣味 ○ コアラ鑑賞 ○ Gジェネレーションエターナル 

こんな気持ちになったのではないでしょうか? みなさん 3 

AWS Network Firewall導⼊したいな 4 

ということでAWS Network Firewallの話をします 5 

話すこと 6 ● AWS Network Firewallとは ● なぜAWS Network Firewallを導⼊するのか ● 何はともあれ対称ルーティング ● Allow List vs Deny List ● 最初の第⼀歩、マネージドルール (時間があれば) ● HOME_NET は適切なサイズで運⽤を (時間があれば) 

話さないこと 7 ● 料⾦について ● クォータの詳細について 

AWS Network Firewallとは 

AWS Network Firewallとは 9 AWSマネージドのファイアウォール‧ IPS/IDSサービス ● インフラ管理不要 ● 複数の通信制御⼿法 ○ 5 Tuple ○ ドメインリスト ○ Suricata互換のルール ● ディープパケットインスペクション対応 ● AWS提供のマネージドルール ○ AWSの脅威インテリジェンスフィードをベース とした ● イン/アウトバウンドのTLSインスペクション ● ログやダッシュボードを⽤いた分析 https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/arch-igw-ngw.html 

なぜAWS Network Firewallを導⼊するのか 

よくあるAWS Network Firewallを導⼊するケース 11 ● Good ○ Security Groupでは実施できない5 Tupleでの制御を⾏いたい ○ L7レベルなど、トラフィックのヘッダーやペイロードといったIPアドレスとポートの 組み合わせでブロックできない不審な通信を制御したい ○ 不審な通信を検出した場合に、効率良く横展開を防ぐために中央で管理をしたい ○ 最新の脅威情報をベースに不審な通信を制御したい ● Not Good ○ 要件としてIPS/IDSの導⼊が必要だから導⼊したい 

なぜAWS Network Firewallを導⼊するのかを考えよう 12 ● 「何を」、「何から」守りたいかをよく考える ○ 「IPS/IDSの導⼊が必要だから」の本質を考える ○ 短絡的な選択をすると、過剰コストになりかねない ○ 場合によっては既存の対応で⼗分かもしれない → 要件に応じた最適な選択を⾏う 

必要に応じて脅威モデリングを実施しよう 13 ● DFDを作成して、守りたい資産の処理を整理 ● STRIDEモデルやサイバーキルチェーンなどのフレームワークで評価 https://catalog.workshops.aws/threatmodel/en-US/what-are-we-working-on/debrief https://catalog.workshops.aws/threatmodel/ja-JP/what-can-go-wrong/stride-per-element 

よくあるIPS/IDS導⼊時の製品⽐較の評価軸 14 ● IPS/IDS導⼊の⽬的との合致度 ● 対応できる脅威 ● 検出の正確性 ● 検出のリアルタイム性 ● ダッシュボードの情報量、⾒やすさ ● 運⽤負荷 ● パフォーマンス ● ランニングコスト ● 導⼊コスト 

導⼊の期待値を調整する 15 ● 過剰な期待を持つことは何事も禁物 ● 以下を認識しておこう ○ 何ができないか ○ 何が向いていないか、⼿間がかかることは何か ○ 何とトレードオフか 

AWS Network Firewall導⼊時に注意すべき点の例 16 ● GUIでL7レベルの細かいルールの定義ができない ● 数時間レベルのアイドルタイムアウトの設定ができない ○ TCPの場合6,000秒、TLSインスペクションの場合120秒 ● 機械学習による振る舞い検知機能は提供されていない ● Active Directory等と連携するDLP機能は提供されていない ● カテゴリごとのドメインフィルタリング機能は提供されていない ● 検出したトラフィックのペイロードを書き換えるといった無害化機能は提供されていない ● 厳密なドメインフィルタリングを効率的に⾏うにはTLSインスペクションを有効化することになる ● UDPベースのトランスポートプロトコルの TLS インスペクションはサポートされていない ● TLSインスペクションのスコープの送信元/送信先のIPアドレスとポートで否定を使⽤することができない ○ ⼀部を除外をする場合は除外対象以外を列挙する必要がある ● マネージドルールグループ内のルール単位でアラートモードにすることはできない ● ログをベースにダッシュボードを表⽰しようとすると、都度 CloudWatch Logs Insights もしくは Athena のクエリ料⾦がかかる ● 若⼲のレイテンシー増加が発⽣する 

⼀つだけ紹介 17 ● GUIでL7レベルの細かいルールの定義ができない ● 数時間レベルのアイドルタイムアウトの設定ができない ○ TCPの場合6,000秒、TLSインスペクションの場合120秒 ● 機械学習による振る舞い検知機能は提供されていない ● Active Directory等と連携するDLP機能は提供されていない ● カテゴリごとのドメインフィルタリング機能は提供されていない ● 検出したトラフィックのペイロードを書き換えるといった無害化機能は提供されていない ● 厳密なドメインフィルタリングを効率的に⾏うにはTLSインスペクションを有効化することになる ● UDPベースのトランスポートプロトコルの TLS インスペクションはサポートされていない ● TLSインスペクションのスコープの送信元/送信先のIPアドレスとポートで否定を使⽤することができない ○ ⼀部を除外をする場合は除外対象以外を列挙する必要がある ● マネージドルールグループ内のルール単位でアラートモードにすることはできない ● ログをベースにダッシュボードを表⽰しようとすると、都度 CloudWatch Logs Insights もしくは Athena のクエリ料⾦がかかる ● 若⼲のレイテンシー増加が発⽣する 

AWS Network Firewallのドメインフィルタリングの動き 18 ● 以下の値を確認して判定 ○ HTTPSの場合 : SNIのServer Name ○ HTTPの場合 : Hostヘッダー ● AWS Network Firewall上でDNSによる名前解決は⾏わない → クライアントの名前解決結果を信じる → SNI またはHostヘッダーが操作されていても気付けない https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html 

何かしらのケアをしなければSNIスプーフィングが成⽴してしまう 19 実際のアクセス先には nfw-test.www.non-97.net を指定 SNIのServer Name として、dev.classmethod.jp を指定 dev.classmethod.jp にアクセスする際のIPアドレスが nfw-test.www.non-97.net のIPアドレスに nfw-test.www.non-97.net に dev.classmethod.jp としてHTTPSの 接続が成⽴ nfw-test.www.non-97.net とのTLSハンドシェイク 

何かしらのケアをしなければSNIスプーフィングが成⽴してしまう 20 dev.classmethod.jp として接続したことになっているが、 実際の接続先であるnfw-test.www.non-97.net にのコンテンツが返ってきている 

詳しい挙動はこちらの記事を 21 

何はともあれ対称ルーティング 

何を何から守りたいかが決まると配置が決まる 23 ● 主な配置の検討の軸 ○ 分散と集約 ■ 考慮ポイント : 管理コストと障害や設定ミス時の影響度合い ○ 検査対象のトラフィックの範囲 ■ ワークロードとIGW間 ■ ワークロードとパブリックサブネットリソース間 ■ 同⼀VPCのワークロードとワークロード間 ■ East-West (VPCとVPC間) ■ North-South (VPCとオンプレミス間) ■ North-South (VPCからインターネットへのアウトバウンド通信間) ■ North-South (インターネットからワークロードへのインバウンド通信間) 

分散 × ワークロードとIGW間 24 ● 個々のVPC単位で全インターネット間の通信を検査 ● 注意点 ○ NAT Gatewayを経由する検査対象のパケットは常に送信元IPアドレスがNAT Gatewayとなってしまう ○ 対象のトラフィックがHTTPSの場合、インバウンドのTLSインスペクションを有効にしなければディープパケットインスペクションによる検査ができない 

分散 × ワークロードとパブリックサブネットリソース間 25 ● NAT GatewayやALBなどパブリックサブネットリソースとの間で検査 

分散 × 同⼀VPCのワークロードとワークロード間 26 ● VPC 内のサブネット間のトラフィックの検査 

集約 × East-West (VPCとVPC間) 27 ● VPC間で検査 

集約 × North-South (VPCとオンプレミス間) 28 ● VPCとオンプレミス間で検査 

集約 × North-South (VPCからインターネットへのアウトバウンド通信間) 29 ● VPCからインターネットへのアウトバウンド通信間で検査 

集約 × North-South (インターネットからワークロードへのインバウンド通信間) 30 ● インターネットからワークロードへのインバウンド通信を検査 ● 注意点 ○ 現状、ターゲットグループでALBやNLBと別VPCのインスタンスIDやAuto Scaling Groupの指定および、ALBやNLBでクロスアカウントのターゲットグループを指定 できないため、ターゲットをAuto Scalingさせたり、ECS Fargateを使⽤したりと動的にリソースが変化する仕組みを取ることができない ○ 個⼈的には各VPCにNetwork Firewallエンドポイントを追加配置する形が良いと考える (その分のコストはかかる) 

いずれも対称ルーティングとなっていることが重要 31 戻りのトラフィックのみNetwork Firewallを通る⾮対称ルーティングでは パケットがドロップする https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/asymmetric-routing.html 

⾮対称ルーティングとなっている例 32 

Transit Gatewayのアプライアンスモードを有効に 33 リクエストとレスポンスで同じAZのFirewall Endpointにルーティング https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/how-transit-gateways-work.html#TGW_Scenarios アプライアンスモード有効前 アプライアンスモード有効後 

Transit Gatewayとの統合も使おう 34 Inspection VPCを⾃作しなくとも検査が可能に ※ 元々Inspection VPCにインターネットのアウトバウンド通信集約⽤にNAT Gatewayを⽤意されている場合は、NAT Gateway⽤のEgress VPCが必要 

Allow List vs Deny List 

ファイアウォールサービスを導⼊する時の考慮点 36 ● Allow List で制御するか ● Deny Listで制御するか 

Allow List と Deny Listの⽐較 37 項目 Allow List Deny List 説明 明示的な許可がない限り通信を許可しない 明示的な拒否定義がある通信を拒否する 定義に当てはまらない通信は許可 初期導入コスト 高い 比較的低い 運用負荷 高い 比較的低い 特にマネージドルールグループ利用する場合 保護対象ネットワーク 追加のスケーラビリティ 低い 正常なアクセスパターンを網羅的に把握している必 要がある 比較的高い セキュリティレベル (過剰な許可をしていない場合 ) 比較的高い ー ゼロデイ対策 / 未知の脅威への対応 (過剰な許可をしていない場合 ) 比較的高い 比較的低い キャパシティーユニット消費 量 比較的少ない 比較的多い マネージドルールグループを使用する場合は消費 量が多くなりがち 

結局どちらで考えれば良いんだ...?? 38 

両⽅という選択肢もある 39 

AWS Network Firewallの通信の評価フロー 40 ステートレスルールで評価されてから ステートフルルールで評価 https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/firewal l-rules-engines.html 

ステートフルルールの評価フロー 41 Action Order と Strict Order とで評価の優先度が異なる 項目 Action Order Strict Order ルールグループ内のルール間の 優先度 1. pass 2. drop 3. reject 4. alert の順で評価 priority キーワードを用いることで同一アクション内 の優先度を指定可能 (Suricata互換ルール限定) 定義された順で評価 ルールグループ間の優先度 個別の設定はなく、全ルールグループ内のルール で同上の優先度に基づいて評価 ルールグループ単位で設定した優先度に基づい て評価 

Strict Order時のデフォルトアクションは変更が可能 42 ※ Action Orderの場合はデフォルトアクションはPassで固定 項目 説明 なし (None) 許可 すべてをドロップ (Drop all) すべてのパケットをドロップ [利用ケース] SYNなどハンドシェイク時のパケットの到達ですらも暗黙的に拒否したい場合 [注意点] SYNやSYN-ACKもドロップするため、HTTPなどのTCPレイヤーの上位層以上のプロトコルに対するルールを記 載しても評価前にドロップされてしまう 確立された接続のパケットをドロップ (Drop established) HTTPなどの上位レイヤーの接続の確立に必要な L3やL4パケットは許可され、確立済みの接続のパケットはド ロップ [利用ケース] ● TCPのハンドシェイク部分を許可するための追加ルールを記述する手間を減らしたい場合 ● ドメインリストのルールグループを使用したい場合 アプリケーションドロップが確立されました (Application Layer drop established) サーバーが開始したバナーパケットと確立された接続のパケットをドロップ セグメンテーションされたL7のトラフィックについては以下のような挙動を行う ● tls.sni フィールドが検出されるまで、セグメンテーションされた TLS Client Helloパケットを許可し、その後 SNIに基づいてルールを適用する ● http.host フィールドが検出されるまで、セグメンテーションされた HTTPSリクエストパケットを許可し、その 後ホストに基づいてルールを適用する 

推奨はStrict Order 43 https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-evaluation-order.html ● 直感的な分かりやすさ ● 暗黙的な拒否の実装 を重視するのであればStrict Orderがオススメ 

Allow ListとDeny Listの良いところを組み合わせる 44 例 ● 過検知してしまった通信 例 ● マネージドルールグループで定義されている通信 ● 明らかに通信しないであろう国のIPアドレスとの通信 ● 既知の不審な通信 ● 通常利⽤しないプロトコルの通信 例 ● ap-northeast*.amazonaws.com との通信 ● ⽇本国内のIPアドレスとの通信 ● 社内ネットワーク内の通信 

False Negative / False Positiveの検出にはダッシュボードを活⽤ 45 Alert Log/Flow Logに対してCloudWatch Logs Insights もしくは、Athenaで ダッシュボードの値を⽣成 

イメージはAWS WAFのTop Insightsセクション 46 

宛先ドメインを絞りたい場合もダッシュボードを活⽤ 47 トラフィック分析モードが有効になった時点から最⼤30⽇間のHTTP or HTTPSでアクセスしたドメインリストを⽣成 

ルール追加のプロセス 48 Denyルールを追加する場合 1. 不審な通信の特徴を把握する ○ ダッシュボードの結果から推察 ○ JPCERT/CC など信頼できるソースから提供されている 脆弱性情報の⼊⼿ 2. 不審な通信に対するルールを作成し、Alert モードで様⼦を⾒る ○ 過剰な検出がされていないかを確認する 3. 問題ないことを確認後、Drop/Rejectに変更 Allowルールを追加する場合 1. Alert LogからDrop/Rejectされている通信 を把握する 2. 許可したい通信の特徴を整理する 3. AlertルールとPassルールを追加し、様⼦を ⾒る ○ 過剰な許可がされていないかを確認する 4. 問題ないことを確認後、Alertルールを削除 

最初の第⼀歩、マネージドルール (時間があれば) 

AWS Network Firewallのルールグループの種類 50 ● アンマネージドルールグループ ○ ⾃⾝が定義する ○ ルールグループの形式は3種類 1. 標準ステートフルルール (5 Tuple) 2. ドメインリスト 3. Suricata互換ルール⽂字列 ● AWSマネージドルールグループ ○ AWSが定義する ○ Active threat defense を除いて追加料⾦なしで使⽤可能 ○ 新しい脆弱性や脅威に基づいて、⾃動的に更新 ■ 更新時には指定したSNSトピックへ通知 

⾃分で0から定義できますか? Deny Listでは脅威となる通信を定義する必要がある 51 

Suricata互換ルールは真っ⽩なキャンバスに書いていくことに 52 

まずはマネージドルールグループを採⽤しよう 53 Domain and IP ルールグループ名 説明 AbusedLegitMalwareDomains 通常は正当なドメインだが、侵害を受けておりマルウェアをホストして いる可能性のあるドメイン MalwareDomains マルウェアをホストしていることが知られているドメイン AbusedLegitBotNetCommandAndControlDomains 通常は正当なドメインだが、侵害を受けておりボットネットを ホストしている可能性のあるドメイン BotNetCommandAndControlDomains ボットネットをホストしていることが知られているドメイン Threat signature ルールグループ名 説明 ThreatSignaturesBotnet 複数ソースから自動生成される署名 ThreatSignaturesBotnetWeb HTTP ボットネット ThreatSignaturesBotnetWindows Windows ボットネット ThreatSignaturesIOC 侵入を示唆するレスポンスやエクスプロイトキット ThreatSignaturesDoS DoS ThreatSignaturesEmergingEvents 一時的なものと予想される注目度の高いイベント ThreatSignaturesExploits 直接的なエクスプロイト ThreatSignaturesFUP ゲーム トラフィック、潜在的に不適切な Web サイト、P2P トラフィッ ク、および組織のポリシー違反 ThreatSignaturesMalware マルウェア および WORM ThreatSignaturesMalwareCoinmining コインマイニングを実行するマルウェア ThreatSignaturesMalwareMobile モバイルおよびタブレット OSに関連するマルウェア ThreatSignaturesMalwareWeb HTTP および TLS プロトコル内の悪意のあるコード ThreatSignaturesPhishing 認証情報フィッシング活動 ThreatSignaturesScanners ポートスキャンツールなどのツールによる偵察やプロービング ThreatSignaturesSuspect 不審と疑わしい通信 ThreatSignaturesWebAttacks Webのクライアント /サーバー/アプリの攻撃と脆弱性 Active threat defense ルールグループ名 説明 AttackInfrastructure AWS内部の脅威インテリジェンスおよび妨害サービスである MadPot のAmazon脅威インテリジェンスをベースとしたルール 処理したデータ量に応じて 0.005/GB の追加課金が発生 ● https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/aws-managed-rule-groups- atd.html ● https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/aws-managed-rule-groups- domain-list.html ● https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/aws-managed-rule-groups- threat-signature.html 

● ファイアウォールポリシーごとにステートフルルールグループは20個まで ○ マネージドルールグループの数は21個 ● キャパシティユニットは30,000まで ○ 全てのマネージドルールグループの合計は46,400 全てのマネージドルールグループを使⽤することは現実的ではない 54 

想定している脅威からルールグループを 厳選する必要がある そのため 55 

アンマネージドルールグループを使⽤するシチュエーション 56 ● 明⽰的なAllow/Alert/Drop/Rejectを⾏いたい場合 ● マネージドルールグループに⼀部許可したい通信が含まれている場合 ○ マネージドルールグループのルールは公開されているため、⼀部抜粋する形で適⽤ ○ もちろん、元のマネージドルールグループでルールが更新されても⾃動更新されないので要注意 

HOME_NET は適切なサイズで運⽤を (時間があれば) 

HOME_NETとは 58 ● 保護対象となる⾃⾝のネットワーク ● ⼀般的に送信元として使⽤される ● HOME_NET以外の変数はアンマネージドルールグループの”標準ステートフ ルルール”と”Suricata互換ルール”で定義する ● デフォルトのHOME_NETはAWS Network FirewallのFirewall Endpointが 存在しているVPC CIDR ○ Transit Gatewayとの統合機能を使⽤している場合は明⽰的なHOME_NETの指定が必要 

広すぎるHOME_NETを使ってはいけない 59 ● 送信元と送信先の両⽅がHOME_NETに含まれている場合は検出されないルールが 多い → 広すぎる HOME_NET を指定すると、内部のネットワーク内の通信が検査対象とならない → 特に⾮透過型プロキシを使⽤している場合、外部ネットワークとの通信であっても検査対象外と なる → では、HOME_NET ではないIPセット変数を使えば良いか? 

HOME_NET を使わないという選択肢はない 60 ● マネージドルールグループ内のルールではほぼHOME_NETを使⽤している → HOME_NET を定義しなければマネージドルールグループを有効活⽤できない → HOME_NET の定義は必要 → HOME_NET をルールグループごとに使い分ければ良いか? 

マネージドルールグループでは HOME_NET の使い分けは不可 61 ● マネージドルールグループで使⽤する“HOME_NETの定義はファイアウォールポ リシー単位” かつ “ファイアウォールポリシーはAWS Network Firewallに⼀つ” → 単⼀のAWS Network Firewall内のマネージドルールグループではHOME_NET を⽤途ごとに使い分 けることはできない ■ アンマネージドルールグループについては使い分けが可能 → 場合によっては AWS Network Firewall を分割することも考えよう 

まとめ 

まとめ 63 ● 真の⽬的や要件とマッチしているかを整理して導⼊の判断をしよう ● 対称ルーティングであることを必ず意識しよう ● Allow ListとDeny Listは組み合わせて使おう ● 運⽤負荷軽減のためにマネージドルールグループを使ってみよう ● ルールに保護対象のネットワークが含まれているか改めて確認しよう 

No content