---------------------------------------------------------------------■ DNS の再帰的な問合せを使った DDoS 攻撃の対策について 2006/03/29 (Wed)---------------------------------------------------------------------< o:p> ▼概要 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 ; &n bsp; 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 &nb sp; my-network ; 19 } ; 20 allow-transfer { none ; } ; 21 }; 22 23 // [パート 3] ルートサーバへの hint 情報
24 // 25 zone "." { & nbsp; 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 ��鮴瀋蠅靴泙后���首鞜�赱鈑重劉孑�舵猟���鞜郛ではいかなる場合�も
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 情報です。これはキャッシュサー
バとして動作させる場合に必要なものですので、必ず記述してください。尚
&qu ot;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 へのゾーン転送を許可する設定です。
[パート���首鞜�赱鈑重劉孑�弓��逅跂荻褓��鞜郛のセカンダリーサーバと��ての設定
41 〜 46 行目までが "example2.jp" のセカンダリサーバとしての設定です。
example.jp のマスタサーバの設定と同様に、45 行目の allow-query を設
定しています。
▼ BIND でのキ��礇奪轡絅機璽个肇灰鵐謄鵐張機璽个諒���首鞜�赱鈑重劉孑昭鏈霈鹿鏈霈鹿齔瘤昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь種咋商鈞齔纂�咋昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь舵猟��鞜郛首鞜�齡�綵с闌闥今崖崖崖Ьはキャッシュ・コンテンツ兼用型として設定されることがあります。しかし、コンテンツサーバとキャッシュサーバを分離することで、ルータやファイアウォールによる適切なパケットフィルタリングなどを行うことが可能になります。上記の設定を元にキャッシュサーバとコンテンツサーバを分離した設定例を以下に示します。< o:p> 現在� BIND 8 でキャッシュ・コンテンツ兼用サーバを運用している場合は、この設定のように分離した運用を行うことを強く推奨します。 コンテンツサーバ用の設定
-------------------------------------------------------------------1 // [パート 2] グローバルオプションの設定
2 // 3 options {4 fetch-glue no ; // BIND 9 では不要
5 recursion no ; // コンテンツサーバの場合は no
6 directory "/etc/ns" ; 7&nb sp; 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.z one" ; 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 情報のファイル名として &q uot;/dev/null" を指定している点です。この設定では、特�� allow-query でアクセス制限を行う必要は無いため、[パート 1]にあたる acl
の設定はありません。 キャッシュサーバ用の設定
-------------------------------------------------------------------1 // [パート 1] 自組織のネット��錙璽�寮瀋��首鞜�赱鈑重劉孑昭鏈霈鹿鏈霈鹿齔瘤昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь�碵雹�碵雹�碵雹��碵雹��鏈霈鹿鏈霈鹿齔瘤昭�鱚昭頏緇首鞜�赱鈑重劉孑��跂洲竢跫鮑３崖崖皆商鈞齔殺鈞齔殺鈞齔�界鈞齔�痺�逋�續�鳬�種咋昭�咋昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь�碵雹�碵雹�碵雹��碵雹�碵雹�碵雹�碵雹�碵雹�芦�窺蔚���纂鏈霈鹿鏈霈鹿齔瘤昭�鱚昭頏緇首鞜�赱鈑重劉孑��跂洲竢跫鮑３崖崖皆商鈞齔殺鈞齔殺鈞齔�畿鈞齔殺鈞齔殺鈞齔殺鈞齔殺鈞齔�厩荻蔚軒碓握渥牡�種咋昭�咋昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь�碵雹�碵雹�碵雹��碵雹�碵雹�碵雹�碵雹�碵雹�群�握握渥蔚�種咋昭�咋昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь�碵雹�碵雹�碵雹��碵雹��種咋昭�咋昭�鞜郛鹿頏緇腫鱚昭齔瘤�瘤臀杜��齡�綵с闌闥今崖崖崖Ь�碵雹�碵雹�碵雹��碵雹�鏈霈鹿鏈霈鹿齔瘤昭�鱚昭頏緇首鞜�赱鈑重劉孑��跂洲竢跫鮑３崖崖皆商鈞齔殺鈞齔殺鈞齔殺鈞齔珊�碵雹��鈞齔�杣�鞜郛首鞜�齡�綵с闌闥今崖崖崖���ぢパート 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 は、キャッシュサーバとコンテンツサーバがそれぞれ別々の実装になっ
ており、キャッシュサーバとコンテンツサーバの兼用はできません。コンテンツ��機璽个��首鞜�赱鈑重劉孑��銷粮鷦�鞜郛、キャッシュサーバは< span lang=EN-US> 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 この場合は、ローカ��襯曠好箸任△襦��首鞜�赱鈑重劉孑庄卸�����鞜郛と 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-2012 Japan Registry Services Co., Ltd.
沒有留言:
張貼留言