« 個別の管理ポリシーを用いたパーミッションの編成について | メイン | AWS Black Belt Tech Webinar 「Amazon ElastiCache」資料公開 »

「DDoSに対するAWSのベストプラクティス(日本語版)」の公開と攻撃対象領域の削減によるDDoS攻撃への備え方

お知らせ:

本ブログ記事でも紹介されているホワイトペーパー"AWS Best Practice for DDoS Resiliency"の日本語訳が公開されました。こちらよりダウンロードできますので是非ご参照ください。

 

分散型サービス妨害攻撃(DDoS)はネットワークや、システム、アプリケーションを、それらが処理できる以上のトラフィックやコネクション、リクエストにより溢れさせる企てとして有害な攻撃者により時折用いられるものです。 当然のことながら、お客様はしばしばこの種の攻撃から私達がどのようにお客様のアプリケーションを守ることを支援できるのか尋ねられます。 お客様の可用性を最大化する支援をするため、AWSはDDoS対策アーキテクチャーを構築するためにAWSのスケールを活用できるようにするベストプラクティスを提供しています。 これらのベストプラクティスは"AWS Best Practice for DDoS Resiliency"(「DDoSに対するベストプラクティス」)のホワイトペーパーの中で深く議論されており、それらには、あなたのアプリケーションの可用性を保護し、DDoS攻撃へのより適切な対策を助けるリファレンスアーキテクチャーも含まれています。

攻撃者があなたのアプリケーションを標的とするような機会を最小化することは重要なことです。 このホワイトペーパーの中で、私達はこれを「攻撃対象領域を削減する」として触れています。 DDoS攻撃においては、これはあなたのアプリケーションに到達することができるトラフィックのタイプを制限することを意味します。 例えば、もしあなたがシンプルなウェブアプリケーションを構築しているとしたら、あなたはTCPのポート80と443をインターネットに公開するだけでよいかもしれません。 これはあなたのアプリケーションと同じポートやプロトコルで通信を行わない多くのよく見られるDDoS攻撃からのトラフィックをブロックするようにしてくれます。

DDoS対策アーキテクチャーを構築する際に考慮すべきベストプラクティスのうちの一つでしかありませんが、このブログ記事では、セキュリティグループとネットワークアクセスコントロールリスト(ACLs)の構成により、あなたのアプリケーションへのアクセスを制御し、公開されたエントリーポイントを最小化するために、どのようにAmazon Virtual Private Cloud(VPC)を用いるか説明をします。

一般的なDDoS攻撃

Amazon VPCの構成について議論をする前に、DDoS攻撃と攻撃対象領域を最小化することがどのようにあなたのアプリケーションに到達する悪意のあるトラフィックを防ぐことになるか理解しておくことは重要なことです。 DDoS攻撃の最も一般的なものに反射攻撃があります。これはネットワークインターフェースを輻輳させ、正当なトラフィックを妨げる程の量のトラフィックを生成し得るものです。 反射攻撃を行うために、攻撃者は始めにインターネットをスキャンし、Simple Service Discovery Protocol (SSDP), Domain Name System (DNS), Network Time Protocol (NTP), Simple Network Management Protocol (SNMP)といったUser Datagram Protocol (UDP)サービスを立ち上げているサーバーを探します。 構成により、こうしたサービスはしばしば最初のリクエストの何倍ものサイズのレスポンスを返します。 これは攻撃者が成りすましたソースアドレスを用いて大量の小さなリクエストを送付することを可能にし、時として何十倍、何百倍の大きさのレスポンスを生む結果となります。 これらのレスポンスはDDoS攻撃のターゲットである、なりすまされたソースIPに対して送り付けられます。

以下の図はどのように攻撃者が犠牲者へのDDoS攻撃となる増幅されたレスポンスを引き出すため、なりすましたリクエストを利用するか詳細を示しています。

図1:反射攻撃によるDDoS攻撃

セキュリティグループの構成

