DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。(分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが)
DNS Cache Poisoningの概要と対処 [nttv6.net] (PDF) というのが公開されていました。キャッシュサーバ側の対応の他、ドメイン管理者側でネームサーバ台数を増やすという方法が載っています。だとすると BIND のような多数の IP アドレスに bind できるサーバを使用していてグローバル IP アドレスに余裕があれば、自分のサイトが偽装される率を落とすことができそうです。
$ dig +short porttest.dns-oarc.net TXT @192.168.xx.xx z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "xx.xx.xx.xx is POOR: 26 queries in 3.1 seconds from 26 ports with std dev 7.65"
だめじゃん… (26回問い合わせに 26個のポートを使っているが標準偏差(だと思う)が 7.65 と小さい) 完全にダメな場合は from 1 port と表示されます。
$ dig +short porttest.dns-oarc.net TXT @127.0.0.1 z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "xx.xx.xx.yy is GOOD: 26 queries in 3.0 seconds from 26 ports with std dev 16362.04"
DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。
リンクされている ZDNet の記事を読みましたが、「外部に再帰検索を許可した Open なキャッシュサーバであることを利用している」という印象をなぜ持たれたのかよくわかりませんでした。いずれにしても、外部から直接攻撃する代わりに、攻撃対象のネットワークの中の善意のユーザーに攻撃を肩代わりさせる方法も以前からあるようです。なので、今回新たに見つかった攻撃方法は、内部向けのキャッシュ DNS サーバーを外部向けの DNS サーバーから分離するだけでは防げないと思います。
なお、「今回新たに見つかった攻撃方法」と書きましたが、正確には、 full-disclosure メーリングリストのメール「The cat is indeed out of the bag [seclists.org]」 (の最後の 4 個の段落) に書いてある攻撃方法のことを指しています。これが Dan Kaminsky さんが 8 月に発表予定の脆弱性というのと同じかどうかは知りません。
(分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが)
ポートのランダムだけでは単なる軽減ですよ (スコア:0)
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:3, 参考になる)
どのくらい軽減かが問題ではないでしょうか。
いままで 16bit の ID で識別していたのを、さらに port をランダムにすることにより 16bit の識別できる情報が付加されたことになります。16bit であれば 65535通りで、これがまぐれ当たりする確率は誕生日のパラドックス [wikipedia.org]のために以外に高いということですが、さらに 16bit あれば実用上はなんとかなると思います。
たとえば、(サーバ攻略成功の確率50%を超えるのに)いままで 1時間かかるところが 16bit 増えることにより 60,000時間=6.8年になれば、単なる軽減ではなく当面は十分な軽減だと思いますが。
これでいいのか TTL [janog.gr.jp] (PDF) が信用できるとすると、port が 53 固定の場合で伏字の著名サイトで攻略可能性50%までの時間を 16時間~数年と計算しています。単純に 16bit 倍してはいけないと思いますが、桁数で考えても数年かかるのではと思います。計算式があるので計算してみてはどうでしょう。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:1)
実装の弱さ(疑似乱数の弱さ)を突いた攻撃をしてくれば何bit追加されても意味なし.
Re: (スコア:0)
ですので従来手法の何千・何万倍も効率良く攻撃できるので,
「今まで1時間かかるところが」の部分が「いままで数十秒かかるところが」に変わってしまったのが
現状なのだと思います。
なので,サーバへのパッチ当てが行われない場合,ポートの分散だけでは
軽減として十分とは言えないかもしれません。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:5, 参考になる)
[基本]
・汚染に成功させるためには ID と ポートを的中させる必要がある
・また本物のサーバからの応答との競争に勝つ必要がある
・本物のサーバとの競争に勝つ可能性が 1/2 と仮定すると、防御方法が
ポート固定で ID だけがランダムの場合には16ビットなので
65536 * 2 / 2 となり平均65536回の試行で汚染に成功する
[従来]
・今までのバースデイアタックでは一度失敗すると TTL が切れるまで
再攻撃が成功しなかった。
・よって従来方式で TTL 300秒ならば 300 * 65535秒 = 平均 227日の
かかる計算になる。
[今回]
・今回の方法では TTL に関係がなくサーバマシンの性能限りの速度で
攻撃が可能。最近の高速環境だと 10000 query/sec くらいは軽い。
・よって防御方法が ID だけだと 65536 / 10000 で平均6.5秒もあれば
汚染に成功する
[対策]
・サーバに今回の対策パッチを当てるとポートがランダムになる。
・ポートは16ビットあるが、さすがに全部は使えないので半分の
32768種類を使うとすると、攻撃に必要な時間は
6.5 * 32768 ≒ 213000秒 ≒ 平均2.5日になる。
[結論]
・パッチを当ててない状態だと、もはや致命的。
・パッチを当てたからといって安全確実ではないが、当てないよりマシ。
・firewall とかでDNSパケットの流量制限してれば、もう少し安全かもしれない
・根本的な対策は DNSSEC ということになるけど、普及には時間がかかりそう
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:4, 参考になる)
どうもそのようです。私のコメントは誤解を生むものでした。申し訳ありません。
DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。(分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが)
DNS Cache Poisoningの概要と対処 [nttv6.net] (PDF) というのが公開されていました。キャッシュサーバ側の対応の他、ドメイン管理者側でネームサーバ台数を増やすという方法が載っています。だとすると BIND のような多数の IP アドレスに bind できるサーバを使用していてグローバル IP アドレスに余裕があれば、自分のサイトが偽装される率を落とすことができそうです。
キャッシュサーバのチェックツール:自分が使用できるキャッシュサーバのポートがランダムかどうかは、porttest.dns-oarc.net の TXT レコードを検索すると結果をテキストで返してくれるようです。
だめじゃん… (26回問い合わせに 26個のポートを使っているが標準偏差(だと思う)が 7.65 と小さい) 完全にダメな場合は from 1 port と表示されます。
OK の場合はこうなるようです。
nslookup でも「nslookup -q=txt porttest.dns-oarc.net チェック対象サーバ」でチェックできると思います。もしタイムアウトになったら 10秒置いてもう一度実行するとキャッシュから結果が引けると思います。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:2, 参考になる)
https://www.dns-oarc.net/oarc/services/dnsentropy [dns-oarc.net]
だと図示されて説得力があります(中央の Test My DNS をクリック)
ちなみにインターネットに出て行くところで NAPT 機構が噛んでいて、フルリゾルバがその内側にいる場合、
bind / djbdns / unbound / PowerDNS recursor などでソースポートランダム化がおこなわれても
実際にインターネットに出て行くソースポートは全部インクリメンタルに整列されてしまって
対策意図が台無しということがありますので要注意
(上記 URL だと一目瞭然)
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:1)
リンクされている ZDNet の記事を読みましたが、「外部に再帰検索を許可した Open なキャッシュサーバであることを利用している」という印象をなぜ持たれたのかよくわかりませんでした。いずれにしても、外部から直接攻撃する代わりに、攻撃対象のネットワークの中の善意のユーザーに攻撃を肩代わりさせる方法も以前からあるようです。なので、今回新たに見つかった攻撃方法は、内部向けのキャッシュ DNS サーバーを外部向けの DNS サーバーから分離するだけでは防げないと思います。
なお、「今回新たに見つかった攻撃方法」と書きましたが、正確には、 full-disclosure メーリングリストのメール「The cat is indeed out of the bag [seclists.org]」 (の最後の 4 個の段落) に書いてある攻撃方法のことを指しています。これが Dan Kaminsky さんが 8 月に発表予定の脆弱性というのと同じかどうかは知りません。
「前のコメントの方法」がどれを指しているかわからないので、もしかしたら同じことを意図されているのかもしれませんが。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:3, 参考になる)
dnscacheのように元からソースポートを分散させている場合は、パッチ当ては必要無い(パッチ自体が無い)です。
ですから、ソースポートを固定にする設定を行っている場合は、パッチを当てるだけでは効果が無いので、設定も見直す必要があります。
他にも、外部からの再帰的な問い合わせには答えないようにするのも重要です。
外部からの再帰的な問い合わせを無視すれば、それによる外部への問い合わせも行わないので、詐称も出来なくなります。
当然内部からの攻撃の対策にはなりませんが、外部からの攻撃を防げるだけでも十分に意味があると思います。
Open RecursionだとDNS amp攻撃の問題もあるので、この機会に是非とも対応を行って欲しいです。