アカウント名:
パスワード:
新しく(iptablesの-m conntrack --ctstate NEWに相当)アクセスしてきたホストをちょっと(1分くらいでいい?1秒でもいいかも?)だけブロックしたら、事実上防御可能じゃないの?
残念ながらUDPなんですよ「アクセスしてきたホスト」という概念が信頼できないんですUDPなので……
そもそもカミンスキーアタックは第三者が権威サーバのIPを騙ったパケットを送りつける攻撃ですので……
件のサイトのポスターのⅢ. Side Chennelを見てたんだけれども、図だと閉じたポートへのアクセスに対してICMPを返している(そしてそれを利用してICMPカウンターを回す)から、iptablesで言うところのRejectになってるような気がするんだが、これをDropにするのはだめなのかな?
53/TCPは絶対にサポートしてくれ。タイムアウトするまで53/TCPが閉じているかどうか判定できなかったらTCPへの移行が実質不可能になる
「閉じてる」ポートだけDropするだけだから。たいてい今どきのリゾルバって53/TCPも開いてるんじゃないのかい(UDPでアクセスして応答がUDPに入りきらない場合、UDPに入らんからTCPでやり直してって返事が来るでしょ。RFC5966か?)負荷など何らかの事情でTCPで応答できない状態ならきっとICMPも返せないよ。トラブルやらメンテの時だけファイアウォール設定変えてICMPで到達できんのを知らせればセカンダリに行くでしょ。いやメンテは代替機使うのかな…分からん
駄目だったのは35%って事なら、その手の設定で回避出来てたって事なんじゃない?この攻撃を想定しておらずとも、安全側に上手く倒した設定だったら耐えれたとかそういう
ICMPの返信利用して、2^16あるポートのうち権威サーバーへの問い合わせに使われてるポートを検出すれば、DNS自体のIDと合わせて、最大2^16*2回の試行でカミンスキーアタックが成功するよ、っていうアタックなんでしょう。だったらソースアドレスは偽造できないし、全UDPポートのスキャンに2^16分(秒でもいいかも)かかるようにしたら、アタックは事実上成立しないのでは?
ボットネットとか使ったら、1分ドロップしても、2^16分はかからないか。でも権威サーバーからの返信が返ってくるまで止めればいいのだから、1分も止めたら十分じゃないかな。
最初のUDPアクセスをドロップしたら、ICMPのエラーメッセージが返らないから、その時点でもう攻撃が成立しない。ソースアドレスをブロックする必要なんかないね。これは恥ずかしい。
Public DNSがー、ってのはエニキャストとか使ってて接続追跡がやりにくいのかな?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
許可してない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がー、ってのはエニキャストとか使ってて接続追跡がやりにくいのかな?