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

[辻 伸弘（ソフトバンク・テクノロジー株式会社），＠IT]

ゾーン情報の転送とは

　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の場合

dig @xxx.xxx.xxx.xxx ドメイン名 axfr

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

nslookupの場合

nslookup > server ゾーン転送元サーバ（プライマリDNSサーバ） > ls -t ns ドメイン名

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

; <<>> DiG 9.2.3 <<>> @●●.jp ●●.jp axfr ;; global options: printcmd ●●.jp. 86400 IN SOA name.●●.jp. root.●●.jp. 2007192633 4444 2929211 19111 ●●.jp. 86400 IN MX 5 king.●●.jp. ●●.jp. 86400 IN MX 10 ace.●●.jp. ●●.jp. 86400 IN MX 100 name.●●.jp. ●●.jp. 86400 IN NS name.●●.jp. ●●.jp. 86400 IN NS ■■.jp. joker.●●.jp. 86400 IN A xxx.xxx.xxx.xxx snowwind-gm.●●.jp. 86400 IN A xxx.xxx.xxx.xxx topper.●●.jp. 86400 IN A xxx.xxx.xxx.xxx muman.●●.jp. 86400 IN A xxx.xxx.xxx.xxx zoom.●●.jp. 86400 IN A xxx.xxx.xxx.xxx 〜 略 〜 ftp-1.●●.jp. 86400 IN CNAME www.●●.jp. ftp-2.●●.jp. 86400 IN A xxx.xxx.xxx.xxx testweb.●●.jp. 86400 IN CNAME ftp-2.●●.jp 〜 略 〜

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

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

• 「ftp-1」はFTPサービスを行っているサーバの１台目ではないか？ そして、「www」の別名（CNAME）であり、実体は同じホストであるはずだ。
• 「ftp-2」はFTPサービスを行っているサーバの2台目ではないか？
• 「testweb」は、サイトの更新の際などに何らかのテストを行うためのサーバではないか？ そして、「ftp-2」の別名（CNAME）であり、実体は同じホストであるはずだ。

ということである。

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

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

• 「ftp-1」は、行っているサービスそのままの名前だろうな。21番ポートはオープンしているだろう。
1. anonymous（匿名）でのログインが可能であったり、安易なパスワードを設定しているユーザーが存在するかもしれないな。
2. 別名は、「www」なので、公開用Webサーバのコンテンツアップロード用だろう。
• 「ftp-2」も行っているサービスそのままの名前だろうな。こっちも21番ポートはオープンしているだろう。
1. そして2台目のFTPサーバか？
2. anonymous（匿名）でのログインが可能であったり、安易なパスワードを設定しているユーザーが存在するかもしれないな。
• 「testweb」はWebサイトのテストに使用していそうな名前だな。
1. となると、公式に外部に公開していることを通知していないサーバなのでセキュリティを考慮した運用があまりなされていないのでは？
2. もしかすると、そこに存在する脆弱性は本番運用を行っているWebサーバ「www」にも存在するかもしれないな。
3. 別名は、「ftp-2」で実体が同じということは、「ftp-2」はテスト用コンテンツのアップロード用だろう。
4. 「www」=「ftp-1」、「testweb」=「ftp-2」の組み合わせで運用が行われているのか。
5. まずは、この「testweb」「ftp-2」サーバを標的とするか。うまくいけば公開用まで乗っ取れるかもしれないしな。

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

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

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

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

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

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

options {             〜 略 〜             version "tsuji";                         〜 略 〜 } ;

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

options {             〜 略 〜             allow-transfer{ ゾーン転送を許可するアドレス1; ゾーン転送を許可するアドレス2; ゾーン転送を許可するアドレス3; }; };

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

【注1】

ゾーン転送の許可、不許可はプライマリDNSサーバがIPアドレスのみをチェックしている。従って、なりすましに対しては脆弱となる。そのような場合はTSIG（Transaction Signature）を使った証明書による認証を組み込むことができるが、今回は割愛させていただく。