分散サービス拒否（DDoS）攻撃を仕掛けるDNS ampとは？：Tech TIPS

連載目次

解説

●DNSサービスを使った分散サービス拒否攻撃、「DNS amp」の発生が懸念

　インターネット上での名前解決サービスを提供するDNSは、インターネットにおける非常に基本的なサービスであるが、これを利用した大規模な分散サービス拒否攻撃（DDoS攻撃）の発生が懸念されている。細工したDNS要求をBOT（攻撃を行うコンピュータ）に送ると、対策の施されていないDNSサーバを“踏み台（攻撃の足がかり）”にして、攻撃対象に大量のDNSパケットが送信される。これにより、処理能力やネットワーク回線が混雑、飽和し、正常な利用ができなくなる。

　小さなDNS要求パケットを送るだけで、その何倍ものサイズのパケットを生成させる（増幅＝amplification＝させる）ことができるので、「DNS amp」などと呼ばれている。本TIPSでは、その攻撃に仕組みについて解説する。Windows OSにおけるDNS amp対策については、TIPS「DNS ampの踏み台サーバになるのを防ぐ（コンテンツ・サーバ編）」「DNS ampの踏み台サーバになるのを防ぐ（キャッシュ・サーバ編）」を参照していただきたい。

• DNS の再帰的な問合せを使った DDoS 攻撃の対策について（JPRS）
• DNS の再帰的な問合せを使った DDoS 攻撃に関する注意喚起（JPCERT/CC）
• DNSの仕組みを悪用したDDoS攻撃が発生、国内サーバも「踏み台」に（ITmediaエンタープライズ）
• JANOG18 Meeting:プログラム　アブストラクトの「DNS amplification attacks」参照（JANOG）
• @police研究開発成果の「DNSの再帰的な問い合わせを悪用したDDoS攻撃手法の検証について」参照（@police）
• DNS amp（jargonaut [ITmedia オルタナティブ・ブログ]）
• DNS amp 2（jargonaut [ITmedia オルタナティブ・ブログ]）

●2種類のDNSサーバ

　一般に、DNSサーバと呼ばれるコンピュータもしくはサービスには、大きく分けて2つの機能がある。DNSゾーン情報を外部に対して提供する「コンテンツ・サーバ」と、クライアントからの名前解決要求を処理する「キャッシュ・サーバ」である。後者は、コンテンツ・サーバが提供するDNS情報（例：www.example.co.jpのIPアドレスはAA.BB.CC.DDなど）へアクセスし、必要ならば上位ドメインに再帰的に問い合わせたり（例：example.co.jp→co.jp→jp→. ドメインへ順に問い合わせる）、結果をキャッシュしたりするので、キャッシュ・サーバと呼ばれている（フル・サービス・リゾルバとかスタブ・リゾルバなどと機能は同じ）。

• ネームサーバの3つの働きとは（Master of IP Network）

　キャッシュ・サーバを自組織内に用意すると、名前解決のたびにインターネットへアクセスする必要がなくなり、名前解決のパフォーマンスが向上する。自組織内に用意しない場合は、通常はプロバイダの提供しているDNSサーバをキャッシュ・サーバとして利用することになる。

　コンテンツ・サーバの機能は、DNSドメインを定義してインターネットに公開する場合、必ず必要になるものである。これに対してキャッシュ・サーバは、DNSドメインを定義しない場合には特に必要ないし、たとえ自分で用意する場合でも、インターネット側からアクセスできるようにしておく必要はない。だがDNSサーバによっては、コンテンツ・サーバの機能とキャッシュ・サーバの機能が一体化しており（例：Windows OSのDNSサービス）、分離することができない。そのため、コンテンツ・サーバとして用意したサーバが、キャッシュ・サーバとしても利用されてしまう可能性がある。

　DNS ampは、このキャッシュ・サーバの機能をインターネット側から利用して行うDDoS攻撃である。キャッシュ・サーバの機能は、通常はインターネット側から利用する必要はないので禁止しておくべきなのだが、DNS amp対策をしていないDNSサーバでは、インターネット側からもこの機能が利用できるようになっている。DNS ampを仕掛けるクラッカーは、このようなDNSサーバを見つけ出し、踏み台サーバとして利用する。

　インターネット側からキャッシュ・サーバの機能が利用できるかどうかは、Windows OSならばnslookupコマンドなどで確認できる。自組織のDNSサーバに対して、外部からnslookupコマンドを実行してみればよい（別のプロバイダ経由で調査すること）。例えば、以下はwww.atmarkit.co.jpというFQDN名を、ns.example.jpというDNSサーバに問い合わせているところである。

　この例では、example.co.jpドメインのDNSサーバを調べ、そのDNSサーバ（ns.example.co.jp）に対してDNSの名前解決を要求している。結果が返されているが（（1））、これはキャッシュ・サーバの機能が外部（インターネット）から利用できる、つまり踏み台として利用可能であるということを表している。

　これに対して正しく対策されたDNSサーバであるns02.example.comでは、応答が戻ってこなかったり、次のように、問い合わせ結果とは異なる応答（ルート・サーバ情報）が表示されたりする。

●BOTによるDNS要求の増幅

