DNSセキュリティの設定：実践でも役立つLPICドリル（10）（1/4 ページ）

本連載は、Linux 認定試験 LPICに対応しています。一般的なLinuxユーザーレベルのトピックは省略し、システム管理とサーバ管理の内容を取り上げています。また、LPIC対策だけでなく、関連するトピックについて系統的な理解を問う問題も出題しています。連載の特徴は、対象となるプログラムのバージョンを可能な限り明記していること、比較的新しくまとまった解説がまだ少ないトピック、重要だが理解しにくいトピックを優先して取り上げていることです。問題を解き、その解説を読むことにより実践でLinuxを活用できる力を身に付けます。

» 2009年02月26日 00時00分 公開
[大竹龍史，ナレッジデザイン]

今回のディストリビューション：CentOS 5.2

■問題を解く鍵　【1】【2】

　このトピックに関連した設定や試験問題を解く際には、以下の項目がポイントになります。

【1】DNSサーバの認証／暗号化機能と設定方法

（1）TSIG（Transaction Signatures）

　RFC2845で記述されたTSIG（Transaction Signatures）は、共通秘密鍵と一方向性ハッシュ関数を使用したトランザクションレベル認証のためのプロトコルです。マスターからスレーブへのゾーン転送、ダイナミックDNS、rndcコマンドによるリモートなサーバ制御などの場合に、クライアント認証の仕組みとして利用できます。

　共通秘密鍵はBIND9の場合はdnssec-keygen、BIND8の場合はdnskeygenコマンドで生成します。

（例）
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST linux1

-a 暗号化アルゴリズムを指定します。TSIGの共通秘密鍵を生成する場合は一方向性ハッシュ関数HMAC-MD5（Keyed Hashing for Message Authentication Code-Message Digest 5）を指定しなければなりません。
-b 生成するキーのビット長を指定します。暗号化アルゴリズムはHMAC-MD5の場合は1-512ビットです。この例では512ビットを指定しています。
-n キーのオーナータイプを指定します。オーナータイプにはZONE、 HOST、 USERがあります。TSIGの共通秘密鍵を生成する場合はHOSTを指定します（ZONEは指定できません）。

　最後に引数として任意のキー名（この例ではlinux1）を指定します。

　この結果、Klinux1.+157+18761.key、Klinux1.+157+18761.privateといった2つのファイルが生成されます。どちらのファイルにも秘密鍵が格納されています。

# cat Klinux1.+157+18761.key
linux1. IN KEY 512 3 157 dfBiWU9xSZo4B....R9JyFEJzeOg==

# cat Klinux1.+157+18761.private
Private-key-format: v1.2
Algorithm: 157 （HMAC_MD5）
Key: dfBiWU9xSZo4B....R9JyFEJzeOg==

（注）太字部分が鍵の値です


rndcコマンドでのTSIGの設定：

　rndcコマンドはBIND4、BIND8で提供されていたndcに代わるnamedの制御コマンドです。TSIGを利用してリモートなサーバの管理ができます。

使用方法：

　rndc [-c config] [-s server] [-p port] [-k key-file ] [-y key] [-V] command

主なサブコマンド：

reload Reload configuration file and zones.
reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
stats Write server statistics to the statistics file.
dumpdb [-all|-cache|-zones] [view ...]
Dump cache（s） to the dump file （named_dump.db）.
stop Save pending updates to master files and stop the server.
halt Stop the server without saving pending updates.
trace level Change the debugging level.
flush Flushes all of the server's caches.
status Display status of the server.

Version: 9.3.4-P1


（例）インストール時のデフォルトの秘密鍵を使用して制御する
# rndc reload
設定ファイルとゾーンファイルを再読み込みします。

# rndc dumpdb
namedに保持されたキャッシュの内容をサブステートメントdirectoryで指定されたディレクトリ下にnamed_dump.dbというファイル名で書き出します。

（例）上記手順で生成した秘密鍵（鍵の名前はlinux1）を使用する設定
サーバ側の設定：
　 /etc/named.confに以下の記述を追加します。

