BIND 9のセキュリティ対策：実用 BIND 9で作るDNSサーバ（9）（2/2 ページ）

» 2003年09月09日 00時00分公開

ゾーンサーバの対策

ゾーン情報の改ざん対策

　現在のところ、namedプロセスやDNSの脆弱性を利用したゾーン情報改ざんの心配はありませんが、サーバそのものを乗っ取られてしまえばその限りではありません。

　BIND 9自体の対策については前出の「ユーザー権限の奪取対策」を参照していただくとして、BIND以外のアプリケーションや構成上の欠陥についても踏み台にされないように努める必要があります。ゾーン情報そのものが改ざんされないまでも、問い合わせクエリーに対する応答メッセージが、問い合わせ元に到達するまでに改ざんされる危険性もあり得ます。このような事態を未然に防ぐ手段として、DNSにセキュリティ拡張を施す試みが行われています。DNSにセキュリティ拡張については、後半の「DNSSEC（DNSセキュリティ拡張）」で後述します。

不正ユーザーによるゾーン転送や不正DDNSの対策

　もしWebサーバやメールサーバのアドレスを公にしたいのなら、ゾーン情報を利用する対象を絞ることは残念ながらできません。一部の人だけにアドレスを公開する場合、一般的にWebサーバやメールサーバも限られた利用に限定されます。

　そこで、せめてゾーン転送とDDNS（Dynamic DNS）の不正利用を防ぐために、アクセスリスト（ACL）やTSIG鍵を用いてセキュアなサービスが保てるようにします。こちらについては以下を参照ください。

第5回：
「ゾーン転送のセキュリティ対策」
第7回：
「ACLによるDynamic DNSの実現とnsupdate」
「Dynamic DNSの動作確認とセキュリティ対策」

キャッシュサーバの対策

キャッシュ汚染攻撃対策

　現在のDNSの利用方法では、DNSの応答を無条件に信頼するしかありません。

　例えば、Webブラウザでwww.atmarkit.co.jpに接続する際に、WebブラウザはDNSキャッシュサーバにwww.atmarkit.co.jpのIPアドレスを問い合わせます。DNSキャッシュサーバから返されたIPアドレスが偽りのものだったら、どうなるでしょうか。見当外れのWebページが表示されれば不審に思いますが、Webページのデザインまで模倣されていては、でたらめなサーバにアクセスしていることに一見して気付くことはできません。

　こうした偽のキャッシュ情報で、DNSが汚染される可能性を否定できるでしょうか。例として、次のような事象を考えてみましょう。

　悪意のある個人（攻撃者）がexample.jpドメインを取得し、次のようなゾーンレコードを用意したとします。

example.jp          IN  NS  www.atmarkit.co.jp.

www.atmarkit.co.jp  IN  A   1.2.3.4 （注）

注：このような、「次のドメイン情報を得るためのポインタ」のようなレコードをグルー（glue）レコードと呼びます。

　通常、www.atmarkit.co.jpのアドレスを解決するにはatmarkit.co.jpのDNSを参照しますが、もし上記のようなレコードがまかり通ってしまった場合、example.jpドメインを参照したDNSキャッシュサーバ（攻撃対象）には次のようなキャッシュ情報が蓄積されます。

example.jpのNSレコードはwww.atmarkit.co.jpであり、www.atmarkit.co.jpのIPアドレスは1.2.3.4である

　「example.jpのNSレコードはwww.atmarkit.co.jp」と「www.atmarkit.co.jpのIPアドレスは1.2.3.4」が蓄積されたてしまった後で、普段どおりwww.atmarkit.co.jpのアドレス解決をDNSキャッシュサーバ（攻撃対象）に問い合わせてきたクライアントには、1.2.3.4という見当違いなIPアドレスが返されます。もし、1.2.3.4がwww.atmarkit.co.jpを中傷するようなページであったり、ショッピングページを装ってカード番号の窃盗をもくろんでいたとしても、ユーザーにはアドレスバーに「www.atmarkit.co.jp」と表示されている以上、一見して正規のページと区別がつきません。

　「クライアントはDNSの応答を信用せざるを得ない」という、DNS元来の脆弱性も絡み大変危険な事態に発展してしまいますが、いくつかの前提条件に依存したこの仮定が実際に発生することは大変まれです。まず、example.jpのゾーン情報にatmarkit.co.jpのような他ドメインの情報を盛り込むことは、基本的にはできません（注）。

