DNSキャッシュポイズニング攻撃を可能にする、SAD DNSと呼ばれる攻撃手法が公表される 24
ストーリー by nagazou
渡る世間は怖い人ばかり 部門より
渡る世間は怖い人ばかり 部門より
あるAnonymous Coward 曰く、
カリフォルニア大学リバーサイド校と清華大学の研究者らがSAD DNSと呼ばれる攻撃手法を公表した。 これは2008年頃に対策が行われたDNSキャッシュポイズニング攻撃を全ての主要なOSで復活させるもので、研究者らの調査によればオープンリゾルバの35%が脆弱な状態であったとのことだ。 DNSキャッシュポイズニング攻撃の関連ストーリー
この攻撃手法では、ICMPパケットの送信制限に関する実装上の仕様を用いてポートのランダム化を無効化することができる。
DNSについて誤った発言をしてしまうと怖い人がやってくるので、攻撃手法の詳細や対処方法については https://www.saddns.net/ を確認して頂きたい。
詳しい説明など (スコア:3, 参考になる)
こういうことがあるたびに Cloudflare さんは丁寧なブログを書いてくれるのでたいへん嬉しい限り（ただし英語）
詳細が気になる方はご参考に
https://blog.cloudflare.com/sad-dns-explained/ [cloudflare.com]
手短にまとめると，ポートのランダム化によりエントロピーが Ephemeral port と DNS のクエリ ID の積になってたのが
ICMP を使ったらあいてるポートがわかるので，結局エントロピーが DNS のクエリ ID = 2^16 = 65536 通りになって
大昔のカミンスキーアタックできますねという話の模様
やー，カミンスキー騒ぎ12年前ですか
時が経つのは早いなぁ
余裕の回避 (スコア:0, フレームのもと)
Your DNS server IP is 0.0.0.0
Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.
The test is conducted on 2020-11-16 00:00:00.000000000
Disclaimer: This test is not 100% accurate and is for test purposes only.
やっぱICMPってクソやわ。
こんなこともあろうかと、nftablesのmeterでlimit rateしていて本当に良かった。
「ICMPは無害だから無条件に通すべき」とかドヤってた馬鹿どもは反省しろよ。
浸透いうなの会 会長、おめーだ馬鹿。
Re: (スコア:0)
早速怖い人が来たぞー
Re: (スコア:0)
怖いけど、ちゃんと説明も添えてくれてて参考になる
// 関係ないけど、怖い人繋がりで大学の教授思い出したわ...
Re: (スコア:0, 荒らし)
icmpに本質的に問題があるんじゃなくて
現行のDNSの運用の方に本質的な問題があって(とはいえ、問題を緩和する方法はある、十分普及してないだけ)
icmpはその穴を突くのに利用されているだけなんですけどね...
その証拠に「icmpでrate limitしてないと、httpのセキュリティが低下する」なんて事態は起きない。
> 「ICMPは無害だから無条件に通すべき」とかドヤってた馬鹿どもは反省しろよ。
> 浸透いうなの会 会長、おめーだ馬鹿。
DNSの浸透なんて無知を示す言葉を使ってしまって、いまだに恨みに思ってる人ですか？
大変ですね...
Re: (スコア:0)
> その証拠に「icmpでrate limitしてないと、httpのセキュリティが低下する」なんて事態は起きない。
この攻撃はrate limitしていることによって成立するのだが? 論文読んだ?
Re: (スコア:0)
なんだろう、この何から何まで分かってない感に満ちたコメントは
Re: (スコア:0)
ICMPって無害だっけ？ICMP爆弾ってOSが落ちるのなかった？
プロトコル拡張して (スコア:0)
それこそ公開鍵暗号とか使ってIPアドレスとドメイン名から作るハッシュで認証すればなりすまし防止できるのでは？
もしくは通信まるごと全部暗号化しちゃうとか(ICMPsになるのかな？)
Re: (スコア:0)
プロトコル拡張が許されるならDNSSECというプロトコルがすでにありましてね
Re: (スコア:0)
ハイパーリンクについては、公開鍵をアドレスにする仕組みにしとけば良かったのでは？と思う。
これだと認証局なしでもある程度信用できるし。今時URL手入力なんざまずないでしょ。
鍵が失効したら？知らん。
Re: (スコア:0)
詐欺メールの書いてるリンク先が知らないドメインならクリックしないが、公開鍵ならクリックしてしまう。
Re: (スコア:0)
.onionアドレスに対応する秘密鍵が失効した時ってどうするんでしたっけ
Re: (スコア:0)
いちばんリーズナブルな対策はDNSクエリにTCPを使う方法だとおもいます
これだけでもほとんどの攻撃を無効化できるんじゃないでしょうか
UDPは発信ホストの情報が偽装し放題というところが
大昔からずっと問題になっておるのでございます
Re:プロトコル拡張して (スコア:2, 参考になる)
RFC 1123にはゾーン転送を除いてまずUDPクエリーから投げなければならないと書かれていましたが、RFC 7766で緩和されて、理論上はいきなりTCPクエリーを投げてもいいことになりましたね。
許可してないUDPポートに、 (スコア:0)
新しく（iptablesの-m conntrack --ctstate NEWに相当）アクセスしてきたホストをちょっと（1分くらいでいい？1秒でもいいかも？）だけブロックしたら、事実上防御可能じゃないの？
Re: (スコア:0)
残念ながらUDPなんですよ
「アクセスしてきたホスト」という概念が信頼できないんですUDPなので……
そもそもカミンスキーアタックは第三者が権威サーバのIPを騙ったパケットを送りつける攻撃ですので……
Re: (スコア:0)
件のサイトのポスターのⅢ. Side Chennelを見てたんだけれども、
図だと閉じたポートへのアクセスに対してICMPを返している（そしてそれを利用してICMPカウンターを回す）から、iptablesで言うところのRejectになってるような気がするんだが、これをDropにするのはだめなのかな？
Re:許可してないUDPポートに、 (スコア:1)
53/TCPは絶対にサポートしてくれ。タイムアウトするまで53/TCPが閉じているかどうか判定できなかったらTCPへの移行が実質不可能になる
Re: (スコア:0)
「閉じてる」ポートだけDropするだけだから。
たいてい今どきのリゾルバって53/TCPも開いてるんじゃないのかい（UDPでアクセスして応答がUDPに入りきらない場合、UDPに入らんからTCPでやり直してって返事が来るでしょ。RFC5966か？）
負荷など何らかの事情でTCPで応答できない状態ならきっとICMPも返せないよ。
トラブルやらメンテの時だけファイアウォール設定変えてICMPで到達できんのを知らせればセカンダリに行くでしょ。いやメンテは代替機使うのかな…分からん
Re: (スコア:0)
駄目だったのは35%って事なら、その手の設定で回避出来てたって事なんじゃない？
この攻撃を想定しておらずとも、安全側に上手く倒した設定だったら耐えれたとかそういう
Re: (スコア:0)
ICMPの返信利用して、2^16あるポートのうち権威サーバーへの問い合わせに使われてるポートを検出すれば、DNS自体のIDと合わせて、最大2^16*2回の試行でカミンスキーアタックが成功するよ、っていうアタックなんでしょう。だったらソースアドレスは偽造できないし、全UDPポートのスキャンに2^16分（秒でもいいかも）かかるようにしたら、アタックは事実上成立しないのでは？
Re: (スコア:0)
ボットネットとか使ったら、1分ドロップしても、2^16分はかからないか。でも権威サーバーからの返信が返ってくるまで止めればいいのだから、1分も止めたら十分じゃないかな。
Re: (スコア:0)
最初のUDPアクセスをドロップしたら、ICMPのエラーメッセージが返らないから、その時点でもう攻撃が成立しない。ソースアドレスをブロックする必要なんかないね。これは恥ずかしい。
Public DNSがー、ってのはエニキャストとか使ってて接続追跡がやりにくいのかな？