防御は敵を知ることから「DNSサーバ攻撃」編

DNS（Domain Name System）とは？

DNSの仕組みを悪用したセキュリティ攻撃が後を絶ちません。どのような攻撃なのかを説明するために、まずDNSの仕組みを簡単に説明します。

Webブラウザなどからインターネットにアクセスするときには、通常ホスト名（例：www.example.com、この中の""example.com""をドメインという）で宛先を指定します。この際に、ホスト名をIPアドレスに変換する仕組みが必要です。この仕組みをDNSと呼びます。

Webブラウザなどインターネットにアクセスするアプリケーションは、社内あるいはインターネット・プロバイダ内に存在するレゾルバと呼ばれるサーバに宛先のホスト名を渡します。

レゾルバは、自分のキャッシュにそのホスト名が存在すれば対応するIPアドレスを返します。キャッシュにない場合には、権威DNSサーバと呼ばれる、世界中のドメインとIPアドレスの対応表を持つサーバ（実体は1つのサーバではなく複数サーバのツリー構造になっている）に問い合わせます。

レゾルバにはキャッシュを持たず権威DNSサーバに問い合わせをするだけのものもありますが、レスポンスの向上と無駄なパケット送信の削減のために、多くのレゾルバはキャッシュを持ちます。キャッシュを持つレゾルバを「キャッシュDNSサーバ」（以下「キャッシュサーバ」）と呼びます。

DNSサーバ攻撃の２つの代表的な攻撃手法

DNSキャッシュポイズニング攻撃

DNSの仕組みを悪用するセキュリティ攻撃の手法は、DNSキャッシュポイズニングと呼ばれています。悪意のある攻撃者が、キャッシュサーバに偽のDNS情報を送り込むことで、攻撃者のサーバにアクセスさせたり、キャッシュサーバの機能を停止させたりします。

まず攻撃者は、キャッシュサーバに成りすましたいホストのIPアドレスを問い合わせます。キャッシュサーバは、キャッシュにそのホスト名がない場合は、権威DNSサーバに問い合わせに行きます。

攻撃者はその応答が返って来る前に、権威DNSサーバからの応答に見せかけた偽のDNS情報を同じキャッシュサーバに送り込みます。成功すると、そのホストにアクセスしようとすると攻撃者のサーバにアクセスすることになったり、そのホストを見つけられなくなったりします。

カミンスキー攻撃

キャッシュサーバはキャッシュにDNS情報が存在する限りは、権威DNSサーバに問い合わせをしないので、キャッシュの存在時間（TTL）を長く設定することが有効な対策でした。ところが、2008年にセキュリティ研究者のダン・カミンスキー氏により、新たなキャッシュポイズニング攻撃法が発表されました。

これは、キャッシュサーバに対して、ドメインは実在するが、存在しないホスト名で問い合わせる（例：53uo21xx7.example.com）ことで、キャッシュサーバから権威DNSサーバに強制的に問い合わせをさせるという攻撃法です。

キャッシュのTTLを長くしても強制的に問い合わせが発生するため、繰り返し攻撃すれば成りすましに成功する確率が高まります。この攻撃法は、発表者の名前をとって「カミンスキー攻撃」と呼ばれています。

こんなサーバが危ない

カミンスキー攻撃は、繰り返し攻撃することで成功率が高まる攻撃方法なので、成功確率を下げることが有効な対策になります。

そのため、カミンスキー攻撃の発表後のDNSサーバソフト（BIND）には、ソースポートランダマイゼーションという機構が標準装備されました。これは、DNSサーバのポート番号をランダムに変化させる防御法で、ポート番号を固定しているDNSサーバと比較すると、カミンスキー型攻撃の成功率が大幅に低下します。

しかし、世界でも日本でも、古いバージョンのDNSサーバがかなり残っていて、これらが標的になった場合には、高い確率でカミンスキー攻撃が成功してしまいます。

さらに危険と言われているものが、オープンリゾルバという、誰からの検索要求にも応答してしまうキャッシュサーバの存在です。これは、BINDの不適切な設定によるものですが、世界中にかなりの数のオープンリゾルバが存在すると推測されています。

オープンリゾルバは、一度カミンスキー攻撃が成立してしまうと、その後はDNSリフレクタと呼ばれるDoS攻撃（不正リクエストによるサービス停止攻撃）の踏み台になる可能性があります。

最大の被害は社会的信用の失墜

オープンリゾルバへの攻撃として有名なのは、2013年3月に発生した、スパム対策組織のSpamhaus Projectと米Cloudflare社へのDDoS（分散DoS）攻撃です。

まずSpamhausのオープンリゾルバが攻撃され、そこからDDoS攻撃がはじまりました。そこで、Spamhausは協力関係にあるCloudflareに支援を要請しましたが、Cloudflareのサーバも1週間にわたるDDoS攻撃を受け、一時期は300Gbps以上のトラフィックが観測され、ヨーロッパを中心に遅延や通信障害が発生しました。

出典：総務省「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会」
　　　http://www.soumu.go.jp/main_content/000277249.pdf

日本では、2015年7月に、DNSソフト「BIND 9」の脆弱性をねらったDoS攻撃で、レンタルサーバサービスを提供するクラウドサービス事業者のDNSサービスが停止する障害が発生しました。

出典： Telecom-ISAC Japan（一般財団法人日本データ通信協会 テレコム・アイザック推進会議）齋藤 和典
　　　「セキュリティ関連の話題（脆弱性対応・攻撃対応）」2015年11月19日
　　　 https://www.nic.ad.jp/ja/materials/iw/2015/proceedings/d1/d1-saitou.pdf

現在、DNSサーバ攻撃による被害は、DoS攻撃やDDoS攻撃による業務停止や通信障害などですが、元来は成りすまし目的の攻撃なので、各種情報の盗難や改ざんなどの被害も起こり得ます。

しかし、何よりも大きい被害は、自社のサーバがこれらの攻撃や犯罪の踏み台にされたことによる社会的信用の失墜です。

他にもまだある！ ゾーン転送要求による攻撃

DNSキャッシュポイズニングやそれから派生するDoS攻撃・DDoS攻撃の他に、ゾーン転送という仕組みを悪用したセキュリティ攻撃もあります。

負荷分散のために同じゾーン（ドメインを分割したうちの1つ、分割しなければドメインと同一）内に複数台のDNSサーバを設置することができますが、その際にゾーン内でDNS情報を同期する必要があります。

そのために発行されるのがゾーン転送要求です。外部からゾーン転送要求を送り込むことができれば、その応答を見て内部構成を把握し、続けて不正なDNS情報を送り込むことが可能になります。

DNSサーバ攻撃への対策は？

対策としては、まず、DNSソフトであるBINDの最新版を入手し、最新のセキュリティパッチを充当することです。

次に、ソースポートランダマイゼーションを有効にしているかを確認し、無効ならば有効にします。 また、自社のDNSサーバがオープンリゾルバになっていないかを確認し、なっていれば無効化します。ただし、これらの対策を講じていても、100%安全ではありません。普段から、不自然なアクセスがないか、既に攻撃を受けていないかを監視することも必要となります。

この機会に、ぜひ、上記の対策を行うほか、不正アクセスやセキュリティ攻撃を監視するサイバー攻撃対策ツールについても、導入検討を進めておきましょう。