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

» 2003年05月10日 00時00分 公開
[鶴長鎮一，＠IT]
前のページへ 1|2|3 　　　　　　

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

　本連載では別に回を設けて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の仕組み 図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 鍵の名前。鍵の名前にはゾーン転送の対象になるドメイン名を指定


　以上の操作で次の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サーバ」バックナンバー
前のページへ 1|2|3 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

＠IT

@ITについて

RSSについて

アイティメディアIDについて

メールマガジン登録

＠ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。