「DNSキャッシュポイズニング」とは

DNS はインターネットの創成期から通信の重要な役割を担うシステムとなっていますが、近年、 DNSサーバー が DNSキャッシュポイズニング という攻撃に晒される危険が増えてきています。これはどういった攻撃で、どんな問題があるのでしょうか？。

DNSサーバーには、 および で説明しているとおり、大きく分けると二つの役割があります。

１．他のDNSサーバーからの問い合わせに対して「権威ある回答」を返す役割。

２．他のDNSサーバーに問い合わせて「権威ある回答」を キャッシュ する役割。

キャッシュポイズニングにより直接的に被害を受け、問題になるのは２．の DNSキャッシュ 機能の部分です。

DNSがその分散システムによって特定のDNSサーバーへの負荷集中を避けるシステムになっていることは、 で説明したとおりですが、この他力本願にも似た仕組みがきちんと機能しているのは、DNSキャッシュサーバーが、

「自分自身が他のDNSサーバーに問い合わせた 名前解決 情報のキャッシュ。」

という単純動作しているだけであって、他のパソコンやサーバーから一方的(強制的?)に送りつけられたその他の名前解決情報は取り扱わない。という理由によります。

しかしながら、悪意を持った第三者がDNSキャッシュサーバーの中のDNSキャッシュの情報を意図的に書き換えることができたとしたらどうでしょう。

そうすると、そのDNSキャッシュサーバーを利用しているパソコンのユーザーを意図的に別のWebサイトに誘導して、フィッシング詐欺などに誘うことが可能になります。

DNSキャッシュサーバーの書き換えによる不正攻撃

こういった、DNSキャッシュサーバーに対する不正な攻撃を DNSキャッシュポイズニング と呼びます。

そして以前は「理論的に可能であっても現実的には実施困難」と思われていたこのDNSキャッシュポイズニングが、2008年7月、Dan Kaminsky氏によって「現実に実行可能」であることが解明され、その具体的な攻撃方法は氏の名前をとって カミンスキー型攻撃 あるいは カミンスキー・アタック と呼ばれるようになりました。

このカミンスキー型攻撃によるキャッシュポイズニングを回避する方法については様々なアイデアが発表されてきましたが、その手法として確立されたのが DNSSEC と呼ばれる手法です。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー

関連ページ・ DNSSECジャパンのサイトへ

DNSSECの登場

DNSSEC の仕組みを簡単にいうと、

「問い合わせる側の DNSキャッシュ サーバー と問い合わせを受ける側の DNSサーバー との間で、ゾーン転送を行う際に一緒に鍵交換による照合を行い、一方的に送り付けられる署名のない 名前解決 情報を一切受け付けないようにする。」

という意外に簡単なものです。

DNSSECによる名前解決改ざんの防止

一般にこの「鍵交換法」と呼ばれる技術を使った、

「デジタル署名で クライアント とサーバーでやり取りされる情報の正当性を保証する。」

という手法は、別に目新しいものではなく、 Webサーバー や メールサーバー を始めとした多くのサーバー アプリケーション ではずっと以前から当たり前のように使われているものです。と、こんなことを書くと、

「そんなに簡単に問題を解決できる手段があるのなら、問題が起こる前にどうしてやっておかなかったの？。」

と思われるかもしれませんので、少しだけその背景を説明します。

DNSサーバーの役割は、

「他のインターネットサービスを便利かつ快適に運用するための名前解決。」

であり、Webサーバーやメールサーバーを利用するための「裏方の事前手続き」にすぎません。

そしてその「裏方の事前手続き」はできるだけ短時間に済ませ、本来の「目に見える」サービスを迅速に開始してやるのが理想です。

しかし DNS が設計された1983年頃といえば、現在と比べると通信速度も遅く、サーバーの処理能力も恐ろしく低いものでしたから、

「DNSは パケット が小さく通信手続の少ない UDP を使い、サーバー負荷の大きな認証作業は避け、できるだけ簡単に処理を終わらせる。」

という方法をとらなければ、快適なインターネット環境を実現できなかった、という事情がありました。

一方、前のパートで DNSキャッシュポイズニング について 「理論的に可能であっても現実的には実施困難」 とされてきたのは、DNSキャッシュポイズニングを行うには大量の攻撃試行が必要とされ、それが可能になる程の通信速度も処理速度もなかった時代には問題にされなかったからです。

