サイバー攻撃「水責め」の恐怖、G7も襲ったDDoS攻撃を解説【後編】

「水責め」という恐ろしい名前のサイバー攻撃があるのをご存知でしょうか。これは元々アメリカで「DNS Water Torture Attack」と名付けられ、それが和訳された呼び名です。水を顔に浴びせたり大量に飲ませたりする拷問を語源として命名されたというなんとも恐ろしげな攻撃です。

前編では、水責めが近年多く観測されており、2023年に日本では政府関連組織や自治体の被害が報道されたことを取り上げました。今回はその厄介な水責めの被害からどのようにしてシステムを守るかという対策について解説します。

DDoS対策の基本的な考え方

「DoS(Denial of Service)攻撃」は、標的となるシステムもしくはネットワーク帯域を過負荷状態にして使用不能にする攻撃です。これを多くの多様な送信元から大量のトラフィックで行う場合にD(Distributed＝分散という意味)が付いたDDoS攻撃となります。これを防ぐ解決策を大別すると以下の2つが主な選択肢となります。

1. 攻撃を遮断する
不正な通信を検知し、対象システムに到達する前に遮断する。不正であることの根拠として、その通信の中身や送信元のIPアドレスなどで判断する手法などが挙げられる。

2. 負荷を分散する
不正な通信が標的にするシステムを地理的に分散し、かつ各場所においてサーバも複数配置して負荷分散を行う。分散して発せられた攻撃を合流させないことでDDoSの成立を阻む。

「遮断」は困難

水責め攻撃の厄介なところは、遮断しづらいところです。水責め以外のDNSを標的にするDDoS攻撃としては、ボットやリフレクション攻撃などによるトラフィックボリューム型の攻撃もありますが、これらの場合にはISPがオンプレミス型のDDoS対策ソリューションによって遮断する対策が有効です。

対して、水責めは形の上ではキャッシュDNSサーバから来ているDNSクエリであり、正当なゾーン情報と照らし合わせない限り不正クエリであるという判別がつきません。正当なISPのキャッシュDNSサーバからも発行されるため、送信元ベースで遮断することもできません。

負荷を分散する方法

現状、水責めに対しては負荷分散が最も有効です。権威DNSサーバは、元々複数台で構成することが想定されており、ゾーンデータを複数サーバで同期させる「ゾーン転送」機能を持っています。これを物理的に離れた大量のDNSサーバ間で構成することで、負荷を分散させることができます。

ですが、企業や自治体が自前で複数データセンターとインターネット回線を調達し、そこに分散DNSサーバを構築するのは限界があります。なぜなら、この分散環境は数百カ所にも及ぶ環境に分散させなければDDoS攻撃を防ぐことは困難だからです。

筆者の所属するアカマイの顧客の話では「数十の拠点に分散したDNSサーバ環境でもDDoS攻撃の被害に遭ってしまった」といったケースもありました。そうなると数百拠点に分散した基盤が必要ですが、これを運用するには莫大な労力がかかるため、自前調達はおすすめできないのです。　

そこで、クラウドサービスで提供される分散型権威DNSサーバを利用する方法が有効です。

地理的に分散し冗長化された基盤を選ぶ

サービス提供者によって国内から海外まで分散の度合いは異なりますが、分散処理させる技術としてIPエニーキャストが使われています。これは共通のIPアドレスを複数のサービス提供カ所で併用することでトラフィックを分散させる方法です。

これによりクライアントからのDNSクエリは、インターネット経路制御上で最も近接したIPに到達することになります。つまり、クライアントが接続してくる場所によって自動的に異なる権威DNSサーバに送られて、地理的に分散させることができます。

このIPエニーキャストを利用した分散基盤の冗長性が、水責め対策の要点です。例として、下図の分散型権威DNSサーバの構成では、顧客が利用するゾーンごとに6つの権威DNSサーバのIPアドレスが割り当てられています。

• 

  分散型権威DNSサーバの冗長構成の例

この6つのサーバIPは、先に記載した通りIPエニーキャストのため、それぞれのIPアドレスの先に実際は数台～数百台のサーバが稼働する「PoP(Poin of Presence＝サービス提供場所)」があり、このPoPを複数まとめた「パフォーマンスクラウド/可用性クラウド」という権威DNSサーバのグループが存在しています。

このように複数階層で冗長化された環境によって分散型の権威DNSサーバを利用することができます。この環境に水責めのクエリを流し込んでも、実際には到達先が散らされてさまざまな場所で処理されるので、一カ所に負荷はかからずDDoS攻撃が成立しなくなります。

分散型DNSプロキシという選択肢

組織によっては、上述した分散型の権威DNSサーバを導入することが難しいケースがあります。例えば、既存で「GSLB(Global Server Load Balancing)装置」を導入していると、そこに外部の権威DNSサービスを組み込むことは困難です。その場合にはDNSプロキシによるDDoS攻撃対策が、新たな選択肢となります。これは、権威DNSサーバの手前に分散型のDNSプロキシサーバを配置し、そこで処理の代替を行わせる方法です。

元来のDNSプロキシは、クエリを権威DNSサーバに転送したり、キャッシュするためのサーバで、水責めのように次々に新しいサブドメイン名への問い合わせが来る場合に負荷を軽減する能力はありません。ですが、このDNSプロキシに「存在するサブドメインのリスト」を持たせれば、「存在しないサブドメイン名のクエリ＝水責め」をここで止めることができます。

下図の具体的なDNSプロキシ構成例では、フィルタ機能を持たせたDNSプロキシを分散配置し、先に解説したIPエニーキャストによって振り分けています。これを利用すれば、水責めはフィルタされて正当なクエリだけが、正規の権威DNSサーバに到達することができますし、さらにトラフィックボリュームによるフラッド型攻撃にも負荷分散で対応できます。この分散型DNSプロキシの良いところは、既存の権威DNSサーバ環境を変更せず、アドオンとしてDDoS対策を導入できる点です。

• 

  分散型DNSプロキシで不正なクエリをフィルタ

まとめ

近年話題になった水責めは、既存のDDoS対策ソリューションでは遮断が困難であり、被害が継続しています。これには権威DNSサーバを水責めを受け止め切るのに十分なスケールで分散させるか、ゾーン情報を持たせた分散型DNSプロキシを前面に配置するかが有効です。

いずれにしろ大規模な分散環境が必要なため、自社で個別調達するのは容易ではありません。分散基盤を有したクラウドサービス型を利用するのが現実的です。

その際には、前述した通り「どのような構成で分散、冗長構成が取られているのか」が重要となります。せっかくクラウドサービスを契約しても、分散が不十分であれば意味がありません。本稿が読者のセキュリティ向上に貢献できることを切に願っております。