ITサービスにおいてリスクマネージメントとは、いつ・どこでも発生しうるリスクへのあらゆる対応戦略を検討し準備することです。ヒューマンエラーのように内部要因により発生する事象であれば、システムやプロセスを改善することでそのリスクを減らせますが、DDoS攻撃(分散型攻撃)のように全く予測できず外部要因(サイバー攻撃)によるものに対しては、その対応にも限界があります。しかしながら、ここで諦めるわけにはいきません。準備をすることで影響範囲を最小化することができるからです。

本ブログでは、明日にでも影響を受けるかもしれないDDoS攻撃に対して、どう準備し対応すべきかについて解説します。

戦略0 : 現状を把握する

まず対応戦略を検討する前に、自らの組織の状態を把握することから始めます。DDoS攻撃は、攻撃者と防御者のインフラおよびアプリケーションの可用性の戦いとも言えます。つまり、自分たちが処理できる範囲を超える攻撃であれば障害となり、範囲を超えなければ通常処理されてそれほどの影響は受けません。

現状把握のチェック方法は、まず会社ネットワークを含めたネットワーク全体のシステム構成図を参照します。バックボーンネットワークからエンドユーザにサービスを提供するサーバまでどのくらいのトラフィックを処理できるのかについて、主にDNS、HTTP/HTTPSなどのサービスを基準にして、例えばL3/L4ネットワーク全体のバックボーンで処理できる容量(例:10Gbps)とL7で処理できるリクエスト数 (例: DNSの 場合200K QPS、HTTP/HTTPSの場合100K RPS)などの数値を把握することで、今後の具体的な対応戦略を検討し、被害範囲を算出するのに役に立ちます。

戦略 1 : ある程度の攻撃に耐えられるサーバ容量の準備

メディアには数百Gbps、1Tbpsの大規模なDDoS攻撃に対する記事が多く出回っていますが、実際は300Mbps ~ 5Gbpsなど小規模の攻撃が大半を占めています。もちろん大規模な攻撃を処理できる体制を準備できればよいのですが、そのためにはたくさんの投資が必要であり、予算と攻撃発生の可能性を考慮しつつ現実的な容量を見極めることが大切です。

では、どの程度の容量を準備すべきなのでしょうか？

正解は「ない」とも言えますが、一般的にイベント時などの急激なトラフィック増加を考慮して2倍程度の容量を準備している場合には、DDoS攻撃に対してはそれよりも2~3倍、つまり通常時の4~6倍の容量を準備するといいでしょう。これにより頻発する小規模の攻撃にはある程度耐えることができるようになります。

戦略 2 : インフラを分散する

DNSやHTTP/HTTPSなどのインターネットサービスは、通信プロトコルがフェイルオーバーに対応しているため、もしもの時に備えて予め2～3重化しておくとよいでしょう。例えば、またDNSの場合は、最小1もしくは2～13までの複数設定が可能ですが、できるかぎり多重化して分散することによって、ネットワークやPoPで障害が発生してアクセスできない状況になっても、他のPoPからサービスを提供することができるため安心です。

$ dig cdnetworks.co.jp ns
cdnetworks.co.jp.     86400       IN            NS           ns1.cdnetdns.net.
cdnetworks.co.jp.     86400       IN            NS           ns2.cdnetdns.net
.ns1.cdnetdns.net.     86400       IN            A             174.35.55.22
ns2.cdnetdns.net.     86400       IN            A             66.114.55.22

<表１>

<表１>について、もし1番目のDNSのns1.cdnetdns.netがあるデータセンターに障害が発生して外部からアクセスができない状況になった場合、DNSクライアントはフェイルオーバーの手順に従って、ns2.cdnetdns.netにクエリーを再送します。これは、HTTP/HTTPSの場合も同じです。

<表2>のように特定のドメインに対して2つの IPを返した状況で、もし1つのIPがアクセスできない状態になるとChromeやFirefoxなどのブラウザは、一定時間の経過後に自動で他のIPにアクセスをしてサービスの可用性を維持します。

$ dig www.cdnetworks.co.jp
www.cdnetworks.co.jp.            86400       IN            A             115.127.249.88
www.cdnetworks.co.jp.            86400       IN            A             115.127.250.124

<表2>

結論としてDDoS攻撃にたいしては、中央集中ではなく分散して対応するとよいでしょう。

＝参考＝
UDPでサービスするDNSプロトコルの場合、パケットサイズが512byteを超過すると、TCPに再転送する特性により、最大13まで複数のNSまたはAレコードを設定できます。もちろんEDNS0により512byte以上もサービスできますが、互換性などを考慮してできれば512byte以内にレスポンスサイズを構成することをお勧めします。

戦略 3 : ISPのサービスを検討する

前述した2つの方法は自主的な対応策でしたが、外部業者を利用する方法もあります。特定のISPまたはIDC（データセンター）のサービスを利用して、彼らからサポートを受ける方法です。ISPは大容量のネットワークとインフラを保有しているため、次のような効率的な対応ができます。