しかし通信が高速になり、攻撃する側も攻撃される側も ホスト機 の性能が飛躍的に向上してしまった結果として、これが現実的な脅威になってしまった、というわけです。

もちろん他方では、現在の通信速度があれば鍵交換の手続きに必要なパケット量の増加も許容範囲ですし、現在の高性能なホスト機にかかれば鍵の確認処理の負荷増大も大きな問題ではなく、DNSSECを実装したからといってインターネットの応答に明確な影響が出ることは考えなくても良いレベルになっており、遅まきながら対策が始まった、という流れになります。

さて、DNSSECは ドメイン名 単位でデジタル署名を行いますが、すでに ルートサーバー では実装が済み、".com"などの著名なgTLD、日本の".jp"などいくつかの"ccTLD"も対応を済ませており 、これから徐々に標準的な実装が進んでゆくものと想像されます。

一方 RHEL クローン である CentOS に側の対応状況ですが、2011年にリリースされた CentOS6 では、DNSSECに対応した BIND バージョン "9.7.x" が標準で インストール されます。

また、 CentOS5 では、標準ではDNSSECに未対応のバージョンのBINDがインストールされますが、これを アンインストール して yum よりバージョン "9.7.x" をインストールすることでDNSSECに対応することができるようになっています。

CentOS4以前や WBEL では残念ながら ディストリビューター からパッケージが準備されていないので、DNSSEC対応版のBINDを独自に入手してインストールする必要があります。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー

関連ページ・ DNSSECジャパンのサイトへ

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

DNSSECと自宅サーバー

実際に DNSキャッシュポイズニング により被害を受けているのは、金融機関系の FQDN に対する改ざんで、目的はいうまでもなくフィッシング詐欺です。

改ざんの対象となるのは当然のことながら多くの クライアント が利用する ISP の DNSキャッシュ サーバー ですから、これらが DNSSEC を実装し、かつ金融機関系の ドメイン名 にきちんとDNSSECに基づいたデジタル署名がなされていれば、こういう被害は防止できることになります。

では、このサイトで解説しているような、主に自宅用途の DNSサーバー を運用する方は、このDNSSECとどう付き合っていけば良いのでしょうか。

まずどうするのかを考える前提として認識すべきことは、このDNSSECの実装は義務でも強制でもなく、あくまで 任意 ということです。いついつまでにDNSSECに対応しなければそのドメイン名は使用できなくなる、というようなことではありません。柔らかい言い方をすれば、

「世界中のDNSサーバー管理者とドメイン名の管理者が協力することで安全なDNS環境が構築できますから、是非ご協力いただけませんか？。」

という啓蒙によって危機意識の共有を促し「いずれ世界中のドメイン名とDNSサーバーがDNSSECに対応してくれたらいい。」という感じの活動です。

ですから慌てる必要はありません。DNSの仕組みを理解したうえで、「よし、協力しよう！。」思ったタイミングで対応すればそれでOKです。

１．自宅内DNSサーバーとしてのみ運用する場合

このセクションで解説しているタイプのDNSサーバーがこれに該当しますが、DNSSECの実装は基本的に不要となります。

DNSSECの実装は前のパートで説明したとおり、カミンスキー型攻撃によるDNSキャッシュポイズニングへの備えであることを思い出してください。

つまりこのケースでは、自宅のDNSサーバーに直接アクセスできるクライアントは自宅内のLANにしか存在しないわけですから、あなたやあなたの家族や友人などに限定されます。つまりその中に悪意をもってそのような攻撃を仕掛ける人がいない限りは心配する必要はありません。

もちろん原理的に突き詰めれば、例えばあなたの自宅にある Windows パソコンやAndroid端末などが外部の第三者に乗っ取られ、自宅内DNSサーバーが攻撃を受けるリスクはゼロではありません。

しかしながら、「DNSキャッシュポイズニング」による攻撃の目的がフィッシング詐欺などにあるとすれば、たかだか数人しかアクセスしないようなDNSキャッシュサーバーを改ざんしたところで、攻撃者にとってはまずメリットはなく、実質的な危険はないと考えられるわけです。

２．権威あるDNSサーバーとして運用する場合

