この記事は、2023年1月25-27日(水-金)に行われたJANOG51における発表を編集部にて記事化したものです。

はじめに

長野雅広といいます。
Twitter / GitHub は @kazeburo というIDでやっておりますので、フォローいただけたらと思っております。
現在はさくらインターネット株式会社のクラウド事業本部 SRE室というところで室長を務めさせていただいております。
ずっとWebアプリケーションの運用やSREをやっておりまして、ISUCONの本を書いたりもしているのですけれども、JANOGは実は初めての参加になりますので、ぜひよろしくお願いいたします。
今回は、DNS権威サーバのクラウドサービス向けに行われた攻撃および対策について、お話しさせていただきます。

SRE室の取り組み

SRE室がどんなことをやっている部署かという話ですが、2022年7月、去年の夏に発足した、新しめの部署になります。ミッションとして、クラウドサービスの信頼性を高めるとか、お客様や社会のDXをしっかり支えるということをやっております。社内でのSREの実践を広めることで、さらに最終的な目標として、さくらの社員がEnabling SREとして、お客様や社外のサービスの信頼性向上に携わっていけたらいいなというのを目標としております。

SRE室は非常に少ないメンバーでやっておりまして、単独ですべてをやりきることはできないので、他の開発チームと一緒になってやる、「Embedded SRE / Enabling SRE」という取り組みをやっています。具体的な取り組みとしては、チーム開発とか運用の体制作りや、CI/CDなどDX(Developer Experience)向上の仕組みの構築などをやっています。あとは、Kubernetesの基盤の構築だとか、ログや監視基盤の研究開発なども行っております。

JANOG39(2017年)の発表振り返り

DNSに関する発表をさくらインターネットからするのは、実は2回目になります。前回はいつだったかというと、2017年のJANOG39のときに発表させていただいております。

DNS権威サーバ向けのDDoS攻撃対策をした話～さくらインターネット編～

このときは、同じようなDNS権威サーバ向けのDDoS攻撃の対策をしたということでお話しさせていただきました。現在は資料が非公開になっていますので、このときにどんなことを発表したかを簡単にまとめてお話しします。

弊社のDNSのコンテンツサーバはいくつかありますが、それらへのDDoS攻撃が行われ、サービスにも大きな影響が出ておりました。その対策として、DDoSに耐えるためのバックボーンを含むインフラ構成の見直しをしまして、L7・DDoS Mitigation装置の導入だとか、100Gのトランジットの導入、それから上流でのBGPなどを利用した対策の検討などを行いました。

今回の発表は、同じ権威サーバではありますが、前回とは異なるサービスである、さくらのクラウドのDNSサービスに行われた攻撃を扱っております。

さくらのクラウドの紹介

さくらのクラウドとDNSアプライアンスの構成を紹介させていただきます。

さくらのクラウドは2011年のサービス開始から12年目に入りました。皆様のご支援のおかげです。改めて感謝申し上げます。

現在、東京と石狩のリージョンで展開しておりまして、IaaSを中心にサーバ/ディスクなどを提供しています。あと、VPCルータだとかデータベースのアプライアンス、それ以外に、特定のお客様にサーバリソースが結びつかない形でのロードバランサやGSLB、さらに今回話題に挙げるDNSアプライアンスなどのサービスもやっております。最近だとオートスケール機能もついて、ネットワークの帯域をオートスケールさせたりという珍しい機能もあります。

DNSアプライアンスの構成

DNSアプライアンスは、権威DNSサーバのクラウドサービスです。お客様が所有するドメインやゾーンの情報などを、コントロールパネルやAPIなどで管理ができるサービスになります。一般的なAとかAAAAのレコード、あとはCNAMEなどに加えて、ALIASのようにDNSサーバ側で名前解決した結果を返すようなものだとか、あとは最近新しく追加されたHTTPS　RRにも対応しております。