注：一般的なゾーンサーバであれば、他ドメインの情報をゾーンファイルに内包する必要はありませんが、トップレベルや2ndレベルドメインのようなDNSではその限りではありません。例えば、example.jpのNSレコードはjpゾーンに記述され、そのAレコードもjpゾーン内に指定されているはずです。トップレベルや2ndレベルドメインのDNSがキャッシュ汚染のもとにならないように、各レジストラはNSレコードに対するホスト情報に注意する必要があります。

　BIND 9では、次のようなログを出力して他ドメインの情報を無視します（注）。

Aug 29 23:37:24.202 general: dns_master_load: example.zone:XX: ignoring out-of-zone data (www.atmarkit.co.jp)

注：BIND 8以前ではnamed.confのoptionsステートメントで明示的に「fetch-glue no」を指定する必要がありました。

　攻撃者AのDNSがこのような防御を備えていなかったり、あえて外している可能性もあります。その場合でも、DNSキャッシュサーバ（攻撃対象）がBIND 9であれば、返答された「www.atmarkit.co.jp IN A 1.2.3.4」をキャッシュしません。キャッシュ汚染を防ぐには最新のBINDを使用し、併せてキャッシュサーバを使用するユーザーを次に紹介する方法で限定します。

キャッシュサーバの不正利用対策

　ゾーンサーバの利用対象者を絞ることはできませんが、キャッシュサーバはその限りではないはずです。そこで、キャッシュサーバの利用対象者をallow-recursionを用いて制限します。

options {

    （省略）

        allow-recursion {

            example-net;    #定義されたACLを用いた場合（none/any/localhost/localnetsを既定のACLとして利用することが可能）

            192.168.20.21;  #直接要求元のIPを指定した場合

            192.168.20.0/24;#ネットワーク単位で指定した場合

        };

    （省略）

};



acl example-net {

        192.168.20.21;

        192.168.20.0/24;

};

named.conf

再帰問い合わせ数の制限

　キャッシュサーバへの突発的な高頻度問い合わせ要求は、named.confのoptionsステートメントにrecursive-clientsを挿入することで抑制できます。

options {

    （省略）

        recursive-clients 400;　←再帰問い合わせの同時要求数を400に制限（デフォルトは1000）

    （省略）

};

named.conf
注：要求数を1000以上に設定する際の注意点については、次回以降「BIND 9の大規模運用」で紹介します。

　ただし、サーバのリソースは食いつぶされないまでも、recursive-clientsを超える要求が発生した場合は、DNSとしての役目を果たせなくなるので注意が必要です。

DNSSEC（DNSセキュリティ拡張）

　DNSそのものの脆弱性の1つに、ゾーン情報の信ぴょう性を保証する手段がないことが挙げられます。第5回や第8回ではTSIG鍵を紹介しましたが、これは共有鍵を配布する必要があり、広くそれも不特定多数で使用するのは事実上不可能です。

　そこで、RSAなどの公開鍵暗号方式のような仕組みが必要となるわけです。公開鍵暗号方式でゾーン情報に鍵を掛けることで、DNSクエリーで交換されるメッセージを認証可能にし、ゾーン情報の信頼性を確保します。そのためキャッシュ汚染やクエリー応答メッセージのなりすましといった事態にも対応可能になります。

　現在、DNSを改善するためのセキュリティ拡張はIETF（http://www.ietf.org/）のDNSEXT（DNS Extensions）ワーキンググループ（http://www.ietf.org/html.charters/dnsext-charter.html）で作業が進められており、この成果が順次BIND 9に反映されています（注）。

注：BIND 9.2.2にもすでにDNSSECの一部は実装されており利用可能です。次回以降「BIND 9の新機能」で紹介します。

　インターネットの普及とともに、セキュリティに対する対価も大きくなってきています。社会的な犯罪は法とモラルで対応する必要がありますが、インターネットの世界においては技術力とそれに追随する努力で未然に抑制することができます。中にはspamのように技術者の枠を逸脱した問題もありますが、DNSではそうしたことが起こらないように、われわれ管理者が死守していく必要があります。DNSSECのような、よりセキュアな実装が登場することに期待しつつ、せめて自社で運用するDNSには普段から配慮を怠らないようにしましょう。

「次回」へ

「実用 BIND 9で作るDNSサーバ」バックナンバー