DDoS対策について考えてみた

はじめに

DDoS攻撃やランサム攻撃など、サイバー攻撃がニュースでも盛んにとりあげられるようになってきました。

ITに馴染みがない方もこういう言葉を耳にする機会が増えたのではないでしょうか。

今回はDDoS攻撃に対してどう防御していこうか考えてみようかと思います。

※本記事では詳しい技術的な解説などは行いません。

目次

– DDoSとは
– 防御策
– まとめ

DDoSとは

そもそもDDoS攻撃とはなんでしょうか。
Distributed Denial of Service attack（分散型サービス拒否攻撃）というのが正式名称です。
長いのでDDoS（ディードス）攻撃と呼んでいます。

ものすごく大雑把な言い方をすると、いろいろなところから大量の通信を送り付けることで、対象サービスを利用できなくする攻撃と言ってしまえばいいかもしれません。
インターネット上のサービスは後ろにサーバなどの機器が必ずあります。

その機器が対処できないレベルの通信を送り付けてしまうと、その機器のリソースを使い切ってしまってサービスにつながらなくなるというわけですね。

単純じゃないかと思われるかもしれませんが、単純だからこそ防御が難しかったりします。

古くはオンラインゲームがサービス停止状態になってしまったりするなどの事例もありました。

近年はというと、ランサムDDoSというものも出てきました。

ランサムと言えばランサムウェアを用いた攻撃が一般的ではありますが、身代金を目的としたDDoS攻撃も海外では珍しくありません。

では、どのようにしてDDoS攻撃からサービスを守ればいいのでしょうか。

防御策

Amazon Route53

いきなりDNSです。
というのも、DDoS攻撃のうちDNSを対象にしたものは全体の1/3程あると言われているからです。

できるだけ可用性の高いDNSを利用することで、仮にDNSが攻撃されたとしてもサービスの継続性を確保できるようになります。

Amazon Route53はSLAがAWSサービスで唯一100%となっているため、それだけAWSが自信をもっているサービスだと思っています。
（※SLAが100%=100%の可用性で利用できるというわけではありませんのでご注意ください。）

もちろんRoute53単独で利用するだけではなく、異常検知サービスを組み合わせることで攻撃に対する更なる防御策を講じることができます。

単に可用性が高いだけでなく、他サービスと組み合わせた異常検出が可能ということでAmazon Route53を利用する価値があるのではないでしょうか。

DDoS周りに絞って書くとこのような感じでしょうか。

●メリット
・可用性が高い
・ヘルスチェックと連携させたフェールオーバー機能

●デメリット
・直接的なDDoS対策機能にはならない
・多機能すぎて把握が難しい

Amazon CloudFront

AWSが提供しているCDNです。
世界中に存在するエッジサーバを利用することで、自環境のリソースへのアクセスを減少させることができます。

世界中に存在するエッジロケーションから配信することでユーザとの接続遅延を最小限にすることができます。

CloudFrontの機能を利用して、WAFなしでも特定国からのアクセスを遮断することなどもでき、非常に便利なサービスです。

先に書いたように自環境の前段にエッジサーバをかませることでDDoS攻撃への対策を（ある程度）見込めますがこれは副次的な機能かなと思っています。

あくまでもコンテンツ配信の高速化を主眼としたサービスのため、Cloudfrontをいれて終わり、というわけにはいかないかなと考えています。

例えば、数年前にはやったEDoS攻撃（Economic Denial of Service）に対してCloudFront単体では弱いんですね。
クラウド環境を利用している場合、たいていのケースではリクエスト処理に課金が発生しているかと思います。

EDoSとは大量のアクセスを送り付けることで大量の課金を発生させ、サービスを閉じさせてしまうというビジネス型の攻撃です。

通常の数十倍~数百倍のアクセスが来た場合、それに比例した料金を支払う必要が出てきます。
サービスの継続性とコストが見合わなくなった場合、サービスを停止せざるを得ないため、特に小規模環境に対して有効な攻撃だと言えます。

※DDoSと異なり、サービスを直接停止させない規模のアクセスに限定させることが多く検知が難しい攻撃です。

また、CloudFrontでさばけない量のアクセスが来た場合もサービス断が発生してしまいます。
最適なキャッシュ設計を行うためにはアプリケーション側の知識も必要になるため、インフラエンジニアだけでは対応が難しいのが実情です。

●メリット
・可用性が高い
・ヘルスチェックと連携させたフェールオーバー機能