ちょっと話がずれるのですけれども、APIの操作からDNSの反映までの速度がどれぐらいかかっているかというのをグラフにしています。グラフが見にくいですが、APIの呼び出しを含めて23秒ぐらいで反映しているということが分かります。こういった見える化するというのもSREの取り組みの一つとしてやっております。

DNSアプライアンスの構成の話をします。

DNSサーバは、さくらのクラウドの石狩と東京の2つのリージョンを利用してサービスをしております。それぞれのリージョンにおいて、複数台のサーバで冗長化をしています。図の左側がns1で石狩、右側がns2で東京という形でDNSを分散して、さらに各リージョンでも複数台のサーバが動いています。

DNSサーバの中身については、権威DNSサーバとして、PowerDNSの権威サーバの方、RecursorではなくAuthoritative Serverを採用しております。PowerDNSの場合、バックエンドがいくつか選べるのですけれども、バックエンドとしてRDBMSであるMariaDB(MySQL互換のデータベース)を使用しています。

DNSの更新の動きとしては、まず図の右側のAPIの方からデータベースを更新して、それがレプリケーションされることでDNSサーバの後方にあるMariaDBが更新されて、PowerDNSはそれを参照するということになります。なので、APIの更新がされれば、わりと早い段階でお客様の実際の名前解決ができるということになっております。

DNSサーバへの攻撃

それでは今回の本題であるDNSサーバへの攻撃の話をします。

まず、なぜDNSサーバが狙われるのかという話をします。

DNSサーバが動作しなければ、一般のユーザーの方、お客様にとってはインターネットが利用できないのとほとんど同義になります。名前解決ができないとWebのアクセスも一切できませんし、スマホのアプリを使うこともできません。

なのでDNSは、そのサービスの拒否攻撃に使われます。DNSサーバの運用主体への脅迫だとか抗議のための攻撃、あとは特定のウェブサイトやアプリを使えなくするために攻撃が行われます。あと、正当な名前解決の結果を改ざんして不正サイトに誘導する、いわゆるフィッシングのために行われます。

どんな攻撃があるんだろうということで、無理やり分類してみました。

DDoSによるサービス拒否攻撃の部分では、DNSフラッド攻撃、これはサーバなり、サーバの前にあるネットワークが耐えきれないほどの帯域の通信を行わせるような攻撃ですね。それともう一つ、これを今回扱うのですけれども、DNSの水責め攻撃というのがあります。もう一つは先ほど言った、DNSの名前解決の部分を改ざんする攻撃ですね。キャッシュポイズニングと言います。これについては、IIJさんの方から、BGPのルートを上書きすることでキャッシュポイズニングを行う記事もありました。非常に参考になりました。

今回の発表で扱うDNSの水責め攻撃は、ランダムサブドメイン攻撃とも呼ばれております。2014年くらい、今から9年前に初めて観測されたとされています。2014年に初めて観測された頃から2016年にかけて、攻撃だとかそれに関する議論などが非常に多くなされていて、最近は記事を探していてもDNS水責め攻撃について書かれたものはあまり多くないという感覚です。

実際にどういう攻撃なのかをスライドで説明していますが、攻撃対象となるゾーンに対して、大量にランダムなサブドメインを作って問い合わせを行います。それによってDNSの機能停止や機能の低下、レスポンスが非常に悪くなるようなことを狙う攻撃になります。

攻撃者は、フラッド攻撃のように特定のデータベースに対して直接名前解決を大量に行うのではなくて、パブリックDNSのようなオープンリゾルバに対して、大量のランダムなサブドメインの問い合わせを行います。そのオープンリゾルバはDNSキャッシュサーバとして動いていますが、ネガティブキャッシュ、つまりそのドメインが存在しないという情報、存在しているという情報も含めて、そのようなランダムなサブドメインに対しては当然キャッシュを持っていないので、結果として権威DNSサーバの方に問い合わせが発生します。その数が多ければ多いほどDoSとなるという仕組みです。

今まで観測している中では、フラッド攻撃のような何Gbps、何10Gbpsのような高帯域にはならないのですけれども、それでも影響を受けてしまいます。あと、DNSのクエリとしてはまったく正しいものが攻撃としてやってくるので、防ぐのが非常に難しいということも挙げられます。