　　 key "linux1" {
　　　algorithm hmac-md5;
　　　secret "dfBiWU9xSZo4B....R9JyFEJzeOg==";
　　};

クライアント側（rndcコマンド側）の設定：

　　 /etc/rndc.confに以下の記述を追加します。

　　 key linux1 {
　　　algorithm hmac-md5;
　　　secret "dfBiWU9xSZo4B....R9JyFEJzeOg==";
　　};

　　 server 172.16.1.1 {
　　　keys { linux1;};
　　};

（例）上記手順で設定した秘密鍵（鍵の名前はlinux1）を使用して制御する
# rndc -s 172.16.1.1 -y linux1 status

サーバのステイタス情報を表示します。
-sでサーバを、-yで鍵の名前を指定します。

（2）DNS Security Extensions

　RFC2535で記述されたDNS Security Extensions（DNSSEC：DNSセキュリティ拡張）はデジタル署名によるDNSデータの完全性を提供します。サーバはゾーンデータを秘密鍵で署名し、それを受け取ったクライアント（リゾルバ：クライアントアプリケーションに組み込まれたDNS名前解決のライブラリルーチン）がサーバの公開鍵によって、データが改ざんされていないかどうか、その完全性を検証します。

　サーバの鍵は上位ゾーンの鍵により署名されます。リゾルバは当該ゾーンに含まれているサーバの公開鍵のKEYリソースレコードの正当性を、その親ゾーンの公開鍵により検証します。この鍵の正当性を検証する階層構造の故に、実際の運用例はまだ少ないものと思われます。

（注1）BIND8ではDNSSECの機能はまだ部分的にしか提供されていないようです。BIND9の使用が推奨されます


（注2）鍵の検証のために上位ゾーン（最終的にはルートゾーン）まで）をさかのぼらなければならない、という困難さを解決するために、ISC（Internet Systems Consortium）ではDNSSEC Lookaside Validation（DLV）という技術を提唱しています。これは信頼できる代替ゾーンによって、鍵の正当性を証明する仕組みです


　DNSSECで使用する秘密鍵・公開鍵のキーペアはBIND9の場合はdnssec-keygen、BIND8の場合はdnskeygenコマンドで生成します。

（例）
dnssec-keygen -a RSA -b 512 -n ZONE school.knowd.co.jp.

-a 暗号化アルゴリズムを指定します。秘密鍵・公開鍵のキーペアを生成する場合は、RSA、RSASHA1、DSA、DHのいずれかを指定します。この例ではRSAを指定しています。
-b 生成するキーのビット長を指定します。暗号化アルゴリズムはRSAの場合は512〜2048ビットです。この例では512ビットを指定しています。
-n キーのオーナータイプを指定します。オーナータイプにはZONE、HOST、USERがあります。秘密鍵・公開鍵のキーペアを生成する場合はZONEを指定します（HOSTやUSERは指定できません）。

　最後に引数として任意のキー名（この例ではschool.knowd.co.jp.）を指定します。この結果、Kschool.knowd.co.jp.+001+33861.key、Kschool.knowd.co.jp.+001+33861.privateといった2つのファイルが生成されます。

　Kschool.knowd.co.jp.+001+33861.ke　ファイルには公開鍵が、　Kschool.knowd.co.jp.+001+33861.private　ファイルには秘密鍵が格納されています。

# cat Kschool.knowd.co.jp.+001+33861.key
school.knowd.co.jp. IN DNSKEY 256 3 1 AwEAAc4HDaELT2j....D13mz4RF3Q==

# cat Kschool.knowd.co.jp.+001+33861.private
Private-key-format: v1.2
Algorithm: 1 （RSA）
Modulus: zgcNoQtPaNNcvk72a....B1QeD13mz4RF3Q==
PublicExponent: AQAB
PrivateExponent: YfqquZ7GWgTCg2LL/oYY....5/gI6XiyAK3XxQ==
Prime1: /lVhpYblUTOyeGn51D+P6yDxvAXOc/g/KQOvrt4Blp8=
Prime2: z2Ckuhi7oQOskTKv1U04v3uJuTB+0JFlAHeF4GfbPgM=
Exponent1: XxIniCqeufXrNtvWiaKg97G+6xv4ip03butz1pgiW90=
Exponent2: Ex5b0XRaR/vouvIrV8ToyG6BQfuAlYXyA9sBErFAezU=
Coefficient: CiV9h5Lvxf1ZjZt7tUJ0jSYdI44+A4XXrlKJ6zqXws4=

