DNSSECについて

DNSがドメイン名をIPアドレスに解決するプロトコルであることは誰もが知っていますが、返されたIPアドレスの信頼性をどのようにして知ることができますか? 攻撃者がDNS応答を改ざんしたり、 DNSキャッシュをポイズニングしたりして、アドレスバーに正当なドメイン名が表示されている悪意のあるサイトにユーザーを誘導する可能性があります。 DNS Security Extensions(DNSSEC)は、DNS応答のデータ整合性を維持することを目的とした仕様です。 DNSSECは、PKI(公開鍵インフラストラクチャ)を使用して、ゾーンのすべてのDNSリソースレコード(A、MX、CNAMEなど)に署名します。 DNSSEC対応のDNSリゾルバー(GoogleパブリックDNSなど)は、パブリックDNSKEYレコードを使用してDNS応答(IPアドレスを含む)の信頼性を検証できるようになりました。

DNSSECリソースレコード

リソースレコード(RR)には、ドメインに関する特定の情報が含まれています。 一般的なものには、ドメインのIPアドレスを含むAレコード、IPv6情報を保持するAAAAレコード、およびドメインのメールサーバーを含むMXレコードがあります。 DNS RRの完全なリストは、ここにあります。

同様に、DNSSECにもいくつかのRRが必要です。

  • DNSKEYリゾルバーが検証に使用する公開鍵を保持します。
  • RRSIG RRごとに存在し、レコードのデジタル署名が含まれています。
  • DS -委任署名者–このレコードはTLDのネームサーバーに存在します。 したがって、 example.com がドメイン名の場合、TLDは「com」であり、そのネームサーバーはa.gtld-servers.net.b.gtld-servers.net.からm.gtld-servers.net.までです。 このレコードの目的は、DNSKEY自体の信頼性を検証することです。

セットアップ環境

ドメイン名: example.com

これを行うために実際の.COMドメインを使用しましたが、この記事ではexample.comに置き換えました。

マスターネームサーバー:
IPアドレス: 1.1.1.1
ホスト名: master.example.com
OS: Debian 7

スレーブネームサーバー:
IPアドレス: 2.2.2.2
ホスト名: slave.example.com
OS: CentOS

ファイルの場所と名前

BINDの構成ファイルとゾーンファイルの名前と場所は、使用するLinuxディストリビューションによって異なります。

Debian / Ubuntu

サービス名: bind9 メイン構成ファイル:/etc/bind/named.conf.optionsゾーン名ファイル:/etc/bind/named.conf.localデフォルトのゾーンファイルの場所:/var/cache/bind/

CentOS / Fedora

サービス名:名前付きメイン構成およびゾーン名ファイル:/etc/named.confデフォルトのゾーンファイルの場所:/var/named/

bind-chrootを使用している場合、これらは変更される可能性があります。 このチュートリアルでは、マスターNSにはDebianを使用し、スレーブNSにはCentOSを使用したので、ディストリビューションに応じて変更してください。

DNSSECマスター構成

options{ }内に次の構成ディレクティブを追加して、DNSSECを有効にします

nano /etc/bind/named.conf.options

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

これらは、一部のディストリビューションですでに追加されている可能性があります。 ゾーンファイルの場所に移動します。

cd /var/cache/bind

次のコマンドを使用して、ゾーン署名キー(ZSK)を作成します。

dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com

haveged をインストールした場合、このキーが生成されるまでに数秒しかかかりません。 そうしないと、非常に長い時間がかかります。 サンプル出力。

[email protected]:/var/cache/bind# dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com
Generating key pair..................+++ .............+++
Kexample.com.+007+40400

次のコマンドを使用して、キー署名キー(KSK)を作成します。

dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com

サンプル出力。

[email protected]:/var/cache/bind# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com
Generating key pair......................++ .............................................................................................................................................................................................................++
Kexample.com.+007+62910

これで、ディレクトリには4つのキー(ZSKとKSKのプライベート/パブリックペア)が含まれるようになります。 DNSKEYレコードを含む公開鍵をゾーンファイルに追加する必要があります。 次のforループはこれを行います。

for key in `ls Kexample.com*.key`
do
echo "\$INCLUDE $key">> example.com.zone
done

dnssec-signzoneコマンドでゾーンに署名します。

dnssec-signzone -3 <salt> -A -N INCREMENT -o <zonename> -t <zonefilename>

塩をランダムなものに置き換えます。 これが出力の例です。

