[レポート] Building DDoS-resilient applications using AWS Shield #reinvent #NET314-OF

本セッションについて

概要

DDoS events can threaten the performance and availability of your applications. Learn how AWS has built a comprehensive defense against DDoS attacks that can be applied across scaled, multi-Region applications. Join this session to find out how to automatically detect and mitigate application-layer traffic anomalies that risk impacting application availability and responsiveness with AWS Shield Advanced.

スピーカ

• Paul Bodmer, AWS Shield Security Manager, AWS
• Oliver Sturrock, GM, AWS Shield, AWS

Agenda

• AWSネットワークの可用性を保護すること
  • Web traffic
  • DNS
  • Traffic from impacted AWS customers
• どう最初の攻撃パケットが来る前にDDoSを中止できるのか
  • Threat intelligence
  • Monitoring botnets
• DDoS復元力のためのフレームワーク

動画

セッションの内容

インターネットの立ち入り

インターネットトラフィックは多様な所からくる。例え、

• Internet peers
• Regional PoPs
• AWS Client VPN
• AWS Private 5G
• AWS Cloud WAN
• AWS Wavelength
• AWS Ground Station
• AWS Outposts

このようなインターネットからのトラフィックに対して、次のようなサービスを使える。

• Web traffic to a CDN
  • Amazon CloudFront
• DNS traffic
  • Amazon Route 53
• Any traffic an AWS-managed endpoint
  • ELB
  • Global Accelerator
  • Amazon API Gateway
• Any traffic to customer-managed endpoints
  • Traffic from AWS to AWS

CloudFrontへのDDoS攻撃（Web traffic to a CDN）

CloudFrontに来るトラフィックは80・443ポートの大体 HTTP、HTTPs で最近は QUICもある。他タイプのトラフィック（例えばUDP）をBlockすることができるがBlockせずにRequest floodを取る。緩和するため検知された攻撃の５０％は他の第７層サービスからCloudFrontに対するRequest floodであるほど、Request floodは一番一般的な攻撃である。

このような攻撃に対してCloudFrontの拡張性を活用できる。CloudFrontでは435個以上のPoPがあり、DNSやBGP（Border Gateway Protocol）を使ってトラフィックのルーティング方法を変更できるので、攻撃されているPoPを分離できる。しかし、パッケージはPoPで削除できずオリジンへ行くため、AWS Wafを使ってこのようなトラフィックをコントロールした方がいい。

Route53へのDDoS攻撃（DNS traffic）

Route 53のホストゾーンに何が含まれているのかを理解した上、ただのドメインネームフィルターを作成してそのトラフィックをBlockしたり削除（drop）したりして正しいドメインはDNSサーバーへ行ける。

あるトラフィックからあるエンドポイント（Any traffic an AWS-managed endpoint）

NACL

NACLは全てのユーザーVPCにあるトラフィックをハンドリングできるいい手段である。これは AWS Shield Advancedの特徴である。例えば、あるインスタンスがDDoSトラフィックのターゲットになった場合、AWSは ユーザーが作成したNACL Configuration を持ってくる。

Byte match

パケットの第３層または第４層のヘッダーにBite sequenceを入れたり第４層のペイロードにBite sequenceを入力すると該当のsequenceが含まれてない全ての項目をフィルタリングできます。

Health-based detection

使用方法は、Route 53の Health checkを作成しエンドポイントの状態をモニタリングしたりアプリケーションのカスタムメトリクスを作成してモニタリングする。特定の比率を超えると状態が unhealth になりAWS Shield Advancedから保護されているリソースと連結される。状態が Healthの場合、AWSはより多いデータポイントを収集する。これは結果的に検出および緩和感度レベルに影響を与える。

Traffic from AWS to AWS

DDoS defensesがあるためAWS ネットワーク上にあるインスタンスからの攻撃に対して、すぐ検知できるし攻撃を行うインスタンスをショットダウンしたりトラフィックをブロックしたりすることが可能である。なおAWSネットワークの外部からのトラフィックに関する追加的なインサイトもある。

DDoS復旧に対するフレームワークの考え方

• マルチリージョンまたはマルチAZアーキテクトを構築する
  • DDoSだけではなく他の障害のためにもマルチリージョンまたはマルチAZのアーキテクトを構築した方がいい。
• なおRoute 53、CloudFrontのようなEdgeサービスの拡張性を活用する
• モニタリングする
  • ダッシュボードを使用し他方がいい。
• 拡張性があるアプリケーションを作成する
  • ALBやAuto Scalingなど
• セキュリティモデルを定義する
  • 適用するAWSセキュリティサービスを決め、動作を定義する。
• AWSと協力する

最後に

ネットワーク上では多様な威脅がありますが、本セッションではDDoSという一つの種類に関していろいろ聞くことができて良かったです。

セッションに参加する前にはAWS ShieldだけならDDoSは大丈夫じゃない？と思いましたが、それ以外の対策もあったりさすがだと思いました。

私には内容が少し難しでしたが、AWSはDDoS攻撃をどう防げるのか、そしてAWS Shieldがどう動作するのかなどが分かって面白いセッションでした。