スレーブ・サーバのゾーン転送とセキュリティ：実用 BIND 9で作るDNSサーバ（5）（3/3 ページ）

» 2003年05月10日 00時00分公開

ゾーン転送のセキュリティ対策

　本連載では別に回を設けてBIND 9のセキュリティについて説明する予定ですが、ゾーン転送に関しては極めて危険度が高いため、この点についてはここで紹介しておきます。

使わせないのが基本

　ゾーン転送に関するセキュリティ対策は、何よりもマスター・サーバ側で、あらかじめ指定されたスレーブ・サーバ以外からはゾーン転送を受け付けないようにするのが第一です。

options {

            （省略）

                    allow-transfer{ スレーブ・サーバ1のIP;  スレーブ・サーバ2のIP; }; （1）

            };

            （2）

            zone "example.jp" {

                    type master;

                    file "example.zone";

                    allow-transfer{

                            none;   （3）

                    };

            };

            （4）

マスター・サーバ側のnamed.conf

（1）追加したい分だけ「;」で区切って追加する
（2）ゾーンセンテンスでも記入可能
（3）無指定
（4）optionsステートメントで指定されたものより、ゾーンセンテンスで指定されたものの方が優先されるため、この場合example.jpに対してはどこからもゾーン転送が行えない

　設定したらnamedを再起動し、digコマンドで許可が与えられているサーバとそうでないサーバで期待したレスポンスが返ってくるかどうかを確認します。

$ dig @マスター・サーバ example.jp axfr

            

            ; <<>> DiG 9.2.2 <<>> @マスター・サーバ example.jp axfr

            ;; global options:  printcmd

            ; Transfer failed.　←失敗

ゾーン転送の許可が与えられていないクライアントで実施した場合

$ dig @マスター・サーバ example.jp axfr

            

            ; <<>> DiG 9.2.2 <<>> @マスター・サーバ example.jp axfr

            ;; global options:  printcmd

            （省略）

            ;; Query time: 12 msec

            ;; SERVER: マスター・サーバのIP#53(マスター・サーバ)

            ;; WHEN: Wed Apr 23 05:59:19 2003

            ;; XFR size: 20 records　←成功

ゾーン転送の許可が与えられているクライアントで実施した場合

TSIGの利用

　マスター・サーバのアクセス制限は上記の要領で完了しますが、スレーブ・サーバはIPアドレスでのみマスターを識別しているため、マスター・サーバのIPを偽装した「なりすましサーバ」が出現した場合はまったくの無防備になります。

　そこで、TSIG（Transaction Signature）を用います。TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします（注）。

図4　TSIGの仕組み

注：暗号には認証と秘匿2つの機能があり、ここでは認証の機能のみが提供されます。そのため、マスターとスレーブで交換されるメッセージは平文のままです。

　では、TSIGを実装します。まず、dnssec-keygenコマンドを使用して共有鍵を作成します。作業はマスター、スレーブどちらでも構いません。

/usr/sbin/dnssec-keygen 
            -a HMAC-MD5 -b 512 -n HOST example.jp

注：コマンドパスおよびexample.jpは環境に応じて書き換えてください。


-a	RSA、DSAなどの暗号化アルゴリズムを指定できるが、TSIGではHMAC-MD5（鍵付きハッシュ関数）を指定
-b	鍵の長さを指定。十分な長さが必要だが、HMAC-MD5アルゴリズムでは512bits（注）が最大になる
-n	ZONE、HOST、ENTITY、USERが指定できるが、ここではHOSTを指定
example.jp	鍵の名前。鍵の名前にはゾーン転送の対象になるドメイン名を指定

注：鍵の長さはRFC 2541
http://rfc-jp.nic.ad.jp/cgi-bin/direct.cgi?keyword=2541&language=eng&x=14&y=15
を参照。

　以上の操作で次の2つのファイルが作成されます。

Kexample.jp.+157+01798.key
Kexample.jp.+157+01798.private

　「157」はHMAC-MD5で生成されたことを示し、「01798」はハッシュ値であるため環境によって変わります。

　ファイルの中身は次のようになっています。

$ more Kexample.jp.+157+01798.key

            example.jp. IN KEY 512 3 157 1GPx/sFNPz40U/NuspDqo……（省略）

　次に、生成されたファイルから共有鍵（上の赤字の個所）を抜き出し、named.confに埋め込みます。

key "example.jp" {          （1）

                  algorithm hmac-md5;   （2）

                  secret "1GPx/sFNPz40U/NuspDqo……（省略）";

            };

            

            （3）

            zone "example.jp" {

                    type master;

                    file "example.zone";

                    allow-transfer{

                            key example.jp;

                            IPアドレス; （4）

                    };

            };

マスター・サーバの/etc/named.conf

（1）dnssec-keygenを実行した際に指定した「鍵の名前」を指定
（2）暗号化アルゴリズムを指定
（3）該当ドメインのゾーンセンテンス
（4）ここでIPを指定した場合は、そのサーバのみゾーン転送時にTSIGは要求されない

 key "example.jp" {

                  algorithm hmac-md5;

                  secret "1GPx/sFNPz40U/NuspDqo……（省略）";

            };

            

            （1）

            server マスター・サーバのIP {

                    keys "example.jp";  （2）

            };

            

            （3）

            zone "example.jp" {

                    type slave;

                    masters {

                            マスター・サーバのIP;

                    };

                    file "example.zone.bak";

            };

スレーブ・サーバの/etc/named.conf

（1）次のセンテンスを追加
（2）複数形のkeysになっていることに注意
（3）該当ドメインのゾーンセンテンスは修正の必要ない

　重要な共有鍵が記入されているため、named.confのパーミッションに注意しましょう。特定のユーザー（たいてはroot）のみがアクセス権を持つように、

# chmod 600 named.conf

としておきます。

　実施に当たっては、rsyncと同様に2台のサーバの内蔵時計が同期していることが重要になるため、前述のntpdateなどで時刻の修正を行ってからnamedデーモンを再起動します。再起動したら、バックアップファイルのタイムスタンプやログファイルを参照し、スレーブ側でゾーン転送が行われていることを確認します。この時点で、先ほど紹介したdigコマンドによるAXFRの確認はできなくなっています。これは正常な動作で、TSIGを使用しなければゾーン転送は実施されません。

　以上でTSIGの実装は完了ですが、共有鍵を定期的に変更することを考えると、多少の手間を感じます。そのため、BIND 9では共通鍵交換を支援するTKEYが用意されました。今後のバージョンアップが期待されます。

　今回はスレーブ・サーバの運用についてお話ししました。サーバ1台当たりの処理能力が上がっても、依然としてDNSの分散配置の重要性は増すばかりです。「データの一貫性を保証する分散システム」の代名詞ともてはやされるDNSですが、そこで利用されているゾーン転送の仕組みをご理解いただけたと思います。

「次回」へ

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