アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ポートのランダムだけでは単なる軽減ですよ (スコア: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 なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。(分離しても前のコメントの方法
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:2, 参考になる)
https://www.dns-oarc.net/oarc/services/dnsentropy [dns-oarc.net]
だと図示されて説得力があります(中央の Test My DNS をクリック)
ちなみにインターネットに出て行くところで NAPT 機構が噛んでいて、フルリゾルバがその内側にいる場合、
bind / djbdns / unbound / PowerDNS recursor などでソースポートランダム化がおこなわれても
実際にインターネットに出て行くソースポートは全部インクリメンタルに整列されてしまって
対策意図が台無しということがありますので要注意
(上記 URL だと一目瞭然)