Amazon Web Services

DDoS攻撃の緩和戦略

Sakura Onishi

自己紹介

$ whoami

• Sakura Onishi (@sakuxa)
• 所属
  • VJソリューションズ株式会社
  • 合同会社CatCode
  • JAWS-UG 徳島支部 + たまにクラウド女子会
• 頼まれたことは幅広くなんでもやる
  • Web, iOS, Infra, Security, Big Data, DevOps ...
  • 2年くらい前に魅力を知り、AWS沼に落とされる 
  • 最近よく扱うのは Java, PHP, Python, TypeScript, elixir
• LGBT - トランスジェンダー
  • TokyoRainbowPride の運営サポート
• 猫好き

今日話すこと

DDoS対応戦略

攻撃の種類:

• UDP Flood / UDP Storm
• SYN Flood (プロトコル攻撃)
• HTTP (GET/POST) Flood (アプリケーション攻撃)
• ICMP Flood / smurf Attack

 

DDoS対策として:

• 攻撃範囲の最小化
• サーバの垂直/水平スケーリング
• オリジンIPの秘匿化
• IDSやWAFの実装
• 攻撃時の対応計画

DDoSの主な攻撃手法

UDP Flood (UDP Storm)

• UDP攻撃はUDPパケットを攻撃対象サーバのランダムなポートへ大量に送信する
• サーバはパケットを受け取ったUDPポートを待ち受けているアプリケーションを探し、待ち受けているアプリケーションがない場合、到達不能のエラー応答を行う
• 攻撃対象がこの攻撃パケットを大量に受信してしまうと、エラー応答を担うICMPパケットが大量に生成され、サーバやネットワーク機器が過負荷に陥りダウンする
• TCPと違いIPアドレスの偽装が容易である
  • ハンドシェイクが必要ないため

 

 

SYN Flood

• TCP接続の確立に必要な 3-way handshake を狙った攻撃

 

 

 

 

 

• 攻撃者は大量のSYNを攻撃対象サーバへ送り、その応答としてホストは SYN-ACK を返すが、攻撃者は ACK 応答を行わない
• 結果としてサーバはACK応答を待つオープンコネクションが大量に生成され、利用可能な接続リソースが減少する

1. クライアントは接続要求として SYN をサーバへ送信する (Synchronized)
2. サーバは SYN-ACK をクライアントへ応答する (Synchronized Acknowledgement)
3. クライアントは ACK を応答して接続を確立する (Acknowledgement)

HTTP (GET/POST) Flood

• いわゆるF5アタック
• TCPプロトコル
  • IPの偽装は難しい
• 大量のGETやPOSTリクエストをサーバに送信する
  • GETリクエストは、生成がシンプルでスケールしやすい
  • POSTリクエストは、アプリケーションで負荷の高いパラメータを付与することで攻撃を効率化できる
• レイヤ7（アプリケーション層）のダウンを狙う

ICMP Flood / smurf Attack

• 大量のPINGを送りつける
• ICMPはハンドシェイクの必要もなくIP偽装が容易
• smurf Attack
  • 踏み台ネットワークのブロードキャストアドレスに、攻撃地対象サーバを送信元として偽装したPINGを送る
  • 踏み台ネットワーク内の全サーバが一斉に攻撃対象サーバーに向けてPING応答を返却する
  • 攻撃の増幅に成功
• 対策としてはファイアウォールでICMPを破棄する設定にする
  • 他の攻撃と違い、正当なリクエストでは使用しないプロトコルを用いているため、防ぐのは比較的容易
  • ELBやCloudFrontを挟む

DDoS 防御戦略

DDoS 防御戦略 (1)

攻撃範囲の最小化

• ELBとCloudFrontを使ってアプリケーションへの負荷を分散
• 多層アプリケーションアーキテクチャを採用することで、レイヤ別に戦略を適用できる

 

サーバの垂直/水平スケーリング

• インスタンスタイプを大きいものへ変更（垂直スケーリング）
• Auto Scaling を有効化して、負荷に応じてサーバ台数を増やすことで無限に処理能力を拡張できる（水平スケーリング）

DDoS 防御戦略 (2)

オリジン秘匿化による保護

• バックエンドサーバなど背後に存在するリソースのIPを表に出さない
  • Route53 のエイリアスレコード
  • CloudFront
  • ELB

IDSやWAFの実装

• AWSを採用する場合、出る幕は少ないかもしれない

攻撃時の対応計画

• 例えば地理的な攻撃パターンが見つかったとき、地理ベースのアクセス拒否を行うのか？

DDoS 対策: UDP Flood

• アプリケーションで待ち受けているポート以外を開かない
  • VPC ACL
  • EC2 Security Group
• エラー応答を返す代わりにパケットを破棄する
• 攻撃IPをブロックする対策はあまり有効でないことが多い

 

DDoS 対策: SYN Flood

• 有効なTCPリクエストのみを通過させるようにする
  • CloudFront
  • ELB
  • 独自のWAFレイヤ
• CloudFrontやELBを間に挟むだけで、有効なTCPのみをオリジンサーバに通過させることができる
• 何らかの理由で設置できない場合は、ウェブサーバ内に SYN Flood に対応したWAFを設置する
• TCP接続確立前の攻撃であるため、攻撃者IPアドレスは偽装されている可能性がある

DDoS 対策: HTTP Flood

• サーバからのレスポンスをキャッシュさせる
  • CloudFront
  • キャッシュ可能な静的ページが多い場合とても有効
• データの即時性が求められるアプリケーションの場合でも、数秒のキャッシュを挟むだけで改善が期待できる
• 結果セットが動的に変わるアプリケーションの場合はスケールさせて対応するのが基本戦略
• TCP接続確立後なのでIPアドレスの偽装は基本的に不可能
• 攻撃元の地理的な規則性があれば、CloudFrontなどで地理的なアクセス制限を設定することもできる

CloudFront

• CloudFrontは正当なユーザーへコンテンツを配信し続けながらDDoS攻撃そのものを緩和・軽減することが可能

 

• エッジロケーションが増大するトラフィックに応じて自動的にスケールする

 

• 有効なTCPコネクションやHTTPリクエストのみをエッジロケーションでフィルタリングできる
  • UDP Flood / SYN Flood 攻撃に有効

 

WAF (Web Application Firewall)

WAFを使うことで無効なリクエストをフィルタリングしたり、トラフィックの状態やアクセス元などの状態を監視できる。

多くのWAFにはIDS (Instruction Detection System) が含まれ、通信状態の解析や疑わしい挙動の通報が可能。

 

• トラフィックの監視目的に利用
• 攻撃と思われるリクエストのブロックや通報
• マルウェア対策
• データ破壊対策 など

 

Webサーバ自身にWAFを導入することもあるが、WebサーバやELBの前段に設置しトラフィックをフィルタすることも多い

WAFを使った構築例