アカウント名:
パスワード:
トラフィックを絞っていくやり方もあると思うが影響無いレベルに落ちるのは時間がかかるでしょうね、組み込みとかにも使われてるだろうし
cnameでntp.nict.jpとかntp.jst.mfeed.ad.jpに向けるんじゃダメなのかな。この際Googleに丸投げするのも・・・世界で一番安定してるだろうし。
一部のルータなどが、IP決め打ちでアクセスしてくるようにファームウェアを設定して出荷されてるんですよ。で、ユーザ側から設定し直せ無い場合も多々。
http://motosumiyoshi.cocolog-nifty.com/gyoumuyo/2018/01/ntp-864f.html [cocolog-nifty.com]
1990年代後半以降に出荷されたルーター機器で、福岡大学のNTPサーバーを、しかもIPでハードコーディングされた製品が出荷され始めます。例えば、（槍玉に挙げるつもりは更々ありませんが）アラフォー以上のおっさんならみんな知ってる名機、MN128-SOHOシリーズ。その中でも名機中の名機、SL11の時刻修正機能の仕様として、以下の記載があります。「※［NTPサーバアドレス（プライマリ）］を省略したときは、「133.100.9.2」と設定されます。」（NTT-ME「MN128-SOHO SL11 活用ガイド」215ページ 「5-23 本製品の時刻を修正する（時刻修正機能）」より抜粋）つまり、ユーザー側が意図して設定してなくても勝手に福岡大学のNTPに接続してしまうということが起こりえるわけです。まあMN128-SOHOシリーズは15年以上前の機器ですから致し方ないとして、発表によりますと今でもハードコードした製品を出荷しているメーカーがあるようで。しかも、時刻同期だけじゃなくてネットワーク死活監視用として用いている実装もあるらしいです。TP-Link製の無線LAN中継器の一部でこのような実装がされていることが露見しちょっとした話題になりましたが、どうやら氷山の一角だそうなので、民生用の機器については既存も含めて改めて確認しておいたほうがよさそうです。
1990年代後半以降に出荷されたルーター機器で、福岡大学のNTPサーバーを、しかもIPでハードコーディングされた製品が出荷され始めます。
例えば、（槍玉に挙げるつもりは更々ありませんが）アラフォー以上のおっさんならみんな知ってる名機、MN128-SOHOシリーズ。その中でも名機中の名機、SL11の時刻修正機能の仕様として、以下の記載があります。
「※［NTPサーバアドレス（プライマリ）］を省略したときは、「133.100.9.2」と設定されます。」（NTT-ME「MN128-SOHO SL11 活用ガイド」215ページ 「5-23 本製品の時刻を修正する（時刻修正機能）」より抜粋）
つまり、ユーザー側が意図して設定してなくても勝手に福岡大学のNTPに接続してしまうということが起こりえるわけです。
まあMN128-SOHOシリーズは15年以上前の機器ですから致し方ないとして、発表によりますと今でもハードコードした製品を出荷しているメーカーがあるようで。しかも、時刻同期だけじゃなくてネットワーク死活監視用として用いている実装もあるらしいです。
TP-Link製の無線LAN中継器の一部でこのような実装がされていることが露見しちょっとした話題になりましたが、どうやら氷山の一角だそうなので、民生用の機器については既存も含めて改めて確認しておいたほうがよさそうです。
とりあえず前回のスライド [janog.gr.jp]くらい読んでから喋ろうな。どうせ読まないだろうから引用しておくと
よくある質問と答え（3）・Q：上流のISPでフィルタしてもらえば？・A：技術的には可能ですが、ISPで長期に渡りそのフィルタを維持し続けてもらうことが難しいと思っています ・様々な製品のファームウェアにアドレスが埋め込まれていることから、リクエストパケットは長期に渡り送られ続けると予想しています ・例えば数年後にそのフィルタが意図せず削除された場合、福岡大学に向けて多量のリクエストパケットが流入してくる恐れがあります
SINETのみに接続しているわけではありません、別コメントで提示されているスライドの9枚目を見てください。トラフィックはSINET側よりもOCN側からくるもののほうが多いので、SINETでフィルタしても効果は限定的です。
なるほどタチが悪い。何かの理由でNTPサーバーのIPアドレスが変更になったら時計が狂い続けるデバイスってことか。そもそもこのNTPサービスも無保証だろうし、きっぱり切ってもいいと思うけどなぁ。問題のあるデバイス使ってるユーザーが時計狂いに気づけばメーカーに問い合わせるだろうし、メーカーに対応させれば・・・
まぁたとえ完全に終了してポートもブロックしてもトラフィックは来続けるって問題は残り続けるか。ISPにブロック頼む。
時刻合わせなんかには使ってない。WAN側がインターネットに繋がってるか調べてるだけ。反応がない場合は、インターネットに繋がってないと判断して繋がるまで定期的にリトライをかける。要するにWatchDog。
で、以前サービスを止めたら、リトライが増えて逆にネットワーク負荷が上がり支障が出た。
> で、以前サービスを止めたら、リトライが増えて逆にネットワーク負荷が上がり支障が出た。
そして今回も止めてみて同じ結果になることが確認できただけ
今回は「支障が出」てはいない。どれくらいトラヒックが増えるかのデータ取りと、支障が出ないようにパケットを捨てる方法を決めるための実験。
問題の製品が使用されなくなるまで（ファームウェアが対策されるまで）続くよね、
足元を見られているだけの気がするなあ。「日本の大学だから、廃止するときもソフトランディングしてくれるだろう」って。これが中国の組織だったら、あっさりshutdownでハードランディングなのであった。
shutdownどころか、まともにメンテナンスされてないものと見なされて攻撃対象になるんでは。
日本でもこれやってもいいんじゃないかという気が少しだけします(´・ω・｀)
計画停電で止めたらトラヒックが激増してえらいことになったんだってば。
ウォッチドッグのつもりでの実装なんだろうけども、数が増え続けた結果、プロトコル的に「攻撃して良い？」「勘弁してよ」の関係になってしまっている。だから「勘弁してよ」と答えない選択をしたらどうなるかって確認したのだよね。そうしたら本当に攻撃が来てしまったと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
いきなり停止するのではなく (スコア:0)
トラフィックを絞っていくやり方もあると思うが影響無いレベルに落ちるのは時間がかかるでしょうね、組み込みとかにも使われてるだろうし
Re: (スコア:0)
cnameでntp.nict.jpとかntp.jst.mfeed.ad.jpに向けるんじゃダメなのかな。
この際Googleに丸投げするのも・・・世界で一番安定してるだろうし。
Re:いきなり停止するのではなく (スコア:3, 参考になる)
一部のルータなどが、IP決め打ちでアクセスしてくるようにファームウェアを設定して出荷されてるんですよ。
で、ユーザ側から設定し直せ無い場合も多々。
http://motosumiyoshi.cocolog-nifty.com/gyoumuyo/2018/01/ntp-864f.html [cocolog-nifty.com]
Re:いきなり停止するのではなく (スコア:1)
SINET ですよね。
DDoS mitigationサービスはダメでしょうか?
DDoS mitigationサービス申請
https://www.sinet.ad.jp/application_procedures/form-ddos
Re:いきなり停止するのではなく (スコア:2, 参考になる)
とりあえず前回のスライド [janog.gr.jp]くらい読んでから喋ろうな。どうせ読まないだろうから引用しておくと
Re:いきなり停止するのではなく (スコア:1)
SINETのみに接続しているわけではありません、別コメントで提示されているスライドの9枚目を見てください。
トラフィックはSINET側よりもOCN側からくるもののほうが多いので、SINETでフィルタしても効果は限定的です。
Re: (スコア:0)
なるほどタチが悪い。
何かの理由でNTPサーバーのIPアドレスが変更になったら時計が狂い続けるデバイスってことか。
そもそもこのNTPサービスも無保証だろうし、きっぱり切ってもいいと思うけどなぁ。
問題のあるデバイス使ってるユーザーが時計狂いに気づけばメーカーに問い合わせるだろうし、
メーカーに対応させれば・・・
まぁたとえ完全に終了してポートもブロックしてもトラフィックは来続けるって問題は残り続けるか。
ISPにブロック頼む。
Re:いきなり停止するのではなく (スコア:1)
時刻合わせなんかには使ってない。
WAN側がインターネットに繋がってるか調べてるだけ。反応がない場合は、インターネットに繋がってないと判断して繋がるまで定期的にリトライをかける。要するにWatchDog。
で、以前サービスを止めたら、リトライが増えて逆にネットワーク負荷が上がり支障が出た。
Re: (スコア:0)
> で、以前サービスを止めたら、リトライが増えて逆にネットワーク負荷が上がり支障が出た。
そして今回も止めてみて同じ結果になることが確認できただけ
Re: (スコア:0)
今回は「支障が出」てはいない。
どれくらいトラヒックが増えるかのデータ取りと、支障が出ないようにパケットを捨てる方法を決めるための実験。
Re: (スコア:0)
問題の製品が使用されなくなるまで（ファームウェアが対策されるまで）続くよね、
Re: (スコア:0)
足元を見られているだけの気がするなあ。
「日本の大学だから、廃止するときもソフトランディングしてくれるだろう」って。
これが中国の組織だったら、あっさりshutdownでハードランディングなのであった。
Re: (スコア:0)
shutdownどころか、まともにメンテナンスされてないものと見なされて攻撃対象になるんでは。
Re:いきなり停止するのではなく (スコア:1)
日本でもこれやってもいいんじゃないかという気が少しだけします(´・ω・｀)
Re: (スコア:0)
計画停電で止めたらトラヒックが激増してえらいことになったんだってば。
Re: (スコア:0)
ウォッチドッグのつもりでの実装なんだろうけども、数が増え続けた結果、
プロトコル的に「攻撃して良い？」「勘弁してよ」の関係になってしまっている。
だから「勘弁してよ」と答えない選択をしたらどうなるかって確認したのだよね。
そうしたら本当に攻撃が来てしまったと。