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応答を待つオープンコネクションが大量に生成され、利用可能な接続リソースが減少する
- クライアントは接続要求として SYN をサーバへ送信する (Synchronized)
- サーバは SYN-ACK をクライアントへ応答する (Synchronized Acknowledgement)
- クライアントは 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を使った構築例
AWS上でのDDoS対策
By Sakura Onishi
AWS上でのDDoS対策
- 2,888