[email protected]:/var/cache/bind# dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o example.com -t example.com.zone
Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone signing complete:
Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                        ZSKs: 1 active, 0 stand-by, 0 revoked
example.com.zone.signed
Signatures generated:                       14
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.046
Signatures per second:                 298.310
Runtime in seconds:                      0.056

「ソルト」として16文字の文字列を入力する必要があります。 次のコマンド

head -c 1000 /dev/random | sha1sum | cut -b 1-16

ソルトとして使用される16文字のランダムな文字列を出力します。

これにより、各DNSレコードのRRSIGレコードを含むexample.com.zone.signedという名前の新しいファイルが作成されます。 この「署名された」ゾーンをロードするようにBINDに指示する必要があります。

nano /etc/bind/named.conf.local

zone { }セクション内のfileオプションを変更します。

zone "example.com" IN {
    type master;
    file "example.com.zone.signed";
    allow-transfer { 2.2.2.2; };
    allow-update { none; };
};

このファイルを保存してバインドをリロードします

service bind9 reload

同じサーバーでdigを使用してDNSKEYレコードを確認してください。

dig DNSKEY example.com. @localhost +multiline

サンプル出力

[email protected]:/var/cache/bind# dig DNSKEY example.com. @localhost +multiline
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> DNSKEY example.com. @localhost +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43986
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.       IN DNSKEY

;; ANSWER SECTION:
example.com.        86400 IN DNSKEY   256 3 7 (
                AwEAActPMYurNEyhUgHjPctbLCI1VuSj3xcjI8QFTpdM
                8k3cYrfwB/WlNKjnnjt98nPmHv6frnuvs2LKIvvGzz++
                kVwVc8uMLVyLOxVeKhygDurFQpLNNdPumuc2MMRvV9me
                fPrdKWtEEtOxq6Pce3DW2qRLjyE1n1oEq44gixn6hjgo
                sG2FzV4fTQdxdYCzlYjsaZwy0Kww4HpIaozGNjoDQVI/
                f3JtLpE1MYEb9DiUVMjkwVR5yH2UhJwZH6VVvDOZg6u6
                YPOSUDVvyofCGcICLqUOG+qITYVucyIWgZtHZUb49dpG
                aJTAdVKlOTbYV9sbmHNuMuGt+1/rc+StsjTPTHU=
                ) ; key id = 40400
example.com.        86400 IN DNSKEY   257 3 7 (
                AwEAAa2BE0dAvMs0pe2f+D6HaCyiFSHw47BA82YGs7Sj
                qSqH3MprNra9/4S0aV6SSqHM3iYZt5NRQNTNTRzkE18e
                3j9AGV8JA+xbEow74n0eu33phoxq7rOpd/N1GpCrxUsG
                kK4PDkm+R0hhfufe1ZOSoiZUV7y8OVGFB+cmaVb7sYqB
                RxeWPi1Z6Fj1/5oKwB6Zqbs7s7pmxl/GcjTvdQkMFtOQ
                AFGqaaSxVrisjq7H3nUj4hJIJ+SStZ59qfW3rO7+Eqgo
                1aDYaz+jFHZ+nTc/os4Z51eMWsZPYRnPRJG2EjJmkBrJ
                huZ9x0qnjEjUPAcUgMVqTo3hkRv0D24I10LAVQLETuw/
                QOuWMG1VjybzLbXi5YScwcBDAgtEpsQA9o7u6VC00DGh
                +2+4RmgrQ7mQ5A9MwhglVPaNXKuI6sEGlWripgTwm425
                JFv2tGHROS55Hxx06A416MtxBpSEaPMYUs6jSIyf9cjB
                BMV24OjkCxdz29zi+OyUyHwirW51BFSaOQuzaRiOsovM
                NSEgKWLwzwsQ5cVJBEMw89c2V0sHa4yuI5rr79msRgZT
                KCD7wa1Hyp7s/r+ylHhjpqrZwViOPU7tAGZ3IkkJ2SMI
                e/h+FGiwXXhr769EHbVE/PqvdbpcsgsDqFu0K2oqY70u
                SxnsLB8uVKYlzjG+UIoQzefBluQl
                ) ; key id = 62910

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 27 18:18:30 2013
;; MSG SIZE  rcvd: 839

RRSIGレコードの存在を確認してください。

dig A example.com. @localhost +noadditional +dnssec +multiline
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> A example.com. @localhost +noadditional +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.         IN A

