AWS への Billing DDoS攻撃について。有効な対策はなさそう。

Billing DDoS攻撃とは、よしだの造語です。データ転送やリクエスト数に課金されるAWSサービスへ DDoS 攻撃を受けると、サービスはダウンしないかもしれません。でも、インターネットにエンドポイントを持つサービスの多くが、データ転送量やリクエスト数に対して課金がされるようになっているので、DDoS 攻撃でソフトウェア、ハードウェア的なダウンを狙えない代わりに、サービス提供者のお財布を狙う攻撃が想定されます。わぉ。

色々と調べてみたのですが、これといって有効な解決策が見つかっていません。いい方法がある、書いてあることが間違っている、などご指摘有れば是非コメントいただければと思います。

AWSには様々なサービスが有る中で、特に CloudFront については注意が必要な気がします。CloudFront は本質的に、利用者にエンドポイントが開かれている必要があるため、簡単にブロックすることは出来ません。例えば、ブロックする方式として EC2 を前段に立てて、プロキシやファイヤーウォールを稼働させ、条件をパスしたリクエストを CloudFront のエンドポイントにフォワードする方式が考えられます。この場合、確かに攻撃者のリクエストをフィルターすることが可能になりますが、EC2は固定のリージョン、AZを選択する必要があります。このため、CloudFront のアクセスしたロケーションに合わせたエッジサーバーの選択によるレスポンスの高速化、という売りが失われてしまいます。こうなると、もはや CDN ですらありません。

一方で、CloudSearch のように、必ずしもエンドユーザーにエンドポイントが開かれている必要がないサービスの場合*1、検索アプリケーションにのみ、アクセスを制限するという方法があります。検索アプリケーションを EC2 で稼働する場合は、アプリケーションの前段で iptables 等を噛ませたり、Security Group でフィルターしたりと、やり方はあります。

多くのAWSサービスの料金体系には、データ転送に対する課金が含まれる

CloudSearch や CloudFront の用に、必ずインターネットにエンドポイントを開いている仕様のサービスが幾つかあります。これらのサービスはの課金体系は、それぞれ色々ですが、大体リクエスト数や転送Outのデータ量で課金がされます。

例えば、以下は CloudSearch の課金体系です。データ転送が含まれます。参考：http://aws.amazon.com/jp/cloudsearch/pricing/

検索インスタンス
ドキュメントバッチのアップロード
データ転送

次に、CloudFront 。こちらも同じくデータ転送が含まれます。参考：http://aws.amazon.com/jp/cloudfront/pricing/

インターネットへのリージョンデータ転送送信
オリジンへのリージョンデータ転送送信
HTTP メソッドのリクエスト料金

細かくはチェックしきれていませんが、CloudFront のように、前段にEC2などを立ててエンドポイントを利用者から隠ぺいする方法が無効なサービスが他にもあるかもしれません。

攻撃にはどのぐらいのリクエスト数が必要か？それは現実的な数字か？

一方で、攻撃者の立場になれば、現実的に送信可能なリクエスト数でサービスを止められる程度に破産させることができるか？という疑問が湧いてきます。

一例として、￥200万円使わせるためには、500KBのコンテンツがあることを前提とすると、およそ月間で3億リクエスト送信する必要があります。以下、簡単な計算式です。日本という列に記載してある金額は、月あたり1GBのデータ出力(CloudFrontからインターネットへ)にかかる金額です。

	日本	データ量合計	金額合計
最初の10TB	0.190 USD	10TB	1,900 USD
次の40TB	0.140 USD	50TB	7,500 USD
次の100TB	0.120 USD	150TB	19,500 USD

それぞれの課金帯の最大のデータ量に対して、GBあたりの金額を掛けあわせたのが金額合計です。100TB帯で、最大19,500USDかかりおよそ200万円前後という事になります。これを 150TB を 500 KB で割ると、およそ月間３億リクエストという数字になります。

これは、秒単位にすると、およそ116リクエストなので JMeter のようなちょっとしたツールとハードがあれば簡単に実現できます。ただし、表をみると分かるのですが、リクエスト数が増えていくとGB単位の金額が安くなるので、リクエストを増やせば増やすほど攻撃の効果が下がってきます。

つまり、￥２００万円使わせるぐらいは簡単に出来そうということがわかります。チェックしたのはたかだか￥２００万円なので、大手のサービなら屁でもないかもしれませんが、この攻撃が怖いのが１００％確実に防ぎきる方式が今のところ見当たらない点です。

監視・検知方法はないか？

監視・検知の方法ですが、一番即効で検知できると思われるのは、CloudWatch の Billing Alert を使うことだと思います。課金される金額をアラートのトリガーに設定しておいて、単位時間中にその金額を上回ったら SNS で通知といった使い方が可能です。ちなみに、CloudFront の Network-In に対するアラートは仕掛けられないようです。*2 EC2は可能なのですが。

一方で、アクセスログを出力させて、これをチェックするという方法もありますが、CloudFront の性質上、リアルタイムでログ出力がされない、S3 にのみ出力される、ログのフォーマットが一般的なフォーマットではない、という理由から即効性のある検知用途には使えないかなと思っています。あとで、攻撃やアクセススパイクを分析するために使用するのが良いかと思います。

対策は？

調べられた範囲では、完璧な対策はありません。そもそもDDoS攻撃の中でも、一見正常なリクエストにしか見えない HTTP GET Flood 攻撃そのものが、WBS砲やGnoucy砲などのような、何かしらの外部要因によるアクセススパイクなのか攻撃なのかはログやデータからは簡単には判別ができません。もちろん、１箇所のホストから同じコンテンツに 100req/sec もあれば、該当するIPアドレスからのアクセスをブロックしてもいいと思いますが、攻撃がたくさんのホストからされれば判別が難しくなります。

さらに困ったことには、CloudFront では、IPをブロックする機能はありません。

また、特定コンテンツへのリクエストが続いているのであれば、そのコンテンツを取り下げる、という方法もあると思いますが、おそらく最近の攻撃やツールはそれほど単純ではないような気がします。複数のコンテンツに、複数のサーバーからランダムに GET リクエストを投げられると場合によっては、Distribution を一時的に止めざるを得ないと思っています。すなわち一時的なサービスの停止です。

公式な見解？

一応、DDoS の対策はしているが、セキュリティ上の理由により公開が出来ないとのこと。以下、引用。

We have multiple techniques for detecting and mitigating DDoS attacks that for security reasons we don't share in detail publicly. Whether the request makes it to the customer and results in a bill depends on the nature of the request - some will, some won't. We do incur real expenses for serving this traffic so we generally pass that on, but we are happy to have a conversation on a case by case basis.

https://forums.aws.amazon.com/message.jspa?messageID=253609

アマゾンデータサービス様各位に於かれましては、具体的な対策をご検討いただけますよう切に願いますw