●デメリット
・EDoS攻撃に弱い
・対DDoS特化サービスではないため、さばけるアクセスには限界がある
・キャッシュ設計が難しい

Amazon WAF

AWSが提供しているアプリケーションファイアウォールです。
手動で設定も可能ではありますが、AWSが用意しているマネージドルールを利用するのが手早く実装できます。
もちろんAWSが用意しているルールのため、それぞれの環境に特化したものではなく、場合によってはそぐわなないルールなどもあるかもしれません。
しかしながらスモールスタートが可能であること、とりあえずいれておけば最低限の防御はできるであろうことからマネージドルールから始めてみるのがいいでしょう。
CloudFrontの部分でも記載をしたEDoS攻撃ですが、

DDoS対策として今年リリースされた内容ではありますが、L7の防御機能がリリースされています。
ALBやCloudFrontで利用でき、自動的にDDoSの検知と緩和を行ってくれるマネージドルールとのことです。
話を聞く限りでは、Shield Advancedの自動緩和にかなり近い内容になっているような気がします。
とはいえ、実際に利用している正常な通信をブロックされると支障がでてしまうため、必ず事前にブロックされるかどうか通信の検査を行ってください。
Countモードで様子を見てからBlockに切り替えるのを忘れずに。

●メリット
・DDoSに代表される攻撃的な通信の遮断が可能
・WAFでブロックした通信分の料金が請求されないなどEDoS攻撃への保護も可能

●デメリット
・環境にあったルール設計が難しい
・誤遮断の危険性がある

AWS Shield Advanced

Shield Standardの上位オプションと言っていいかと思います。
と言っても普段我々はShield Standardの有効化や設定など行っていないのでピンと来ないかもしれません。

Shield Standardと異なり自分でリソースの保護など初期設定が必要ではあるものの、実際にDDoS攻撃を受けた際は自動的にL7層の攻撃緩和をしてくれたり、専門チームからのサポートを受けられるなど技術的なメリットはかなり大きいものです。
また、AWS WAFの料金も基本無償（一部有償）となったり、DDoS攻撃を受けた際のコスト保護が受けられるなどEdoS攻撃にも強くなっています。

月間3000USDの固定費がかかり、12か月の間解約ができないなどしばりはありますが、その固定費もOrganization単位です。
Organizationにアカウントが10個あったとしても3000USDのサブスクリプション費用は変わらないのでマルチアカウントの場合はコスト的にもメリット出てくるのではないでしょうか。

●メリット
・AWSが抱えているDDoS専門チームがDDoS対応してくれる
・DDoSに対応したWAFルールを自動的に追加してくれる
・サブスクリプション費用はOrganization単位で共通
・DDoS攻撃時に急増したコストを無料にしてくれる
・AWS WAFの料金が基本的にかからない

●デメリット
・月間3000USDのサブスクリプション費が発生する
・設定が難しい

まとめ

DDoS対策を行う場合、大きく分けて二つに分かれるかなと思いました。
一つはShield Advancedを利用する場合。
Organization構成をとっており、複数の環境でDDoS対策が必要な場合はこちらでいいかなと思います。
月間3000USDの継続的な支払いが必要な代わりに、AWSから大きなサポートが受けられるためです。

もう一つはShield Advancedを利用しない場合、すなわちAWS WAFをうまく使っていくパターンです。

AWS WAFを利用する必要があるため、ALBないしCloudfrontを利用する必要がありますが、DDoS攻撃に対する保険と考えれば必要経費だと考えます。

WAFルールは自分で設計していってもいいですが、自環境に特化したWAF設計を行うのもなかなか大変なのでWAFのマネージドルールをうまく使っていくのがいいと思います。

厳格な通信制御というのは理想ではありますが、現実的ではありません。
設計ができるのか、設計から実装までの落とし込みができるのか、実装後の運用保守はどうするのか、すべてクリアにするのは中々大変なことです。
理想を求めて実装が遅れるよりも、まずはマネージドルールから始めていくのが大切なことだと感じます。

最近はALBやCloudfrontのコンソールからそれぞれに適したWAFをAWSが自動で設定してくれますのでうまくつかっていくといいでしょう。

最後になりますが、Shield Advancedを利用する場合でも最後に動くのはWAFであることに変わりはありません。
WAFを動かす場合は必ずCountモードで試してからBlockに切り替えるのを忘れないようにしてください。