AWS環境をDDoSから保護する

はじめに

近年、DDoS攻撃に関するニュースを見かける機会が多くなってきましたね。とりわけ、ウクライナ情勢もあいまってロシア系ハクティビストからのDDoS攻撃の矛先が日本にも向いているようです。(詳細は以下のトレンドマイクロの記事を参照ください。)

そこで今回は、AWSにおけるDDoS保護についてホワイトペーパーをもとに解説します。(最新のホワイトペーパーは英語版しかないようです。)

AWSにおけるDDoS保護とAWS Shield

AWSにおけるDDoS保護と聞いて最初に思いつくのは、みなさん大好き(？) AWS Shieldでしょう。特に何かの設定をせずとも自動でDDoSからの保護を提供してくれる素晴らしいサービスです。(資格試験でもよく出てきますよね。)

それでは、上司にアーキテクチャをレビューしてもらったとき、DDoSに対する対策は適切かと問われたときになんと答えますか？AWSではDDoS対策を自動で行うShieldがあるのでDDoSの心配はいりませんと答えてよいでしょうか？
これは必ずしも成り立つとは限らず、Shieldでは守り切れないこともあります。

DDoSは軽減はできても完全に防ぐことはできません。できる限り軽減し、回復力を高める、これがAWSにおけるDDoSからの保護です。

次節以降で攻撃の種類について触れ、緩和手法まで解説します。

ネットワーク層への攻撃

ホワイトペーパーではUDPリフレクション攻撃とSYNフラッド攻撃について触れられていますので、この2つについて解説します。(他にもオンプレミスで有名なものにDNSアンプ攻撃がありますが、AWSで話題になることが少ないのはRoute53という素晴らしいサービスがあるからでしょう。自前でDNSサーバを構築する場合は当然ながら保護する必要がありますのでお気を付けください。こちらの記事でGlobal AcceleratorとShield Advancedを利用したセルフホストのDNSサーバの保護方法について解説されています。)

UDPリフレクション攻撃

UDPリフレクション攻撃は、UDPがステートレスプロトコルであることを悪用した攻撃です。攻撃者はUDP要求パケットの送信元IPを攻撃対象のIPに偽装することで、応答パケットが攻撃対象のIPに送信されるように仕向けます。この時、中間サーバを介するのは攻撃トラフィックの量を増幅させるためです。UDPはプロトコルごとに増幅係数と呼ばれる、元の要求に対して何倍の応答が返るかという指標を持っています。(DNSでは28～54倍だそうです。)これにより、サーバの負荷を増大させることが可能です。

UDPリフレクション攻撃を示す図^※1

SYNフラッド攻撃

SYNフラッド攻撃は、TCPのスリーウェイハンドシェイクを狙う攻撃です。スリーウェイハンドシェイクではSYN→SYN+ACK→ACKという流れでハンドシェイクを完了しますが、攻撃者はハンドシェイクを完了させるためのACKを送信しません。これを大規模に行うことでハーフオープン状態のTCP接続を大量に生成し、新規の接続を妨害するのがSYNフラッド攻撃です。

スリーウェイハンドシェイクを示す図^※1

※1 ホワイトペーパーより引用

アプリケーション層への攻撃

ホワイトペーパーではHTTPフラッド攻撃、キャッシュ無効化攻撃およびWordPress XML-RPCフラッド攻撃について触れられていました。(WordPress XML-RPCフラッドは私も初めて知りました。)

HTTPフラッド攻撃

攻撃者がターゲットに大量のHTTPリクエスト（データ送信要求）を送り、サーバーやWebサイトを使えなくする攻撃のことです。(シンプルですね。)一部のHTTPフラッド攻撃は正規のHTTP要求を模倣することがあり、この場合リクエストレートの制限が難しくなります。

キャッシュ無効化攻撃

クエリ文字列^※3を利用してCDNを回避し、オリジンに負荷をかけようとする攻撃のことです。

WordPress XML-RPCフラッド攻撃

WordPressを狙ったDoS攻撃です。WordPressピンバックフラッド攻撃とも呼ばれます。サイトでXML-RPC^※4が有効になっていると、ハッカーはxmlrpc.phpを悪用して短時間で膨大な数のピンバックをサイトに送信することができ、アプリケーションに負荷をかけることが可能です。私も知らなかったですが、WordPressは攻撃の標的になりやすいようです。(WordPressをセルフホストしている方は気を付けましょう！)

