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を使った構築例