読者です 読者をやめる 読者になる 読者になる

CloudFlareがDDoS の影響を低減するために行った対策

あの規模の DDoS をどう防いだかに興味があったのでCloudFlare ブログの記事を読んでみた。誤読があったらご指摘頂きたい。

端的に言うと、CloudFlare は対処できるだけのインフラを整備していた、と言うことに尽きる。もちろんその場での判断の適切さ、オペレーションの実施などあったのだろうけど、それはこの攻撃が始まる以前からインフラと共に醸成されていたものに見える。勝負は始まった頃には大体着いているものだし、このケースもそうなのだと思う。

インフラがあったんじゃん、なーんだという話では無く、そういうインフラや技術を普段の活動から作れていた、という所に凄味があるのだと思う。

http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho

  • 3/18 に SpamHaus に攻撃が発生。サイトが落ちる。
  • 3/19 に SpamHaus から CloudFlare にコンタクト。この攻撃を低減できないかと問い合わせを受ける。
  • 先ずは CloudFlare 上で再度 SpamHaus サイトを立ち上げてトラフィックの記録。
  • 75Gbps のトラフィック
  • 攻撃者は ripe.net の zone file 問い合わせを open resolver に対して行った
  • リクエストはおよそ 36bytes
  • レスポンスはおよそ 3000bytes になる。およそ100倍に増幅される
  • 問い合わせの際に source ip を SpamHaus のそれにする事で攻撃
  • 結果として750Mbps のトラフィックを元手に 75Gbps の DDoS を生成
  • 30000以上の open resolver からの攻撃となった

対応

  • この分量の攻撃をオンプレミスの設備で対応することは難しい
  • CloudFlare のネットワークはこの手の攻撃に対抗できるよう設計している
  • anycast をヘビーに使っている
  • 世界中の 23 のデータセンターで同じ IP アドレスを持つ。anycast 機構により分散ルーティング。
  • このため many-to-one な通信で無く many-to-many な通信となり通信量が分散希釈された
  • 一度通信が希釈されれば各データセンターで止めることが出来た

その他の事

  • 多くの攻撃はDNS reflection だったが ACK reflection も使っていた
  • マッチしない ACK をドロップすることで対応
  • こういった攻撃の際には自分たちが攻撃元のサーバに反撃してるんじゃないかと言われるけど実際にはリフレクション攻撃に利用されているだけなんだよ(読み方間違ってるかも

http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet

もう少し詳細を書いた記事

  • 先の記事では 75Gbps のトラフィックとあったが、こちらの記事では85Gpbs になっている
  • 3/18 時点で10Gpbs
  • 3/19 に攻撃トラフィックのサイズ増加、ピークでは90Gbps で、3/21 0:15 になるまで継続的に 30Gbps と 90Gpbs の間を変化
  • 3/22 18:00 アタックが再開。ピーク時 120Gbps。前回書いたように anycast による分散を行った。Spamhaus に対しても他の顧客に対しても影響が無いように分散。4時間後、攻撃が中止された。
  • この後は上位プロバイダへの攻撃の記述が続いている