（１）ACL（アクセスコントロールリスト）を設定する

もしwww.example.comというドメインでWebサービスを提供している場合、そのIPを目的地として入ってくるUDPやICMPパケットは遮断しても問題はないでしょう。アプリケーションの特性を考慮し、使用していないプロトコルはISPに要請して遮断しましょう。ただし、適用後に変更が効かなかったり、変更するのに時間がかかったりするため、適用前には十分に検討しましょう。

<表3>では Ciscoのようなバックボーンネットワーク装備から特定のIP帯域 (10.1.1.0/24)を目的地としたUDP/ICMPおよびフラグメントパケット、そしてTCP SYNで異常に大きいサイズ (128~1500byte)のパケットを遮断するACLルールの例を表示しています。

deny udp any 10.1.1.0 0.0.0.255
deny icmp any 10.1.1.0 0.0.0.255
deny ip any 10.1.1.0 0.0.0.255 fragments
deny tcp any 10.1.1.0 0.0.0.255 syn packet-length 128-1500
permit ip any any

<表3>

また、攻撃によく利用される攻撃トラフィックも、トラフィックの特性を把握すればACLで簡単に遮断することができます。

●NTP 増幅攻撃
any : 123/udpをソースとしてany: 1024:65535に入ってくるパケット の中で、サイズが120byte以上のUDPは遮断しましょう。なぜなら、正常なNTP(123/udp)レスポンスパケットは100 byte以内ですが、攻撃トラフィックは120byte以上のためです。

●SSDP 増幅攻撃
any : 1900/udpをソースとしてany : 1024:65535に入ってくるパケットの中でサイズが300byte以上のUDPは遮断しましょう。なぜなら、SSDP 増幅攻撃に使用される平均パケットサイズは320~340byteのためです。適用後、正常にフィルタリングされているかを、サーバからtcpdumpなどのコマンドで確認できます。

<表4>の例は、NTPサービスである123/udpに入ってくるトラフィックの中でパケットサイズが120byte以上のものがあるかを確認するためのものです。

$ tcpdump udp and src port  123 -nn -i any and greater 120

<表４>

(2) Blackhole Routing 処理する

もし攻撃の規模が対応できるレベル以上に大きな場合には、無理に防ぐよりも攻撃ターゲットとなる目的地のIPを遮断し、他のIPでサービスを継続するのも一つの方法です。この際に使用できる方法がRTBH(Remote Triggered Blackhole routing) またはNull routingという技術です。

特にupstream ISPとBGPプロトコルを通じて連動している場合には、実行後即時に該当IPがルーティングから除外され、これをネットワーク全体に速やかに知らせることで効率よく対応ができます。このために、前述の通り常時複数のIPを設定しておくことを推奨しています。ほとんどのサービスは自主的にフェイルオーバーに対応するため、もし1つのIPが遮断されアクセスができなくなっても、他のIPでサービスが継続されるためです。これにより正常ユーザは変更したIPにアクセスをすることで、サービス利用を続けることができます。

補足として、攻撃者は特定のIPに攻撃を始めてから対象IPをあまり変更しないという特徴があります。一方で攻撃者によっては変更されたIPに再攻撃する場合もありますが、これは経験上頻度が少ないと言っていいでしょう。

戦略 4 : CDNを積極的に活用する

最後に考えられるもっとも効果的なソリューションはCDN（コンテンツ・デリバリ・ネットワーク）を利用することです。グローバルCDNプロバイダは、膨大な帯域幅と高容量設備を全世界に分散して保有しており、このインフラを通じてサービスを提供しているため、DDoS攻撃の防御に非常に効果的な対応ができます。

特にCDNはリバースプロキシで動作する仕組みで、お客様のオリジンIP情報は表示せず、すべてのトラフィックはCDNインフラを通過するため、攻撃トラフィックもまずCDNインフラに向かいます。

<図１>はCDNetworksのとあるPoPで攻撃が発生した例です。赤枠で囲まれた「In」に記載された数字と緑色のグラフの推移を見ると、150Gbps～MAX250Gbpsの 大規模DDoS攻撃が入ってきていますが、特にサービスに影響がおよぶことはなく安定的に提供を持続することができました。これは、CDNではなく一般的なデータセンターやクラウドを利用していた場合には対応できないレベルのトラフィック規模でした。

<図１>

では、なぜCDNではこのような対応ができるのでしょうか？

前述を見ると、CDNに委任された後はクライアントからもっとも近いPoPのIPが動的に割り当てられ、攻撃トラフィックを分散する効果があります。

また、割り当てられるPoPはGSLBと連動した監視システムでリアルタイムにモニタリングされ、もし特定のPoPがダウンしたり性能が劣ったりすると、自動的にサービスから除外され、サービスができる新しい別のPoPが割り当てされるため、可用性を維持することができます。このようにCDNでは最適なサービスのためにドメインのDNS TTL(キャッシュする時間)を20～30秒に短く設定してサービスを提供しています。