反射攻撃では、攻撃者は一般的なUDPサービスが用いられていれば世界中どこからでも大量のトラフィックを生み出すことができます。 幸いにも、こうした攻撃は発見が最も容易なものでもあり、多くの場合Amazon VPCのセキュリティグループを構成することで軽減することができます。 セキュリティグループは、あなたのアプリケーションに必要とされるポートとプロトコルのみによるコミュニケーションだけを許可することで、あなたのインスタンスに対するインバウンドとアウトバウンドのトラフィックをコントロールすることが可能です。 他のポートやプロトコルでのアクセスは自動的に拒否されるのです。

次の図は、この記事の始めに触れたウェブアプリケーションを例として、Amazon VPCの構成についてのリファレンスアーキテクチャーを示すものです。 より詳細に関しては、「VPCのセキュリティグループ」をご覧ください。

図2:Amazon VPCの構成に関するリファレンスアーキテクチャー

このリファレンスアーキテクチャーでは、私達は一つのDMZのPublicサブネットと、二つのPrivateサブネットを用いて構成されたAmazon VPCを利用しています。 これにより、インターネットを経由したユーザーと管理者のコミュニケーションを許可するセキュリティグループと、DMZからのみアクセスが可能となる内部リソースのための別のセキュリティグループを作成することが可能となります。 VPC内部のサブネットの作成とルーティングについてのより詳細な情報は、「VPCとサブネット」を参照ください。

SSH要塞ホスト セキュリティグループ

SSHの要塞ホストはSecure Shell(SSH)サービスのみホストし、セキュアな管理者アクセスを提供するために使われるEC2インスタンスです。 管理者はインターネットや特定のインターネットアドレスのレンジよりTCPポート 22に接続することができます。 SSH要塞ホストに接続した後は、管理者はウェブアプリケーションサーバーやMySQLデータベースサーバーのインスタンスに接続することができます。 このポートに対するDDoS攻撃があった場合は、SSHサービスのみが影響を受けます。 これはあなたのウェブアプリケーションの可用性に影響を及ぼすためにこのポートを攻撃者が用いることを妨げます。 不正アクセスの可能性を最小化するために、あなたのネットワークのPublic IPのレンジのみSSH要塞ホストのセキュリティグループとコミュニケーションすることを許可されるようにするべきです。 以下の表は、SSH要塞ホスト セキュリティグループを構成するために使うことができるルールの例を示しています。

 ELB セキュリティグループ

Elastic Load Balancing (ELB)は自動的にインバウンドのトラフィックを複数のAmazon EC2インスタンスにルーティングすることでより大きなフォルトトレランスをもたらしてくれます。 ELBはまた、あなたのウェブアプリケーションにかわりリクエストを受けたり、キャパシティへの要求を処理するために自動的にスケールすることで、攻撃対象領域を削減することを可能とします。 加えて、ELBはあなたが指定したポートとプロトコルによるウェブアプリケーションへの適正な接続のみ通すように設計されています。 これはDDoS対策に関する更なるレイヤーをもたらしてくれます。 ELBを介してユーザーがあなたのウェブアプリケーションにアクセスできるようにするためには、インターネットからのTCPポート80と443のみを許可し、リクエストをウェブアプリケーションサーバー セキュリティグループのEC2インスタンスに送信できるようなセキュリティグループをセットします。 以下の表はELB セキュリティグループを構成するために使うことができるルールの例を示しています。

 NAT セキュリティグループ

この例の中のウェブアプリケーションサーバーとMySQLデータベースはプライベートサブネットにホストされているため、直接インターネットから出たり入ったりする経路を持っていません。 ELBを経由してユーザーにコンテンツを提供するために要求されていることではありませんが、ソフトウェアの更新等のためにインスタンスのインターネット接続を許可することは望ましいかもしれません。 ウェブとデータベースをホストするEC2インスタンスがインターネットにアクセスできるようにするために、私達はNetwork Address Translation (NAT)インスタンスをそれ自身のセキュリティグループ内に作成します。 NATインスタンスにより、インターネットからのインバウンドの接続を拒否しつつ、プライベートサブネットからインターネットへとトラフィックを安全に通すことができるようになります。 詳細な情報に関しては「NATインスタンス」を参照ください。

