【レポート】「Edge Servicesを利用したDDoS防御の構成(AWS WAF/Shield)」AWS Summit Tokyo 2019 #AWSSummit
こんにちは、臼田です。
こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。
本ブログでは『Edge Servicesを利用したDDoS防御の構成(AWS WAF/Shield)』に関する内容をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
中谷 喜久
2017年にリリースされたAWS Shield Advancedは日々多くのDDoS攻撃に対処しています。本セッションではよりDDoS耐性を高めるための構成/Tips/アップデートのご紹介と実際に対処を行うDDoS Response Team(DRT)の関わりについてご紹介いたします。
レポート
- 対象者
- AWSのDDoS対策サービスに興味がある方
- AWS Shieldについて理解を深めたい方
- どのように利用するのか知りたい方
- ゴール
- AWS Shield Advancedの中身について理解を深める事
- インターネット
- 概要
- インターネットは言葉はあるけどモノは無い
- ネットワークで繋がっている
- 実態はISPたちが繋がってできている複雑なもの
- 基本は待つネットワーク
- 可用性とかは後から考えられたもの
- インターネットは常に安定しているわけではない
- アプリケーション、サービスに接続するためにはいくつものネットワークを経由する
- 行きと帰りで違うルートを通ることもある
- それぞれのホップで性能劣化や再送が起きる
- Edge Serviceを利用した高速化、安定化
- なるべくユーザに近いところでサービスを提供したらいいと言う考え方
- エッジサービスはオリジンと通信する
- AWSのエッジサービスはエッジサービス-オリジン間をAWSのネットワークで提供
- 高いパフォーマンスと可用性を実現
- Edge Services
- AWSのエッジサービス郡
- Route53やGlobal Acceleratorのパフォーマンス系
- Shield / WAFというセキュリティ系
- エッジは180接続ポイントある
- 最近は南アメリカ等にも増えた
- 東京では6ロケーション増えた
- 全部で14ロケーション
- 世界で一番多い
- AWSのインフラはこちらで可視化されている
- 概要
- DDoS
- DoSとは
- 少ないリクエストでサービスを止める
- DDoSとは
- 分散された複数の攻撃者からターゲットを攻撃する
- DoSとの違いは量が多いこと
- 悪意があるのかを判断するのが難しい
- しかし受けるとサービスが止まってしまう
- 分散環境でDDoS防御
- オリジン側で止めるよりも、エッジで止めるほうが効率的
- エッジサービスはDDoS対策にすごく向いている
- どれくらいの規模なのか
- DDoSはよく規模で語られる
- 2016年のMiraiは1テラ程度
- Shield AdvancedではGlobal Threat Dashboardで可視化される
- 日常的にまんべんなくDDoSが起きていることがわかる
- 過去2週間のサマリが見れる
- 一定のDDoS量が常にある
- このときの最大リクエスト数は220KRPS
- しかしレベルはLocal
- これが通常通り
- ダッシュボード
- Packet Rate
- CPUリソースが消費される可能性がある
- Bit Rate
- 帯域の消費を見ている
- Request Rate
- HTTPリクエストによりアプリケーションのリソースを消費させているのを見ている
- 上記3つの時系列グラフもある
- それぞれタイミングがずれる
- いろいろ混ざって攻撃されているのがわかる
- Packet Rate
- サービスリリースの流れ
- ずっとAWS Shield Standardがあった
- WAFが2015年から出た
- Shield Advancedが出てきた
- 昨年Firewall Managerが出てきた
- AWS Shield Standard
- レイヤー3/4防御
- すべてのインターネットに面したAWSのサービスに対してついている
- 無償
- AWS WAF
- レイヤー7防御
- ルールベースのWebへの攻撃の防御
- レートコントロールを利用したDDoS防御
- DoSとは
- この2つで基本的なDDoS対策が可能
- DDoS Resiliency Architecture
- 困難な状態から迅速に回復できる能力(耐性)
- 適切なアラート、モニタリングの設定を含めた全体的なアーキテクチャ
- 守るべきものをきちんと守る
- インターネット側から考えると、まずはCloudFrontを使う
- 低レイヤーのDDoSを防御
- ついでにキャッシュで高速化
- WAFを併用できるのでこれも活用する
- Route53も忘れてはいけない
- DNSへのDDoSもよくある
- DNSが落ちるとサービスが利用できないのでこれも重要
- Route53で守りましょう
- Attack Surfaceを減らすためにSecurity Groupやサブネット設定をしっかりする
- EC2等は適切なインスタンスタイプで構成して、過剰なリクエストがある場合にはスケーリングするように設計する
- DDoSの内容を止めていいか判断することが難しい場合も多分にあるため
- 適切なモニタリングを行う
- CloudWatchで見る
- CPU使用率やリクエストの数など、複数の観点で監視する
- ホワイトペーパーもあるので具体的な監視したほうがいいメトリクスなどはこちらを確認
- AWS Shield Advanced
- DDoSに特化したメトリクスをCloudWatchで見れる
- 大規模なアタックから保護
- 攻撃の検知と緩和を可視化
- どれぐらいの規模で増えているかなども見れる
- Standardだと実際に攻撃を受けていることを見れない
- AWS WAFとFW Managerが無料で利用可能
- 24 x 7 DDoS Response Team(DRT)でのサポート
- 専門家と話しながら対応できる
- コスト保護(DDoSによるコストの吸収)
- オートスケールした際の費用などをサポート
- 対象サービス
- Route53
- CloudFront
- ALB
- Global Accelerator
- EIP
- インターネットで使われている全てのプロトコルに対応している
- 使い方
- 管理コンソールから始められる
- $3,000かかりますよ、というボタンを押す
- まずはどのリソースを守るのか選択する
- 全てが本番環境ではないので、Shield Advancedの対象とするリソースをユーザが選択できる
- デフォルトは全て選択されている
- アプリケーションを保護するためのWAFの設定を入れる
- 新規に作成することも、既存を利用することも可能
- WAFの費用はAdvancedでは発生しないので可能な限り使っていく
- 検知した際の通知先SNSトピックを登録する
- 後から追加も可能
- 3ステップで完了
- リソース一覧と状況が見れる
- どのように検知されるのか
- アノマリ検知する
- 統計情報を取得してベースラインを策定し、異常値を検知する
- それぞれのエッジロケーションから情報を収集して集計・評価している
- Mitigation(緩和)
- 基本的には自動防御
- 詳しくは言えないが最近またDDoSの手法は増えてきている
- 新しいものについても追随してアラートしている
- 現在進行中の攻撃についてもIncident画面で見ることが可能
- 自動防御
- L3/4のDDoS攻撃緩和はBlackwatchで行っている
- DRTがインバウンドで開発した装置
- L7は原則WAFで実施
- 常に速い速度で変化していくので自分たちでやっている
- しきい値もしくはシグネチャで緩和する
- 基本的に人手を介した緩和を行わないようにしつつ、DRTがメンテナンスしていく
- L3/4のDDoS攻撃緩和はBlackwatchで行っている
- DRT Engage
- エンタープライズサポート等の契約が必要
- L7の攻撃が会った場合にDRTで対応してもらう体制も可能
- DRTから新しい事象の連絡をすることも可能
感想
DDoSに対する基本的な考え方からしっかりと理解することが出来ました。
よりクリティカルな要件にはAWS Shield Advancedを活用していきたいですね。
ちなみに弊社ではこれをサポートさせていただくメニューがございますので参考にしてください。