IRCnet-jpが複数ISPを制限 24
ストーリー by Oliver
/JOIN 部門より
/JOIN 部門より
koshian 曰く、 "/.-jに集まってるみなさんの中にはIRCを利用してらっしゃるかたもかなりいらっしゃると思います。特にIRCnet-jp(WIDE系)はユーザーも多いのではないでしょうか。私もIRCnet-jpにいるのですが、今月19日あたりから逆引ができてるはずなのにチャンネルオペレータ権限が行使できない、nickが変えられないなどの症状が、あちらこちらで見掛けるようになりました。
原因はサーバ側で特定ISPユーザーを制限ユーザーに指定してるせいでした。IRCコマンド"/stats I"で見る事ができる情報によれば、J-COM、有線ブロードネットワークス、So-net、ODN、@NIFTY、インターネットメガアクセスサービス、OCN、ぷらら等が対象のようです。他にもIPアドレスでの制限もかなり多いようですが。
最近調子が悪く、よくスプリットを起こしていたIRCnet-JPですが、それと何か関係があるんでしょうか?"
これって (スコア:2, 興味深い)
一部の不届き者のせいで正常なユーザが被害を被る構図が
いろんな分野で増えているような気がするなぁ。。。
----
gen+nob+ash
Re:これって (スコア:1)
リトライ中にチャンネルに来たDTIユーザーの知人にはすんなりオペ権限が配布されていただけに、不思議に思い何度もつなぎ直してた (^-^;
あ、今つないでみたけど、制限解除されてるみたいです。
wide系サーバのI-Line (スコア:2, 参考になる)
ただ,藤沢については,まだ設定は反映されていないようだ
20:15時過ぎは 一部のIRCサーバではI-Lineは元に戻っていたようだ。 ※join,partのかなり多いチャンネルのログを見た感じでは…
内輪チャンネルで ocn や j-com を使っている人が多く,皆困っていたようだった.
すぷりっとおきちゃうと (スコア:1)
（Ｔ□Ｔ）あぅーみんなどこいっちゃったのぉー
な
気分になるのって
私だけ？（爆死）
++mermaid++
Re:すぷりっとおきちゃうと (スコア:1)
# 同性でしたが
Re:すぷりっとおきちゃうと (スコア:1)
# でも、ここ何日（1ヶ月以上？）よく切れますね。
# サーバ間にだれか立ってて、それが邪魔になってるとか。
# 「邪魔です、どいてくださいっ。おっとっと…わーっ」（こける＝server split）
--- にゅ
Re:すぷりっとおきちゃうと (スコア:0)
Re:すぷりっとおきちゃうと (スコア:1)
調子悪い (スコア:1)
毎回状況は異なるけど最近は一日数回ほどサーバから切断されます。
時間的に朝と夕だな
あと、IRCnet-jpでチャンネルのリスト取得しようとすると接続切るの
やめてほしいなぁ。他にコマンド使えなくするとか注意文表示するなど方法はあるとおもうんだけど
Re:調子悪い (スコア:4, 参考になる)
> やめてほしいなぁ。他にコマンド使えなくするとか注意文表示するなど方法はあるとおもうんだけど
IRCnetではチャンネルの数が多すぎて、普通の回線ではMax SendQ Exceededで落ちます。
サーバ側のSendQが埋まらないくらい速くlistコマンドの結果を受け取れればよいようです。
# "超"速い回線では落ちないという話があります。100Mbpsとか。
というわけで、サーバの設定のせいではないはずです。
Simon (Don't call me "Shi'mon". Call me "Sai'mon")
-- real thing goes strange. sometimes.
Re:調子悪い (スコア:3, 参考になる)
ということで、既に100Mbpsごときでもおそらく無理なんじゃないかと。
-- Takehiro TOMINAGA // may the source be with you!
Re:調子悪い (スコア:1)
いやね、100Mbpsな環境あたりからだとlist取れたという話を
聞いたもので、てっきりそうなのかと思ってたのですが。
また聞きは安易に信じてはいけませんな…。
Simon (Don't call me "Shi'mon". Call me "Sai'mon")
-- real thing goes strange. sometimes.
Re:調子悪い (スコア:1)
立っているマシンのネットワーク環境、受け取る側のネットワーク
環境、受け取るクライアントの性能など、複雑な要素が絡み合って
いるようです。
localhostでも取れないという報告がありましたが、同一ネットワーク
上なら取れたという話もありますし、多分相当様々な要素が絡んで
いると思います。
ともあれ、ircdのSendQを埋めないようにさえすればlistは取れま
すが、その時にあるチャンネルの数も変動しますし、毎回確実に取
れるという方法はなさそうですね。
ちなみに、achuya氏のチャンネルリスト(今見られませんね)はlist
の結果ではなく、再帰的なwho等で作っているようです。
Simon (Don't call me "Shi'mon". Call me "Sai'mon")
-- real thing goes strange. sometimes.
Re:調子悪い (スコア:1)
特定のドメインからは Max SendQ が多めに取られています．
そのホストから /list で取得すれば Max SendQ Exceeded で落ちることはなくなります．
Re:調子悪い (スコア:0)
Re:調子悪い (スコア:0)
Iどころか (スコア:1, 参考になる)
制限されてるIP範囲からみて、同じ階か１つ下の誰かが犯人。
困ったもんだ。
影響範囲外のサーバにmadoka [madoka.org]上げて中継するかなあ。
Re:Iどころか (スコア:0)
kyotoのページ見ても数年前のオフ会情報しか載ってないし。
メーリングリスト参加要望は年単位で放置されてるし:p
ポリシーや最近の設定ぐらい公表できんもんですかねぇ。
Re:Iどころか (スコア:1)
一時期Livedoor使っていたのでパスワードを使っていました。
いっそのこと (スコア:0)
Re:いっそのこと (スコア:2, 参考になる)
DoS対策の製品を出しているベンダーがいくつかあるようですが、ああいう製品の効果のほどはどうなんでしょうかねえ。
------------------ セキュリティって何?
Re:いっそのこと (スコア:1)
なんでそんな目にあうかというとサーバを弱らせて
スプリットが発生した隙を狙ってよからぬことを目論む輩が
いっぱいいるからですな。
バックアップネットワーク (スコア:1)
これでネットワークがひとつ落ちても安心。
DoS対策製品(Re:いっそのこと） (スコア:1)
１）変なパケットをサーバに送りつけていないかチェック
２）何らかの頻度で通常のトラフィック量を記録ししきい値を越えると
通信制限をかける
３）２）と同じだがトラフィック量ではなく送信元IPアドレス
（偽造されているされていないは問わず）を記録しておき、
いつもより異なるIPアドレスからのパケットが送られていることから判断
こう言ったことぐらいしかやってないんじゃないかなぁと思います。
となると、判断に揺らぎが出来きるため誤警報が山ほど出て
導入されるエンジニアや現場の方はかな～り大変かなという気がします。
話が脱線しますが、この手の製品は自身がブリッジとして働くので
実際に遮断が出来るというのはメリットかも知れません。
今までのセキュリティ製品（IDSですが）は、モニタしているだけなので
DoSを検知したときには、サーバはご臨終していて意味ないじゃんというジレンマが
あったのでそれに比べると現実的なアプローチだと思いますけど・・