アカウント名:
パスワード:
新情報が無さ過ぎて、誰もコメントを付けないまま4時間。
せっかくなので。
そろそろISPは動的にIPアドレスを割り当てている配下のネットワークから、自社DNS以外に飛んでいく53番ポートのパケットを落とすか、横取りして代理応答するような仕組みを導入する時期に来ていないだろうか。
Public DNSが使えなくなることなんか、こんなDDoS攻撃を防ぐためなら全く構わない。
DNSサーバ側に入ってくるほうで53番をふさぐことは難しいんだから、出ていくほうで止めてくれないと。SMTPの25番を塞いだやり方と考え方は似てるけど。
ISPのDNSがうんこ過ぎて回避したいのに横取りされたらたまったもんじゃないんですが# jcomとか
ISPの質に関わる部分ですので、ISPに改善要望出すかISPを変更するというのが望ましい対処では。
JCOMの場合、選択の主目的はネットでない可能性が高いからなあ。人に依ってはそれは本末転倒って事になる。
dns water torture攻撃の踏み台にされるのを防ぐために動的IPアドレスの範囲にIP53BをかけてるISPは多いですね。
完全にパケットの中身を見てるから通信の秘密の侵害はOB25Bの比ではないぞ
宛先アドレス見ないとルーティングもできないんですがそれは…
そういうのを正当業務行為という。
でもUDPの場合、送信元は偽装されるからなぁ。どれほど効果があるか。
今時のまともなプロバイダは、TCP/UDP ヘッダの source address を詐称したパケットは中継しないのが普通でしょう。TCPベースでも、最初の1パケットだけで成立する SYN FLOOD は送信元詐称できますしね。
個々の端末単位でパケットフィルタリングしているのではなく、外との出入口で「srcが自プロバイダに割り当てられたアドレス」は外に出さない、という設定ですので、フィルタリングによる負荷はほとんどありません。
そういう設定を推奨するRFC2267 [ietf.org]が出たのは1998年。もう20年近く経つというのに、未だにそう設定してない所がそれなりにあるからこそ、DNS リフレクター攻撃が成立してしまうわけですが…なげかわしいことです。
送信元の詐称は関係ないのです。接続する顧客ネットワークから53PortのUDPが自社以外に向かって飛んで来たら捨てるだけなので。
某プロバイダで数年前に通信障害が発生したが、これは単に彼らの管理下にあったDNSサーバが応答しなくなっただけで、LAN内でDNSサーバ立てると、とりあえずは解決した。そういう経験をしてるので、あまり気の乗らない提案。
ちなみにそのプロバイダは、DDoSに辟易したか、こないだ外部からUDP53に飛んでくるパケットを遮断する挙にでた。(外部向けのコンテンツサーバには通したと思われるが)しかしながら、これにより中で自前のDNSサーバ立ててた客が泣く羽目になった(その後、申し出た者には解除)。
名前解決のために、違うフレームワークが求められているのだろうか。
顧客用のDNSサーバは複数立てるのが普通なので、それでもトラブルが頻発するなら接続業者を変えたほうがいいでしょう。あるいは何年かに一度あるかないか、ほぼないかもしれない障害のために自前DNSを立てたいがために深刻なDDoS攻撃の温床となってしまうことを良しとするか考えましょう。ほんとに必要ならDNSサーバの設置をISPに申請してポートを開けてもらえばいいだけです。
「某」とか言っているからいつまでも改善されないんだよ実名を出せよ
ということは、ISPのDNSがダウンしたときに、8.8.8.8に切り替えることも出来なくなるのか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
ISPによるPort53のフィルタ (スコア:1)
新情報が無さ過ぎて、誰もコメントを付けないまま4時間。
せっかくなので。
そろそろISPは動的にIPアドレスを割り当てている配下のネットワークから、自社DNS以外に飛んでいく53番ポートのパケットを落とすか、横取りして代理応答するような仕組みを導入する時期に来ていないだろうか。
Public DNSが使えなくなることなんか、こんなDDoS攻撃を防ぐためなら全く構わない。
DNSサーバ側に入ってくるほうで53番をふさぐことは難しいんだから、出ていくほうで止めてくれないと。
SMTPの25番を塞いだやり方と考え方は似てるけど。
Re:ISPによるPort53のフィルタ (スコア:1)
ISPのDNSがうんこ過ぎて回避したいのに横取りされたらたまったもんじゃないんですが
# jcomとか
Re: (スコア:0)
ISPの質に関わる部分ですので、ISPに改善要望出すかISPを変更するというのが望ましい対処では。
Re: (スコア:0)
JCOMの場合、選択の主目的はネットでない可能性が高いからなあ。
人に依ってはそれは本末転倒って事になる。
Re:ISPによるPort53のフィルタ (スコア:1)
dns water torture攻撃の踏み台にされるのを防ぐために
動的IPアドレスの範囲にIP53BをかけてるISPは多いですね。
Re: (スコア:0)
完全にパケットの中身を見てるから通信の秘密の侵害はOB25Bの比ではないぞ
Re: (スコア:0)
宛先アドレス見ないとルーティングもできないんですがそれは…
Re: (スコア:0)
そういうのを正当業務行為という。
Re: (スコア: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が自社以外に向かって飛んで来たら捨てるだけなので。
Re: (スコア:0)
某プロバイダで数年前に通信障害が発生したが、これは単に彼らの管理下にあったDNSサーバが応答しなくなっただけで、LAN内でDNSサーバ立てると、とりあえずは解決した。
そういう経験をしてるので、あまり気の乗らない提案。
ちなみにそのプロバイダは、DDoSに辟易したか、こないだ外部からUDP53に飛んでくるパケットを遮断する挙にでた。
(外部向けのコンテンツサーバには通したと思われるが)
しかしながら、これにより中で自前のDNSサーバ立ててた客が泣く羽目になった(その後、申し出た者には解除)。
名前解決のために、違うフレームワークが求められているのだろうか。
Re: (スコア:0)
顧客用のDNSサーバは複数立てるのが普通なので、それでもトラブルが頻発するなら接続業者を変えたほうがいいでしょう。
あるいは何年かに一度あるかないか、ほぼないかもしれない障害のために自前DNSを立てたいがために深刻なDDoS攻撃の温床となってしまうことを良しとするか考えましょう。
ほんとに必要ならDNSサーバの設置をISPに申請してポートを開けてもらえばいいだけです。
Re: (スコア:0)
「某」とか言っているからいつまでも改善されないんだよ
実名を出せよ
Re: (スコア:0)
ということは、ISPのDNSがダウンしたときに、8.8.8.8に切り替えることも出来なくなるのか。