 |
 |
記事検索 |
イベントレポート |
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
「DNS Day」では、安定運用とセキュリティが最大の関心事に |
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
パシフィコ横浜で開催中の「Internet Week 2006」で6日、日本ネットワークインフォメーションセンター（JPNIC）の主催によるカンファレンス「DNS Day」が行なわれた。今回のテーマは、DNSにおけるセキュリティ再考。プログラムの前半では運用や取り組みに関する報告、最新トピックの紹介などが行なわれ、後半ではセキュリティにまつわる話題が提供された。 ● JPドメインのトピックは、DNS更新間隔の短縮
最初のプログラムでは、日本レジストリサービス（JPRS）の白井出氏によりJPドメイン名を管理するJP DNSに関する報告が行なわれた。白井氏はこの中で、今年一番のトピックは3月から4月にかけて実施した更新時間の短縮だと語り、従来の24時間間隔から15分間隔まで縮めるために行なったことや、その後の運用状況について報告した。 続いて、WIDEプロジェクトの関谷勇司氏がルートDNSサーバーの運用に関して報告。近年のルートDNSサーバーはAnycastという技術によりかなりの数が運用されているが、その効果などについて報告された。
● lame改善のためにはゾーンの委任停止も
AS112プロジェクトとは、インターネット上に流れ出てくるプライベートアドレスのクエリ（要求）を処理するための活動。ルートDNSサーバーなどへの無意味なクエリを減らすことなどが目的で、日本国内ではWIDEプロジェクトとOCNが設置している。 吉村氏の調査によれば、OCNの場合、プライベートアドレスのクエリは逆引きの場合で約20％、全体で見ると4％程度の量があり、ゾーンのオーソリティ情報を問い合わせるSOAのクエリでは5～20％になるという。また、dynamic updateの場合は6割がマスユーザーのWindows端末だと推測できるが、法人ユーザーも相当数あり、社内のホスト名が外部に漏れる危険性があることなどもあわせて示された。 吉村氏は、本来プライベートアドレスは閉じたネットワークの中で処理されるべきものであり、「AS112が無い世界がよい世界」だとして自身のネットワークを確認してみて欲しいと締めくくった。 小山氏からは、lame delegationの改善に関するポリシーの実装提案がされた。lameとは、DNSサーバーが適切に運用されていない状態を指し、利用者から見ると権威ある名前解決が行なわれない結果となる。JPNICでは逆引きDNSを管理しており、lame delegationを減らすことが課題の1つとなっている。 ここでは、JPNICから連絡の取れるアドレスレンジに対して一定期間確認を行ない、lameと判定された際に出される改善要求にもかかわらずlameが解消されない場合には、該当する逆引きゾーンの委任を停止する形が提案された。今後は、この提案をより現実的なものとするために、さらに検討を重ねていくとしている。 DNSとドメイン名に関する世界的な政策動向は、正引きについてはJPRSの宇井隆晴氏が、逆引きに関してはJPNICの川端宏生氏が報告した。宇井氏からは、ICANNやIETFで話題となっている内容が報告され、川端氏からはポリシーに関する動向や策定、逆引きゾーンの委任に関する報告がなされた。 ● DNSパケットの肥大化による影響は
後半最初の発表は、インターネット総合研究所（IRI）の伊藤高一氏と住商情報システムの森拓也氏による「コンテンツデータ肥大化の問題とその対応」。今後予想されるDNSパケットの肥大化によって引き起こされるDNSへの影響が提示された。 DNSは、本来の機能である名前解決以外にも、例えばスパム対策のためのドメイン認証などで使われるようになってきている。しかし、DNSのパケットがUDPで通信する場合は、そのメッセージの大きさに512バイトという制約がある。現在でもラウンドロビンをいっぱい設定するなど、ケースによっては512バイトを超える事例が存在するが、今後、DKIMやDNSSECが一般化してくると問題が顕在化する可能性があるということだ。 DNSでは、UDPで出したクエリに対してtruncated（切り捨てられた）な応答が返ってくるとTCPにフォールバックしたり、あるいは最初からより大きなサイズを扱うことのできるEDNS0（Extension mechanism for DNS）を使うことになっている（実装によってはEDNS0にフォールバックするものもある）。これがうまくいかないと、DNSによる名前解決が失敗することになるケースが出てくる。また、実際には、通常のUDPで失敗したら単にフォールバックすればよいといった簡単な話ではなく、例えばEDNS0を使うとフラグメント化されたパケットが送られることになり、ドロップ率が上がるとしんどそうだとか、やはりTCPは重いといった内容が簡単な実験結果とともに示された。 今回の発表は、DNSメッセージの大きさが512バイトを超える際にDNSがどのようなことになるかを検討したものだが、全体的に見れば「EDNS0を使おう」という結果になったということだ。ただし、EDNS0はネットワークの状況に影響を受けやすい点には注意が必要であり、また、世の中みんながEDNS0に対応しているわけではないのでむやみにTCP 53番ポートをふさがないようにと付け加えている。 ● DNSレコードのTTL短縮でポイズニングが成功し易く、試算値を発表
DNS amplification attacksとは、送信元IPアドレスを偽装したDNSクエリを使いターゲットを攻撃する手法である。相手の帯域を埋めるために、数多くのパケットや増幅した大きなパケットを送りつけることで実現するが、そのためにDNSの仕組みが利用される。 松崎氏はこの仕組みを具体的に説明し、これを防ぐためには、必要な範囲にだけサービスを提供することや、送信元IPアドレスを検証するためのSource Address Validationを導入して欲しいとした。 民田氏の発表は、DNSリソースレコードのTTL（Time To Live：保持期間）が短いと、キャッシュサーバーへの（虚偽のデータを挿入する）ポイズニングが成功しやすくなるというものだ。DNSが使用するクエリIDは16ビットしかないため、そのIDを推測しやすい。気長に嘘のDNS応答をキャッシュサーバーに送り続ければ、そのうちに当たってしまう。この「そのうち」が、意外に短いということだ。 1つの例として、権威DNSサーバーが2台、攻撃対象のキャッシュサーバーが100台、RTT（Round-Trip Time：あるデータを送ってから相手の確認応答が返ってくるまでにかかる時間）が20msと仮定して、AレコードのTTLが86,400秒の場合と30秒での計算値が示された。 それによると、前者の条件の場合は1台あたりの攻撃レートを100pps（Packet Per Second）として、いずれか1台のキャッシュサーバーへのキャッシュポイズニングが成立する確率が50％を超えるまでの時間に約15カ月要するが、後者の条件では攻撃レートを10分の1の10ppsとしても50％を超えるまでの時間がたったの38時間となってしまうということだ。 もちろん、これは条件を仮定した上での計算値だが、TTLを短くすることにはリスクがあることが改めて示された格好だ。民田氏は、この問題を避けるためにはDNSサーバーの数を増やすか、インターネットに対してIPアドレスを偽装したパケットを出せないようにすることだとした。 関連情報 ■URL Internet Week 2006 http://internetweek.jp/ ■関連記事 ・ JPドメイン名DNSの更新間隔が短縮、ドメイン登録後15分で利用可能に（2006/04/05） ・ 日本のネットワークオペレーターが集結する「JANOG18 Meeting」開催（2006/07/20） ・ 米SANS、大規模なDNS書き換えを行なう「DNSポイズニング」攻撃の概要を公表（2005/04/05）
（ 遠山 孝 ）
- ページの先頭へ-
|
