アカウント名:
パスワード:
新しく（iptablesの-m conntrack --ctstate NEWに相当）アクセスしてきたホストをちょっと（1分くらいでいい？1秒でもいいかも？）だけブロックしたら、事実上防御可能じゃないの？
残念ながらUDPなんですよ「アクセスしてきたホスト」という概念が信頼できないんですUDPなので……
そもそもカミンスキーアタックは第三者が権威サーバのIPを騙ったパケットを送りつける攻撃ですので……
ICMPの返信利用して、2^16あるポートのうち権威サーバーへの問い合わせに使われてるポートを検出すれば、DNS自体のIDと合わせて、最大2^16*2回の試行でカミンスキーアタックが成功するよ、っていうアタックなんでしょう。だったらソースアドレスは偽造できないし、全UDPポートのスキャンに2^16分（秒でもいいかも）かかるようにしたら、アタックは事実上成立しないのでは？
ボットネットとか使ったら、1分ドロップしても、2^16分はかからないか。でも権威サーバーからの返信が返ってくるまで止めればいいのだから、1分も止めたら十分じゃないかな。
最初のUDPアクセスをドロップしたら、ICMPのエラーメッセージが返らないから、その時点でもう攻撃が成立しない。ソースアドレスをブロックする必要なんかないね。これは恥ずかしい。
Public DNSがー、ってのはエニキャストとか使ってて接続追跡がやりにくいのかな？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
許可してないUDPポートに、 (スコア:0)
新しく（iptablesの-m conntrack --ctstate NEWに相当）アクセスしてきたホストをちょっと（1分くらいでいい？1秒でもいいかも？）だけブロックしたら、事実上防御可能じゃないの？
Re: (スコア:0)
残念ながらUDPなんですよ
「アクセスしてきたホスト」という概念が信頼できないんですUDPなので……
そもそもカミンスキーアタックは第三者が権威サーバのIPを騙ったパケットを送りつける攻撃ですので……
Re: (スコア:0)
ICMPの返信利用して、2^16あるポートのうち権威サーバーへの問い合わせに使われてるポートを検出すれば、DNS自体のIDと合わせて、最大2^16*2回の試行でカミンスキーアタックが成功するよ、っていうアタックなんでしょう。だったらソースアドレスは偽造できないし、全UDPポートのスキャンに2^16分（秒でもいいかも）かかるようにしたら、アタックは事実上成立しないのでは？
Re:許可してないUDPポートに、 (スコア:0)
ボットネットとか使ったら、1分ドロップしても、2^16分はかからないか。でも権威サーバーからの返信が返ってくるまで止めればいいのだから、1分も止めたら十分じゃないかな。
Re: (スコア:0)
最初のUDPアクセスをドロップしたら、ICMPのエラーメッセージが返らないから、その時点でもう攻撃が成立しない。ソースアドレスをブロックする必要なんかないね。これは恥ずかしい。
Public DNSがー、ってのはエニキャストとか使ってて接続追跡がやりにくいのかな？