DNS、管理者として見るか？ 攻撃者として見るか？：セキュリティ対策の「ある視点」（5）（2/3 ページ）

ゾーン情報の転送とは

　BINDに代表されるDNSは、主にドメイン名（ホスト名）とIPアドレスなどのひも付けを行っている。

　例えば、皆さんが、ブラウザのアドレスバーにhttp://www.atmarkit.co.jp/と入力し＠ITのサイトにアクセスしたとしよう。DNSはドメイン名の問い合わせを受けたら、そのドメインのIPアドレスを返すことで、ブラウザはドメイン名だけでWebサーバにたどり着くことができる（実際にはもっと複雑な挙動をしているが、詳細は割愛させていただく）。

　DNSがドメイン名からIPアドレスを調べてくれているおかげで覚えにくいIPアドレスではなく、人間が覚えやすいドメイン名（ホスト名）でアクセスすることが可能となっている。

　ゾーン情報というのは、ドメイン名とIPアドレスをひも付けしているレコードの集合体のことを指したもので、各組織のDNSには自組織で管理しているサーバのドメイン名（ホスト名）とIPアドレスが登録されている。

　通常DNSは、負荷分散や冗長化などの目的でドメイン情報のマスターデータを管理するプライマリDNSサーバ（マスターDNSサーバ）とそのゾーン情報のコピーを行っているセカンダリDNSサーバ（スレーブDNSサーバ）といった2台、組織の規模によっては、それ以上の台数で運用が行われることが多い。

　このプライマリDNSサーバとセカンダリDNSサーバの間でゾーン情報をコピーすることをゾーン転送と呼ぶ。

ゾーン転送の落とし穴

　ゾーン情報はセカンダリDNSサーバからプライマリDNSサーバへUDPを用いて問い合わせの開始を行い、その後TCPを用いてゾーン情報の転送、コピーが行われる。このことから、プライマリDNSサーバはセカンダリDNSサーバからのゾーン転送要求に応じるだけで事足りる。

　だが、ペネトレーションテストの現場ではインターネットに公開しているDNSサーバで、ゾーン転送に応じる要求元を制限していないものによくお目にかかる。

　そのような設定になっているとインターネット上からゾーン転送要求を送信することで、そのDNSサーバの持つ、ドメイン名（ホスト名）とIPアドレスなどをひも付けしているレコードの情報が取得されてしまうのである。

　ゾーン情報の取得は以下のように行う。

　こちらもdig、nslookupの両方で取得可能であるので、両方の方法を紹介しておこう。「xxx.xxx.xxx.xxx」の部分をBINDが稼働しているホストのアドレスに変更してほしい。

digの場合

　nslookupの場合は、以下のように対話的に手続きし取得を行う。

nslookupの場合

　以下は、digを用いてゾーン転送要求をし、それに応じたDNSサーバのゾーン情報を取得したものである（一部省略、変更を加えている）。

　上記結果の●●.jpの前、つまり、ホスト名を見てほしい。注目していただきたいのは、取得結果のログの下部である。

　「testweb」「ftp-1」「ftp-2」とそのサーバの用途を推測できるような名前のホスト名を持つものがあることが分かるだろう。これらのホスト名に対して、取得した情報から推測・確認できることは、

ということである。

深読みでここまで分かるあなたのイントラネット

　これを攻撃者の視点で見てみよう。

といったところだろうか。

　ゾーン情報の転送制限を行っていないことで、ネットワークの情報（サーバ用途やネットワーク構成など）が外部から取得可能な場合、前述したように攻撃の計画を立てる手助けをしてしまうことにつながる可能性があることがご理解いただけたと思う。

　ネットワーク情報のデータベースとも呼べるゾーン情報を取得され、ネットワークを把握されることから、思わぬウイークポイントを発見され、芋づる式にネットワークを掌握されてしまう可能性も考えられる。

無差別コピーを防ぐための対策

　上記のようなことを防ぐためには、ゾーン情報の転送先を制限することとなる。

　制限をBINDの設定ファイル（/etc/named.confなど）内のoptions内に以下のように記述を追加する。

　セカンダリDNSサーバが複数存在する場合などで、複数のアドレスからの許可を行いたい場合は、以下のように「;」で区切るという記述方法を用いる。

　設定を行ったら、BINDの再起動を行うことで設定が反映される【注1】。