ウェブアプリケーションサーバー セキュリティグループ

このセキュリティグループは、このウェブアプリケーションとしてコンテンツを提供する全てのEC2インスタンスを含むことになります。 これらのEC2はELBからくるウェブアプリケーションのリクエストのみ受け付けるようにします。 攻撃対象領域を最小化する取組として、これらのインスタンスにはVPCのサブネットのアドレスレンジからのプライベートIPアドレスしかアサインされません。 それにより、これらのインスタンスがインターネットから直接アクセスされることを防ぎます。 ウェブアプリケーション セキュリティグループを、ELB セキュリティグループからのTCPポート80及び443とSSH要塞ホスト セキュリティグループからの(管理者用アクセスのための)TCPポート22だけ許可するように構成します。 以下の表はウェブアプリケーションサーバー セキュリティグループを構成するために使うことができるルールの例を示しています。

 MySQLデータベースサーバー セキュリティグループ

同様に、MySQLデータベースサーバーはウェブアプリケーションをホストするEC2インスタンスからのみアクセス可能にしたいところです。 これを行うために、バックエンドのPrivateサブネットのIPアドレスレンジからMySQLデータベースサーバーにPrivate IPアドレスをアサインし、ウェブアプリケーションサーバー セキュリティグループのEC2インスタンスからのみTCPポート3306の接続を許可するMySQLデータベースサーバー セキュリティグループを構成します。 以下の表はMySQLデータベースサーバー セキュリティグループを構成するために使うことができるルールの例を示しています。

 Network ACLの設定

Network ACLは伝統的なファイアウォールのように番号順に処理されるステートレスのallow及びdenyルールを作れるようにすることで追加の防御レイヤーを提供するものです。 これはEC2のインスタンスレベルでトラフィックを許可するセキュリティグループとは反対に、サブネットレベルでトラフィックを許可したり拒否したりするために便利です。 例えば、もしあなたが望ましくない、もしくは悪用の可能性のあるインターネットのIPアドレスかレンジを識別した場合、あなたはdenyルールによりそれらをアプリケーションに到達する前にブロックすることができます。 あなたは、IPサブネット全体をターゲットにするか、個別のIPアドレスをターゲットにするかルールを作成する際に決めることができます。 以下の表はこの記事の前に話したセキュリティグループを補完するカスタムNetwork ACLのサンプルです。 より詳細な情報については、「ネットワークACL」を参照ください。(Network ACLにおける適切なエフェメラルポートレンジ[1024 - 65535]の選択の仕方については、「一時ポート」を参照ください。)

他の検討すべきベストプラクティス

Amazon VPCのセキュリティグループやNetwork ACLを適切に構成することは、あなたのアプリケーションの攻撃対象領域を減らす助けとなる有効なツールとなります。 これらのアプローチは似て見えるかもしれませんが、それぞれが攻撃対象領域の削減に重要な役割を持っています。 これは特にDDoSの状況においては重要になります。 なぜならばセキュリティグループはあなたのアプリケーションのリソースにアクセスできるトラフィックを決めることができるようにするもので、Network ACLはサブネットレベルで明示的に拒否すべきポート、プロトコル、トラフィックのソースを定義できるものであるからです。 今、あなたは2つの重要なVPCのセキュリティ機能を構成することができましたので、Amazon CloudWatchによる監視や、Aamzon CloudFront, Amazon Route53, Elastic Load Balancing, Auto ScalingといったDDoS対策アーキテクチャーの他のコンポーネントも検討すべきです。

このブログの記事がAWS上でより安全なアプリケーションを構築する助けとなることを望みます。 もしAmazon VPCでどのように攻撃対象領域を減らすかについて質問があれば、是非下のコメント欄に記入ください。

- Jeffrey Lyon, AWS Edge Services(日本語訳は高田智己が担当しました)

原文:https://blogs.aws.amazon.com/security/post/Tx3NVS2JAL7KWOM/How-to-Help-Prepare-for-DDoS-Attacks-by-Reducing-Your-Attack-Surface

 

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2017年11 月

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30