ここ数日、BINDに関わる脆弱性の話題が、ツイッターやMLなどを賑わしている。そこで、今回は、このBINDの脆弱性について書いてみたいと思う。

■ 今回の脆弱性は何？

今回発見されたBINDの脆弱性は、query.c に起因するバッファオーバーフローだ。ソース名からおわかりいただけるように、DNSに対するQueryに対する脆弱性が発見されている。

今回の脆弱性は、キャッシュサーバに特定のレコードをあらかじめキャッシュさせ、それを呼び出すことでDNSがクラッシュする。

queryを行う際に特定の攻撃手法を用いることで、適切に処理ができなくなり、クラッシュしていると想定される。

このqueryは、キャッシュ機能と呼ばれる機能に対する脆弱性であるそのため、キャッシュ機能を提供していない場合は、問題のあるバージョンであっても、クラッシュしないと想定される。

■ 対策するにはどうすればいいの？

現在わかっている対策方法は２つある。１つは、パッチを素直に適用する方法。１つは、キャッシュサーバの提供をやめる方法だ。*1

通常、Google DNSの様に、広く誰もが自由に使ってよいDNSを提供していることは希である。セキュリティ上の観点からも、広く公開することは決して安全であるとは言えない。

■ もう少し踏み込んでセキュリティ対策を考えてみる

先ほどまでの話は、個別のBINDをどのように対策するかに終始した。今回は、実運用する際にDNSをどのように運用すべきかを考えてみる。

通常、DNSを提供する場合、２種類の理由から運用を行う

1. インターネットにサイトを設置し、ドメインを運用する。
2. クライアントが存在し、インターネットに接続するために運用する。

上記２つのDNSは、１台で運用しているケースが多い。これは、コスト削減の一環から、そのようになる。また、実際に運用が始まった場合、保守のことを考えるなら、保守機材は少ない方が運用しやすい。こう言った理由からも、１台で運用しているケースが多いだろう。

しかしながら、今回の様に、キャッシュサーバに対する攻撃が始まったことを考えるなら、ドメイン情報を提供するサーバと、キャッシュサーバは分離した方が良い。これは、キャッシュサーバを今回の様にメンテナンスしている際に、ドメイン情報を提供するサーバに、影響を与えない為である。