意外と知られていない？ DNSが抱えるセキュリティ問題

12月6日、Internet Week 2006のセッションの1つとして行われた「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。

[高橋睦美，ITmedia]

　12月5日から8日にかけて「Internet Week 2006」が横浜で開催された。このうち12月6日に日本ネットワークインフォメーションセンター（JPNIC）が主催した「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。

なりすましと反射を悪用したDoS攻撃

　取り上げられた課題の1つは、偽装した発信元IPアドレスから不特定多数のDNSサーバにクエリを投げかけ、被害者に多数のパケットを反射させてDoS状態に陥れる「DNS amplification attack」だ。2006年3月には実際にその被害が発生し、警察庁からも関連するレポートが公表されている。

　この攻撃では、IPアドレスを偽装してDNSクエリを投げつけることにより、被害者に応答を集中させる。たたでさえクエリに対する返答は大きくなる上、インターネット上の複数のキャッシュサーバを利用することで、リプライは何倍にも「増幅」（Amplify）される。被害者からすれば、何もしていないのに突然大量のパケットがやってきて、帯域が埋め尽くされてしまう。

　「この攻撃はUDPを使っているため簡単に利用できる。また増幅率も大きく、最大で60倍になる場合もある。さらに、リゾルバ（DNSキャッシュ）が世界中に分散しているため、いろいろなソースからの攻撃を（被害者に）ぶつけることができる」とインターネットイニシアティブの松崎吉伸氏は指摘した。

　当面の攻撃を防ぐには、DNSキャッシュのサービス範囲を限定し、「オープンリレー状態」をなくすことだと松崎氏。また、DNSサーバがハックされ、この攻撃への悪用を狙って大きなレコードを返すよう設定を変更されてしまう可能性もあるので、運用者としては脆弱性をふさいでおくこともポイントという。

　さらに、より根本的な解決策として、送信元IPアドレスを検証して偽装されたパケットを通さないようにする「Source Address Validation」がある。「ただし、一気にすべてのところでSource Address Validationを導入する、というわけにもいかないだろう」と松崎氏は述べ、すぐにでも可能なアドホックな対策として、DNSサーバのサービス範囲をきちんと限定することを挙げた。

　特に、ISPや企業・組織が運営しているDNSサーバだけでなく、ブロードバンドルータなどUDPリレー機能を搭載している機器も踏み台に悪用される可能性があるという。「自分がどの範囲にサービスを提供しているかをきちんと定義し、それ以外のアクセスは禁止すべき」（同氏）

　また松崎氏は、ボット／ボットネットがDNS amplification attack攻撃に関与している可能性にも触れた（関連記事）。

　「DNSクエリを投げつけるよりも、直接攻撃するほうが（攻撃者にとっては）効果的ではないか」という会場の指摘に対し、松崎氏は「攻撃リソース分散させることによって各々のレートを抑え、攻撃を止められないようにすることができる。また、反射攻撃によって本当の攻撃元を隠し、何度も別の用途に使えるようにしているのではないか」と作者側の動機を分析している。

設定によっては飛躍的に高まる「毒入れ」攻撃の可能性

　DNSサーバというのは、クエリを投げれば基本的に正しい答えが返ってくると期待されている。しかしその仕様の脆弱な部分を突いて、偽の情報、つまり「毒」をDNSサーバに食べさせる「キャッシュポイズニング」という攻撃手法が存在しており、以前からその危険性が指摘されてきた（関連記事）。

　日本レジストリサービス（JPRS）の民田雅人氏によると、DNSリソースレコード（DNS RR）のTTL（Time To Live：キャッシュの保持期間）の設定によっては、「毒」を食べさせることができる確率が飛躍的に高まるという。

　DNS応答パケットのIDをランダムに変えながら送信していくと、一定の確率で「当たり」が出て、キャッシュポイズニング攻撃が成功する。

　この場合、大量のクエリリクエストが生じるため、攻撃の存在を検出しやすいのだが、TTLが短くかつアクセスが多いDNSサーバの場合、意外と高い確率で「ウソの情報を突っ込むことができてしまう」（民田氏）。しかも、低レートで攻撃が成功する確率が高まるため、検出がより困難になる可能性がある。

　民田氏は実際に、権威DNSサーバ2台、攻撃対象のキャッシュサーバが100台、RTT（Round-Trip Time）が20msという環境を仮定して、TTLの条件を変えて攻撃成功確率を計算してみた。AレコードのTTLが8万6400秒の場合は、1台当たりの攻撃レートを100ppsとしても、成立確率が50％を越えるまで約15カ月という時間が必要だった。それが、TTLを30秒とすると、攻撃レートを前者の10分の1の10ppsとしても、38時間で攻撃成功確率が50％を越える。

　民田氏はこの計算結果を踏まえ、「極端に短いTTL設定を避ける」「DNSサーバの数を増やす」、また実装によっては「固定のポートを用いないようにする」といった対策を挙げた。また、より根本的な対策として、DNS amplification attackへの対策同様、送信元IPアドレスを偽装したパケットを出せないようにするフィルタの導入やDNSSECの導入が必要だとしている。

512バイトの壁あれこれ

　DNS Dayではまた、インターネット総合研究所（IRI）の伊藤高一氏と住商情報システムの森拓也氏による「512バイトの壁」にまつわるプレゼンテーションも行われた。

　DNSは基本的にUDPでやり取りする以上、その長さが512バイトを超えると応答が返ってこず、通信できなくなる。そこで代わりにTCPを用いて通信する（TCPフォールバック）か、拡張仕様である「EDNS0」（Extension mechanism for DNS）を用いることになる。両氏は、そこから生じるさまざまな影響について触れた。

　まず、512バイトの壁を越える可能性だが、伊藤氏によるとIPv6のAAAAアドレスのほか、ラウンドロビンを多数設定する場合などがある。また今後、DNSSECやDomainKeysが本格的に実装されてきた場合も、長さが512バイトを超える可能性があるという。

　512バイトを超えた場合のDNSサーバの挙動としては、TCPフォールバックかEDNS0のいずれかを取ることになるが、森氏によると、いずれの場合も通信に影響が生じる恐れがある。TCPフォールバックの場合は、EDNS0の場合と比べレスポンス低下が見られ、「やっぱりTCPの場合はそれなりにペナルティが大きい」（同氏）。一方EDNS0の場合、フラグメントされたパケットが送信される可能性があり、「パケットドロップ率が高い環境だと、とても悲しいことになる」という。

　結論としては、「やはりEDNS0を使おう」というところに落ち着くが、ネットワーク状況に影響を受けやすいこと、またすべてのサーバがEDNS0を実装しているわけではないことに注意が必要だという。