Yahoo!BBのDHCP誤認問題 33
ストーリー by Oliver
レイヤ2スイッチに絶句 部門より
レイヤ2スイッチに絶句 部門より
nyaonyao曰く、"何かとセキュリティ面で問題が多いといわれる「Yahoo！BB」ですが、日経ITProの記者の方も被害に合ったようです。記事はこちら。
「AirMacにハブをつなぎ、そのハブにPCとインターネット回線をつなぐとAirMacが同一局内のYahoo!BB網越しにDHCPアドレスを割り当てる」らしいんですが、うちはAirMacじゃないけど、同じようなことをしてます（Yahoo!BBではない）。これって、普通じゃないの？
ちなみにここの記事は、記事そのものよりも読者コメントの方が面白いことが多いので、是非どうぞ。"
何を今更... (スコア:5, すばらしい洞察)
L2SW相当で接続されているネットワークであれば、YBB!でなくてもCATVでも同じような問題は起こるし、AirMACじゃなくてもDHCPサーバを外に繋げば他のいわゆるブロードバンドルータでも無線LANのAPでもLinuxでもWindowsでも同じ事。
CATVなんかで既に知られている問題なのに、YBB!だけで起こる特異な現象のような書き方をするのは、単に記者の無知をさらけ出してるだけでしょ。
もちろん、YBB!の宣伝に乗せられていんた～ねっとを始めようとする人への啓蒙という意味で、こういう事象を取り上げるのは有益だけど、記者が今頃初めて知って驚いてどうするよ？って感じですね。
Re:何を今更... (スコア:0)
そのときは、何度かケーブルモデムのファームウェアが自動でアップデートされるたびに
記事の解説っぽい長文 (スコア:2, すばらしい洞察)
さらに、私の無知をさらけ出すことになるでしょう ;)
それでも良いなら、長文お付き合いお願いします。。。
＞ 記事はこちら。
斜め読みしかしてませんが、この記事の記者と同じようにず～っと昔、
月刊ASCIIの記者がAirMacで同じ穴に落ちてましたね・・・
繋げた後、回りのマシンがネットに繋げなくなっていくという(笑)
＞ 「AirMacにハブをつなぎ、そのハブにPCとインターネット回線をつなぐと
＞ AirMacが同一局内のYahoo!BB網越しにDHCPアドレスを割り当てる」らしいんですが、
＞うちはAirMacじゃないけど、同じようなことをしてます（Yahoo!BBではない）。
＞ これって、普通じゃないの？
どんな環境だか知りたいかも・・・
外部へのDHCPdが停止してるor叩き落されていれば問題ないですけど・・・
AirMacっておそらく、閉じた家庭内LANを想定していたのではないでしょうか？
だから、DHCPdも搭載されていたのでしょう。
たとえばこんな感じ
+～～無線～～PC1
+～～無線～～PC2
AirMac
+～～有線～～PC3
+～～有線～～PC4
これだったら、迷惑誰にもかけないし便利ですよね・・・
でも、この環境の有線側にY!BBモデムを接続すると途端に問題が起きます。
たとえばこんな感じ
+～～無線～～PC1
+～～無線～～PC2
AirMac (有線側に対してDHCPd有効のままでIPアドレスを共有する設定)
+～～有線～～PC3
+～～有線～～PC4
Y!BBモデムA
｜
局内-+-Y!BBのDHCPd
｜ +-Y!BBのゲートウェイ-(途中省略)-The Internet
｜
Y!BBモデムB
+～～有線～～PC5
さて、この場合、PC5がIPアドレスを収得するときどうなるかは
非常に気まぐれな事になります。
もし、Y!BBのDHCPdの応答が速ければ問題ありません、
しかし、AirMacの応答が速ければPC5はAirMacからIPアドレスを収得します。
そして、デフォルトゲートウェイもAirMacに設定されます、
このとき、PC5は以下のような経路を通る事になります。
PC5＜＞Y!BBモデムB＜＞局内＜＞Y!BBモデムA＜＞AirMac＜＞Y!BBモデムA＜＞局内＜＞Y!BBのゲートウェイ＜(省略)＞ネット
こうなったら、もう速度は期待出来ません。
# だって、どんなにがんばってもY!BBモデムAの上りまでしか出ませんから
# PC3、4も影響を受けますが、まぁあんまり問題にならないかも
# グローバルIPが貰えるようになるか
# AirMac経由のプライベートIPになるかぐらいしかないので・・・
さらに、悪意の有るユーザーがDHCPdを動かして
そのDHCPサーバーの設定で、デフォルトゲートウェイが
悪意のあるユーザーのマシンのIPアドレスだったらどうなるでせうか？
そのDHCPサーバーからIPアドレスを収得したマシンの通信は
その悪意の有るマシンを経由するのですべて筒抜けになるんですけど・・・
さらに、Y!BB管理外で、同期もしてないDHCPサーバーが複数有ったら、
IPアドレスの衝突が起きませんか？
昔話ですが、某CATVのネット接続でWindows NT Serverユーザーが
DHCPサーバーをONにしたままケーブルモデムに繋いで
周りのPCがインターネットに接続できなくなり、
ネットワークを混乱に陥れた罪でNTは接続禁止になりました。
また、「ファイルを共有してしまう」なんて事も有りました。
Y!BBとCATVは似たシステムかと思います。
そして、昔CATVが引き起こした「周りとファイルを共有」とか
「DHCPサーバーを動かされてネットワーク混乱」とか
同じ失敗の道を歩んでる気がします。
前例があったのに未対策なのはちょっと・・・＞Y!BB
DHCP誤認問題の根本の原因はブロードキャストを許可してることなので
ブロードキャストを叩き落す設定にすればOKだと思うんですけど・・・
# ただし、DHCPを使うならブロードキャストが必要なわけで
# その場合は、Y!BBモデムがDHCPリレーエージェントになればOKかと。
## ただし、どこかにまだDHCPd+ブロードキャスト許可のモデムがあれば
## 盗聴されるかもしれませぬ。
### あ、でも局側で、DHCPサーバー以外へのブロードキャストを
### すべて捨てれば良いのかなぁ？
って、かなり記事とダブった内容なのはご愛嬌ということで(ぉ
念のためにもう一度書きますが、全て無保証です。
私が無知の為、間違っている可能性もあります。
Re:記事の解説っぽい長文 (スコア:2, 参考になる)
まぁ、その通りでしょう。なぜなら、古いAirMacは、ethernet
のポートが一つしかないから。ふつーにADSLモデムと接続すると、
自然とDHCPDがY!BB側に向いちゃう。
最近出た(Ver2?)AirMacはちゃんと2ポートあって、WAN,LANって
書いて有るみたい。
# この件、前のY!BBセキュリティネタの時、postしたんだけど
# 誰も反応しなかったので、みんな知ってるんだと思ってた。
# http://srad.jp/comments.pl?sid=10464&cid=58047
backboneでもip layerを切らないものが (スコア:1)
末端向けではありませんが、どうもip layerを切らないという傾向はIXなどのbackboneにも広がっている [zdnet.co.jp]ようです。IXぐらいまで来るとpacket衝突率が問題になったり、IX内でのpolicy-based routingが難しいなどの問題も出てきそうですが...
IT Proの記事は (スコア:0)
読者コメントがないと得るものが何もなかったりする。
Re:IT Proの記事は (スコア:0)
ユーザがDHCPを垂れ流していても・・・ (スコア:0)
それを防ぐのが筋というものでしょう。
DHCPを流さないように、不正(?)なユーザに警告するという事とは別に
流れてきた場合に、落とす 事が必須だと思うのですが...
ip layerを切らないのは実用上大問題 (スコア:5, 参考になる)
dhcp(rfc2131)はbootp(rfc951)と協調できる(eg relay agent)ようにするため、bootpと同じくip layerにおけるprotocolとして定義されています。このため、dhcpをfilterしようとするとどうしてもip layerでの処理が必要になってしまいます。datalink layerだけではどうにもなりません。
ただし、私はsecurityだけでなく、networkのavailabilityにも疑問を持っています。datalink layerの中で、閉路が作れてかつEthernetと似ているもの(そうでないとlayer 2 switchという話は出ない)というと、fddiぐらいしか思いつきません。しかしfddiの機器はそれなりに値が張ります。このため、Yahoo! BBが採用している可能性は低くなります。
Ethernetだけでnetworkを組もうとすると、どうしても木(閉路のないgraph)を作らざるを得ません。ということは、どこか1個所で障害が起きればその下流が孤立してしまいます。普通はこの事態を防ぐために、ip layerでbackupを確保できるようなnetwork [wide.ad.jp] 設計 [wide.ad.jp]をします。Yahoo! BBがそれを敢えてしなかったというのは一体...
もう1つ、scalabilityの問題もあります。少なくともEthernetでは、経路の集約が全くできません(そもそもdatalink layerでやっているという話を私は全く聞いたことがない)。ということは、あちこちのdatalink layer switchにO(node数)のdatalink layer用経路情報が溜るわけです。各switchのdatalink layer経路情報に一貫性を持たせる方法はEthernetには用意されていません。したがって、packetがどこかで行き先を見失ってしまう恐れがあります。よしんば経路情報に一貫性を持たせたとしても(全nodeがbackbone areaに属しているospf areaを考えて下さい)、経路情報の変化をnetwork全体に伝搬させるのは困難です(ospfの場合、Ciscoなどの専用routerでも100台程度が限界 [wide.ad.jp])。
Re:ip layerを切らないのは実用上大問題 (スコア:1)
PS.
この手の意見を書くと、 ないよりはまし とか 安けりゃいいじゃん という意見が書かれるんですが、それはまた別の議論なんですけどぇ...
すずきひろのぶ
Re:ip layerを切らないのは実用上大問題 (スコア:3, 参考になる)
社風もあるかも知れませんが、やろうとすればcostを削りつつospf + bgpというかなりしっかりした構成もできるんですよ。PCをrouterにして(それこそYahoo! BBやSoftbank社内のお下がりでよい)、zebra [zebra.org]やmrt [merit.edu]を走らせる手です。Load balanceだけはOSに依存しますが、それ以外の機能はrouterとしては十分です。実際、私は仕事場と自宅でzebraのcvs版を用いています。休日に仕事場のgatewayが死んだ時にも40秒で確実に経路が更新されて助かりました(経路障害は間違いなく現地直行になるのでこのcostは大きい)。
なおかつ、前のcommentでもciteしましたが、ospf + bgpについては実践に役立つ資料が誰でも読めるところに置いてある [wide.ad.jp]わけです(私も参考にしました)。講演を聞きに行くとなるとかなりお金がかかります(N+Iということは数万円でしたっけ?)。その資料が公開されているわけですから、使わないのはもったいないです。
...ただ、それとは別に、上述の社風が出てくるのはもう1つ原因がありそうです。もともとPCの自作派から広がり、現在かなり広範囲に浸透している(少なくとも私はそう見ている)、「hardwareがなんとかしてくれるから、softwareは自分では扱う必要がない」という思い込みです(PC自作志向の最大の罪と私は考えてます)。こう思い込んでしまうと、「routingって、高いrouterを買わなきゃできないんじゃないの?」という考えしか出てきません。当然、出てくるものもhardwareの限界や短所をそのまんま引きずった形になってしまいます。本来softwareでそこを補うのが正しい方法なんですが...(例えばルート [root-hq.com]はそういう考えができてます。MIS [miserv.net]の無線networkで電柱に載せた基地局の中ではNetBSDが動いているそうで、OSなどのsoftwareでさまざまな工夫をしているそうです。)
Re:ip layerを切らないのは実用上大問題 (スコア:2)
wideのインターネット講義はとてもするには良い教材だけど、それを見たからといって実践的なエンジニアになれるわけではないし、ましてや大規模なネットワークを構築するためのグランドデザインができる 人材がインスタントにできるわけじゃない です。金があってもなくても妊婦が出産するには１０ヶ月かかりますっていうのと同じです。
システムやネットワークを作るときは定石がありーの、エンジニアリングがありーのとか思っていて、そうそう「マジック」はないと僕は思っているのですが、 孫マジック とくと拝見させていただきたいものだなぁ、と思っています。
すずきひろのぶ
Re:ip layerを切らないのは実用上大問題 (スコア:2)
もちろん、例えばIXへの接続点にPCをなんてのは私も恐いですし、IX側もいい顔をしないでしょう。ですが、末端近くになってrouterの数が問題になる(例えば市町村内の局)場合だと、必ずしもfull routeを流す必要はありません。大抵はbackboneへのdefault routeで済ませるでしょう。そうなると専用routerほどの処理能力が本当に必要なのかという疑問にならないでしょうか。
ちなみに前述のルートが作った基地局は、寸法ではPHSの基地局よりもさらに小さかったと記憶しています。小型時刻表ぐらいの大きさだったかなぁ? この大きさで、Ethernetの口と802.11bが喋れるpccardが載っているそうです。こういうものを使えば、大きさの問題は気にならなくなるのでは?
人材はあくまで積み上げで作るというのは確かに事実です。心配なのは、(少なくとも過去には)買収で伸し上がってきたSoftbankがその事実に気が付くかです。私は悲観的な見方をしています。買収というのは出来合いのものを買うわけで、決して欲しいものを1から作ることにはなりません。その点では、むしろSoftbankのスピード経営から生じるべくして生じたのが、今回の問題ではないでしょうか。孫マジックが起きたとしても、悪い方向にしか働かない可能性の方が大きいです。
Re:ip layerを切らないのは実用上大問題 (スコア:1)
すずきひろのぶ
Re:ip layerを切らないのは実用上大問題 (スコア:1)
Terminologyでしくじってしまったのは私のヘマですが、専用routerといってもCiscoなどとは違って、中のsoftwareをいじろうとすればcustomizeできますよね? 必要ならPPPoEを載せるなどできますし。
私の場合、「専用router」というと、とにかく経路制御だけに専念するものという印象があるので。
Re:ip layerを切らないのは実用上大問題 (スコア:0)
てゆーか、 (スコア:1)
Yahoo!BBのやりくちをモニタしてると、製造業で言えば「動けば御の字」みたいな、初期の試作レベルのブツをとにもかくにも商品として世に出して、んで、ユーザーに文句言われたらその都度直してる、という風に見えるんですよ。
メンテナンスがどうのという以前に、こう、何から何まですべて泥縄で、組織としてシステマティックに動いているように見えないのは、偏見かなぁ。
ユーザー数が多くなればなるほど、一度構築したシステムは変更しづらいってことぐらいは理解してて欲しいんだけど…
Re:てゆーか、 (スコア:1, 参考になる)
いやほら、 (スコア:1)
どこだって多かれ少なかれあるとは思うんですが、Yahoo!BBの問題は、技術上の問題点をを抱えているにもかかわらず、低価格だけを前面に押し出して、あっという間に全国展開してしまったことこそが重要ではないか、という気がしています。
私が聞く限り、Yahoo!以外の8M ADSLのサービスは、どこもろくでもないことになっているようですが、これらは結局のところYahoo!が火をつけた、つまりサービスインの時期が早まったのは各社ともYahoo!に対抗するため、と考えるのが妥当ではないかと思います。
これは悪貨が良貨(無論それまでだって「最高！」という訳ではなかったと思うが)を駆逐したという一例であり、それこそがYahoo!BBの罪ではないかと思うんですが。
Re:ip layerを切らないのは実用上大問題 (スコア:1)
> (eg relay agent)ようにするため、bootpと同じくip
> layerにおけるprotocolとして定義されています。
> このため、dhcpをfilterしようとするとどうしても ip
> layerでの処理が必要になってしまいます。datalink
> layerだけではどうにもなりません。
んなこたぁナイ。
最近のスイッチなら載ってる機能の Private VLAN を使えば、
すくなくとも隣近所にブロードキャストやマルチキャストをとば
さないことは可能だ。
Cisco 製品に限ってしまうかもしれんが。
そういえば Cisco の SSG とか、Unisphere の SSC とか
使ったサービスって日本でやってるところないのかなー。これやれ
ば、今回みたいな問題は起きてこなさげなんだけど。
--- show mpls ldp neighbor
Re:ip layerを切らないのは実用上大問題 (スコア:0)
usen (スコア:1)
ユーザーからはルータを介して/29のサブネットにいるように見えます。
Re:ユーザがDHCPを垂れ流していても・・・ (スコア:1)
読者コメントより (スコア:0)
＞ています。指示も、数時間以内に対処するなど、とても普通の状況では
＞ありません。残業も月１００時間以上が一般的で、多くのスタッフ（外注）
＞が近くのホテルで宿泊しています。 JAVA関係のProgramerでも、経験が
＞数年程度あれば、残業込みで120万円/月位になるそうです。 YahooBB
＞は、早期に保守体制を根本的に整備しないと、新たな問題に直面すると
＞思います。
いいなー。
残業代でるんだぁ。
Re:読者コメントより (スコア:0)
残業代出せばいいってもんじゃないし。
Re:読者コメントより (スコア:2, 参考になる)
時間外労働の限度に関する基準 [mhlw.go.jp]のページに特別条項付き協定に関する情報が載っています。
＃私の勤めている会社は、年に千数百時間残業できる協定になっていました。(詳細な数字は忘れてしまいましたが)
Re:読者コメントより (スコア:0)
三六協定なんて結んでいるはずがないと思われ。
Re:読者コメントより (スコア:0)
Re: -1 仕事探しは別で(読者コメントより)(オフトピ (スコア:0)
---
男なら辻希美 ただいま無職。。。
Re:読者コメントより (スコア:0)
Re:読者コメントより (スコア:0)
頭の固いオッサンも少なそうで。
Yahoo BB の設定に注意(重大なセキュリティリスク) @ (スコア:0)
Re:Yahoo BB の設定に注意(重大なセキュリティリスク) (スコア:1)
このなかで気になったというと、broadcast(multicastも含む)問題 [2ch.net]かなぁ。igpを使うとripにしろospfにせよ、multicastないしはbroadcastを使わざるを得ない。ということはそれを悪用して、network全体を飽和させることが可能(あるいはdhcpでやってしまってもよい、少なくともDHCPDISCOVERはfilterできない)。
どうも少しはfilteringしているようだけど、igpを使わないと全部static routeを使うはめになる。routerが落ちても自動回復ができず、人間の出番となる。
まさかとは思うけど、トラブル対応人員の人件費の方が、ip layerの分割よりも安く上がってるのかな? もうそれぐらいしか思いつかん。