はじめに
AWS で Web サイトを公開している場合、AWS WAF で DDoS 対策を行っている方も多いと思います。AWS WAF は柔軟なルール設定が可能で、DDoS 対策としても非常に強力です。
しかし、「Web ACL にルールを設定しただけで満足」 していませんか？
実際に大規模な DDoS 攻撃を受けると、既存のルールだけではブロックしきれないケースがあります。その結果、サービスが停止したり、オートスケーリングによる急激なスケールアウトでコストが跳ね上がったりすることもあります。
この記事では、いざという時に落ち着いて対応できるよう、事前に準備しておくべき対策を紹介します。
ある日突然 DDoS 攻撃が来て、サービスが停止したらどうする？
攻撃を受けた際、最も怖いのは「攻撃を受けていることに気づかない」ことです。
まずは、攻撃を検知できる仕組みが必要です。Route 53 のヘルスチェックや CloudWatch アラームを活用して、検知できるようにしておきましょう！
（検知できる仕組みを作る方法はすでに様々な記事で紹介していると思うのでここでは割愛します）
検知ができたら次は対応です。大量のリクエストをサーバーが処理しきれず停止してしまった場合、方針は大きく2つあります。
- 攻撃のリクエストを処理できるように サーバーを強くする
- 攻撃リクエストを WAF でブロックできるようにする
サーバーを強くする
まずはサービスを維持するために、サーバーの台数を増やして負荷に耐える方法です。
EC2 や ECS にはオートスケーリングというCPUの負荷などに合わせてスケールアウトやスケールインをしてくれる機能があります。
ただし、これはあくまで「時間を稼ぐ」ための手段であり、根本的な解決には攻撃の遮断が必要です。
リクエストをブロックする
WAF で効率的にブロックするには、「どこから」「どんな」攻撃が来ているのかを知る必要があります。
Athena でログを分析して攻撃の傾向を把握する
「攻撃が始まってからログを見よう」と思っても、設定が不十分だと分析に時間がかかります。事前に WAF のログを S3 に出力し、Amazon Athena でクエリを叩ける状態にしておきましょう。
私がよく行うログの分析方法は主に以下です。
- 攻撃のリクエストが多いタイミングのログをざっくり1000件くらい表示して、傾向を見てみる
- IP アドレスやリクエストのパス、国、User Agent、JA3Fingerprint ごとにそれぞれグループ化して偏りがあるか見てみる
例えば、「特定の国からのリクエストが多い」「特定のパスに対してリクエストが多い」ということがわかったら、両方を満たすリクエストブロックするルールをWAFに追加すれば OK です。
WAF の操作に慣れておく
AWS WAF は UI が比較的頻繁にアップデートされる気がします。緊急時に「ルールを追加するボタンが見つからない！」と慌てないよう、定期的にコンソールに触れて操作に慣れておくことも重要です。
おわりに
一番良いのは、適切なルールが設定されており、攻撃が来ても落ちないサービスです。
しかし、攻撃の手法も日々進化しています。
攻撃が来た時に最短で復旧できるよう、以下の準備をドキュメント化しておきましょう。
- 検知後の初動（誰に連絡し、どこを確認するか）
- サーバー台数を増やすためのオペレーション手順
- Athenaでログを分析するためのクエリ集
- WAFの最新UIでのルール追加手順
準備さえできていれば、いざという時も冷静に対応できるはずです！！