AWS Best Practices for DDoS Resiliencyをナナメ読みして学ぶDDoS対策

この記事は武蔵野アドベントカレンダー25日目の記事です。

皆様、DDoS対策は十分でしょうか？ 2018年もDDoS攻撃の多い年でした。この記事は、公開されているDDoS対策のAWSベストプラクティスをザックリ読んでみようというものです。

この記事で言いたいこと

• AWSの公開しているベストプラクティスは情報量がすごい
• DDoS攻撃にはインフラストラクチャー攻撃とアプリケーションレイヤー攻撃に分けられて、それぞれターゲットが異なるし防御の仕方が違います──というのが一般論なんだけど、AWSにおいてはどっちにも有効なサービスが多い
• ELB、CloudFront、AWS WAFとそれらへのセキュリティグループ、NACLsの設定を適切にやるとDDoS対策として強い。さらに頑張る場合はAWS Shield Advancedをサブスクライブか
• AWSのサービスは数年で結構変わるので、変化を追いかけていく必要がある

翻訳元: AWS Best Practices for DDoS Resiliency

AWS Best Practices for DDoS Resiliency
(https://d1.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf)

AWSホワイトペーパーの一つで、AWSにおけるDDoS対策のベストプラクティスが記載されています。

2018年6月リリース版が英語のみですが公開されているため、本記事ではこの記事を ザックリ 読んでDDoS対策を考えてみようと思います。時間がある人はホワイトペーパーを全部しっかり読むのが良いです。
最初はこの記事も和訳を目指したんですが、30ページ超える資料を1記事に和訳しようとすると長くて読んでられなくなるのと、結構訳すのもしんどかったのでザックリ要約してみました。

ナナメ読みする

はじめに: Denial of Service Attacks

DDoS攻撃は、OSIモデルにおける レイヤー3 (ネットワーク層) 及び4 (トランスポート層) への攻撃 と、 レイヤー6 (プレゼンテーション層) 及び7 (アプリケーション層) への攻撃 が多く見られます。

インフラストラクチャレイヤー攻撃

レイヤー3および4への攻撃。代表的な攻撃は以下のようなものです。

• UDPリフレクション攻撃
  • 送信元を偽装したUDPパケットを、大きなUDPレスポンスを返却するサーバへ送信することで、ネットワークや監視システムを圧迫するほど 大量のトラフィックを生成する攻撃
  • たとえば、DNSはリクエストに対して28 ～ 54倍のレスポンスを返す。つまり、攻撃者は 64 bytes のリクエストペイロードをDNSサーバに送信することで、3400 bytes 以上のトラフィックを生成することができる
• SYNフラッド
  • SYNパケットを送り続けて接続を半分開いた状態にする(ACK待ちにさせる)ことで、システムの利用可能なリソースを枯渇させる攻撃

アプリケーションレイヤー攻撃

レイヤー6及び7への攻撃。代表的な攻撃は以下のようなものです。

• HTTPフラッド
  • 正規ユーザーからと思えるような HTTPリクエストを多量に送信する攻撃
• キャッシュバスティング攻撃
  • HTTPフラッドの一種で、CDNからのキャッシュ応答とならないようリクエストにバリエーションの多いクエリ文字列を付与したもの
• WordPress XML-RPC フラッド
  • WordPress pingback floodとも呼ばれる攻撃で、XML-RPC APIを悪用して 大量のHTTPリクエストを生成する攻撃
  • WordPressのサイトAから別のWordPressのサイトBへ引用が作成されたことを検証・通知する仕組み(Pingback)を悪用したもの。リンクや引用が本当に作成されたか検証するため、WordPressからリクエストが飛ぶ仕組みを悪用する。WordPressのサーバが中間にいるため、攻撃された場合はリクエストのUser-AgentはWordPressとなる

ミティゲーション(緩和)テクニック

すべてのAWSカスタマーはAWS Shield Standardの恩恵を受けられます。

• AWS Shield Standard
  • 追加料金なし、全リージョンに自動で付与されている
  • Webアプリケーションが対象だが、対策は インフラストラクチャレイヤー攻撃への対策 となる
  • AWS Shieldによって緩和された トラフィックについては課金されない

さらに、以下のサービスを使うことでより強い可用性を得ることができます。

• Amazon CloudFront
• Amazon Route 53
• AWS WAF

これらのAWSサービスを組み合わせた、DDoS回復性リファレンスアーキテクチャが以下の図(Figure 5 - AWS Best Practices for DDoS Resiliencyより引用)です。

各サービスにBP1～BP7のタグがついており、以降の説明ではこれらのタグを用いて説明します。

また、 AWS Shield Advanced に加入してDDoS緩和を行う方法もあります。

• 以下のサービスで利用可能
  • Amazon Route 53
  • Amazon CloudFront
  • Elastic Load Balancing
  • Elastic IP (Amazon Elastic Compute Cloud および Network Load Balancer)
• DDoS response team (DRT)にサポートを依頼できる
• AWS管理コンソール、API、Amazon CloudWatchから監視・アラームが行える
• AWS WAF (アプリケーションレイヤー攻撃への対策) , AWS Firewall Manager へのアクセスを追加費用なしで提供
• DDoS攻撃に起因する スケーリング関連コストの払い戻し を要求できる

インフラストラクチャー攻撃の防御 (BP1, BP3, BP6, BP7)

• インスタンスサイズ (BP7)
  • EC2の スケールアップを検討してください。 インスタンスの追加(水平方向のスケールアップ)、より大きなインスタンスの利用(垂直方向のスケールアップ)、どちらも可能です
  • M4など最大サイズのインスタンスは25Gbitインターフェイスを追加することもできます
• リージョンの選択 (BP7)
  • DDoSは国際的に飛んでくるので、国際キャリアおよび大規模なピアが頻繁な活動を維持している場所の近くでは大きなインターネットキャパシティを提供できます(正直なにを言ってるのかよくわかってない)
• ロードバランシング (BP6)
  • ロードバランサでトラフィックを分散 しましょう
  • アプリケーションタイプに応じて、 ALB（Application Load Balancer）またはNLB（Network Load Balancer）という2種類のELBを検討する必要があります
    • WebアプリケーションではALBがオススメ。SYN FloodやUDP Floodへの対策も兼ねています
    • TCP-ベースのアプリケーションであれば、NLBがオススメ
• AWS エッジロケーションを使用した大規模配信 (BP1, BP3)
  • Amazon CloudFrontでキャッシュ配信を行うことでHTTP Floodから防御できます
  • キャッシュ可能なコンテンツがなくても、TCPコネクションの最適化で配信速度を上げることができます
  • Amazon Route 53を利用することで、DNSサービスがDDoS攻撃の標的になっても、エンドユーザがアプリケーションにアクセスできるようにします

アプリケーションレイヤー攻撃の防御 (BP1, BP2, BP6)

• 悪意のあるウェブリクエストの検出とフィルタリング (BP1, BP2)
  • Amazon CloudFrontを用いることでオリジンサーバへの負荷を軽減できるだけでなく、コネクションを終了させないDoS攻撃(例: Slowloris)からも耐性を高めることができます
  • AWS WAF の Web ACL (web access control lists) を設定することで、リクエストをフィルタリングできます。フィルタされたリクエストは403応答が返却されます
    • AWS Marketplaceで提供されている AWS WAF の管理ルールを使用すれば、既知の悪意のあるIPアドレスをブロックできます
    • 悪意のあるリクエストを特定するには、Webサーバーのログを確認するか、AWS WAFのログ機能を利用するか、Sampled Requests機能を使用してください。 Sampled Requestsは、過去3時間の間にAWS WAFルールに一致したリクエストに関する詳細を提供 します
• スケールして吸収する (BP6)
  • Amazon CloudWatchアラームの設定、オートスケーリングの開始によってイベントに応じてAmazon EC2フリートのサイズを自動的に調整することができます

攻撃領域の削減

攻撃者が標的にできる領域を小さくする設計は重要です。インターネットにすべてのリソースを公開する必要はありません。 例えば、ELBの背後にいるEC2インタンスはインターネットからアクセスされる必要は無いでしょう

AWS リソースの難読化 (BP1, BP4, BP5)

• セキュリティグループとNACLs (BP5)
  • Amazon VPCのアクセス制御にはセキュリティグループとNACLs ( Network Access Control Lists)が利用できます
    • セキュリティグループはインスタンス単位、NACLsはサブネット単位で制御可能です
  • AWS Shield Advanceをサブスクライブしている場合、Elastic IPを保護対象に加えることができます。保護対象のEIPは迅速にDDoS検知されるほか、被攻撃時にはNACLsの情報をAWSネットワークの境界にも適用します
• オリジンの保護 (BP1, BP5)
  • Amazon CloudFrontを利用している場合、 自動でAmazon CloudFrontからのみリクエストを受け付けるようセキュリティグループが更新されます
• API エンドポイントの保護 (BP4)
  • Amazon API Gatewayを利用することで、背後のコンポーネントをパブリックなアクセスから隔離させることができます

オペレーションテクニック

• 可視性
  • Amazon CloudWatch を使用して、AWS で実行中のアプリケーションをモニタリングすることができます
  • Global Threat Environmentダッシュボードには、AWS全体で検知したDDoS攻撃に関する概要が表示されます
  • VPCフローログを確認することで、IPトラフィックに関する情報を得ることができます
• サポート
  • AWS Shield Advancedをサブスクライブしており、ビジネスサポートまたはエンタープライズサポートを受けている場合、DRTチームにエスカレーションできます

2019年はどうなる？

ここまで和訳っぽいことを書いていましたが、実は2016年度版には日本語版も存在します。

日本語版があるならそれでいいじゃん！という気になりますが、実は2年で結構記載が変わっています。読んでいて気になったのは以下の感じでしょうか。

• AWS Shieldに関する記載。2016年にはサービスがなかった
• インタフェースの最大転送量が10Gbitから25Gbitに上がってる
• Web ACLに関する記載が結構変わってる。AWS Marketplace自体は2016年にギリギリあったけど、まだフィルタリング対象のリストが販売されていたりはしなかった？

AWSのサービスはどんどん増加しているため、2018年度版の記載もいずれ更改されるでしょう。では2019年度版が出てくるとしたらどう変わるでしょうか？
たとえばAWS Security Hubの利用なんてものが書かれるかもしれません。

AWS Security Hubは、AWS純正サービス(AWS Shield Advanceのアラートが出力されるCloudWatchも含む)だけでなくサードパーティ(AWSパートナー)性のサービスも含めてアラートの確認や優先順位付けなどのセキュリティ監視が行えるサービスです。

このホワイトペーパーの面白いところとして、DDoS緩和に直接結びつくものではない監視やアラートなど運用についてもしっかり触れられている点が挙げられます。
AWSパートナーのサービスにはF5やIncapsulaのDDoSプロテクションサービスもあるため、それらの利用を検討するべきかもしれません。

おわりに

AWS上に環境構築するのは単なるVM上で環境作るのとはまるで違うので、しっかりサービスを把握しておきたいですね。