一般的にhttp://www.example.comはCDNに委任しますが、ルートドメイン(nakedまたはapex) であるexample.comはRFC規約の制限によりCNAMEで委任できず、オリジンIPがそのまま使用されることが多いため、もし攻撃者がこれに気づいた場合に大きなリスクとなります。このためCDNetworksのクラウドDNSでは、独自開発した”リゾルブCNAME”という機能を提供してルートドメインもCDN を利用できるようにしています。ただし、ANAME、ALIASなどの名前でこれに似通ったサービスを提供している他のDNSベンダーも存在します。

ドメインに対するHTTP/HTTPS対応を整えたら、次に検討が必要なのはDNS サーバです。

DNSはトラフィックが少なく、負荷が少ないという理由で低容量サーバで独自構築をすることが多い部分ですが、実はDNSはインターネットサービスの基盤であり、もし障害が発生した場合に影響はとても大きいために、アメリカやヨーロッパでは独自運用せずに外部の専門サービスベンダーにアウトソースしてパフォーマンスや可用性などの問題を解決しています。

DNSも多重化することが重要です。特にDNSはひとつの組織、ひとつのベンダーのサービスのみを利用するのではなく、多重化することによって可用性を高めることができます。

例として有名なSNSサービスであるtwitter.comの場合、独自DNSおよび クラウドDNSベンダーの両方を利用することで2重化運用しています。この際に違うDNSベンダーの間のゾーンレコードの同期化はゾーントランスファーという技術を使用していますが、CDNetworksでは一般的なCDNのほかクラウドDNSおよびゾーンレコードの同期化のためのゾーントランスファーサービスを提供しています。

もしご興味がある場合にはトライアルサービスの利用をお勧めします。

twitter.com.                            172800     IN            NS           ns3.p34.dynect.net.
twitter.com.                            172800     IN            NS           ns4.p34.dynect.net.
twitter.com.                            172800     IN            NS           r01-01.ns.twtrdns.net.
twitter.com.                            172800     IN            NS           r01-02.ns.twtrdns.net.

<表5>

なお、CDNetworksのような大規模なグローバルCDNプロバイダは、世界中へ速いDNSレスポンス処理のために、特定地域のみにあるユニキャスト（Unicast）ではなく、ルートDNSのように数百～数千の大規模エニーキャスト（Anycast）を基盤に多重化して分散されており、ほとんどの攻撃に対して安定的にサービスができるネットワーク構成で運用をしていると言えます。

ここまではリスクマネジメントの立場でDDoS 攻撃への対応策について簡単に解説してきました。

これ以外にもモニタリングや攻撃トラフィックを防御する技術など、多くのテーマがありますが、これらについては、今後一つずつ解説してゆきたいと思います。

CDNetworksでは、自動化された監視システムを通じて全世界のCDN PoPから発生しているDDoS攻撃のトラフィックをリアルタイムでモニタリングしています。1日でも数回の攻撃トラフィックが発生していますが、自動化された対応システムにより、ほとんどの場合にWebサービスに影響はおよびません。

https://attackmap.cdnetworks.com/ にアクセスすると、CDNetworksの一部のPoPから発生しているDDoS攻撃トラフィックの現況がリアルタイムで提供されており、どのくらい攻撃が頻繁に発生しているかを直接見ることができます。

リスクマネジメントを行う立場として、今一度自社のDDoS 対応戦略について検証し、足りない点があればCDNetworksにご相談ください。

CDNはDDoS攻撃から自社のWebサービスを守るための最適なソリューションとして必ず貴社のお役に立つことができるはずです。

クラウド型DDoS攻撃防御サービス「フラッド・シールド」

CDNetworksのフラッド・シールドは、世界中にCDNプラットフォームを展開するCDNetworksだからこそ実現できるクラウド型のDDoS攻撃対策サービスです。大規模な攻撃の場合でも、CDNプラットフォームが攻撃トラフィックを吸収します。また、通常のトラフィックに対してはコンテンツを配信し続けられるので、サービスの可用性が確保されます。ネットワークレイヤ（L3/L4）のすべての攻撃のほか、アプリケーションレイヤ（L7）の攻撃にも対応。昨今発生しているDDoS攻撃のほぼすべてに対応可能です。

CDNetworksのフラッド・シールドにご興味のあるお客様は、お気軽にご相談ください。
また、CDNetworksでは、フラッド・シールドについて詳細をまとめたホワイトペーパーを提供しています。是非ご覧ください。

なお、弊社では、Web会議（30分ほど）でのサービス紹介も承っております。
ご興味、ご関心のあるお客様は、お気軽にお問い合わせフォームよりお申し付けください。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■お問い合わせはこちら　>>お問い合わせフォーム
■関連資料のダウンロードはこちら　>> 資料ダウンロード
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
株式会社シーディーネットワークス・ジャパン　TEL 03－5909-3373 （営業部）