Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWS Network Firewallの設計/運用の勘所 #NW_JAWS

Avatar for のんピ のんピ
October 09, 2025
400

AWS Network Firewallの設計/運用の勘所 #NW_JAWS

NW-JAWS #18 ~秋の夜長のスペシャル回(LV300以上)~ の登壇資料です。

Avatar for のんピ

のんピ

October 09, 2025
Tweet

More Decks by のんピ

Transcript

  1. ⾃⼰紹介 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ジェネレーションエターナル
  2. 話すこと 6 • AWS Network Firewallとは • なぜAWS Network Firewallを導⼊するのか

    • 何はともあれ対称ルーティング • Allow List vs Deny List • 最初の第⼀歩、マネージドルール (時間があれば) • HOME_NET は適切なサイズで運⽤を (時間があれば)
  3. 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
  4. よくあるAWS Network Firewallを導⼊するケース 11 • Good ◦ Security Groupでは実施できない5 Tupleでの制御を⾏いたい

    ◦ L7レベルなど、トラフィックのヘッダーやペイロードといったIPアドレスとポートの 組み合わせでブロックできない不審な通信を制御したい ◦ 不審な通信を検出した場合に、効率良く横展開を防ぐために中央で管理をしたい ◦ 最新の脅威情報をベースに不審な通信を制御したい • Not Good ◦ 要件としてIPS/IDSの導⼊が必要だから導⼊したい
  5. よくあるIPS/IDS導⼊時の製品⽐較の評価軸 14 • IPS/IDS導⼊の⽬的との合致度 • 対応できる脅威 • 検出の正確性 • 検出のリアルタイム性

    • ダッシュボードの情報量、⾒やすさ • 運⽤負荷 • パフォーマンス • ランニングコスト • 導⼊コスト
  6. AWS Network Firewall導⼊時に注意すべき点の例 16 • GUIでL7レベルの細かいルールの定義ができない • 数時間レベルのアイドルタイムアウトの設定ができない ◦ TCPの場合6,000秒、TLSインスペクションの場合120秒

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

    • Active Directory等と連携するDLP機能は提供されていない • カテゴリごとのドメインフィルタリング機能は提供されていない • 検出したトラフィックのペイロードを書き換えるといった無害化機能は提供されていない • 厳密なドメインフィルタリングを効率的に⾏うにはTLSインスペクションを有効化することになる • UDPベースのトランスポートプロトコルの TLS インスペクションはサポートされていない • TLSインスペクションのスコープの送信元/送信先のIPアドレスとポートで否定を使⽤することができない ◦ ⼀部を除外をする場合は除外対象以外を列挙する必要がある • マネージドルールグループ内のルール単位でアラートモードにすることはできない • ログをベースにダッシュボードを表⽰しようとすると、都度 CloudWatch Logs Insights もしくは Athena のクエリ料⾦がかかる • 若⼲のレイテンシー増加が発⽣する
  8. 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
  9. 何かしらのケアをしなければ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ハンドシェイク
  10. 何を何から守りたいかが決まると配置が決まる 23 • 主な配置の検討の軸 ◦ 分散と集約 ▪ 考慮ポイント : 管理コストと障害や設定ミス時の影響度合い

    ◦ 検査対象のトラフィックの範囲 ▪ ワークロードとIGW間 ▪ ワークロードとパブリックサブネットリソース間 ▪ 同⼀VPCのワークロードとワークロード間 ▪ East-West (VPCとVPC間) ▪ North-South (VPCとオンプレミス間) ▪ North-South (VPCからインターネットへのアウトバウンド通信間) ▪ North-South (インターネットからワークロードへのインバウンド通信間)
  11. 分散 × ワークロードとIGW間 24 • 個々のVPC単位で全インターネット間の通信を検査 • 注意点 ◦ NAT

    Gatewayを経由する検査対象のパケットは常に送信元IPアドレスがNAT Gatewayとなってしまう ◦ 対象のトラフィックがHTTPSの場合、インバウンドのTLSインスペクションを有効にしなければディープパケットインスペクションによる検査ができない
  12. 集約 × North-South (インターネットからワークロードへのインバウンド通信間) 30 • インターネットからワークロードへのインバウンド通信を検査 • 注意点 ◦

    現状、ターゲットグループでALBやNLBと別VPCのインスタンスIDやAuto Scaling Groupの指定および、ALBやNLBでクロスアカウントのターゲットグループを指定 できないため、ターゲットをAuto Scalingさせたり、ECS Fargateを使⽤したりと動的にリソースが変化する仕組みを取ることができない ◦ 個⼈的には各VPCにNetwork Firewallエンドポイントを追加配置する形が良いと考える (その分のコストはかかる)
  13. Allow List と Deny Listの⽐較 37 項目 Allow List Deny

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

    Order Strict Order ルールグループ内のルール間の 優先度 1. pass 2. drop 3. reject 4. alert の順で評価 priority キーワードを用いることで同一アクション内 の優先度を指定可能 (Suricata互換ルール限定) 定義された順で評価 ルールグループ間の優先度 個別の設定はなく、全ルールグループ内のルール で同上の優先度に基づいて評価 ルールグループ単位で設定した優先度に基づい て評価
  15. 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リクエストパケットを許可し、その 後ホストに基づいてルールを適用する
  16. Allow ListとDeny Listの良いところを組み合わせる 44 例 • 過検知してしまった通信 例 • マネージドルールグループで定義されている通信

    • 明らかに通信しないであろう国のIPアドレスとの通信 • 既知の不審な通信 • 通常利⽤しないプロトコルの通信 例 • ap-northeast*.amazonaws.com との通信 • ⽇本国内のIPアドレスとの通信 • 社内ネットワーク内の通信
  17. ルール追加のプロセス 48 Denyルールを追加する場合 1. 不審な通信の特徴を把握する ◦ ダッシュボードの結果から推察 ◦ JPCERT/CC など信頼できるソースから提供されている

    脆弱性情報の⼊⼿ 2. 不審な通信に対するルールを作成し、Alert モードで様⼦を⾒る ◦ 過剰な検出がされていないかを確認する 3. 問題ないことを確認後、Drop/Rejectに変更 Allowルールを追加する場合 1. Alert LogからDrop/Rejectされている通信 を把握する 2. 許可したい通信の特徴を整理する 3. AlertルールとPassルールを追加し、様⼦を ⾒る ◦ 過剰な許可がされていないかを確認する 4. 問題ないことを確認後、Alertルールを削除
  18. AWS Network Firewallのルールグループの種類 50 • アンマネージドルールグループ ◦ ⾃⾝が定義する ◦ ルールグループの形式は3種類

    1. 標準ステートフルルール (5 Tuple) 2. ドメインリスト 3. Suricata互換ルール⽂字列 • AWSマネージドルールグループ ◦ AWSが定義する ◦ Active threat defense を除いて追加料⾦なしで使⽤可能 ◦ 新しい脆弱性や脅威に基づいて、⾃動的に更新 ▪ 更新時には指定したSNSトピックへ通知
  19. まずはマネージドルールグループを採⽤しよう 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. HOME_NETとは 58 • 保護対象となる⾃⾝のネットワーク • ⼀般的に送信元として使⽤される • HOME_NET以外の変数はアンマネージドルールグループの”標準ステートフ ルルール”と”Suricata互換ルール”で定義する •

    デフォルトのHOME_NETはAWS Network FirewallのFirewall Endpointが 存在しているVPC CIDR ◦ Transit Gatewayとの統合機能を使⽤している場合は明⽰的なHOME_NETの指定が必要
  21. 広すぎるHOME_NETを使ってはいけない 59 • 送信元と送信先の両⽅がHOME_NETに含まれている場合は検出されないルールが 多い → 広すぎる HOME_NET を指定すると、内部のネットワーク内の通信が検査対象とならない →

    特に⾮透過型プロキシを使⽤している場合、外部ネットワークとの通信であっても検査対象外と なる → では、HOME_NET ではないIPセット変数を使えば良いか?
  22. マネージドルールグループでは HOME_NET の使い分けは不可 61 • マネージドルールグループで使⽤する“HOME_NETの定義はファイアウォールポ リシー単位” かつ “ファイアウォールポリシーはAWS Network

    Firewallに⼀つ” → 単⼀のAWS Network Firewall内のマネージドルールグループではHOME_NET を⽤途ごとに使い分 けることはできない ▪ アンマネージドルールグループについては使い分けが可能 → 場合によっては AWS Network Firewall を分割することも考えよう
  23. まとめ 63 • 真の⽬的や要件とマッチしているかを整理して導⼊の判断をしよう • 対称ルーティングであることを必ず意識しよう • Allow ListとDeny Listは組み合わせて使おう

    • 運⽤負荷軽減のためにマネージドルールグループを使ってみよう • ルールに保護対象のネットワークが含まれているか改めて確認しよう