;; ANSWER SECTION:
example.com.          86400 IN A 93.184.216.119
example.com.          86400 IN RRSIG A 7 2 86400 20131227171405 (
                            20131127171405 40400 example.com.
                            JCoL8L7As1a8CXnx1W62O94eQl6zvVQ3prtNK7BWIW9O
                            lir/4V+a6c+0tbt4z4lhgmb0sb+qdvqRnlI7CydaSZDb
                            hlrJA93fHqFqNXw084YD1gWC+M8m3ewbobiZgBUh5W66
                            1hsVjWZGvvQL+HmobuSvsF8WBMAFgJgYLg0YzBAvwHIk
                            886be6vbNeAltvPl9I+tjllXkMK5dReMH40ulgKo+Cwb
                            xNQ+RfHhCQIwKgyvL1JGuHB125rdEQEVnMy26bDcC9R+
                            qJNYj751CEUZxEEGI9cZkD44oHwDvPgF16hpNZGUdo8P
                            GtuH4JwP3hDIpNtGTsQrFWYWL5pUuuQRwA== )

;; AUTHORITY SECTION:
example.com.          86400 IN NS master.example.com.
example.com.          86400 IN NS slave.example.com.
example.com.          86400 IN RRSIG NS 7 2 86400 20131227171405 (
                            20131127171405 40400 example.com.
                            hEGzNvKnc3sXkiQKo9/+ylU5WSFWudbUc3PAZvFMjyRA
                            j7dzcVwM5oArK5eXJ8/77CxL3rfwGvi4LJzPQjw2xvDI
                            oVKei2GJNYekU38XUwzSMrA9hnkremX/KoT4Wd0K1NPy
                            giaBgyyGR+PT3jIP95Ud6J0YS3+zg60Zmr9iQPBifH3p
                            QrvvY3OjXWYL1FKBK9+rJcwzlsSslbmj8ndL1OBKPEX3
                            psSwneMAE4PqSgbcWtGlzySdmJLKqbI1oB+d3I3bVWRJ
                            4F6CpIRRCb53pqLvxWQw/NXyVefNTX8CwOb/uanCCMH8
                            wTYkCS3APl/hu20Y4R5f6xyt8JZx3zkZEQ== )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 28 00:01:06 2013
;; MSG SIZE  rcvd: 1335

マスターサーバーの構成が完了しました。

DNSSECスレーブ構成

スレーブサーバーでは、DNSSECを有効にし、ゾーンファイルの場所を変更するだけで済みます。 BINDのメイン設定ファイルを編集します。

nano /etc/named.conf

これらの行が存在しない場合は、options { }セクション内に配置します。

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

zone { }セクション内のfileオプションを編集します。

zone "example.com" IN {
    type slave;
    file "example.com.zone.signed";
    masters { 1.1.1.1; };
    allow-notify { 1.1.1.1; };
};

BINDサービスをリロードします。

service named reload

新しい.signedゾーンファイルがあるかどうかを確認します。

[[email protected] ~]# ls -l /var/named/slaves/
total 16
-rw-r--r-- 1 named named  472 Nov 27 17:25 example.com.zone
-rw-r--r-- 1 named named 9180 Nov 27 18:29 example.com.zone.signed

出来上がり! それでおしまい。 正常に動作していることを確認するために、前のセクションで説明したように、digを使用してDNSKEYにクエリを実行します。

レジストラを使用してDSレコードを構成する

.signedゾーンファイルとは別にdnssec-signzoneコマンドを実行すると、dsset-example.comという名前のファイルも作成されました。これにはDSレコードが含まれています。

[email protected]er:/var/cache/bind# cat dsset-example.com.
example.com.        IN DS 62910 7 1 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD
example.com.        IN DS 62910 7 2 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859F FFC3F59D

これらは、ドメインレジストラのコントロールパネルに入力する必要があります。 以下のスクリーンショットは、GoDaddyの手順を示しています。

ドメインレジストラのコントロールパネルにログインし、ドメインを選択して、DSレコードを管理するオプションを選択します。 GoDaddyのコントロールパネルは次のようになります。

GoDaddy's Domain control panel

dsset-example.com.ファイルのデータの内訳は次のとおりです。

DSレコード1:

キータグ: 62910 アルゴリズム: 7 ダイジェストタイプ: 1 ダイジェスト: 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD

DS record 1

DSレコード2:

キータグ: 62910 アルゴリズム: 7 ダイジェストタイプ: 2 ダイジェスト: 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859FFFC3F59D

