クラウドにおけるDDoS対応の自動化について理解する #SID324 #reinvent

こんにちは。池田です。年内にEcho Plusを入手できるのか不安になってきました。

はじめに

Automating DDoS Response in the Cloud - SID324 - re:Invent 2017 というセッションについて、英語の勉強を兼ねてセッション動画とスライドの内容からAWSにおけるDDoS対策を理解するためにまとめたものです。

DDoS対応の進化

種類

• オンプレミス環境におけるDDoS対策
  • オンサイトでのDDoS攻撃を軽減するためのネットワークおよびインフラストラクチャの拡張が必要
  • 可視性と制御
  • 大規模な設備投資
    • メンテナンスコスト、および社内の専門知識
• CLOUD-ROUTEDにおけるDDoS対策
  • トラフィックを他のネットワークにルーティングして、より優れた軽減能力、管理対象サービスを受ける
  • 先行投資や社内の専門知識なしに、より大きなDDoS攻撃を軽減する
  • ブラックボックスソリューション
    • 対応の待ち時間、追加の障害点、運用コストの増加
• CLOUD-NATIVE(AWS)におけるDDoS対策
  • AWS上のすべてのアプリケーションの自動常時オンDDoS保護
  • 16のリージョンと107エッジポイントを活用した、大規模な攻撃を緩和する
  • シンプルで柔軟で手頃な価格
    • 堅牢な能力（Robust capabilities without undifferentiated heavy lifting）

AWS SHIELD

• 標準的な保護(Standard Protection)
  追加費用なしですべてのAWSユーザが利用可能
  • 最も一般的なネットワークおよびトランスポート層に対する自動防御AWSリソースにおけるAWSリージョンのDDoS攻撃
  • Amazon CloudFrontとAmazon Route 53を使用している場合、すべての既知のネットワークおよびトランスポート層攻撃に対する包括的な防御
  • AWS WAFを使用する場合、アプリケーション層の保護が利用可能
• 高度な保護(Advanced Protection)
  追加の保護、機能、および利点を提供する有料サービス
  • Amazon CloudFront、Amazon Route 53、一部のAWSリージョンでグローバルに利用可能
  • DDoSの迅速なエスカレーション
    • 複雑なエッジケースを支援するレスポンスチーム（DRT : the AWS DDoS Response Team）
  • 攻撃の可視性と強化された検出
  • 経済的ダメージを目的とした攻撃(Economic DoS Attack)を緩和するコスト保護
  • アプリケーションレイヤー保護のためのAWS WAF、追加費用なし
• DDoSに対する準備(PREPARE: DDOS-RESILIENT ARCHITECTURE)
  • グローバルに分散された攻撃緩和機能
  • アプリケーションに渡す前にスリーウェイハンドシェイクを検証するSYNプロキシ機能
  • Slowloris(「スローHTTP攻撃」を行うDoSツール)の緩和
  • 信頼性の高いDNSクエリのみを許可することにより、ネットワーク分散された複雑な攻撃を軽減
    • 送信元DNSの検証を行う
  • 悪質なリクエストをブロックまたはレート制限するための柔軟なルール言語を提供

アラートの対応

• CloudWatchまたはカスタムダッシュボードのレビュー
• 可用性またはパフォーマンスの問題を特定
• オンプレミス攻撃またはsmokescreen attacksを確認する
• AWSサポートまたはAWS DDoS対応チーム（DRT）にエスカレートする

ClowdWathc Metrics のキーポイント（KEY CLOUDWATCH METRICS）

• DDoS攻撃または異常なトラフィック量を示すメトリック
  • AWS WAF： AllowedRequests、CountedRequests、BlockedRequests
  • AWSシールドアドバンス： DDoSDetected、DDoSAttackBitsPerSecond
• DDoSに固有ではないアプリケーション異常の指標
  • Amazon CloudFront: Requests, TotalErrorRate
  • Amazon Route 53: HealthCheckStatus
  • Classic Load Balancer: BackendConnectionErrors, HTTPCode.*, Latency, RequestCount, SpilloverCount, SurgeQueueLength, UnHealthyHostCount
  • Application Load Balancer: ActiveConnectionCount, ConsumedLCUs, HTTPCode.*Count, NewConnectionCount, ProcessedBytes, RejectedConnectionCount, RequestCount, TargetConnectionErrorCount, TargetResponseTime, UnhealthyHostCount
  • Network Load Balancer: ActiveFlowCount, ConsumedLCUs, UnHealthyHostCount, NewFlowCount, ProcessedBytes, TCP_Client_Reset_Count, TCP_ELB_Reset_Count, TCP_Target_Reset_Count
  • Amazon EC2: CPUUtilization, NetworkIn
  • Auto Scaling: GroupMaxSize

DDoS攻撃を検知した時ただちに取るべきアクション

• アプリケーションのパフォーマンスと可用性を確認する
  • AWS WAFでサンプリングされたリクエストをチェックする
• 通常のルールを使用して悪意のあるパターンをブロックする
  • レートベースのルールを使用して、ヒットIPを一時的にブロックする
• CloudFrontの速やかなデプロイ
  • スタンバイ状態を維持しておき緊急時に展開する
  • AWS上または他の場所でホストされているWebアプリケーションを保護する
  • 静的コンテンツと動的コンテンツをサポート
  • http://amzn.to/2mYNX6A のガイドを参考に
