連載
» 2003年05月10日 00時00分 UPDATE

実用 BIND 9で作るDNSサーバ(5):スレーブ・サーバのゾーン転送とセキュリティ (3/3)

[鶴長鎮一,@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ですが、そこで利用されているゾーン転送の仕組みをご理解いただけたと思います。


前のページへ 1|2|3       

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

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

メールマガジン登録

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