re:Invent 2023: AWSのDDoS対策最前線 - エッジサービスによる防御戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Safeguarding infrastructure from DDoS attacks with AWS edge services (NET201)
この動画では、AWSのDDoS対策の最前線について、Paul BodmerとTzoori Tamamが詳しく解説します。年間100万件以上のDDoS攻撃に対処するAWSの戦略や、HTTP/2 rapid reset脆弱性への対応など、最新の攻撃トレンドを学べます。また、AWS WAFやShield Advancedの具体的な設定方法や、プロキシを悪用した攻撃への対策など、実践的な防御テクニックも紹介されています。DDoS対策の最新動向を知りたいエンジニアにとって、見逃せない内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Paul BodmerとTzoori Tamamによる自己紹介とDDoS対策の概要
みなさん、こんにちは。Paul Bodmerです。本日はお越しいただき、ありがとうございます。私とTzoori Tamamで、DDoSの管理方法と、皆さんが活用できるサービスや機能についてご紹介します。 まず自己紹介ですが、私はperimeter protection organizationのShield Threat Research teamのマネージャーです。私のチームは、私たちのペリメーターに入ってくる脅威を理解し、それをインフラストラクチャの保護とより良い機能の構築に活用するための実用的なインテリジェンスに変換することに多くの労力を費やしています。
Tzoori、自己紹介をお願いできますか？
Tzoori Tamamと申します。私はEdgeサービス、具体的にはCloudFront、Edge、Shieldを扱うPrincipal Solutions Architect specialistです。偶然ですが、今日の話でこれらすべてに触れる予定です。
私たちは過去に多くの協力をしてきました。だから今日は同じ服を着ているんですよ。Tzooriは、お客様がサービスを導入する際のサポートに多くの時間を費やしてきました。 彼が話すのは、DDoSから身を守るために皆さんができることと、いくつかの例についてです。私は、現在の状況や私たちが見ている傾向について簡単に説明し、その後、インフラストラクチャの可用性を保護するために実装したメカニズムについて詳しく説明します。
DDoSイベントの現状と傾向：インフラストラクチャ層からアプリケーション層へ
これは200レベルの講演ですが、平均して200レベルだということを申し上げておきます。一部の内容は技術的で詳細に踏み込むかもしれませんが、他の部分はより高レベルな内容になります。楽しんでいただければと思います。では、私たちが見ている状況を見てみましょう。 このグラフは、私たちが検出し、緩和しているDDoSイベントの数を示しています。ご覧のように、ほぼ横ばいです。年々、大幅な増加は見られません。毎年約100万件のDDoSイベントが発生しており、100万件をわずかに下回っています。
しかし、これに惑わされてはいけません。DDoSは間違いなく今後も存在し続けます。なくなることはありませんし、この分野ではまだまだ多くのイノベーションが起きています。詳しく見ていくと、これらのDDoS攻撃を2つのグループに分けることができます。最初のグループはインフラストラクチャ層のイベントです。ここでは明らかな下降傾向が見られます。インフラストラクチャ層のイベントは長い間存在してきました。これらは最初に利用されたDDoSの種類で、通常は下位のネットワーク層プロトコルを悪用します。例えば、悪意のある攻撃者が大量のSYNパケットを送信して接続を確立し、リソースを圧迫するTCPや、UDPプロトコルを使用して送信元IPを偽装するUDPリフレクション攻撃などです。
これは今日ではあまり一般的ではなく、比較的簡単に解決できる問題です。私たちは長年にわたり、インフラストラクチャの可用性を維持するためにこれに取り組んできました。イノベーションが起きているのはアプリケーション層です。初めて、私たちが検出し緩和したDDoS攻撃の大半がこの層で発生しています。これが現在、DDoSが行われる最も一般的な方法となっています。アプリケーション層は、HTTP層またはWebトラフィック層とも言えます。これらの攻撃は、大量のWebリクエスト、つまりHTTPリクエストとして現れます。Webリクエストフラッドは、今年これまでに検出したDDoSイベントの56%を占めており、年間40%という急速な率で増加しています。
HTTP/2 rapid reset脆弱性：新たなDDoS攻撃ベクトル
ここで、この分野で私たちが目にしたいくつかのことについてお話ししたいと思います。これは私たちが研究し、情報を収集し、機能を構築するために時間とエネルギーを費やしている分野です。興味深い展開の1つは、Q3にCVEが公開されたことです。皆さんの中には、これに対処しなければならなかった方もいるかもしれません。これはHTTP/2 rapid reset脆弱性と呼ばれ、CVE-2023-44487として識別されています。私たちは1秒あたり1億5500万リクエストというピークを観測しました。
前回re:Inventの舞台に立ったとき、ピークは500万だと言ったと思いますが、今や1億5500万に達しています。これは新しいベクトルであり、HTTP/2プロトコルの悪用です。HTTP/2はHTTP/1に比べて多くの利点がありましたが、このタイプの脆弱性への扉を開いてしまいました。8月と9月にこれらの攻撃を目にしました。Amazon CloudFront上で運用していた私たちの顧客は、これらの攻撃から自動的に緩和され、保護されていました。しかし、これは非常に興味深いベクトルであり、少し時間を割いて議論したいと思います。
これは、このrapid reset脆弱性の仕組みを説明する簡単なグラフです。HTTP/1では、リクエストを送信してレスポンスを待つ必要があるHTTPセッションがありました。大量の計算能力があり、多くのソースに分散してWebリクエストを送信できれば、高いボリュームのリクエストフラッドを達成できました。多くのHTTPセッションを作成し、高いレートで送信する必要がありました。そのようにして、1秒あたり約500万リクエストに到達しました。しかし、HTTP/2では、リクエストをパイプライン化できるという利点があります。レスポンスを待つ必要がありません。1つのセッションで多くのリクエストを送信でき、より高いレートのHTTPリクエストを達成することができます。
これは明らかにDDoSの攻撃手法です。急速なリセットが興味深いのは、「リセット要求、リセット要求」と入力すると、受信側サーバーに多大な負荷がかかり、これらの接続とリセットをすべてログに記録するからです。クライアントは応答を待たずに要求を送り続けるため、非常に強力な攻撃手法となります。現在では、Amazon CloudFrontやその他のウェブアプリケーションレイヤーサービスで、このような攻撃に対する緩和策や保護機能が導入されています。
プロキシ悪用：DDoS攻撃の新たなトレンド
この攻撃手法は、私たちが「プロキシ悪用」と呼んでいるものも利用しています。私たちの情報によると、アプリケーションレイヤーでのDDoS攻撃の88%がプロキシを利用しているそうです。これは非常に興味深い分野です。インターネット上には多くのプロキシサーバーが存在します。プロキシサーバーとは、HTTPリクエストを受け取り、指定された場所に転送するサーバーのことです。大学のネットワークから外部にアクセスしたい学生や、本来閲覧してはいけないものを見たい場合に、トラフィックが監視されないようにプロキシを使用するのは賢い方法です。
インターネット上には数千のオープンプロキシがあり、認証なしで誰でも使用できます。善意でも悪意でも利用可能です。悪意のある攻撃者は、実際の発信元IPを隠蔽するためにこれらを使ってDDoS攻撃を仕掛けています。彼らはプロキシドライバーを構築します。これは基本的に、50行ほどのPythonコードを実行する大規模な計算機で、インターネット上の約1万のプロキシのリストに大量のリクエストを送信します。攻撃対象から見ると、プロキシのIPアドレスしか見えません。先ほど述べたように、アプリケーションレイヤー攻撃の88%がこの手法を利用しています。
これはボットネットとは明確に異なります。ボットネットの場合、侵害されたインスタンスにマルウェアやソフトウェアプログラムをインストールする必要があります。これらのインスタンスはコマンド＆コントロールサーバーによって制御され、攻撃者はコントロールサーバーからボットにコマンドを送信するだけで済みます。ボットももちろんHTTP攻撃を行えますが、私たちはボットネットとプロキシネットワークを別の問題として追跡していることを覚えておいてください。
AWSのグローバルネットワークにおけるDDoS対策の課題と戦略
さて、DDoSにどう対処するか掘り下げてみましょう。 まず、私たちが対処しなければならない規模は途方もないものです。50カ国以上に約600のポイントオブプレゼンスを持つグローバルネットワーク全体で、毎日何千ものDDoS攻撃を観測しています。これらの攻撃は絶え間なく発生しています。攻撃は様々な形式、方法、エンドポイント、そして世界中の様々な地域から来ています。このような状況は、DDoSへの対処方法について私たちに新たな発想を強いることになりました。
これが私たちのチームが存在する理由です。これが私たちのミッションです：私たちは、AWSをサイバー攻撃の魅力的なターゲットにしないことで、Amazonのインフラを保護することを目指しています。DDoSを完全になくすことはできないということに気づきました。DDoS攻撃を行う理由は少なくとも10種類はあり、DDoSは常に存在し続けるでしょう。しかし、私たちチームとしてやりたいのは、AWSをターゲットにしにくい場所にするための機能を構築することです。この点については、後ほど詳しくお話しします。
ここで難しいのは、単純なアプリケーションを保護するのではなく、先ほど見たような規模のグローバルインフラを保護することです。 もしこのようであれば完璧でしょう：アプリケーションへの入口が1つで、予想されるトラフィックを理解し、そのトラフィックの行き先を知り、必要な場所でスケールでき、監視と管理が比較的容易です。これが私たちの仕事で、これが私たちが保護しているものであれば、はるかに簡単でしょう。しかし、現実には、 私たちの仕事はそれよりも少し複雑です。
複数の入口があります。Amazon CloudFrontディストリビューションを通じて、AWS Global Acceleratorを通じて、インターネットに公開されているNetwork Load Balancerにトラフィックを送ることができます。衛星からも来る可能性があります。あらゆる場所から来る可能性があるのです。そして、これらの各入口をどのように保護し、どのトラフィックがDDoSで、どれがそうでないかを理解する必要があります。このトラフィックが取りうる経路は様々で、至る所に輻輳ポイントがあり、可用性を維持するためにはこれらを避けるよう努めなければなりません。これが、私たちが解決しようとしている問題がとても興味深い理由です。考慮すべき変数が非常に多いからです。
私たちはAWS Shieldをネットワークに統合することでこれを実現しています。ShieldはDDoS保護製品で、TzooriがShield Advancedと呼ばれる外部機能や外部サービスについて話す予定です。私たちの多くの仕事は、Elastic Load BalancingチームやAmazon CloudFront、AWS Global Acceleratorなどの他のサービスチームと協力し、それらのサービスに検出、緩和、学習機能を組み込むことです。これにより、どの入口からでも、主にNetFlowデータを使用して異常を監視できます。そのデータを使用して緩和策に変換し、トラフィックをブロックしたり、レート制限したり、スケールしたりして対処するシステムを所有しています。これが私たちのアプローチです。
AWSのデフォルトDDoS緩和策：CloudFrontとバックボーンネットワークの保護
DDoSへの対処戦略において非常に重要だと考える4つの主要な分野についてお話ししたいと思います。今週のJIGIの後で5つ目を追加すべきかもしれませんが、それは次の講演のためにとっておきましょう。まず、デフォルトの緩和策です。デフォルトの緩和策とは、常にオンになっている緩和策のことです。デフォルトで存在し、 サービスを使用しているだけで、デフォルトの緩和策の恩恵を受けています。例えば、Amazon CloudFrontを使用している場合、ウェブ関連以外のトラフィックは予想していませんよね？
そのため、CloudFrontを使用している場合、脅威の約44%がすぐに対処されます。インフラストラクチャ層に関連するイベントは、CloudFrontを使用していれば全て処理されます。なぜなら、予想されるトラフィックを把握し、悪意のあるものを排除できるからです。これにより、セキュリティ態勢が即座に改善されます。これが一つの緩和策です。もう一つは、AWSを装うものを全て排除することです。これはよく見られる現象です。「私はAWSです」と主張するトラフィックが我々のネットワークに入ってきますが、我々は「いいえ、AWSは我々です。あなたではありません」と言います。これらのパケットを識別して排除できます。なぜなら、ネットワークに入れてしまうとリフレクション攻撃と呼ばれるものが発生するからです。これは、トラフィックが入ってきて、エンドポイントで反射し、なりすまされた送信元に戻るというものです。この攻撃ベクトルは、境界ネットワークでこれらのACLやフィルタリングルールを実行することで、今では防御しています。
デフォルトで保護しているもう一つの領域はバックボーンネットワークです。バックボーンネットワークでは、DDoSシグネチャに一致するパケットを検出するデフォルトの緩和策を実施しています。これは主にインフラストラクチャ層のDDoSで、よく理解されており、検出が容易です。例えば、プロトコルと送信元ポートの組み合わせは、通常DDoSを識別する方法です。これらの緩和策をネットワークに配置することで、そのシグネチャに一致する大量のトラフィックスパイクがあれば、それらのパケットは即座に破棄され、正当なトラフィックのための容量が確保されます。最後に、デフォルトの緩和策の一環として、既知の攻撃者のレート制限を行っています。これは私のチームの成果であり、ネットワーク上の全てのDDoS攻撃から学んだ結果です。
アプリケーション層では、より興味深い対策を行っています。ここでは、トラフィックを送信する送信元を追跡します。これらの送信元の大部分はプロキシで、攻撃の88%がプロキシから来ています。悪用されているプロキシを追跡し、Amazon CloudFront POPとAWS Global Acceleratorホストに既知の攻撃者緩和策を適用します。つまり、悪意があると分かっているものは、これらのサービスを使用していれば自動的に保護されるということです。
プロトコル認識型の緩和策：TCPとDNSの保護メカニズム
次に、プロトコル認識型の緩和策があります。ここでは、これらのプロトコルがどのように機能するかを理解し、 悪用を防ぐ機能を構築しています。TCPの場合、インテリジェントなTCP制御を構築しており、SYNプロキシと呼ばれる機能も含まれています。この内部機能はTCP接続を処理し、特にSYNフラッドを防ぐように設計されています。SYNフラッドは、悪意のある攻撃者が大量のSYNパケット（TCPハンドシェイクプロセスの一部）を送信する攻撃です。我々のSYNプロキシ技術は、サービスとアプリケーションに代わってこのハンドシェイクを管理します。
接続が確立されると、ウェブリクエストを受信するためにバックエンドに送信されます。 これは特に、悪意のある攻撃者がこのプロセスを悪用するのを防ぐように設計されています。攻撃者はSYNパケットを送信するだけで、我々はSYN-ACKで応答しますが、 攻撃者は応答しません。SYNプロキシがなければ、アプリケーションリソースがこれらのSYNパケットすべてを処理しなければなりません。Edge サービスを使用する利点は、Amazon CloudFrontとAWS Global Accelerator上のSYNプロキシ技術が、この攻撃ベクトルを完全に管理してくれることです。
Amazon Route 53のDNS側では、パケットの優先度管理テクニックを使用しています。P0（最重要）からP7（最低重要）までの8つのバケットがあります。トラフィックが入ってくると、それに応じて優先順位をつけます。紫色の線は、ポップが処理できる総容量を表しています。トラフィックが総容量を下回っている場合、何も落とすことなくバケット間で分散されます。しかし、そのポップで処理できる量を超えるトラフィックがある場合、優先度の低いバケットのパケットを後回しにして、より重要なトラフィックを確実に通過させます。
これは、疑わしさのスコアリングと組み合わせると非常に効果的です。キャッシュポイズニング攻撃のように見えるパケットにスコアをつけ、優先度の低いバケットに入れて簡単に落とすことができるのです。これが、Amazon Route 53のポップの容量と可用性を管理する方法です。
AWSネットワーク内部からのDDoSと不正利用への対策
よくお客様から聞かれる質問の1つに、AWSネットワーク内部からのDDoSや不正利用についてがあります。これは実際に起こっており、私たちはそれに対処するための対策を講じています。
これは確かに起こります。そして、私はここに立って、AWSネットワーク上に悪いものは何もないと嘘をつくつもりはありません。なぜなら、時にはお客様のインスタンスが安全でなく、適切なセキュリティポリシーが前面にないことがあります。パッチが当たっていないソフトウェアを実行していて脆弱なため、悪意のある人々がそれらをボットに変えてしまうのです。
そして、このような状況に陥ります。悪意のある人物が、私たちのネットワークの外部と内部のインフラを侵害してボットネットを構築しているのです。この場合、私たちのネットワーク上のエンドポイントである被害者を標的としたDDoS攻撃が見られますが、そのエンドポイントに向かうトラフィックは、私たちの境界の外部からも内部からも来ています。AWS Shieldを通じて入ってくるトラフィックを保護するためのテクニックについてはすでに言及しましたが、私たちのネットワーク上で実行されているインスタンスやコンピューティング能力のトラフィックヒューリスティクスに対するモニタリングも行っています。
私たちは自動的に不正利用を検知し、そのインスタンスを隔離することができます。具体的には、不正利用されているポートからのトラフィックを自動的にブロックし、インバウンドSSHのみを許可します。これにより、Trust and Safety部門がお客様に連絡を取り、「インスタンスで不正な動作が検出されました。原因を特定して解決しましょう」と協力して対応し、その後隔離を解除することができます。この自動不正利用緩和は、DDoS対策の一環です。不正利用を素早く検知すればするほど、インスタンスの復旧を迅速に支援でき、ネットワークの可用性をより早く回復できます。
非常に効果的だと分かった手法の1つが、ボットネットの妨害です。これは先ほど言及した、AWSを魅力的でないターゲットにするという私たちのミッションの一環です。ボットネットを発見したら、ボットからコマンド＆コントロール（C2）サーバーまでのトラフィックを追跡できます。C2サーバーの場所が分かれば、East-Westトラフィック（AWSからAWSへのトラフィック）を止める非常に簡単な方法は、ネットワーク上のボットがC2と通信できないようにすることです。
ボットがC2と通信できなければ、攻撃命令を受け取ることができず、攻撃に参加できません。私たちはネットワーク層で、そのC2からのトラフィックをブラックホール化する緩和策を講じます。つまり、あるリージョンのEC2上で侵害されたボットが動作していても、攻撃命令を受け取ることができず、攻撃に参加できないのです。被害者がAWS上にいない場合でも、ボットネットの一部を妨害できます。これは、AWSをボットネットのインフラとして使用すると、C2の場所を追跡して特定できるため、魅力的でない場所にしているということです。
ボットネット対策：C2サーバーの追跡とテイクダウン
私たちは外部の企業と協力して、テイクダウン要請を行います。テイクダウン要請とは、セキュリティエンジニアが悪意のある人物のドアをノックダウンして「やった！」というようなものではありません。これは、ISPやドメインレジストラに不正利用を報告し、「このIPアドレスから不正利用が確認されました。ここにデータがあります。テイクダウンをお願いします」と伝えることです。これは非常に効果的であることが分かっています。例えば、C2をテイクダウンする場合、他のホスティングプロバイダーと協力します。私たちのネットワークでは自動的に行っていますが、これは外部のプロバイダーと協力して「こちらがデータです」と伝えるのです。
彼らがC2をテイクダウンすると、悪意のある人物は別の場所でインフラを再構築せざるを得なくなります。これにより、コストと障壁が上がります。
これをさらに効果的に行う方法は、ドメイン名を使用するボットネットをターゲットにすることです。これらのボットネットは、コマンド＆コントロールサーバーのIPアドレスではなくドメインを参照することで耐障害性を構築しています。これにより、ボットネットは複数のサーバーに解決でき、1つのサーバーがダウンしても耐性を持たせることができます。ドメイン名の登録を解除することで、ボットネット全体を使用不能にし、悪意のある者に再度インスタンスを侵害して別のドメインを指すようにコードを更新させることができます。これは彼らにとって大きなコストとなります。
私たちはしばらくの間これを行ってきました。 最近、このことでニュースになりました。オンラインで見つけられる記事では、私たちのインテリジェンスがインフラストラクチャを削除することでインターネットをクリーンアップする能力をサポートしていることについて述べています。また、Mad Potというサービスについても言及されています。これは、この能力を提供するハニーポットのネットワークです。 例えば、先ほどのプロキシベースのインフラストラクチャを覚えていますか？私たちには、プロキシのふりをするハニーポットがあります。 これにより、プロキシ攻撃が発生したときに中間者になることができます。世界をより悪くしたくないので、トラフィックを転送はしませんが、これによってこれらのプロキシドライバーがどこにあるかを知ることができ、それらも削除することができます。
DDoS保護における共有責任モデルとWell-Architectedアプリケーションの重要性
つまり、私たちはプロキシとボットネットの悪意のある者を妨害しているのです。 これらのハニーポットを使用して観察したプロキシに関する興味深い統計があります。この例では、1日に400回以上の攻撃を送信していたプロキシドライバーを示しています。これは驚くべきことです。私たちがそれを削除すると、攻撃が徐々に消えていくのが分かります。私たちはこれを至る所で行っており、多くのISPと密接に協力しています。 これらは、プロキシドライバーをホストしているのを見たISPの一部で、彼らは私たちのパートナーです。この取り組みで大きな成功を収めており、もしあなたがこれらのISPの1つで働いているなら、ぜひお話ししたいと思います。悪意のあるインフラストラクチャを妨害するために、より密接に協力したいと考えているからです。
さて、これが私たちのインフラストラクチャを保護する方法です。ここでTzooriに引き継ぎます。彼が責任の共有について説明します。
ありがとう、Paul。Paulは、AWSで自社のワークロードを実行する際に得られるすべてのメリットと、皆さんが知らないうちに、また何もしなくても、DDoS攻撃からどのように保護されているかについて説明しました。しかし、すべてのセキュリティの話と同様に、セキュリティは共有責任です。つまり、DDoS保護も共有責任なのです。AWSがアプリケーションと使用しているインフラストラクチャを保護するために行うことに加えて、今後のDDoS攻撃に対して耐性を持つことを確実にするために、いくつかのことを行う必要があります。これらの攻撃はインターネットの現実であり、いつかは誰にでも起こり得ることです。
「Fight Club」と同じように、DDoS攻撃に対して回復力を持つ、あるいは自己防衛する準備をするための第一のルールは、適切なアーキテクチャを持つことです。Well-Architectedレビューにより、アプリケーションが無期限ではありませんが、ある程度までスケールイベントに耐えられるように構築されていることを確認できます。優れた回復力のあるアーキテクチャは、アプリケーションとインフラストラクチャを適切な方法で構築することから始まります。これはセキュリティに特化したものではありませんが、Well-Architectedアプリケーションとは何かを理解する必要があります。Well-Architectedプログラムをご存じない方は、QRコードをご覧ください。これは基本的に、ルールに従っているか、少なくともあなたが従っていないルールを認識し、それらを修正するためのバックログアイテムを作成できるようにするものです。
アプリケーションが適切にモニタリングされ、スケーラブルで自動化されていることを確認してください。Auto Scalingやサーバーレスコンポーネントを使用して、自動的にスケールアウトするようにしましょう。もちろん、セキュアにすることも重要です。これから、さまざまなタイプのアプリケーションやアーキテクチャにおいて、それが何を意味するのかについて詳しく見ていきます。
異なるアプリケーションアーキテクチャにおけるDDoS保護戦略
アーキテクチャについて話す際、異なるタイプのアプリケーションがあり、これらさまざまなタイプのアプリケーションを保護するためにできることも異なります。ここでは、4つの異なるアーキテクチャ、4つの異なるタイプのアプリケーションに焦点を当てていきます。
まず、オンプレミスで使用しているアプリケーションについて話しましょう。すべての顧客が完全にAWS上で運用しているわけではなく、一部にはまだオンプレミスで運用しているアプリケーションがあります。ここで、Amazon CloudFront（私たちのCDNサービス）がリバースプロキシサービスであり、機能的にはアプリケーションがどこにあるかを気にしないということを思い出すのに良いタイミングです。 まだHTTPベースのアプリケーションやAPI、HTTP通信を扱うウェブアプリケーションをAWS以外のどこかでホストしている場合、これらのアプリケーションを保護するための良い出発点は、CloudFrontをその前に配置することです。
トラフィックをCloudFrontに引き寄せることで、前述の良い点すべてのメリットを得られるだけでなく、後ほど説明するAWS Shield AdvancedやAWS WAFなどの追加のコントロールを有効にすることができます。これはアプリケーションがどこにあるかに関係なく可能です。つまり、アプリケーションがオンプレミス、他のクラウドベンダー、またはホスティングプロバイダーで動作している場合でも、CloudFrontを使用してこれらのアプリケーションを保護できます。もちろん、AWS上で動作している場合は、さらに多くのことができますが、それについては後ほど詳しく説明します。
サーバーレスアプリケーションについて話すとき、これらのアプリケーションは通常、何らかのAPIサービスを使用します。自作のイングレスAPIかもしれませんし、リスナーを実行しているApplication Load Balancerかもしれませんが、サーバーレスアプリケーションに特化して言えば、Amazon API GatewayとAWS AppSyncが見られます。これらは両方ともAWS WAFを搭載でき、WAFで受信トラフィックを保護できます。インフラ部分はサーバーレスコンポーネントを使用する本来の目的通りに管理されていますが、セキュリティ部分は依然としてあなたの責任です。
API Gatewayについてよくご存知の方は、エッジ最適化方式で実行できることをご存知でしょう。つまり、内部的にCloudFrontを使用しているということです。エッジ最適化されたAPI GatewayにWAFを有効にすると、WAFはリージョンで適用されます。DDoSを念頭に置いていて、Edgeサービスがもたらすすべての利点を活用したい場合は、API Gateway上に独自のCloudFrontディストリビューションを有効にできます。そうすれば、WAFの配置場所を制御でき、WAF Web ACLをCloudFrontとAPI Gatewayの両方に、あるいは必要に応じてCloudFrontのみに割り当てることができます。ほとんどのお客様は、CloudFront上でWAFを管理するだけで十分でしょう。
非HTTPトラフィックについては、HTTPを使用せずCloudFrontの恩恵を受けられないアプリケーションもまだあります。CloudFrontは厳密にHTTPリバースプロキシですが、非HTTPトラフィックを扱えるEdgeサービスもあります。具体的には、AWS Global Acceleratorがあります。Global Acceleratorはエッジで実行され、前述のネットワーキングメカニズムを通じてトラフィックを受信し、レイヤー3とレイヤー4でトラフィックを転送します。つまり、Global AcceleratorではTCPレベルで処理を行います。独自の非HTTPプロトコルをリッスンするNetwork Load Balancer上の弾力的IPを通じてアプリケーションが公開されている場合でも、DDoS緩和に関していくつかのベクトルに対してGlobal Acceleratorの保護を受けることができます。
最後に、AWSでWebアプリケーションを実行している場合、これは典型的なユースケースです。常に、必ずアプリケーションをCloudFrontの背後で実行してください。それによってアプリケーションは高速化され、データ転送アウトのコストが低下し、さらに安全になります。CloudFrontなしでWebアプリケーションを公開する理由はほとんどありません。AWSでWebアプリケーションを実行している場合は、ほぼ常にCloudFrontを使用してそのアプリケーションを隠すべきです。高速化とコスト削減以外にも、なぜそれが理にかなっているのか、簡単な例を挙げてみましょう。
Paulが言及したように、CloudFrontは有効なHTTPリクエストのようなWebトラフィックのみを処理します。そのため、DDoS攻撃の約44%を占めるインターネットのランダムなノイズ、例えばSYNフラッドやTCPフラッド、ポートスキャン、IPスキャンなどについて、完全に気にする必要がなくなります。そういったトラフィックパターンはもう見られなくなります。さらに、たまたまCloudFrontに属するランダムなIPアドレスを対象とするトラフィックでも、ホストヘッダーにあなたのホスト名やアプリケーション名が含まれていない場合、そのリクエストはあなたのCloudFrontディストリビューションに転送されることすらありません。
簡単な実験をしてみることができます。VPCにApplication Load Balancerを立ち上げ、そこにWAFを設置してログを確認してみるのです。すると、ホストヘッダーにIPアドレスを送信する大量のトラフィックが見えるはずです。これは、インターネットの特性によるものです。あなたのサーバーは見つけられ、スキャンされ、脆弱性があれば攻撃されるでしょう。CloudFrontを使用すると、このようなインターネット上のランダムなIPアドレススキャンがフィルタリングされます。CloudFrontは、ホストヘッダーにあなたのアプリケーション名を含む有効なHTTPリクエストのみを処理し、あなたのアプリケーションに関連付けます。その上でWAFを有効にし、さらにアプリケーションを保護するための設定を行うことができます。この講演で一つだけ覚えておいてほしいことがあるとすれば、それはCloudFrontを使うということです。
AWS WAFとShield Advancedの機能と利点
さて、これまで言及してきた二つのサービス、WAFとShieldについてもう少し詳しく見ていきましょう。まずはWAFから始めます。 AWS WAFはアドオンサービスです。他のサービスの上に追加するものです。現在、WAFを有効にできるサービスは7つあり、基本的に下層のサービスの属性として機能します。CloudFrontディストリビューション、ALB、API Gateway、AppSync、またはここに挙げられているサービスのいずれかをお使いの場合、WAFポリシーであるウェブACLをこれらのサービスに付加するだけです。レイテンシーはほとんど追加されません。通常、WAFを追加しても一桁ミリ秒のレイテンシー増加と言われており、ほとんど測定できないレベルです。ネットワークの複雑さも増しません。ホップを追加したり、TLS証明書をインストールしたりする必要はなく、すでにトラフィックを処理しているサービスで有効にするだけです。非常に簡単なのです。
WAFは何をするのでしょうか？AWS WAFはルールのリストです。マネージドルールもあれば、カスタムルールもあります。これらについては後ほど詳しく説明します。リクエストが来ると、ウェブACLに到達し、ウェブACLにはルールのリストがあり、それらは順番に処理されます。例えば、IPアドレスに基づいてトラフィックを許可する特定のルールがある場合、そのリクエストに対しては他のルールは関係ありません。 終了ルール（許可、ブロック、その他）にヒットすると、そのリクエストに対する決定が下され、ドロップされるか通過が許可されます。ウェブACLには複数のルールを設定できます。ルールはゼロでも、必要に応じて多数設定することもできます。これらのルールにはそれぞれ特定のマッチ条件があります。送信元の国やIPアドレスのような単純なマッチ条件もあれば、リクエストのJSONボディ内の特定の要素の値のような非常に複雑なマッチ条件もあります。また、これらの条件の組み合わせも可能です。
WAFルールは、必要に応じて複雑にも単純にもできます。これらのルールの中には管理されているものもあり、後ほど説明します。WAFルールは複数の方法で追跡されます。CloudWatchメトリクスのブリップを作成します。特定のルールにヒットするたびに、CloudWatchマップにプラス1が記録され、ウェブACL内の特定のルールにいくつのリクエストがヒットしたかがわかります。また、WAFロギングを有効にすると、リクエストに関連するすべての情報がログに記録されます。リクエストの内容、リクエストの属性、AWS WAFの処理中にどのようなルールにマッチしたか、終了アクション（リクエストの処理方法を決定したアクション）は何だったかなどが記録されます。ルールごとに、そのルールのマッチ結果として単一のアクションを設定できます。明示的な許可（マッチした場合、リクエストを許可し、処理を停止）、ブロック（マッチした場合、ブロック）、カウント（リクエストに特別な処理を行わず、後の使用のためにフラグを立てる）などがあります。
また、リクエストを処理する際に、ウェブACL内の他のルールが対応できるようにラベル付けすることもできます。これらのラベルについては、実際のWAFポリシーのデモンストレーションを行う際に後ほど説明します。アクティブチャレンジを行うこともできます。JavaScriptチャレンジやCAPTCHAチャレンジを使って、入ってくるリクエストに積極的にチャレンジすることができます。
JavaScriptチャレンジは、ブラウザに送信される静かな中間チャレンジです。本物のブラウザであれば、それを解決してトークンを返し、アクセスが許可されます。一方、ボット、特にDDoSボットは、レスポンスを見たり、チャレンジを気にしたりしません。通常、JavaScriptを実行する方法を知りません。そのため、アクティブチャレンジは一般的にDDoS攻撃を防ぐことができますが、もっと良い方法があります。後ほどそれについて説明します。これは使用できるもう一つの対策です。
CAPTCHAは、どれだけ人間らしいかをテストします。WAFには組み込みのCAPTCHAメカニズムがあり、不審なトラフィックが実際の人間によるものかどうかを判断するのに使用できます。これらの種類のコントロールもDDoS攻撃の緩和に使用できますが、DDoS攻撃を緩和するにはもっと簡単な方法があります。これがAWS WAFの基本的な説明です。Paulが言及したように、この講演は平均して200レベルの内容ですが、今の説明は100から150レベルくらいでした。
さらに詳しく見ていくと、マネージドルールについて話すと、これらはAWS WAF Web ACLに実装できるルールですが、誰か他の人が管理しています。これらのルールのほとんどはAWSマネージドルールで、その大半は無料です。どのルールを追加するかを選ぶだけです。DDoSに関して具体的に言えば、IPベースのルールがあります。IP評価や匿名プロキシなどで、これらはPaulのチームの仲間が提供するリストを使用しています。悪意のある既知のIPをブロックするか、チャレンジを出すか、レート制限をかけるかを決めることができます。
しかし、WAFはWAFなので、WAFベースのルールも使用できます。Log4j、SQLインジェクション、クロスサイトスクリプティングなどのアプリケーションの脆弱性に対するルールです。ただし、この講演はDDoSについてです。マネージドルールの中には有料のものもあります。この講演に特に関連するのはボットコントロールルールで、これは受信トラフィックのさまざまな種類の行動異常を追跡します。送信元IPやユーザーエージェントのような非常に単純なものから、このセッションからのリクエストが通常のセッションからのすべての他のリクエストとどれほど異なるかといった非常に複雑なものまであります。
これは非常に複雑な一連のコントロールとルールです。DDoSのリスクを軽減するために、これを有効にすることもできます。これがボットコントロールです。また、Web ACLに追加できるパートナールールもあります。パートナーが提供する、彼らが精選し、研究し、作成したIPやセキュリティルールを簡単に実装できます。チェックボックスをクリックするだけでWeb ACLに追加できます。そうすることで、私たち独自のIPインテリジェンスルールセットと、必要であれば別のベンダーのものも利用できます。
カスタムルールに関しては、先ほど述べたように、ほぼどのような条件でもマッチングを設定できます。マッチしたら、そのトラフィックをどう扱うかを決めます。許可、ブロック、カウント、チャレンジ、またはCAPTCHAなどです。リクエストを強化することもできます。これらのリクエストの扱いが不確かで、ソフトなルールを作りたい場合は、マッチ時に単にカウントするだけでなく、カスタムヘッダーをリクエストに追加して、下流のアプリケーションが対応できるようにすることもできます。
アプリケーションに独自のロジックを組み込んで、「これは悪意のあるIP、少なくともそう思われるIPだ。アプリケーションレベルで何か対策を。チェックアウトやサインアップを許可しないで」というようなことができます。そして、カスタムルールのサブセットとして、レートベースのルールも設定できます。これは基本的に同じことをしますが、特定の基準や一連の基準に基づいてマッチングを行い、特定の属性から一定量のリクエストが集計された後にのみ実行されます。つまり、単一のIPから特定の基準に合致するX回以上のリクエストが過去5分間に行われた場合に、アクションを起こすのです。アクションとは、ブロック、チャレンジ、カウント、またはCAPTCHAを指します。
また、IP以外のキーに基づくレートベースのルールも作成できます。これは、IPごとにカウントするのではなく、フットプリント全体でどれだけのPOSTメッセージを受け取っているかをカウントするということです。例えば、アプリケーションに対して5,000回のPOSTメッセージしか許可しないようにすることができます。それ以上だとデータベースがダウンしてしまうことがわかっているからです。つまり、IP以外のキーに基づくレートベースのルールを使って、他の要素もカウントできるのです。カウントできる要素の1つに、特定のラベルが付けられた進行中または過去5分間のリクエスト数があります。先ほど言及したこれらのラベルについて覚えていますか？DDoSに対する適切なWAFポリシーを設定する際に、このラベルの効果が見られます。
マネージドルールが発行したラベル、具体的にはIP評価ルールを使用します。悪意のあるIPからのリクエストがX回を超えたら、悪意のあるIPのブロックを開始するというものです。それまでは単なる小規模な攻撃で、インターネットのノイズのようなものなので気にしません。最近導入されたもう1つの機能として、使いやすい組み込みのWAFダッシュボードがあります。これは2、3週間前くらいだったと思います。これはCloudFrontに直接組み込まれています。CloudFrontには新しいセキュリティタブもあり、CloudFrontコンソール内からWAFを有効にすることができます。CloudFrontコンソール内からロギングを有効にすることもできます。非常に簡単で、ワンクリックとは言えませんが、おそらく3クリックくらいのソリューションです。
この新しいソリューションの一部が組み込みダッシュボードです。このダッシュボードには、トップIP、トップ国、トップURI、トップマッチングルールなど、WAFの使用を開始する際に知っておくべき自動メトリクスが表示されるので、設定を調整できます。また、これらの高度なWAF機能を使用している場合は、不正行為やボット制御に特化したダッシュボードも提供されます。リクエストのうちボットリクエストがどれくらいあったか、チャレンジやCAPTCHAが成功したリクエストがどれくらいあったかなどを確認できます。これらはすべて組み込みダッシュボードに表示されます。先ほど述べたように、WAFログを使用して好きなダッシュボードを自作することもできますが、これらの組み込みダッシュボードは始めるのに最適な場所です。
WAFとShieldを活用したDDoS対策のベストプラクティスと実装例
WAFの実際のスクリーンショットに移る前に、DDoS特有のサービスについて簡単にお話ししましょう。DDoS攻撃によるダウンタイムの影響を理解しているお客様向けに、Shield Advancedというプレミアムサブスクリプションを提供しています。これには多くの利点があります。例えば、攻撃のターゲットになった場合や、身代金要求を受けた場合、あるいは事後や進行中に何が起こったのかを知りたい場合に、Shield Response Teamの専門家に直接連絡を取ることができます。彼らは状況を理解するのを助け、設定に変更が必要な場合は、お客様と一緒に、あるいはお客様に代わって対応します。
Shield Advancedはコスト保護も提供します。DDoS攻撃を受けた場合、コストが発生する可能性があります。ログが増えたり、データ転送量が増えたり、インスタンスをスケールアップしたり、WAFのヒット数が増えたりする可能性があります。これらのコストは全て、Shield Advancedのお客様には保険がかけられており、攻撃後に払い戻しを受けることができます。Shield Advancedのお客様が得られる重要な機能の1つが、レイヤー7の自動緩和ルールです。これは基本的に、チェックボックスにチェックを入れるだけで、Shield Advancedがトラフィックのベースラインを取得し、DDoS攻撃と識別された実際の攻撃を検出した場合、悪意のある incoming traffic にのみ関連するパラメータを見つけ出そうとします。
例えば、今日の午前9時に、過去30日間で一度も見たことがない100万のリクエストを突然受け取ったとします。これらは、リファラーヘッダーがないとか、特定の奇妙なURIにヒットしているなど、これまでと異なるリクエストパターンです。Shield Advancedは、これらの攻撃パターンをブロックするルールを自動的にWAFに追加します。そのため、100万のIPアドレスがそれぞれ5つのリクエストを送信するような超分散型の攻撃であっても、レート制限では効果的にブロックできないケースでも、これらのリクエストがShield Advancedが検出した攻撃パターンに一致する場合、最初のリクエストからブロックされます。Shield Advancedのお客様は、これをウェブアプリケーション用に有効にすることができます。そして、WAFとShieldが相互に通信を行い、WAFが通常のトラフィックの指標とテレメトリを提供し、ShieldがDDoS攻撃が発生した場合に更新を提供します。
実際のUIに入る前に、いくつかのベストプラクティスを見ていきましょう。AWS WAFについて、知っておくべき重要なマネージドルールの1つはIP評価ルールです。私たちが見ているDDoS攻撃では、悪意のあるトラフィックの95-98%がこのIP評価ルールにマッチしています。これは悪意のあるトラフィックを識別する非常に効果的な方法で、ブロックするかフラグを立てるかを選択できますが、少なくともその存在を把握することができます。
Web ACLで1つのルールしか管理できない場合、レートベースのルールかIP評価ルールのどちらかを選択する必要がありますが、どちらのルールも非常に効果的です。2つ目のベストプラクティスは、レートベースのルールです。これは実装が簡単です。単一のIPが5分間に送信できる合理的なリクエスト数、例えば1000リクエストを設定します。IPがこの制限を超えると、ブロックされるかチャレンジされます。アプリケーションが地理的に特定の地域に限定されている場合は、地理ベースの制御を使用して、世界中からの悪意のあるトラフィックのリスクを軽減します。特定の市場エリア以外からのリクエストに対してチャレンジを行うことを選択できます。
Shield Advancedには、プロアクティブエンゲージメントという機能があります。これにより、AWS Shield Response Team（SRT）があなたのアプリケーションの健全性に影響を与える攻撃を検出した際に、警告を発することができます。この機能を利用するにはヘルスチェックの設定が必要ですが、非常に便利な機能です。アプリケーションとそのセキュリティ状態を監視する追加の目を提供してくれます。Shield Advancedを使用する場合は、実際のヘルスチェックを使用し、レイヤー7の自動緩和を有効にする必要があります。
次のスライドでは、WAFルールを使用して、incoming DDoSリクエストを緩和または防御する階層的なアプローチを見ていきます。これはWAFの実際のスクリーンショットで、WAFルールのリストです。各ルールには名前があり、一部は管理ルールで、それぞれにアクションが設定されています。 最初の数個のルールはとてもシンプルです。まず、許可されたIPのリストがあり、これは私の企業ネットワークです。企業の従業員を信頼している場合、特にQA担当者やペネトレーションテスターであれば、彼らが決してブロックされないように明示的に許可したいでしょう。これは完全に信頼できるIPアドレスのシンプルなリストです。
次に、ブロックされたIPのリストがあります。これらは、アプリケーションログの過去の分析から悪意があると判断されたIPで、許可しないものです。自分でリストを管理することもできますし、APIコールを通じて自動的に更新することもできます。国についても同様です。禁輸対象国がある場合や、特定の国からのトラフィックのみを提供する場合、ブロックリストまたは許可リストを設定できます。攻撃時に国をブロックし始めたい場合に備えて、空のリストを用意しておくこともできます。
次のルールセットは管理ルールです。これらは2つのIPベースのルールです。IP評価ルールには、悪意のあるIPのカテゴリがいくつか含まれています。そのうちの1つは特にIP DDoSと名付けられています。これは、攻撃時によく使用されるプロキシを含むため、カウントに設定されています。常に悪意のあるトラフィックを送信しているわけではないため、このカテゴリはカウントに設定されていますが、DDoS時に適切に使用する方法について説明していきます。もう1つのルールである匿名IPには、匿名IPやデータセンター、ホスティングプロバイダーのリストが含まれています。すべてが悪意あるものではありませんが、国内以外のIPからのトラフィックの増加を識別するのに役立ちます。
次の2つのルールは、悪意のあるボットと良性のボットの両方を管理するために特別に設計されています。
DDoSを考える際にこれを使う必要はありませんが、洗練された、あるいは洗練されていないボットからの低速で持続的な攻撃に対して、きめ細かな制御を行うには良い方法です。これら2つのルールにより、よく知られた、あるいは疑わしい非人間的なアクターをブロックしたり、検証済みの信頼できるボットを保護したりすることができます。2番目のルールは、特に検索エンジンやソーシャルメディアのボットなどの信頼できるボットを識別し、常に許可して、後続の3つのレートベースのルールによってブロックされないようにします。そして、これら3つのレートベースのルールは、それぞれ異なることを行っています。
最初のレートベースのルールは、匿名IPからの一定量のトラフィックが確認された場合にのみ、すべての匿名IPにCAPTCHAチャレンジを送信します。これらのレートベースのルールは、IPだけでなくラベルに基づいてマッチングできることを覚えておいてください。 そのため、匿名IPリストを使用して、TOR出口ノード、データセンター、ホスティングプロバイダーからのすべての受信リクエストにフラグを立てることができます。ブロックしているわけではなく、単にフラグを立てているだけです。しかし、3つのルールの最初のものは、例えば、ホスティングプロバイダーから10,000件のリクエストが来ているのを見たら、これは異常な数字なので、これらのIPアドレスから来るすべてのセッションをキャプチャし始めたいということを示しています。これはレートベースのルールの単純な使用例の1つです。これらのスライドの後に、さらに詳しく掘り下げるためのリンクをいくつか紹介します。
次のルールは基本的にブロックを開始します。これはCAPTCHAルールではなく、悪評のあるIP評価を持つすべての受信IPアドレスをブロックするルールです。そして、その特定のルールをダブルクリックして、どのように見えるかをお見せしたいと思います。ルールがあり、それはレートベースのルールです。ラジオボタンがレートベースのルールにフラグが立っているのがわかります。具体的には、3,000に設定しています。つまり、IP評価としてラベル付けされたすべてのIPからの3,000件のリクエストまでカウントしています。ここでカスタムキーを使用しているのがわかります。IP評価ラベルの名前空間を使用していますそして、アクションをブロックに設定しています。その特定のラベル名前空間にはいくつかのラベルタイプがあります。そのため、ブロッキングルールの範囲を絞り込んで、IP DDoSと呼ばれるラベルのみを含めることもできます。他のラベルはその特定のレート制限ルールにマッチさせるために使用しません。
基本的に、これにより「悪評のあるIP評価のリクエストを、全体のリクエスト数が一定の数を超えない限りブロックしたくない」というパニックレベルを設定できます。これはShield Advancedダッシュボードのスクリーンショットです。CloudFront distributionの保護以外にもできることがあるのがわかります。 Route 53ゾーンを作成して保護したり、Elastic IP、ロードバランサーを保護したりできますが、ALBやCloudFrontなどのアプリケーション対応のレイヤー7対応サービスの場合は、Web ACLも関連付けます。これはWAFとShieldを一緒に使用することの利点の一部です。
そうすると、先ほど話した層7の自動緩和を有効にすることができます。基本的に、Shield Advancedが攻撃中に自動的にWAFルールを作成することを許可します。 攻撃が収まると、これらのルールは数時間後に削除されますが、攻撃中は、既知の攻撃パターンに自動的にマッチしてブロックするルールがWAFポリシーに作成されます。これを行うと、Web ACLに長い醜い名前の新しいルールが追加されます。これがShield Advancedが管理するマネージドルールです。 現在、攻撃を受けていない状態では、レートベースのブロッキングレートで層7の既知の攻撃者リストのみが含まれています。つまり、これは粗い粒度の制御ですが、攻撃中にはマッチングできるより多くのルールが追加されます。
最後に、リンクをお見せする前に、これらの機能、つまりShieldとWAFを組織全体で一元的に制御できることをお伝えします。複数のアカウントや各アカウントに複数のリソースがある場合、Firewall Managerと呼ばれる単一のポイントですべてを制御できます。ShieldとWAFを有効にし、特定のルールをすべての保護対象リソース、つまりすべてのCloudFrontディストリビューションやALBに送信することができます。そして、誰かが新しいCloudFrontディストリビューションや新しいALBをスピンアップするたびに、設定したデフォルトのWAFポリシーが自動的に適用されるため、誤って露出することがありません。
そして、これでお別れです。スクリーンショットを撮ってください。これらは5つのリンクで、私たちが話したすべてについてより深く掘り下げることができ、レートベースのツールの使い方、カスタムキーの使い方、AWSでのDDoSのテスト方法などについてさらに学ぶことができます。まだ知っておくべき良い情報がたくさんあります。以上です。お時間をいただき、ありがとうございました。このセッション、NET 201についてフィードバックをいただければ幸いです。PaulとI私はそれによって評価されます。本当に感謝しています。お時間をいただき、ありがとうございました。良い夜をお過ごしください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion