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年になれば、単なる軽減ではなく当面は十分な軽減だと思
Re: (スコア:0)
ですので従来手法の何千・何万倍も効率良く攻撃できるので,
「今まで1時間かかるところが」の部分が「いままで数十秒かかるところが」に変わってしまったのが
現状なのだと思います。
なので,サーバへのパッチ当てが行われない場合,ポートの分散だけでは
軽減として十分とは言えないかもしれません。
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 月に発表予定の脆弱性というのと同じかどうかは知りません。
「前のコメントの方法」がどれを指しているかわからないので、もしかしたら同じことを意図されているのかもしれませんが。