固定IPでDNSサーバー構築 で解説しているタイプのDNSサーバーがこれに該当します。つまり、

「外向きには権威あるDNSサーバーとして、内向きには自宅内DNSキャッシュサーバーとして。」

動作するタイプです。

この場合、二つの点について考える必要があります。

一つ目は「権威あるDNSサーバーとして 」の動作に関してです。

権威ある名前解決情報として配信しているドメイン名が、既にDNSSECへ対応している場合、急ぐ必要はありませんが一応検討しておく必要はあります。

あなたがDNSサーバーで管理しているドメイン名にDNSSECによる署名がない場合、あなたのDNSサーバーが配信するゾーン情報は世界のどこかにあるDNSキャッシュサーバーの中で情報が改ざんされる可能性が存在することを意味します。

つまりこの場合、DNSキャッシュポイズニングで被害を受けるのはあなたのDNSサーバーでもあなた自身でもなく、あなたが配信しているゾーン情報をどのかのDNSキャッシュサーバーを通じて利用する世界中の誰か、ということになります。

従って、あなたが配信しているゾーン情報によって通販サイトや個人情報を取り扱うサイトが運営されており、その偽装サイトを作ることで悪意の第三者が利益を得ることができるという特殊な状況にあるならば、すみやかにDNSSECを実装し、配信するゾーン情報に正当な署名を付加することをお勧めします。

しかし SSL を実装する必要のない程度の趣味のホームページの運営や、個人的なメールの取扱いのレベルのドメイン名の利用であれば特に急ぐ必要はないでしょう。

二つ目はDNSキャッシュサーバーの動作に関してです。

振る舞いそのものは１．と変わらないのですが、権威あるDNSサーバーとしても動作しなければならないという事情から、 ポート番号 53 について ポートフォワーディング が設定されており、外部からの直接攻撃が可能になっている点が異なります。

所詮は個人運用の自宅サーバーですから、攻撃者が決め打ちで攻撃を仕掛けてくることはまずあり得ないと考えられますが、外側にポート番号53が開いていることは調べればわかることですから、無差別なポートスキャンにより IPアドレス を特定され、自動でDNSキャッシュポイズニングを仕掛けられる可能性は否定できないでしょう。

従ってこういう構成のDNSサーバーを運用している場合は、少なくともDNSキャッシュサーバー動作に関してのみDNSSECの実装を検討したほうが良いでしょう。もちろん、急ぐ必要はありません。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー

関連ページ・ DNSSECジャパンのサイトへ

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

DNSSECの将来

さて、ようやく規則と アプリケーション が整備された DNSSEC ですが、世の中のすべての ドメイン名 と DNSサーバー にこれが実装される日は、おそらくやってこないでしょう。

例えば WindowsOS には必須と呼ばれているアンチウイルスソフトも インストール が義務化されている訳ではなく、実際にアンチウイルスソフトを入れずにWindowsパソコンを使っているユーザーも数多く存在します。

自分を守るためのアプリケーションですらそうなのですから、まして自分に対する不利益というより、他人の不利益を防止するのが基本のDNSSECがそれ以上に普及するのは難しく、あるレベル以上には普及することなく、いつまでも普及のための啓蒙活動が続いてゆく、というオチになるはずです。

もちろん、今後DNSに何か新しいセキュリティ上の重大な問題が発見され、多くのエンドユーザーが重大な被害を受けるような事態に陥るとか、あるいは逆に、現在のDNSとは比べものにならないほどに快適で、エンドユーザーに多大な恩恵をもたらす新しい名前解決の仕組みが発明されて現在のDNSが淘汰されるとか、そういう大きな波が訪れないとも限りませんから、これは断言することはできません。

インターネットの考え方の根底には、オープンソース と同じ思想があり、

「公的機関による制限や規制は最小限とし、万人が求めるものは広く普及して標準化され、必要とされないものは淘汰されてゆく。」

という世界観があります。DNSSECはもちろん義務や規制ではありませんから、利用者が必要とすれば広まってゆくでしょうし、それほど必要でないということになれば普及は進まないわけで、実際にそれがどうなっていくかは世界中のインターネット技術者とユーザーの判断次第ということになるでしょう。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー

関連ページ・ DNSSECジャパンのサイトへ

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト