ヘルスチェックしてる？ 怠ってはならないDNSのケア：もう一度見直したいDNS／DHCP（1）（2/3 ページ）
IPネットワークのコアとなるDNSやDHCP。これらのサービスは一度安定稼働してしまうとなかなかメンテナンスまで目が行き届かないというのが現状ではないだろうか。本連載ではDNS、DHCPに今だからこそもう一度フォーカスを当て、企業活動のためには絶対に止められないサービスとしてどのような改善が行えるのかを紹介していく。
忘れてはならないDNSセキュリティアップデート
まず、日々運用するうえで気にしていることにセキュリティアップデートがあると思います。UNIX系のOSでDNSサーバを運用している場合は、多くの場合BINDが利用されています。そのため、BINDのセキュリティアップデートについては、気にしている場合がほとんどでしょう。ほかにも、それ以外に動作しているOSのカーネルやglibcといったサーバを運用するうえで必須のアップデートも度々リリースされています。
Windows Serverの場合は、Windows UpdateによってOS自体のアップデートおよびDNSに関連するアップデートが提供されています。そして、SolarisやLinux上でBINDを利用する場合は、OSの提供元やディストリビューションの提供元によって、OSおよびBINDのアップデートが提供されています。自動的にアップデートされる場合を除いて、アップデートには管理者の作業が伴います。多くの場合インストール作業自体は簡単に行うことができると思います。
しかし、動いているサーバのアップデートは、事前の検証やアップデートによる不具合がないかなどの調査が必要であるため、それなりの時間が必要となります。Webサーバやメールサーバには、アップデートの計画をたてて計画的に実行していると思いますが、DNSサーバは置き去りにされていることがあるようです。
アップデートという面でいうと、すでにサポートが切れているものをそのまま利用している場合があります。例えば、LinuxでいうとRed Hat Linux 9やFedora Coreにインストールされていたものなどがあります。この場合は、OS自体の入れ替え作業も発生する場合がありますので、普通のアップデート以上に時間と労力が必要となります。
開発の終了したBIND 8、移行計画はできてますか？
BINDにかかわる大きなニュースが8月27日にリリースされています。
関連リンク
BIND 8 End Of Life Announcement
http://www.isc.org/index.pl?/sw/bind/bind8-eol.php
これを一言でいうと、BIND 8の開発が終了したということになります。つまり今後BIND 8にセキュリティホールが見つかった場合も、パッチが提供されません。ディストリビュータが独自にアップデートを出す可能性はありますが、BIND 8を利用しているディストリビューション自体がサポート終了となっている場合がほとんどだと思います。
もし、読者の中でいまだにBIND 8を利用している場合は、早々にBIND 9への移行（多くの場合は、OS自体の入れ替え）の計画を立てていただきたいと思います。
DNSの設定ミスによる危険性
少しメンテナンスとは違う話になってしまいますが、設定ミスについて考えてみます。名前解決できないといったものや、ゾーン転送できないといった動作しない場合の設定ミスは、構築時に修正されることが多いでしょう。ですが、動作には問題ないセキュリティ上の問題を放置してしまっている可能性があります。ここでは、その中から最近よく問題になるものをいくつかピックアップしてみます。
再帰的名前解決の制限
フォワーダー（キャッシュサーバ）を構築する際に、許可をする再帰的名前解決の設定上の問題となります。LAN内部にフォワーダーを構築する場合は、この再帰的名前解決が有効になっているはずです。実際の設定は、/etc/named.confに以下の設定が書かれていると思います。
recursion yes;
LAN内部のサーバであれば、これだけの設定でもさほど問題が発生することはありません。なぜならLANに接続できるのは許可されているクライアントと考えることができるからです。許可されていないクライアントが接続できる場合は、別のセキュリティ上の問題を解決する必要があります。
ここで問題とするのは、外部のプライマリをフォワーダーと兼用している場合になります。上記の設定がされていれば、名前解決については問題なく動作していることと思います。ですが、これだけでは再帰的名前解決を許可するクライアントの制限がされていないため、外部のクライアントからの要求も処理してしまいます。
その場合、DDoSの踏み台になる可能性があります。直接サーバに何かをするというわけではありませんが、DNSサーバを踏み台として特定のサーバへのDDoSの加担をすることとなってしまいます。つまり、知らないうちに加害者になってしまうのです。
再帰的名前解決を許可するサーバでは、上記設定と同時に以下の設定により、クライアントの制限をする必要があります。
allow-recursion { IP-Address; };
この問題については、2006年にJPCERT/CCより勧告が出ておりますので、目にした人も多いと思います。
関連リンク
JPCERT/CC Alert 2006-03-29
DNS の再帰的な問合せを使った DDoS 攻撃に関する注意喚起
http://www.jpcert.or.jp/at/2006/at060004.txt
外部のDNSサーバで再帰的名前解決ができていたのは、ある意味性善説に基づいて運用されていたのかもしれません。インターネットの仕組みを悪用する人が増えてくると、それとともに気を付けるポイントが増えてくるということです。
Copyright © ITmedia, Inc. All Rights Reserved.