アカウント名:
パスワード:
新情報が無さ過ぎて、誰もコメントを付けないまま4時間。
せっかくなので。
そろそろISPは動的にIPアドレスを割り当てている配下のネットワークから、自社DNS以外に飛んでいく53番ポートのパケットを落とすか、横取りして代理応答するような仕組みを導入する時期に来ていないだろうか。
Public DNSが使えなくなることなんか、こんなDDoS攻撃を防ぐためなら全く構わない。
DNSサーバ側に入ってくるほうで53番をふさぐことは難しいんだから、出ていくほうで止めてくれないと。SMTPの25番を塞いだやり方と考え方は似てるけど。
でもUDPの場合、送信元は偽装されるからなぁ。どれほど効果があるか。
今時のまともなプロバイダは、TCP/UDP ヘッダの source address を詐称したパケットは中継しないのが普通でしょう。TCPベースでも、最初の1パケットだけで成立する SYN FLOOD は送信元詐称できますしね。
個々の端末単位でパケットフィルタリングしているのではなく、外との出入口で「srcが自プロバイダに割り当てられたアドレス」は外に出さない、という設定ですので、フィルタリングによる負荷はほとんどありません。
そういう設定を推奨するRFC2267 [ietf.org]が出たのは1998年。もう20年近く経つというのに、未だにそう設定してない所がそれなりにあるからこそ、DNS リフレクター攻撃が成立してしまうわけですが…なげかわしいことです。
送信元の詐称は関係ないのです。接続する顧客ネットワークから53PortのUDPが自社以外に向かって飛んで来たら捨てるだけなので。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
ISPによるPort53のフィルタ (スコア:1)
新情報が無さ過ぎて、誰もコメントを付けないまま4時間。
せっかくなので。
そろそろISPは動的にIPアドレスを割り当てている配下のネットワークから、自社DNS以外に飛んでいく53番ポートのパケットを落とすか、横取りして代理応答するような仕組みを導入する時期に来ていないだろうか。
Public DNSが使えなくなることなんか、こんなDDoS攻撃を防ぐためなら全く構わない。
DNSサーバ側に入ってくるほうで53番をふさぐことは難しいんだから、出ていくほうで止めてくれないと。
SMTPの25番を塞いだやり方と考え方は似てるけど。
Re:ISPによるPort53のフィルタ (スコア:0)
でもUDPの場合、送信元は偽装されるからなぁ。
どれほど効果があるか。
Re:ISPによるPort53のフィルタ (スコア:2)
今時のまともなプロバイダは、TCP/UDP ヘッダの source address を詐称したパケットは中継しないのが普通でしょう。TCPベースでも、最初の1パケットだけで成立する SYN FLOOD は送信元詐称できますしね。
個々の端末単位でパケットフィルタリングしているのではなく、外との出入口で「srcが自プロバイダに割り当てられたアドレス」は外に出さない、という設定ですので、フィルタリングによる負荷はほとんどありません。
そういう設定を推奨するRFC2267 [ietf.org]が出たのは1998年。もう20年近く経つというのに、未だにそう設定してない所がそれなりにあるからこそ、DNS リフレクター攻撃が成立してしまうわけですが…なげかわしいことです。
Re: (スコア:0)
送信元の詐称は関係ないのです。
接続する顧客ネットワークから53PortのUDPが自社以外に向かって飛んで来たら捨てるだけなので。