※3 クエリ文字列：URLパラメータとも呼ばれる、サーバーに情報を送るためにURLの末尾につけ足す文字列（変数）のこと
※4 遠隔手続き呼出し (RPC) プロトコルの一種であり、エンコード（符号化）にXMLを採用し、転送機構にHTTPを採用しています。（出典：Wikipedia）

DDoS緩和のベストプラクティス

ここからは、具体的な緩和のベストプラクティスについて解説していきます。

インフラストラクチャ層の防御

EC2に関して、以下が推奨されています。

• 拡張ネットワーキングなどを利用し、より大きな帯域幅を確保する
• Amazon EC2 Dedicated Instanceを利用する
  オンプレミスではDDoSへの対策としてオーバープロビジョニングをしている例が大半だと思いますが、AWSでも同様ということですね。

オートスケーリングの利用

オートスケーリングもDDoS軽減のベストプラクティスの一つです。攻撃を受けて過剰な負荷がかかっても、自動で水平方向に拡張してくれるためです。オートスケーリングというとコスト面が注目されますが、DDoS対策の側面もあるのでこの考えは持っておくとよいと思います。

ELBの利用

Application Load Balancerは、SYNフラッドやUDPリフレクション攻撃などの一般的なDDoS攻撃をブロックし、アプリケーションを攻撃から保護することが可能です。(ALB自体も負荷に応じて自動で拡張します。)
一方、Network Load Balancerに関しては注意が必要です。Network Load Balancerは、有効なリスナーでLBに到達するトラフィックをそのままバックエンドにルーティングしてしまいます。NLBをDDoSから保護したい場合はAWS Shield Advancedで保護が可能です。(AdvancedによりElastic IPの保護が可能なため。)
ALBとNLBのどちらを選定するか、という選択基準としてDDoSからの保護も視点として持っておくとよいですね。

エッジロケーションの利用

以下に、AWSのDDoS耐性リファレンスアーキテクチャ^※5を転載します。

エッジロケーションとして、以下を利用することでDDoSの軽減が可能です。

• Amazon CloudFrontの利用(BP1)
  CloudFrontを利用することにより、SYNフラッドやUDPリフレクションなどのインフラストラクチャ層への攻撃はシャットアウトされます。(CloudFrontは整形式の接続のみを受け入れるためです。)
  また、HTTPフラッドなどのアプリケーション層への攻撃の際も、CloudFrontがキャッシュを持つためオリジンへ到達するトラフィックの量を軽減することが可能です。また、読み込みと書き込みが遅い攻撃者(Slowloris)などからの接続を自動で閉じる機能も有しているようです。
  さらに、ヘッダを使用してCloudFrontからのトラフィックのみがオリジンに到達するように構成可能です。アタックサーフェスを減らすことはあらゆる攻撃に極めて有用なので、これはぜひ実装を検討しましょう。

• AWS Global Acceleratorの利用(BP1)
  Global Acceleratorは、ユーザーに最も近いAWSリージョンにトラフィックをルーティングします。(判断基準はパフォーマンスです。)
  そのため、アプリケーションがあるリージョンでDDoSの被害に遭っても、Global Acceleratorのフェイルオーバー機能によって正常な他のリージョンに振り分けるような構成を実現可能です。また、正当なエンドユーザーのみにサービスを提供するステートレスSYNプロキシ機能などのShieldとの統合を使用して、アプリケーションを保護できます。詳細はこちら。

アプリケーション層の防御

Web Application FirewallはDDoSトラフィックにも有用です。さまざまなマネージドルールを利用できます。また、地理的制限を設定して選択した国からのリクエストをブロックまたは許可することもできます。(ユーザーにサービスを提供する予定のない地理的な場所からの攻撃をブロックするのに有用です。)

※5 ホワイトペーパーより引用

まとめ

本ブログでは、ホワイトペーパーをもとにDDoS攻撃の種類、DDoSの軽減手法について解説しました。
特に、Shield AdvancedがElastic IPを保護可能な点、Network Load BalancerがDDoSに対して本質的に脆弱な点は見落としがちなポイントかなと思います。
DDoS対策は、いかに悪意のあるトラフィックを遮断し、吸収し、捌き切るかというところにあります。DDoS耐性の高いアーキテクチャを構成していきましょう！