BIND 9のセキュリティ対策：実用 BIND 9で作るDNSサーバ（9）（2/2 ページ）
DNSは広く公開するサービスであるため、その運用には細心の注意が要求される。BINDを攻撃者から守るには何をすればよいか。今回はBINDで行うべきセキュリティ対策を紹介する。（編集局）
ゾーンサーバの対策
ゾーン情報の改ざん対策
現在のところ、namedプロセスやDNSの脆弱性を利用したゾーン情報改ざんの心配はありませんが、サーバそのものを乗っ取られてしまえばその限りではありません。
BIND 9自体の対策については前出の「ユーザー権限の奪取対策」を参照していただくとして、BIND以外のアプリケーションや構成上の欠陥についても踏み台にされないように努める必要があります。ゾーン情報そのものが改ざんされないまでも、問い合わせクエリーに対する応答メッセージが、問い合わせ元に到達するまでに改ざんされる危険性もあり得ます。このような事態を未然に防ぐ手段として、DNSにセキュリティ拡張を施す試みが行われています。DNSにセキュリティ拡張については、後半の「DNSSEC（DNSセキュリティ拡張）」で後述します。
不正ユーザーによるゾーン転送や不正DDNSの対策
もしWebサーバやメールサーバのアドレスを公にしたいのなら、ゾーン情報を利用する対象を絞ることは残念ながらできません。一部の人だけにアドレスを公開する場合、一般的にWebサーバやメールサーバも限られた利用に限定されます。
そこで、せめてゾーン転送とDDNS（Dynamic DNS）の不正利用を防ぐために、アクセスリスト（ACL）やTSIG鍵を用いてセキュアなサービスが保てるようにします。こちらについては以下を参照ください。
キャッシュサーバの対策
キャッシュ汚染攻撃対策
現在のDNSの利用方法では、DNSの応答を無条件に信頼するしかありません。
例えば、Webブラウザでwww.atmarkit.co.jpに接続する際に、WebブラウザはDNSキャッシュサーバにwww.atmarkit.co.jpのIPアドレスを問い合わせます。DNSキャッシュサーバから返されたIPアドレスが偽りのものだったら、どうなるでしょうか。見当外れのWebページが表示されれば不審に思いますが、Webページのデザインまで模倣されていては、でたらめなサーバにアクセスしていることに一見して気付くことはできません。
こうした偽のキャッシュ情報で、DNSが汚染される可能性を否定できるでしょうか。例として、次のような事象を考えてみましょう。
悪意のある個人（攻撃者）がexample.jpドメインを取得し、次のようなゾーンレコードを用意したとします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
通常、www.atmarkit.co.jpのアドレスを解決するにはatmarkit.co.jpのDNSを参照しますが、もし上記のようなレコードがまかり通ってしまった場合、example.jpドメインを参照したDNSキャッシュサーバ（攻撃対象）には次のようなキャッシュ情報が蓄積されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「example.jpのNSレコードはwww.atmarkit.co.jp」と「www.atmarkit.co.jpのIPアドレスは1.2.3.4」が蓄積されたてしまった後で、普段どおりwww.atmarkit.co.jpのアドレス解決をDNSキャッシュサーバ（攻撃対象）に問い合わせてきたクライアントには、1.2.3.4という見当違いなIPアドレスが返されます。もし、1.2.3.4がwww.atmarkit.co.jpを中傷するようなページであったり、ショッピングページを装ってカード番号の窃盗をもくろんでいたとしても、ユーザーにはアドレスバーに「www.atmarkit.co.jp」と表示されている以上、一見して正規のページと区別がつきません。
「クライアントはDNSの応答を信用せざるを得ない」という、DNS元来の脆弱性も絡み大変危険な事態に発展してしまいますが、いくつかの前提条件に依存したこの仮定が実際に発生することは大変まれです。まず、example.jpのゾーン情報にatmarkit.co.jpのような他ドメインの情報を盛り込むことは、基本的にはできません（注）。
BIND 9では、次のようなログを出力して他ドメインの情報を無視します（注）。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
攻撃者AのDNSがこのような防御を備えていなかったり、あえて外している可能性もあります。その場合でも、DNSキャッシュサーバ（攻撃対象）がBIND 9であれば、返答された「www.atmarkit.co.jp IN A 1.2.3.4」をキャッシュしません。キャッシュ汚染を防ぐには最新のBINDを使用し、併せてキャッシュサーバを使用するユーザーを次に紹介する方法で限定します。
キャッシュサーバの不正利用対策
ゾーンサーバの利用対象者を絞ることはできませんが、キャッシュサーバはその限りではないはずです。そこで、キャッシュサーバの利用対象者をallow-recursionを用いて制限します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
再帰問い合わせ数の制限
キャッシュサーバへの突発的な高頻度問い合わせ要求は、named.confのoptionsステートメントにrecursive-clientsを挿入することで抑制できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ただし、サーバのリソースは食いつぶされないまでも、recursive-clientsを超える要求が発生した場合は、DNSとしての役目を果たせなくなるので注意が必要です。
DNSSEC（DNSセキュリティ拡張）
DNSそのものの脆弱性の1つに、ゾーン情報の信ぴょう性を保証する手段がないことが挙げられます。第5回や第8回ではTSIG鍵を紹介しましたが、これは共有鍵を配布する必要があり、広くそれも不特定多数で使用するのは事実上不可能です。
そこで、RSAなどの公開鍵暗号方式のような仕組みが必要となるわけです。公開鍵暗号方式でゾーン情報に鍵を掛けることで、DNSクエリーで交換されるメッセージを認証可能にし、ゾーン情報の信頼性を確保します。そのためキャッシュ汚染やクエリー応答メッセージのなりすましといった事態にも対応可能になります。
現在、DNSを改善するためのセキュリティ拡張はIETF（http://www.ietf.org/）のDNSEXT（DNS Extensions）ワーキンググループ（http://www.ietf.org/html.charters/dnsext-charter.html）で作業が進められており、この成果が順次BIND 9に反映されています（注）。
インターネットの普及とともに、セキュリティに対する対価も大きくなってきています。社会的な犯罪は法とモラルで対応する必要がありますが、インターネットの世界においては技術力とそれに追随する努力で未然に抑制することができます。中にはspamのように技術者の枠を逸脱した問題もありますが、DNSではそうしたことが起こらないように、われわれ管理者が死守していく必要があります。DNSSECのような、よりセキュアな実装が登場することに期待しつつ、せめて自社で運用するDNSには普段から配慮を怠らないようにしましょう。
- BIND 9を徹底活用するためのTips集
- DNSの拡張仕様、SRVレコードとENUM
- 次世代のセキュリティ拡張DNSSECをBIND 9で実現
- IPv6対応DNSサーバの実現
- BIND 9のチューニングと大規模運用
- BIND 9の運用情報収集と分析方法
- BIND 9のセキュリティ対策
- DHCPとDynamic DNSの連携システム
- Dynamic DNSの基礎とnsupdateコマンド
- サブドメインの運用と委任
- スレーブ・サーバのゾーン転送とセキュリティ
- キャッシュ／逆引きDNSの構築と運用
- メール／Webサーバを効率的に動かすゾーン設定
- すべての基礎、マスター・ゾーンサーバの設定
- BIND 9の改ざんチェックとインストール
Copyright © ITmedia, Inc. All Rights Reserved.