• ENGAGING WITH AWS
  • AWS管理コンソールまたはAPIを使用して「AWS Shield」サービスのサポートケースを開く
  • 使用可能な最高の優先度を選択する（たとえば、「緊急」または「重大」）
  • 他に良い方法があるか？
  • ケース生成を自動化し、標準化されたメッセージの使用によりケースの作成時間を短縮
  • 事前に定義された明瞭なメッセージにより、人為的ミスの発生確率を低減
  • エンゲージメントワークフローを並列化することで、エスカレーションの時間を短縮
  • 解決策：プログラムでAWSサポートケースを生成し、AWS DDoSレスポンスチーム（DRT）に通知

AWS SHIELD ENGAGEMENT LAMBDA

• ステップ1：http://bit.ly/2ic3XAWからドキュメントをダウンロードする
• ステップ2：手順に従ってAWSラムダ関数を作成し、イベントトリガーを設定（AWS IoTボタンなど）
• ステップ3：提供された関数で変数を設定する
• ステップ4：AWS IAM実行ロールを作成し、[Create function]をクリックする

変数の設定

//ユーザーが設定できるオプション
var config = {

//エンタープライズサポートに加入している場合はこれを 'critical'に変更します
severity: ‘urgent’, 

// AWS Shield Advancedを購読している場合はこれを 'advanced'に変更します
shield: ‘standard’, 

//テスト後にこれを 'off'に変更する
test: ‘on’, 

// AWS Shield Advancedに登録されていない場合、件名とメッセージを変更する
//件名とメッセージをS3で作成した.txtファイルのパスに変更します
standardSubject: 'http://s3.amazonaws.com/aws-shield- lambda/EngagementSubject.txt', 

standardMessage: 'http://s3.amazonaws.com/aws-shield- lambda/EngagementBody.txt' CONFIGURE VARIABLES

POKÉMONにおけるAWS SHIELD導入事例

POKÉMON GOの登場

• 想像をはるかに超えてPOKÉMON GOは成功した
• 誰も予想していなかった7億5000万というダウンロード数

POKÉMON GOによって突きつけられた新たな課題

• 正当なユーザーとトラフィックの大幅な増加
• 不正なユーザーとトラフィックの大幅な不均衡な増加
• ボットによるアクセス負荷
• スキャナー（不正プログラム）によるアクセス負荷
• DDoS攻撃

無償または有償のボットが存在した

• ボットの特徴
  • ポケストップとジムの検索
  • ムーブメントからゲームプレイまでの人間的な行動の多様な選択肢
    (Diverse options for humanlike behavior from movement to overall game play)
  • PokémonOptimizerを使用して高度なキャッチ、展開、転送設定
  • その他、正当なユーザーが行わない/行えない多数の特徴
• スキャナー（不正プログラム）の特徴
  • 大規模なシミュレートを実行してデータを収集する
  • ゲームプレイをスキップして報酬を得る

PTC（THE POKÉMON TRAINER CLUB）とTHE CLOUD-ROUTED WAF

何年もの間、PTCはクラウドルーティングされたWAFプロバイダによって保護されていた
- POKÉMON GOによるトラフィックの増加は、当時利用していたプロバイダーを圧倒した
- 管理インターフェイスが使用できなくなる
- トラフィックが完全に流れなくなる
- トラフィック量の急激な増加は、すぐに新たな対策ソリューションを実装する必要があることを意味した

AWS SHIELD ADVANCEDへの移行

• 既存アプリケーションはAWS上にあった
• 次の主要なPOKÉMON GOの移行イベントはわずか2週間で終了した
  • Pokémon DevOpsとInfoSecがAWSと緊密に連携
  • 1週間でトラフィックをゆっくりと移動させる
  • POKÉMON GOログイントラフィックの100％がAWS Shield Advancedによる保護
• 移行後について（適切な日本語表現がわからず...）
  • Cloud-routed WAF issues are behind us:
    • No more WAF capacity issues taking us offline
  • Pokémon is now seeing:
    • Lower latency through the WAF
    • 優れた分析とログ

AWS SHIELD ADVANCED AWSとの緊密な連携

• 定期的なロードマップと機能に関するディスカッション
• AWS IoTボタンを使用してAWS Shieldチームへの連携
  • インシデントブリッジの迅速な作成が可能になり、時間を短縮

セッションの終わりに

• ボットとスキャナーは消えない
• AWSシールドはAWS（または他の場所）のアプリケーション保護を容易にする
• AWS WAFはブラックボックスではないため、レイテンシとスループットが向上する
• インシデント対応プロセスが大幅に簡素化
• 他にどのような運用プロセスを自動化できるか？

まとめ

知っているつもりでも、改めて整理、列挙していくとシステムにとっての脅威は無数にあり、それを検知するための条件も複雑に関連しています。これを人力で検知、分析、判断、対応を行うのは（過去の経験を振り返っても）とても大変です。
可能な限り誤検知が少なくなるようチューニングされた自動処理はシステム管理者の負担軽減のほか、正当なユーザの利用機会やサービス提供側の機会損失を防ぐことになる大変重要な仕組みだと思います。
事例として紹介された人気ゲームのような、世界中から大量のトラフィックが送られてくるようなシステムならなおのことだと感じました。