Linuxサーバ構築/運用基礎
8.DNS
8.4. DNSサーバのセキュリティ

8.4. DNSサーバのセキュリティ

8.4.1. 通常のセキュリティオプション

named.confの設定で強化できるセキュリティ設定をいくつか記載する。

ゾーン転送の制限

スレーブDNSサーバはマスタDNSサーバからゾーン情報を転送する必要があるが、スレーブDNSサーバ以外はその必要がない。
ゾーン転送をスレーブDNSサーバのみに限定する場合は以下のように行う。

zone "example.net" {
    allow-transfer { 192.168.128.3; };
};

この設定により、ゾーン情報の全体を外部から問い合わせることが制限できる。

DNS問い合わせの制限

DNS問い合わせの制限は不要なDNSサーバ利用を阻止することが可能。
また再帰的な問い合わせの禁止は不正なキャッシュデータをDNSサーバに送りつけるキャッシュ汚染攻撃を回避することができる。

; 192.168.120.0/24からの問い合わせ/再帰的な問い合わせの許可
options {
    allow-query { 192.168.120.0/24; };
    allow-rescursion { 192.168.120.0/24; };
};

; 以下のゾーンはすべてのホストからの問い合わせの許可
zone "example.net" {
    allow-query { any; };
};
zone "192.168.120.in-addr.arpa" {
    allow-query { any; };
};

バージョン番号の秘匿

digコマンドによりBINDのバナー情報として表示することができる。
そのためバージョンを秘匿するにはoptionsオプション内でversionオプションに任意の文字列を指定する。

options {
    version "unknown DNS Server";
};

root以外によるnamedの実行

root権限以外でnamedを実行すれば、DNSサーバがクラッカーにより侵入されたとしても被害を最低限に抑えることができる。
BINDをパッケージでインストールするとnamedユーザが生成され、その権限で実行されることになる。

確認はps -f -C namedで可能。 chrootを使用することでさらに侵入されたときの被害をおさえることができる。

chroot: 任意のディレクトリをプロセスにとっての「/」と扱うことで、そのディレクトリ以外をアクセスできないようにする手法

この場合、namedの運用に必要なファイルはchrootディレクトリ以下に配置する必要がある。

8.4.2. DNSSEC/TSIG

DNSの仕組み強化の仕組みにはDNSSEC/TSIGなどがある。

DNSSEC(DNS Security)はゾーン情報の信頼性を保証するための仕組みで、具体的にはゾーン情報に公開鍵暗号方式の電子署名を行うことでゾーン情報が改ざんされていないこと、DNS応答が正当な管理者により行われることを保証する。
DNSSECの利用にはDNSサーバ/クライアント両方対応している必要がある。

DNSSECの仕組みは以下の通り。

  1. ゾーン情報のハッシュ値(DS)とDNSサーバの秘密鍵で暗号化したものを電子署名とする
  2. DNS問い合わせの際にゾーン情報/電子署名をクライアントに送信する
  3. クライアントは電子署名をDNSサーバの公開鍵で復号する
  4. ゾーン情報のハッシュ値と電子署名の復号結果が一致すれば保証

DNSSEC

この仕組みを順につなげることで信頼性のあるDNSのつながりが完成する。

またゾーン情報に電子署名を行う鍵をZSK(Zone Security Key)、ZSKに電子署名を行う鍵をKSK(Key Signing Key)と呼ぶ。 BIND 9.3.0以降でDNSSECは対応している。

DNSSECの設定

DNSSECをBINDで実装する手順は以下の通り。

  1. ZSK鍵ペアを作成する(ゾーンファイルを格納しているディレクトリで行う)
    • 例：dnssec-keygen -r /dev/random -a RSASHA256 -b 1024 -n zone example.net
    • 上記により公開鍵と秘密鍵が生成される(生成されたファイル名最後5桁は鍵ID)
  2. KSK鍵ペアを作成する
    • 例:dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -n zone example.net
    • 上記により公開鍵と秘密鍵が生成される(生成されたファイル名最後5桁は鍵ID)
  3. ゾーンファイルに生成した公開鍵が読みこまれるように設定する
    • $INCLUDE "鍵ファイル名"
  4. dnssec-signzoneコマンドによりゾーンファイルに署名を行う
    • 例:dnssec-signzone -o example.net example.net.zone
    • 署名後にゾーン名.signed(署名ファイル)が生成される

なお上位ゾーンへ管理する組織へDSレコード登録を申請する必要がある。

TSIGの設定

TSIG(Transaction SIGnatures)は共有秘密鍵の利用によりマスタDNSサーバになりすまし、偽のゾーンデータをスレーブDNSサーバに送ることや、ゾーンファイルを改ざんする攻撃を防ぐための仕組みのこと。
これはマスタDNSサーバ/スレーブDNSサーバがゾーン転送によりゾーンデータを同期することの性質によるもの。

TSIGの設定は以下の通り。

  1. dnssec-keygenコマンドにより共有鍵ファイルの作成
    • 例:dnssec-keygen -a HMAC-MD5 -b 128 -n HOST tsig-key
  2. named.confに共有鍵ファイルを記載する

マスタDNSサーバの例(tsig-keyは鍵名)

key "tsig-key" {
    alogorithm hmac-md5;
    secret "keyの中身":
};

zone "example.net" {
    type master;
    file "example.net.zone";
    allow-transfer { 192.168.1.100; };
};

スレーブDNSサーバの例(tsig-keyは鍵名)

key "tsig-key" {
    alogorithm hmac-md5;
    secret "keyの中身":
};

server 192.168.1.25 {
    keys { tsig-key; };
};

zone "example.net" {
    type slave;
    file "example.net.zone";
};

8.4.3. DANE

DANE(DNS-based Authentication of Named Entitie)はDNSSECの技術を応用して認証情報をDNSベースでやり取りする仕組み。
DNSSECにより、リソースレコードの正当性確認の仕組みがDNSに組み込まれたため、HTTPSなどで使われるX509の証明書とドメインの紐づけの役割を、認証局からDNSに移すことを目的にし、策定されている。

デジタル署名されたレコードをTLSAレコードと呼び、webのHTTPSで使用されるTLSと技術的には同じ方法を用いて、信頼の基盤を認証局からDNSSECに変更する。

8.3. ゾーンファイルの管理