DNS Cache Poisoning 話
すでにわしがrootなりサブrootとして関与しているサイトは対策済み。ただ詳細が正式公開される前の話だったので、 Web-based DNS Randomness Testと、tcpdumpでテストして問題ないことは確認したわけだが、どんな穴でどんなインパクトがあるのかチェックしとく*1。
とりあえず、まとまっている資料を探してみるとこのあたり。
特に気になるのは、メールサーバがポイズニングされたレコードを参照すると、オリジナルの資料の通り NSA 状態になる。これに対抗するには、メールならS/MIMEかPGPになるのだろうかね。しかし普及していないという罠。攻撃側がメールをリレーし、Received も残らないと文字通り何も起きていないように見える*2ので、これは、extreamに危険だな。HTTPSなら証明書チェインにより正しいサーバにつながっているかどうかわかり、しかも証明書チェインは完璧に普及しているわけで、まだマシか。
興味深いのは、攻撃の成功確率を下げる為の施策が、いわゆる一般的なセキュリティ対策そのままであることか。キャッシュサーバに限れれば、
コンテンツサーバなら、権威サーバの数を増やして同じドメインで運用*5して、lameにならないように。などなど。やはり基本が重要か*6。
コンテンツサーバの管理者としては、セカンダリサーバの数を改めてチェックしてみる。JPRSのRFC2182によれば、
5. 何台のセカンダリーが適切か？ DNSの仕様とドメイン名登録規則は、各ゾーンに対して最低2台のサーバーを 要求している。通常これはプライマリーと1台のセカンダリーである。 2台であっても注意深く配置すれば大抵の場合は充分であるが、2台では 不十分な場合もよく発生するので、我々は2台より多くの明記サーバーの 使用を勧める。 (snip) 一般的な組織のゾーンでは、3台のサーバーを設定し、3台のうち少なくとも 1台を他のサーバーから充分に離すことを推奨する。より高い信頼性を 必要とするゾーンに対しては4台、あるいは5台のサーバーが望ましい。
となっているので、３台はやはり必要か。攻撃確率を表す式をみてもセカンダリの数が分母にくるわけで、障害や今回の件に対する耐性がいくらか向上する。
歯がゆいのは、攻撃されるのが「ターゲットサイト」ではなくて、キャッシュDNSサーバであることか。管理しているサイトで、いくら対策を施しても、どこかのDNSサーバがやられるとそのDNSサーバを参照しているクライアントだけが影響を受ける。つまり被害はどうしたって限定的になりやすい。つまり気づきにくい。これはサポート側でチェック対象にした方がいいのかもしらんね。