DS record 2

dsset-example.com.ファイルの2番目のDSレコードにはダイジェストにスペースがありましたが、フォームに入力するときは省略してください。 次へをクリックし、完了をクリックしてレコードを保存します。

これらの変更が保存されるまでに数分かかります。 DSレコードが作成されているかどうかを確認するには、TLDのネームサーバーに問い合わせます。 TLDのネームサーバーを見つける代わりに、はるかに簡単なdig +traceを実行できます。

[email protected]:~# dig +trace +noadditional DS example.com. @8.8.8.8 | grep DS
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> +trace +noadditional DS example.com. @8.8.8.8
example.com.          86400   IN      DS      62910 7 2 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859F FFC3F59D
example.com.          86400   IN      DS      62910 7 1 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD

これが確認されると、次のオンラインサービスのいずれかを使用して、DNSSECが正常に機能しているかどうかを確認できます。

最初のツールは単純なツールですが、2番目のツールは物事を視覚的に表現します。 これが最初のツールのスクリーンショットです。

私がマークした線に注意してください。 最初のものはDSレコードのキータグ値(62910)に言及し、2番目のものはZSK(ゾーン署名キー)を保持するDNSKEYレコードのキーID (40400)に言及します。

ゾーンレコードの変更

レコードを追加または削除してゾーンを編集するたびに、ゾーンを機能させるために署名する必要があります。 そのため、毎回長いコマンドを入力する必要がないように、このためのスクリプトを作成します。

[email protected]# nano /usr/sbin/zonesigner.sh

#!/bin/sh
PDIR=`pwd`
ZONEDIR="/var/cache/bind" #location of your zone files
ZONE=$1
ZONEFILE=$2
DNSSERVICE="bind9" #On CentOS/Fedora replace this with "named"
cd $ZONEDIR
SERIAL=`/usr/sbin/named-checkzone $ZONE $ZONEFILE | egrep -ho '[0-9]{10}'`
sed -i 's/'$SERIAL'/'$(($SERIAL+1))'/' $ZONEFILE
/usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o $1 -t $2
service $DNSSERVICE reload
cd $PDIR

ファイルを保存して実行可能にします。

[email protected]# chmod +x /usr/sbin/zonesigner.sh

レコードを追加または削除する場合は、.signedファイルではなくexample.com.zoneおよびを編集してください。 このファイルはシリアル値のインクリメントも処理するため、ファイルを編集するたびにインクリメントする必要はありません。 編集後、ドメイン名とゾーンファイル名をパラメータとして渡してスクリプトを実行します。

[email protected]# zonesigner.sh example.com example.com.zone

増分シリアルは転送および更新された場合にゾーンを保証するため、スレーブネームサーバーで何もする必要はありません。

ゾーンウォーキングからDNSSECセットアップを保護する

Zone Walking は、 NSEC (Next-Secure)レコードをクエリすることにより、ゾーンのすべてのリソースレコードを検索するために使用される手法です。 NSEC3 がリリースされ、ソルトを使用してこの情報を「ハッシュ」しました。 -3オプションを指定したdnssec-signzoneコマンドに続いて、ランダムな文字列を生成するための別の複雑なコマンドを思い出してください。 これは、次のdigクエリを使用して見つけることができるソルトです。

# dig NSEC3PARAM example.com. @master.example.com. +short
1 0 10 7CBAA916230368F2

これらすべてがゾーンの歩行を困難にしますが、不可能ではありません。 レインボーテーブルを使用していると判断したハッカーは、長い時間がかかりますが、ハッシュを破ることができます。 これを防ぐために、このソルトを定期的に再計算できます。これにより、ハッカーは古いソルトのハッシュを見つける前に新しいソルトがあるため、ハッカーの試みは無駄になります。 以前に作成したzonesigner.shスクリプトを使用して、これを行うためのcronジョブを作成します。 cronジョブをrootとして実行する場合、ファイルの所有権について心配する必要はありません。 または、cronを配置するユーザーが、ゾーンディレクトリに対する書き込み権限と秘密鍵 Kexample.com )に対する読み取り権限を持っていることを確認してください。 。*。プライベート)。

[email protected]:~# crontab -e

0       0       */3     *       *       /usr/sbin/zonesigner.sh example.com example.com.zone

これにより、3日ごとにゾーンに署名され、その結果、新しいソルトが生成されます。 dnssec-signzoneコマンドの出力を含む電子メールも受信します。

提出者:http: //jesin.tk/