---------------------------------------------------------------------
■ DNS の再帰的な問合せを使った DDoS 攻撃の対策について
2006/03/29 (Wed)
---------------------------------------------------------------------
▼概要
DNS の再帰的な問合せ (recursive queries) を使った DDoS 攻撃が数多く発
生しています。適切なアクセス制限を行っていない DNS サーバは、DDoS 攻撃
の踏み台として使用される可能性があります。
DNS サーバはその機能から、キャッシュサーバ (Recursive Server) とコンテ
ンツサーバ (Authoritative Server) の 2 つに分類することができます。ま
た、両機能を兼ね備えたキャッシュ・コンテンツ兼用サーバもあります。
このうち、再帰的な問合せを処理するのがキャッシュサーバであり、本ドキュ
メントは、キャッシュサーバ (兼用サーバを含む) の運用管理者を対象として
います。
コンテンツサーバの設定についても、本ドキュメントを参考に設定を見直して
いただければ幸いです。
* キャッシュサーバ
クライアントからの問い合わせ要求を受けると、コンテンツサーバに対し
て再帰的に問い合わせを行い、結果をクライアントに返す DNS サーバで
す。PC などがインターネットに接続する際に設定する DNS サーバであり、
DHCP や PPP などで自動的に設定される場合もあります。
* コンテンツサーバ
管理するドメインの情報 (ゾーン情報) を持ち、キャッシュサーバからの
問合せに回答する DNS サーバです。
* キャッシュ・コンテンツ兼用サーバ
名前の通り、1 台の DNS サーバでキャッシュサーバとコンテンツサーバ
の両方を兼用するものです。インターネットで利用されている DNS サー
バの多くが、この兼用型であるという統計があります。
▼攻撃の踏み台とならないために BIND 編
DNS サーバの実装として最も多く利用されている BIND は、設定ファイルに指
定しない限り、アクセス制限は行われません。アクセス制限を明示的に指定し
ていない BIND のキャッシュサーバは、DDoS 攻撃の踏み台となる可能性があ
ります。
以下に、アクセス制限を行ったキャッシュ・コンテンツ兼用型の BIND の設定
ファイルの例を示します。これは次のような機能を持つ DNS サーバでの設定
例です。
- 自組織向けにキャッシュサーバの機能を提供している。
- 自組織のネットワークで利用している IP アドレスは、202.11.16.0/23、
192.168.100.0/24、172.20.0.0/16 である。
- "example.jp" と "example2.jp" のコンテンツサーバの機能を提供してい
る。
- "example.jp" は自組織のドメインであり、マスタサーバとして動作し
ている。
- "example2.jp" は別組織のドメインであり、セカンダリサーバとして動
作している。
なお、後に説明する一部の設定を除いて、本設定は BIND 8 と BIND 9 で共通
に利用できるものです。但し、実際に利用する場合は、controls (以下の例で
は省略) を正しく設定してください。controls が無くても動作しますが、設
定ファイルの再読み込みなどができなくなることがあります。
キャッシュ・コンテンツ兼用サーバ
-------------------------------------------------------------------
1 // [パート 1] 自組織のネットワークの設定
2 //
3 acl my-network {
4 202.11.16.0/23 ;
5 192.168.100.0/24 ;
6 172.20.0.0/16 ;
7 } ;
8
9 // [パート 2] グローバルオプションの設定
10 //
11 options {
12 fetch-glue no ; // BIND 9では不要
13 recursion yes ; // キャッシュサーバの場合 yes
14 directory "/etc/ns" ;
15
16 allow-query {
17 localhost ;
18 my-network ;
19 } ;
20 allow-transfer { none ; } ;
21 };
22
23 // [パート 3] ルートサーバへの hint 情報
24 //
25 zone "." {
26 type hint ;
27 file "named.root" ;
28 } ;
29
30 // [パート 4] example.jpのマスターサーバとしての設定
31 //
32 zone "example.jp" {
33 type master ;
34 file "example.jp.zone" ;
35 allow-query { any ; } ;
36 allow-transfer { 172.20.10.1 ; } ;
37 } ;
38
39 // [パート 5] example2.jpのセカンダリーサーバとしての設定
40 //
41 zone "example2.jp" {
42 type slave ;
43 file "bak/example2.jp.zone" ;
44 masters { 192.168.100.200 ; } ;
45 allow-query { any ; } ;
46 } ;
-------------------------------------------------------------------
[パート 1] 自組織のネットワークの設定
3 ～ 7 行目は、アクセス制限を行うために、自組織のネットワークを定義
しています。ここでは、"my-network" という名前で、自組織のネットワー
クである 202.11.16.0/23、192.168.100.0/24、172.20.0.0/16 の 3 つの
IP アドレスの範囲を指定しています。
[パート 2] オプションの設定
11 ～ 21 行目がグローバルなオプションの設定です。12 行目の
fetch-glue は必ず no を設定します。尚 BIND 9 ではいかなる場合も
fetch-glue の機能は no ですので、この行は不要です。13 行目の
recursion yes が、BIND をキャッシュサーバとして動作させるために必要
なオプションです。BIND のデフォルト値は yes ですが、ここでは明示的に
記述しています。
16 ～ 19 行目がアクセス制限の肝となる、allow-query の設定です。
allow-query には、アクセスを許可するネットワークを記述するため、[パー
ト 1]で記述した自組織のネットワークと、localhost (127.0.0.1 や ::1)
からのアクセスを指定します。グローバルオプションで allow-query を記
述することで、このサーバ全体が指定ネットワークからのアクセスのみを許
可するようになります。
BIND ではデフォルトで任意のサーバからのゾーン転送を許すため、20 行目
の allow-transfer で none を指定し、一旦全てのサーバからのゾーン転送
を禁止します。
[パート 3] ルートサーバへの hint 情報
25 ～ 28 行目がルートサーバへの hint 情報です。これはキャッシュサー
バとして動作させる場合に必要なものですので、必ず記述してください。尚
"named.root" は、本ドキュメント執筆時点では、2004 年 1 月 29 日のも
のが最新です (ファイル内に日付が記述してあります)。もしこれより古い
ものしか手元に無い場合には、最新版を以下より入手して下さい。
ftp://ftp.internic.net/domain/named.root
[パート 4] example.jp のマスタサーバとしての設定
32 ～ 37 行目までが "example.jp" のマスタサーバとしての設定です。ゾー
ン情報は、example.jp.zone というファイルに保存してあります。
ここでもっとも重要なのが 35 行目の allow-query の行です。このサーバ
では [パート 2] の options で、自組織のネットワークのみアクセスを許
可する設定を行っています。したがって、このままではコンテンツサーバと
して組織外からの問い合わせに回答しなくなるため、35 行目の
allow-query に any を指定して、インターネット全体からの問い合わせに
回答するように設定します。
36 行目の allow-transfer は、example.jp のセカンダリサーバである
172.20.10.1 へのゾーン転送を許可する設定です。
[パート 5] example2.jp のセカンダリーサーバとしての設定
41 ～ 46 行目までが "example2.jp" のセカンダリサーバとしての設定です。
example.jp のマスタサーバの設定と同様に、45 行目の allow-query を設
定しています。
▼ BIND でのキャッシュサーバとコンテンツサーバの分離
BIND はキャッシュ・コンテンツ兼用型として設定されることがあります。し
かし、コンテンツサーバとキャッシュサーバを分離することで、ルータやファ
イアウォールによる適切なパケットフィルタリングなどを行うことが可能にな
ります。上記の設定を元にキャッシュサーバとコンテンツサーバを分離した設
定例を以下に示します。
現在 BIND 8 でキャッシュ・コンテンツ兼用サーバを運用している場合は、こ
の設定のように分離した運用を行うことを強く推奨します。
コンテンツサーバ用の設定
-------------------------------------------------------------------
1 // [パート 2] グローバルオプションの設定
2 //
3 options {
4 fetch-glue no ; // BIND 9 では不要
5 recursion no ; // コンテンツサーバの場合は no
6 directory "/etc/ns" ;
7 allow-transfer { none ; } ;
8 };
9
10 // [パート 3] ルートサーバへの hint 情報
11 //
12 zone "." {
13 type hint ;
14 file "/dev/null" ; // ファイル名に /dev/null を指定する
15 } ;
16
17 // [パート 4] example.jp のマスターサーバとしての設定
18 //
19 zone "example.jp" {
20 type master ;
21 file "example.jp.zone" ;
22 allow-transfer { 172.20.10.1 ; } ;
23 } ;
24
25 // [パート 5] example2.jp のセカンダリーサーバとしての設定
26 //
27 zone "example2.jp" {
28 type slave ;
29 file "bak/example2.jp.zone" ;
30 masters { 192.168.100.200 ; } ;
31 } ;
-------------------------------------------------------------------
特に重要なところは、5 行目の recursion no と 13 行目の hint 情報のファ
イル名として "/dev/null" を指定している点です。この設定では、特に
allow-query でアクセス制限を行う必要は無いため、[パート 1]にあたる acl
の設定はありません。
キャッシュサーバ用の設定
-------------------------------------------------------------------
1 // [パート 1] 自組織のネットワークの設定
2 //
3 acl my-network {
4 202.11.16.0/23 ;
5 192.168.100.0/24 ;
6 172.20.0.0/16 ;
7 } ;
8
9 // [パート 2] グローバルオプションの設定
10 //
11 options {
12 fetch-glue no ; // BIND 9 では不要
13 recursion yes ; // キャッシュサーバの場合 yes
14 directory "/etc/ns" ;
15
16 allow-query {
17 localhost ;
18 my-network ;
19 } ;
20 };
21
22 // [パート 3] ルートサーバへの hint 情報
23 //
24 zone "." {
25 type hint ;
26 file "named.root" ;
27 } ;
-------------------------------------------------------------------
キャッシュサーバとしては、ゾーンの設定が不要ですので [パート 4] と [パー
ト 5] にあたる部分を除いただけとなります。
▼攻撃の踏み台とならないために djbdns 編
djbdns は、キャッシュサーバとコンテンツサーバがそれぞれ別々の実装になっ
ており、キャッシュサーバとコンテンツサーバの兼用はできません。コンテン
ツサーバが tinydns、キャッシュサーバは dnscache です。
dnscache は、BIND と違い、指定した IP アドレスからのみアクセスを受け付
けます。このため、すでに設定されている dnscache が DDoS の踏み台として
利用される可能性は低いのですが、この機会に改めて設定の見直しを行うこと
をお勧めします。
dnscache のアクセス制限は、設定ディレクトリ内の ip ディレクトリにある
ファイルで指定します。ここでは、/var/service/dnscache/root/ip であると
します。
$ cd /var/service/dnscache/root/ip
$ ls
127.0.0.1 202.11.16
この場合は、ローカルホストである、127.0.0.1 と 202.11.16.0/24 からのア
クセスを許すようになっています。アクセス制限の範囲を広げて
202.11.16.0/23 からのアクセス (つまり 202.11.16.0/24 と
202.11.17.0/24) を許可するのであれば、上記の環境で以下を実行します。
$ touch /var/service/dnscache/root/ip/202.11.17
▼攻撃の踏み台とならないために Windows DNS サービス編
Windows の DNS サーバである、Windows DNS サービスは、単体ではアクセス
を制限する機能はありません。またコンテンツサーバとキャッシュサーバの機
能が兼用となっています。このため、キャッシュサーバにアクセス制限を行う
には、2 台のサーバを使い、キャッシュサーバとコンテンツサーバを物理的に
分離し、キャッシュサーバ側にのみルータ等の外部の機器によるアクセス制限
を施す必要があります。
Windows DNS サービスで、コンテンツ専用サーバとするには、DNS コンソール
のプロパティを選びます。詳細タブに「再帰を無効にする」というチェックボッ
クスがあるので、ここを選択すると、コンテンツ専用サーバになります。
---------------------------------------------------------------------
株式会社日本レジストリサービス Copyright©2001-2024 Japan Registry Services Co., Ltd.