検索
連載

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

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

[大竹龍史，ナレッジデザイン] PC用表示
Share
Tweet
LINE
Hatena

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

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

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

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

（1）TSIG（Transaction Signatures）

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

-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つのファイルが生成されます。どちらのファイルにも秘密鍵が格納されています。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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


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

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

使用方法：

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

主なサブコマンド：

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（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コマンドで生成します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

-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　ファイルには秘密鍵が格納されています。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（3）ゾーン転送の制限

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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


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


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


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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

Copyright © ITmedia, Inc. All Rights Reserved.

　　　　　　 | 次のページへ
ページトップに戻る