こんにちは、ひろかずです。
AWSのDDoS対策(対応状況)ってどうよ。ってふわっと問われることが多くなってきましたので一筆書きます。
★★ 2016/2/23 Slowlorisの箇所を修正しました！CloudFront△です！
#参考
DDoSに対するAWSのベストプラクティス
DDoS Protection Services Review 2016
#一言で言うと
「答えは、DDoSに対するAWSのベストプラクティスに書いてある」なのですが、案内してもピンときた反応がなかったので、「どうしたら伝わるかな」とを考えていました。
ちょうどいいタイミングで、DDoS Protection Services Review 2016が発表されました。
ここでは、基準とするDDoS攻撃の分類が掲載されているので、それらを引用しながら、DDoSに対するAWSのベストプラクティスの内容を当てはめていってみましょう。
※ 訳文はGoogle翻訳です。悪しからずー
#分類と対応策
##Volume Based Attacks
###内容
Volumetric attack rely on swarms of requests, usually illegitimate IP address, overwhelming site bandwidth with a flood of traffic.
attacks are measures in bits per second (Bps).
common attacks include UDP and icmp floods.
体積攻撃はリクエスト、トラフィックのフラッドと、通常、認められていないIPアドレス、圧倒的なサイトの帯域幅の群れに依存しています。
攻撃は秒（bps）あたりのビット数を測定しています。
一般的な攻撃は、UDPとICMPフラッドが含まれます。
###AWS環境での対応策
UDPは、NTPやDNSのリフレクション攻撃と解釈します。
DDoSに対するAWSのベストプラクティスには「攻撃面対象領域を削減する」と記載されていますね。
NTPを用いたリフレクション攻撃は、タイムサーバをVPC内で保持していても、外部からの通信をSecurity Groupで制限していれば、攻撃通信は到達しません。
DNSも用いたレフレクション攻撃は、Route53を使用していれば問題無いでしょう。
Route53自身の対応策はDDoSに対するAWSのベストプラクティスに シャッフルシャーディング や Anycast ルーティング として記載されています。
独自DNSをVPC内に保持している場合は、Security GroupやNetworkACLで参照元のIPを制限しておけば、攻撃の影響は受けにくくなります。
その他のプロトコルについても、外部からの通信を制限する AWSサービスを利用するという考え方は基本的に変わらないでしょう。
ICMPフラッド攻撃については、そもそもSecurity Groupで外部からのICMPを許可していなければ問題にはなりません。
AWS環境でICMPに依存するシステム実装については、監視以外にちょっとイメージできませんが、必要な場合でも 送信元を絞る ことでDDoS攻撃自体の影響は受けにくくなると考えて良いでしょう。
##Protocol Attacks
###内容
The goal of a protocol attack is to drain resources by sending open requests, like a TCP/IP request, with phony IPs, saturating network resources to the point that those resources to the point that those resources can't answer legitimate requests.
Attacks are measures in Packets per second.
Common attacks include Smurf DDoS, Ping of Death and SYN floods.
プロトコル攻撃の目的は、偽のIPアドレスと、 TCP / IP要求のように、オープン要求を送信し、それらのリソースが正当な要求に答えることができないことをポイントにネットワークリソースを飽和させることによって、リソースを排出することです。
攻撃は、秒あたりのパケットで測定されています。
一般的な攻撃はSmurf DDoS 攻撃、SYNフラッドとPing of Deathを含みます。
###AWS環境での対応策
Smurf DDoS 攻撃とPing of Deathですが、考え方はICMPフラッドと同じです。
SYNフラッドは、サービスのオープンポートに仕掛けることができるので少々厄介に思いますが、CloudFrontやELBを前面に設置すれば良いでしょう。
CloudFrontやELBは、有効なTCPリクエストのみバックエンドに転送します。
CloudFrontやELBを前面に設置できない場合、Deep SecurityのようなIDS/IPSが有効です。
Deep Securityは、不正なフラグメントのパケットを遮断します。
##Application Layer Attacks
###内容
Layer 7 attacks are slow and stealthy, sending seemingly harmless requests meant to bring down a web server.
these attacks commonly target HTTP.
Attacks art measured in Requests per second.
Common attacks include Slowloris, Apache Killer and HTTP floods.
レイヤ7攻撃は、Webサーバーをダウンさせることを意図一見無害な要求を送信し、遅く、ステルスです。
これらの攻撃は、一般的にHTTPをターゲットにしています。
攻撃は、秒あたりの要求で測定されています。
一般的な攻撃はSlowloris、Apache killerおよびHTTP floodsが含まれます。
###AWS環境での対応策
Slowloris は、少しずつデータを送ってセッション等のサーバリソースを枯渇させる厄介な攻撃です。
CloudFrontはcacheを回避してくる事が予想されますが、結局オリジンへの問い合わせはCloudFrontが行うので大きな影響はなさそうです。(2016/2/23修正)
Apache killer は、Rangeヘッダに多くのパラメータを指定することにより、Apacheの使用メモリを増大させる攻撃です。
WAFやDeep Seurityのシグネチャによる対処が有効です。
HTTP floods は、いわゆるF5攻撃と解釈できます。
CloudFrontでcacheを返してしまうのが一番ですが、転送料金がかかってしまうのが悔しいところですね。
cacheを回避してきた場合は、Webサーバまでリクエストは到達します。
AutoScale等でリソースを増強して耐える一方で、リクエスト数の推移や4xxや5xxエラーの推移から攻撃を検知して、地域性がある傾向が見られれば、CloudFrontのGeo Restriction(地域制限)やAWS WAFのWebACLで国別のIPレンジで遮断設定するような措置をとる方式が考えられます。
#最後に
DDoSと一言で言っても攻撃手法は様々で、まるっと訪ねてしまうと、まるっとした答えが返ってきがちです。
前述のとおり対策は様々で、完璧に対応し切るのは簡単ではありません。
所有しているシステムの特性で上記の対応策がフィットしない場合もあるでしょう。
WAFを入れて終わりにもできない話(※)ですので、DDoS攻撃の影響を受けにくい構成を上手く取り込みたいところです。
※ もちろん、きちんと管理/運用/チューニングされたWAF,IPS/IDSは非常に強力で有効ですよ！
少しでもDDoS対策を考える助けになれば幸いです。