　DNS ampでは細工されたDNS要求を利用する。通常、DNS要求やその応答では、UDPのパケットが利用される（あて先ポート番号は53番）。DNSのクライアントが、DNSサーバに対してDNS要求パケットを送信すると、それに対する応答がDNSサーバから返される。

正常なDNS要求とその応答パケット
DNS要求はUDPで送信されるが、その送信元アドレスにはパケットを送信したコンピュータ（この例ではPC1）が入っている。そのため、DNS要求を送信すると、その応答は送信元（PC1）へ送り返される。

　だがDNS ampではDNS要求のパケットを細工し、送信元IPアドレス（IPパケットに埋め込まれているIPアドレス情報）を別のコンピュータ（攻撃対象のコンピュータ）に偽装して送信する。実際の送信元はBOTコンピュータ（攻撃用プログラムを仕組んだ、攻撃に加担するコンピュータ）であるが、DNSサーバから見ると、送信元は攻撃先のコンピュータになっている。

DNS ampのDNS要求とその応答パケット
DNS ampでは、送信元IPアドレスが実際のBOTコンピュータではなく（この例ではPC1）、攻撃先のIPアドレス（この例ではPC2）に偽装されているため、DNSキャッシュ・サーバはDNS応答を攻撃先へ返してしまう。これにより、特定のIPアドレスを“攻撃”することができる。DNS ampでは、わざと大きなパケットを応答として返すようなDNS要求を送信する。UDPはTCPと違い、通信に先立ってセッションを確立しないため、どこのIPアドレスから送られてきたパケットであるかを検証する手段がない。そのため、送信元IPアドレスを信じて、そこへ送り返そうとする。

　DNSサーバがこのようなDNS要求パケットを受け取ると、その応答を、偽装されたあて先、つまり攻撃先のコンピュータへ返信する。また、このときに利用されるDNS要求は、TXTリソース（文字列データを定義するリソース・レコード）などが使われる。使用するDNSのプロトコルにもよるが、TXTリソースでは最大4Kbytesのテキスト・データを定義することができるので（プロトコル・ヘッダも含むサイズ）、小さな要求パケットを送るだけで、大きな応答パケットに増幅させることができ、攻撃の効率がよい（DNSの拡張機能を利用しない場合は、ヘッダも含めて512bytesまで）。なお攻撃に使われるDNSレコードは、どこかのドメイン上に正規のレコードとして（あらかじめクラッカーが）定義しているものなので、キャッシュ・サーバがその応答を拒否することはない。

●DNS ampのDDoS攻撃

　DNS ampでは、以上のような細工されたDNS要求パケットを、多数用意したBOTコンピュータ（セキュリティ的に脆弱で、BOTプログラムに侵入され制御を奪われた、攻撃用のコンピュータ。インターネットをスキャンして集める）から送信させることにより、特定のIPアドレスやサイトを攻撃する。このようなDDoS攻撃の可能性は以前から指摘されていたが、インターネットの普及とともに攻撃も行いやすくなり（攻撃に利用できるコンピュータの数が多くなっているし、BOTなどの技術も進化、巧妙化しているため）、危険性はより高まっている。

DNS amp
DNS ampでは、送信元IPアドレスが実際のBOTコンピュータではなく、攻撃先のIPアドレスに偽装されているため、DNSキャッシュ・サーバはDNS応答を攻撃先へ返してしまう。これにより、特定のIPアドレスを“攻撃”することができる。

●DNS amp対策

　DNS ampに対する対策であるが、残念ながら攻撃を受ける側の対策はそう多くない。自分自身で送信していないDNSパケットに対するDNS応答は無視したり、ブロックしたりするなどの対策が有効である。しかし大量のネットワーク・パケットの到来による回線の飽和は対策が困難だ。

　これに対し、DNS ampに加担するDNSサーバ（踏み台DNSサーバ）にならないための対策はそう難しくない。踏み台サーバを所有していることは、対外的な信用にもかかわることであるし、プロバイダなどからネットワーク的に切断されるなどの措置が取られることがあるので、早急な対策が望まれる。

　踏み台対策としては、コンテンツ・サーバとキャッシュ・サーバを完全に分離するのが一番有効である。コンテンツ・サーバはインターネットからアクセスできる必要があるため、DNS要求を受け取らないようにすることはできない。だが、そのサーバ上でコンテンツ・キャッシュ機能（リゾルバ機能）が無効になっていれば、踏み台として利用されることはなくなる。またキャッシュ・サーバが必要なら、コンテンツ・サーバとは別に組織内に用意し、外部（もしくは許可されていないネットワーク）からはアクセスできないようにファイアウォールを設定しておけばよい。

　DNSソフトウェアによっては、コンテンツ・サーバとキャッシュ・サーバ機能を別々に設定、稼働させたり、アクセス制御を行ったりできるが、Windows Server OSに付属のDNSサービスでは、このような設定は利用できない。そのため、2台のDNSサーバを用意し、完全に分離する方法が望ましい。詳細についてはTIPS「DNS ampの踏み台サーバになるのを防ぐ（コンテンツ・サーバ編）」「DNS ampの踏み台サーバになるのを防ぐ（キャッシュ・サーバ編）」を参照していだきたい。

「Windows TIPS」