さくらのクラウドのDNSアプライアンスへの攻撃

さくらのクラウドのDNSアプライアンスへの攻撃は、去年の8月、もしかするとこれ以前にもあったかもしれないのですけれども、8月に大きな攻撃が発生して、それ以来断続的に続いております。その中で、数度にわたりサービスに影響が発生し、お客様にご迷惑をおかけしたというものがあります。

では、どれくらい攻撃が断続的に続いているかですが、12月7日から1月5日まで、大体1か月間ぐらいのグラフの中に、攻撃が行われた回数が11個ぐらいあるんですね。本当に小さい短時間のものも含めると、だいたい毎日1回以上は来ているんですね。そういった状態が8月からずっと続いています。多くは特定の決まったゾーンに対してなのですけれども、それ以外に対しても単発的に来るようなことがありました。

こちらのグラフは、一番長く強かった攻撃ですね。12月15日から16日まで、20時間以上、ずっと攻撃のパケットが来ていました。1分間900万クエリ、秒間に直すと15万ぐらいのクエリがずっと流れていました。これに対して、もちろんフィルタなどをしていたのでサービスの影響はなかったのですが、こういった長い期間、攻撃が行われたというのがありました。

それから、ランダムなサブドメインへのクエリが来るってどういうことなのかというのが、次のtcpdumpの結果です。ドメイン名は実際のドメインからexample.comに変えていますけれども、ランダムな文字列だとか単語の組み合わせですね。意味ある単語をハイフンでくっつけたり、そのままくっつけたりみたいなものがやってきます。ドットが増える(DNSではラベル数と呼ぶ)こともあります。

あと、同じ名前でも大文字小文字が混ざったものがやってくることがあります。これは調べてみると、GoogleさんのパブリックDNSです。8.8.8.8のものですね。その仕様としてあるみたいで、キャッシュポイズニングを避けるためにこういった大文字小文字混在のドメイン名がやってくることがあります。これはおそらく攻撃者がランダムでやっているのではなくて、Googleの仕様としてこういうものがやってくるのだと思います。

次にご覧いただくのは、実際の攻撃元にどんなところが多いかですね。

多いところからいうと、パブリックDNSを提供している会社AさんとBさん。数字の並びが良いIPアドレスをお持ちの2社が多いです。その次に出てくるクラウド大手Cというのは、いわゆるクラウドを提供している会社ですね。ここから推測されることは、やはりパブリックDNSのA、Bは非常に多いので、パブリックDNSやオープンリゾルバを踏み台にしているのだろうなということが想像できます。日によってちょっとずつ傾向が異なることもあって、クラウド大手Cがあったりなかったりということもあります。

スライドの下の方に並んでいるIPアドレスは具体的には調べてはいませんが、米国以外では、ロシア、韓国、フランスなどの国のIPアドレスが混じることもあります。

我々のサービスがなぜ影響を受けてしまったのかですけれども、多くのレコードを管理しやすくするために、バックエンドとしてデータベースを使っているというのがありました。今も使っています。MariaDBをそのままバックエンドとして使うと、水責め攻撃を受けると、先ほどお見せしたようにランダムな文字列で来ますからキャッシュがまったく有効に働かないんですね。都度、PowerDNSがバックエンドのMariaDBに対してクエリを発行し、SQLを発行して、これが1つ1つ、レイテンシにしたら0.001秒とかで返るのだと思うのですけれども、それでも比較的重たい処理になってCPUを使うので応答が遅延し、結果的にPowerDNSがダウンする、みたいなことが起きます。そうするとDNSサーバが落ちてしまうので、お客様に影響が出るということが起きていました。

つづきは後編で

本記事では、DNSサーバへの攻撃手法や、実際に発生したさくらのクラウドのDNSアプライアンスへの攻撃の様子を紹介しました。続く後編の記事では、このような攻撃に対してどのような対策を行ってきたかを紹介します。

発表資料