【2】DNSサーバのアクセス制御と情報提供の制限方法

（1）バージョン情報表示の抑制

　稼働しているBINDのバージョンは外部から調べることができます。

（例）DNSサーバns.school.knowd.co.jpのバージョンを問い合わせる
# host -c chaos -t txt version.bind. ns.school.knowd.co.jp
Using domain server:
Name: localhost
Address: 172.18.0.1#53
Aliases:
version.bind descriptive text "9.3.4-P1"

　version.bindというドメイン名に付加されたCHAOSNETクラスchaosのtxtレコードを問い合わせると、namedはバージョン（この例では、9.3.4-P1 ）を返します。

　しかし、正確なバージョンが分かると、バージョン固有の脆弱性を攻撃する手掛かりとなりかねません。この対処方法として、返すバージョンを設定ファイル/etc/named.confの中で次のように文字列で指定できます。

（例）サブステートメントversionによりメジャーバージョン9のみを回答するように設定
options {
　　　 version　　　“;9”;
}

（2）問い合わせできるホストの制限

　サブステートメントallow-queryにより特定のホストからの問い合わせにだけ答えるように設定できます。

（例）サーバ全体での制限
options {
　　　　 allow-query { 172.17.1.1; 192.168.2/24;};
};

（例）ゾーン単位での制限
zone “domain.com” IN {
　　　　 allow-query { 172.16.1.1; 192.168.1/24;};
};

　サブステートメントblackholeにより特定のホストからの問い合わせに応答せず、そのホストに問い合わせも出さなくなります。

options {
　　　　 blackhole { 172.17.1.1; 192.168.2/24; };
};

（3）ゾーン転送の制限

　サブステートメントallow-transferで特定のホスト（通常はスレーブサーバ）へのみゾーン転送を許可するように設定できます。

（例）サーバ全体での制限
options {
　　　　 allow-transfer { 172.17.1.1; 192.168.2/24;};
};

（例）ゾーン単位での制限
zone “domain.com” IN {
　　　　 allow-transfer { 172.17.1.1; 192.168.2/24;};
};

　ただし、上記の設定では偽装されたIPアドレスのホストからのリクエストにも応答してしまいます。これを防ぐには前項【1】で説明したTSIGを利用することができます。

マスターサーバ側の/etc/named.confの設定：

key keyname {
　　　algorithm hmac-md5;
　　　secret "dfBiWU9xSZo4B....R9JyFEJzeOg==";
};

サーバ全体での制限の場合
options {
　　　allow-transfer { key keyname;};
};

ゾーン単位での制限の場合
zone “domain.com” IN {
　　　allow-transfer { key keyname;};
};

スレーブサーバ側の/etc/named.confの設定：

key keyname {
　　　algorithm hmac-md5;
　　　secret "dfBiWU9xSZo4B....R9JyFEJzeOg==";
};

server 172.16.1.1 {
　　　keys { keyname;};
};

（注1）keynameには生成時のキーの名前を指定します


（注2）dfBiWU9xSZo4B....R9JyFEJzeOg==　はコピーペーストしたキーの値です


（注3）172.16.1.1はマスターサーバのIPアドレスの例です


（4）再帰問い合わせの制限

　サブステートメントrecursionで再帰問い合わせを禁止することができます。

（例）サーバ全体での制限
options {
　　　recursion no;
};

　サブステートメントallow-recursionで再帰問い合わせに答えるホストを指定できます。

（例）サーバ全体での制限
options {
　　　 allow-recursion {172.17.1.1; 192.168.2/24;};
};

　　　　　　 1|2|3|4 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft ＆ Windows最前線2025
AI for エンジニアリング
ローコード／ノーコード セントラル by ＠IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by ＠IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

@ITについて

RSSについて

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

メールマガジン登録

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