[レポート]Outbound security implementation with AWS Network Firewall & Route 53 #NIS305 #AWSreInforce

こんにちは！クラスメソッドの ソ ウヌ です。

アナハイムで開催されている AWS re:Inforce 2023 のセッション動画が Youtubeに公開されました。

本記事は Youtubeに公開されている AWS re:Inforce 2023 のセッション「Outbound security implementation with AWS Network Firewall & Route 53」のセッションレポートです。

本セッションについて

セッション概要

In this session, explore proven methods for increasing workload security by implementing outbound security controls using AWS Network Firewall and Amazon Route 53 DNS Firewall. Learn how to start your outbound security journey and the specific steps you can take to protect VPC workloads by blocking threats and detecting network anomalies on workloads.

アジェンダ

• Egress セキュリティとは
• AWS Network Firewall と Route 53 Resolverの概要
• DNS Firewall
• AWSお客が Egressセキュリティのため多くの時間を費やす理由
• エクスプロイトの解剖学（Anatomy of an exploit）
• Robinhoodの Egressセキュリティジャーニー、学んだこと、ベストプラクティス

セッション内容

Egress セキュリティとは

• Ingress トラフィックの場合、前段にAWS WAFを配置して悪いリクエストをフィルタリングでき、アプリケーションを保護可能

• Egress Connectionは、VPC ワークロードによって開始され、インターネット宛てのネットワークリクエストのこと
• Egress トラフィックの場合、２つの経路がある
  • NAT Gateway を通じてインターネットと通信
  • Route 53 Resover を利用してDNSリクエストを処理
• しかし、これらは攻撃者も利用できる
  • データがインターネットへ抜け出されたり、ワークロードを制御できなかったりすることが可能
• そのため、セキュリティ対策が必要

AWS Network Firewall と Route 53 Resolver DNS Firewallの概要

• 両方 Fully Managed サービス
• Route 53 Resolver
  • DNSレイヤー
  • トラフィックに対して監視や制御が可能(Inspect and control)
• AWS Network Firewall
  • 伝統的なネットワークレイヤー（Route Tableなど）
  • ネットワークトラフィックに対して可視性がある監視や制御が可能

Network Firewallのユースケース

• Network Firewallのポロシーを作成してDev VPCのトラフィックが Prod VPCに届かないようにできる
• 詳細なレイヤーのトラフィックもコントロールできる

AWSカスタマーが Egressセキュリティのため多くの時間を費やす理由

• ２つの大事なこと
  • 予防（Prevention）
    • Ransomwareのようなことを検知だけではなく素早く遮断できる機会ができる
    • SWが起動中の間、強くコントロールしない場合が多いため、先に防御してSoftware supply chainを防御することが重要
    • そして検知できる機会が増加していける
  • 可視性（Visibility）
    • 自分のワークロードが何が起きて何をやっているのか把握したい
    • 設定ミス（misconfiguration）による問題を検知できる
    • トラフィックについて多様な情報を取得できる
    • 脅威ハンティング（Threat hunting）ができ簡単に分析できる

エクスプロイトの解剖学（Anatomy of an exploit）

• 限定されたリソースや多くの時間がかかるため、1つのセキュリティコントロールに対してOver indexing をしないでください

Robinhoodの Egressセキュリティジャーニー、学んだこと、ベストプラクティス

Robinhoodの Egressセキュリティジャーニーの原則について

• 完璧さが発展の邪魔にしないようにする
• できるだけ早く勝つ
  • Route 53 Resolver DNS Firewall
    • AWS Managed domain list
      • Malware, Ransomware, command などと関連されている情報を取得可能
    • Custome domain list
  • Network Firewall
    • AWS Managed Rule Groups
  • DenyリストまたはAllowリストは失敗した選択である
  • お互いに補完するはず
• 寛大なAllowリスト (その他すべてを拒否) は、Denyリストよりリスクを削減できる
  • マネージドルールセットの使用を想定

我々によくできてなかったこと

• アプリケーション動作のスペクトラム
  • リスクが高いトラフィックはDenyリストで、そのほかはAllowリストを使用した方がいい
  • Allowリストを使うと対象以外のトラフィックはデフォルトでDenyされる
  • クラウドアプリは予想できるため、狭過ぎない範囲であればAllowリストを使用しても大丈夫
  • 狭い範囲の Allowリストを使う場合、将来に許可が必要なトラフィックに対して追加対応が必要になるしこれは時間の無題になる

実際のグラフを確認すると、狭い範囲の Allowリストを使うとたくさんの時間がかかってしまう

Network Firewallのベストプラクティス Top 10

1. 対称ルーティングを確保する
2. "strict, drop established" 順の規則を使用
3. statelessルールは使用しないこと
4. カスタムSuricata ルールを使用
5. できる限りカスタムルールグループは少なく使用
6. $HOME_NET 変数が正しく設定されていることを確認する
7. PASS規則の前段に ALERT規則を使用して許可されてトラフィックを記録する
8. "flow:to_server, established" を優先する
9. logging 使用
10. Cost optimize, S3とDynamo DBの場合、VPC Endpointを使用する

最後に

AWS Network Firewall と Route 53 Resolverを活用したOutbound トラフィックのセキュリティについて紹介いたしました。

個人的にはIngressに比べてEgressトラフィックのセキュリティは大事にしてなかったですが反省できました。なお、Outbound トラフィック（egress traffic）については知識がなかったですが、ベストプラクティスまで勉強できてよかったです。

Ingressに比べてEgressトラフィックのよりセキュアなネットワークを構築できると思います。