サーバダウン(鯖落ち)情報 Part48
■ このスレッドは過去ログ倉庫に格納されています
>>601
えぇ、またex5のcampusとmusic4のgeinoが爆撃されています・・・ http://qb5.2ch.net/test/read.cgi/sec2chd/1095070472/199
202.222.28.160 をdeny するです
これはどこのサーバかしらん?
回り広範囲でdenyするです http://qb5.2ch.net/test/read.cgi/sec2chd/1091634596/816
>deny 202.222.28.0/24
>ですかね
原因p2
http://qb5.2ch.net/test/read.cgi/sec2chd/1091634596/814
C:\>nslookup dp48001040.lolipop.jp
ry)
Non-authoritative answer:
Name: dp48001040.lolipop.jp
Address: 202.222.28.160
C:\>whois 202.222.28.160
ry)
Network Information:
a. [Network Number] 202.222.28.0
b. [Network Name] SAKURA-NET
g. [Organization] SRS SAKURA Internet Inc. もう、ex系への●でのスレ立てを禁止してほしいなぁ 202.222.16.0/20 でいきます。
>>608 終らないから、毎日大変なわけで、、、 >>609
規制人を誘導するスレ4[報告スレではありません]
http://qb5.2ch.net/test/read.cgi/sec2chd/1090329080/474
x 202.222.16.0/20 でいきます。
o deny 202.222.28.0/24
>>609
高負荷になってきたら暫定的にbbs.cgi止めることで負荷軽減にはならないんですか?
人大杉みたいに。 現在 deny中
221.251.37.0/24 (>>420 原因>>367)
219.117.221.0/24 (>>538 原因>>367)
202.181.96.0/20 (>>452 原因>>450)
202.222.16.0/20 (>>609 原因http://qb5.2ch.net/test/read.cgi/sec2chd/1095070472/200) >>613
大変ですな‥基地外に振り回され、板住人には煽られ。 >609
乙です。
これで止まると思います。
そろそろこの問題を話し合うスレが必要かもしれませんね。 >>617
えぇ、そうですね・・・
とくに●でのスレ立てに関して・・・ >>611
昨日今日のを見ていると
さらにやられて拡大しちゃうことはあっても・・・
やられているのは大規模な攻撃です
今年の初めにあったいわゆる韓国F5以上の規模です。
test以下不可視にして、LAが下がるのをまとう。 < ex5 ねぇ
202.222.16.0/20
これはどこから出てきた?
whoisすると
202.222.28.0/24 ( http://whois.nic.ad.jp/cgi-bin/whois_gw?key=202.222.28.0 )
になるんだが・・・ 202.222.16.0/20 は読み違えじゃないでしょか。
202.222.28.160
通行人さん@無名タレント<>sage<>04/10/10 02:55:15 Q1sOvmqy<> <>黒川智花ちゃん♪<>202.222.28.160[ogLuUyWgPRpAG3P0]<>202.222.28.160<>ogLuUyWgPRpAG3P0 p2のUAを弾くってのはどうかな?
●入りで放置してるような人はいちいちUAを変えたりしないと思うし。
予防にはなるんじゃなかろうか。 >>623
今起っていることは、そういうことじゃなくて、
bbs.cgi を極端に大量にコールする → サーバ死亡
という現象で●がどうとかは関係なかったり。
固定 IP のサーバからやられているので
そこを deny することで避けているけど
これが 一般のISPのIPふらふらするやつだったら
広範囲でそのISPをdeny するしか私にできることは無いような・・・ まあp2から2chに書き込めなければ
p2を使って爆撃しようという人も出てこないわけで。 そもそもUAで規制されたら
P2のUAを偽装するわけで意味ないかと思われ
とp2ユーザーの俺が言ってみる いやん、だからさー
bbs.cgi を大量に叩かれてサーバが落ちるわけで、、、
UA だろがなんだろが bbs.cgi が呼ばれてから云々は
意味が無いわけで、 UA変えられるような人はそれなりにセキュリティ対策するんじゃない? >>624
●からの爆撃だからbbs.cgiがリクエストを受け付けてしまい、鯖の負荷が上がってる訳じゃないんですか?
●無しでの爆撃(スレ乱立は起きないだろうけど)でも鯖死亡しちゃうんです?
>>629
bbs.cgiが大量に叩かれるような状況を「未然に防ぐには」UA規制もいいんじゃないかと。 $request .= "User-Agent: Monazilla/1.00 p2/".$p2version."\r\n"; >>631
違うと思われ
●があろうとなかろうとサーバを落とすための攻撃だから落ちる
ただ●がある方が実際に爆撃風景を見せ付けられるので
顕示欲を満足させやすいだけかと、 >>631
実況で落ちる ことはよくある話で・・・
>FOX★氏
.htaccess焼き部隊作りますか? >>635
いやつまり書きこめない手段で爆撃する奴はいないだろうと。 問題は●ではなくて、bbs.cgiをただ単に大量にコールすることによる攻撃と。
韓国F5の時よりも大規模かどうかは別として、あの時は単にリロードだったから、
cgi呼ぶのの方が圧倒的にインパクト強いですね。
bbs.cgiを同じIPアドレスから連続して呼べないようにすればいいのかな。
bbs.cgiの「手前」の段階で。 WebサーバがPerl(だったかな)を大量に呼び出してるわけだし
それは落ちるわな・・・
確かにp2+●で書き込み禁止にすれば抑止にはなるかもしれないが
そもそも、そんな事したら現存ユーザーが怒ります
# p2は●共有ツールではありません
>>636
(・∀・)イイ!! >>634
了解。
それなら、踏み台になりやすいp2のUAを弾いたらどうですか?
.htaccessで弾いてしまえば、bbs.cgiは呼ばれないし。 今のところ「鯖を落としたい」でbbs.cgiを叩いてるケースはないと思うです。
「スレ乱立したい」で叩いてるような。
まあ今後出てくるかもしれませんが。 bbs.cgiの手前でbbs.cgiのコールを検知するとすると、
普通にやるならApacheかな。
あるいは、もっと前の段階か。
bbs.cgiだけ、選択的に検出できるとうれしいと。 >>639
>bbs.cgiを同じIPアドレスから連続して呼べないようにすればいいのかな。
>bbs.cgiの「手前」の段階で。
そですねぇ、そんなマジックあるですか?
>>641
p2が問題なんじゃなくて、、、
攻撃している人が問題なわけで、
>>638
まさしく、そう考えています
>>641
短期的にはそれでいいかも知れんが、すぐに意味無くなるよな
しかもユーザーは巻き添え。あまりいいアイディアとは思えん FreeBSD 5.3Rが出るまでちょっとさぼろうかと思っていたけど、
何か緊急策を考えないといけないのかな。 IDSツールの導入ですかね?
それともApacheか・・・
ああ、IDSって検知するだけだから
そこから自動で.htaccessをいじるプログラムが必要なのかな?
# 使ったのが昔だから忘れてしまった ・ 。・ ・ 。・ ⌒
。・゚。・゚・゚・
∧,,∧ ヽ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄フ)))
(;`・ω・) ヽ ノ チャーハン作るね!!
/ o━━━ヽ ノ
しー-J ヽ________ノ この様な事が起った場合どうするか、
以前から考えていたことは
1) BBS で検知 (同一IPから速度A以上での投稿)
2) その IP をピンポイントで .htaccess へ投入
3) 投入されたものを外すのはまぁなにかのタイミングで、
こんなとこなんで 1) の検知さえ出来ればその先は
既存の機能の若干の改造で ok
というとこまでは整っている出ス
1) の検知が、もっと鋭敏に巻き添えあまりなく
別の方法でできるなら・・・
ってとこです。 なんか不可視を意図的に作ってたっぽいんで
聞いてみたんですが問題なさそうですね。 >>651
1) BBS で検知 (同一IPから速度20sec当たり1以上でのスレ立て)
2) その IP をピンポイントで .htaccess へ投入
3) 投入されたものは永久規制 3) 投入されたものは永久規制
無限に増えていくものを作るのは・・・
だって、わしずかみ君ででっかい htaccess が期待通りに
動かないことは既に実証されているわけで、 >>651
1) が簡単に検知できればいいのかな。
2) はbbs.cgiにやらせるのがいいのかなぁ。でもロック処理が面倒かも。
だったら、2) は F22 にでもやらせるか。
検知は、bbs.cgi がコールされてもいいなら、
bbs.cgi をコールした最初で無条件に、IPアドレスをキーにしてDNS呼べばいいんじゃないかと。
で、頻繁に呼ばれたことをDNSサーバ側で検知して、BBXと同じように登録してしまうと。 >>654
条件はきつめに・・・
1.には(同一IPから速度20sec当たり1以上でのスレ立て) と書いた
●+スクリプト以外不可能じゃないかなー? >>655
>検知は、bbs.cgi がコールされてもいいなら、
最初はそれで十分だと踏んでいるんですがねぇ
相手の進化スピードとの競争かも。
んで、
その為に BBS を作ったんで、既にできとります。
ただ問題は物凄い勢いで物凄い投稿をさばいているんで
検知するプログラムを組む自信が無い。。。
つまり限られた時間、限られた資源でどれだけの精度のものが組めるのか
ただ問題なのは >>654
でかい .htaccess はいやですね。
でももし .htaccess で立ち行かなくなったら、
韓国F5の時にも使ったipf(FreeBSDの機能)を使えばもっといけるし。 BBS の統計はこの界隈をみればわかりますが
http://stats.2ch.net/kawasemi-d/2ch.txt
現状最大で 180万投稿/日あります。
組むとしたら最低でも 500万投稿/日、できれば 10倍のキャパ
2,000万投稿/日で設計すべきで
かつこれから導入できる平均投稿数じゃなくピーク時の投稿スピードの
数倍 〜 10倍を目処に設計しなきゃならなく・・・
うぎゃっ って感じです >>657
検知は、ちょっと手法が必要ですね。
少なくともDBは使わないとだめでしょう。Rock54の時と同じような。
某※さんの出番な気が。
また、仕様を考えてやってみることにしますか。
で、それをDNS側と今のBBSプログラムの間に挟みこむと。
つまり、
BBSのDNS => 今のBBSのプログラム(FOXさん作)
↓
BBSのDNS => 検知プログラム => 今のBBSのプログラム
という形にすると。 すみません、p2の規制はp2+レンタルサーバの組み合わせのみにして下さい。
とp2擁護発言をしてみる。 >>659
そんなところですね。普通にテキストなテーブルでやったんじゃ、もたないし。
同じIPアドレスから何かがN回来たら登録、という仕組みは
既にRock54システムで作っているので、これを改良すればいいはずで、
それはBerkeley DBでデータ持っているので、それなりに高コールにも耐えるはず。
現行のBBSシステム(banana238)でできるかどうかは、やってみないとわからない部分がありますけど。 >>660
ふむふむ
そんな感じかと、
1) で検知した段階で qb6 のある cgi を叩いてもらえれば with 'denyするIP'
そのあとは一気に各サーバに最新の .htaccess を配るだけで、 >>664
…と思ってみてみると、あれ、pingかからないですね。
ちょっと901の様子見てきます。 901 様子がおかしいですね。
pingかからないし、リモートコンソールも応答がない模様。
今はなにもさせていないので、ハードウェアトラブル再発?
リブート依頼出します。 ロリポなら固定だし202.222.28.160だけで十分なんじゃないの?
たのむ、そうしてくれ〜〜〜 orz あとは、ApacheのモジュールでCGIがコールされる前に検知できるのかも。
例えば、あるIPアドレスからM秒の間にN回同じCGIがコールされたら、
そのIPアドレスからはあらかじめ定められたP秒間、そのCGIはコールできなくする、
みたいなことをできるモジュールって、何かあるのかしら。 あ、今気がつきましたが、
現行のBBSって、IPアドレスはキーにしていないような。
つまり「どのIPアドレスからコールされたか」は、今はBBS側では検知できないですね。
というか、変えれば(IPアドレスもキーに追加すれば)いいのか。
これはそんなに難しくはなさそうですね。
さて、今日はいったん寝ます。そろそろこの話題は別に新スレかしら。 Servertype inetd
にしちゃうのは無謀なのかしら?
起動コストはかかるけれども、tcpserver から httpd を起動すれば、deny したいIPアドレスからのアクセスは httpd の起動前に落とせるから、、、
ちなみに自宅鯖では、、、
exec \
/usr/local/bin/tcpserver -vRH -x deny_list.cdb 0 http /usr/sbin/httpd -F 2>&1
みたいに動かしています。(-c で最大接続数の設定も出来ますし、-t でtimeoutも設定できます。)
deny_list.cdb は BBQ と同じ手法で構築できるかと思います。
参考URI
http://www.emaillab.org/djb/tcpserver/options.html >>669
仕様としてPIDの部分を変更すればいいかと。
ここはBBSコールを一意にするための乱数であって実際の統計処理には使われていませんしね。
つまり、
発言時unixtime.発信元IPアドレス.発言バイト数.スレッドkey.板フォルダ名.サーバ.CGI名.BBS.2ch.net
例として
1083670976.255.255.255.255.129.1083670787.liveanb.live8.2ch.net.bbs.bbs.2ch.net
連投規制の関係で発言時unixtimeと発信元IPアドレスが同一というのは
同一スレへの爆撃でない限りありえないはず。 >>609
規制範囲広すぎるのでは・・・。
うちのp2(非ロリポ、さくら専鯖)も巻き込まれて困ってます。
せめて202.222.28.0/24にできないでしょうか。 deny from 219.17.0.0/16
よろ〜
from
【BBQ 1本目】公開串登録所 【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1091634596/848
>848 名前: [―{}@{}@{}-] YahooBB219017082026.bbtec.net●[] 投稿日:04/10/10 15:11:17 ID:raPz2x94
> これも●付きかな?
> http://219.17.82.26/~takuya/orgold/p2/ >>609
うちもsakura専鯖利用ですが、、巻き込まれて困っています。
範囲の見直し、ご検討いただけないでしょうか・・・。
宜しくお願いいたします。
>>672
>規制範囲広すぎるのでは・・・。
>うちのp2(非ロリポ、さくら専鯖)も巻き込まれて困ってます。
>せめて202.222.28.0/24にできないでしょうか。
>>609
うちも>>672とまったく同じ構成(p2、非ロリポ、さくら専鯖)で巻き込まれておりやす。
もっちょい範囲狭めていただけないでしょーか。
>>580
システムディスクがいかれた模様。
珍しくSeanさんが書き込んでいました。 >>675 >>677
絞込みを要望する場合は通常のアクセス規制と同様に、規制範囲を絞り込んでも
確実に問題がないという確実なソースを規制人に提示することが不可欠です。
困っているなら自身で範囲を絞り込める立証と、明確な絞込み範囲を提示しましょう。
「困っている人がやる」これは2ちゃんねるの鉄の掟のひとつですよ。
>680
誰か別の●をセットしてスクリプトブン回されてる悪寒
ttp://219.17.82.26/~takuya/orgold/p2/read_res_hist.php#footer 携帯及び●による荒らし報告専用スレッド4
http://qb5.2ch.net/test/read.cgi/sec2chd/1095070472/240
deny from 219.17.
YahooBB219017*.bbtec.net >>679
その前に、なぜ/20という範囲で焼かれたのかが分からないと
反証のしようがありません。
規制対象の鯖は202.222.28.160で、割り当ては202.222.28.0/24です。
しかし、実際に規制されたのは202.222.16.0/20です。
例えば、202.222.28.0の一つ前の割り当てブロックだと
inetnum: 202.222.27.0 - 202.222.27.31
netname: NETASSIST18
descr: Netassist Inc
inetnum: 202.222.27.64 - 202.222.27.95
netname: PASSNET
descr: Collabolatory Co,. Ltd.
など、CIDRで無関係の会社に割り当てられているものもあります。
運営側としては広範囲で焼いた方が楽なのは分かりますが、
もう少し様子を見ながら徐々に広げて行ってもらえると助かるのですが・・・。 >>683
まずはサーバを守るために広範囲。
それから何とかして欲しい人が範囲を絞るために情報を提供。
んで、それが通るかどうかはサーバの中の人の判断。
順序としては普通だと思いますけど。 ネットブロック割り当てを超えた広範な規制はただの怠慢だろ
/20とか馬鹿じゃねーの まぁまぁ、、、
始まりは何時もこういう感じですよ。
後はどのように絞り込むか対策するか
知恵を出し合っていくのですよ。 >>683
>その前に、なぜ/20という範囲で焼かれたのかが分からないと
>反証のしようがありません。
理由は必要ないでしょう?安全策を取って広範囲で規制することも
それは鯖を運用するうえで当然のことだと思いませんか?
何よりどういう規制をしようがそれは場所を提供している2ちゃんねるの
自由ですし。
あなたが今すべきことは規制範囲の理由を求めることではなくて、
「この範囲で絞込みをすれば絶対に大丈夫です」という明確なソースの提示を行い、
それを規制人が見て妥当かどうか判断するだけのことですよ。
O 「「「l
o \. V7
○`) | | r‐、 ピッチャー デニー!
(⌒) o | | >、,>
____`o ○ | |. | |
// |O。゚-ト、. | | |
.//| /(・) ∩ |o. | | | /\ | |
|//| | | | | / | | ̄`l /\
|//| (・) \_| |─/ /く | / r、/`ーっ
|// \ | / / | \/\/ `ー'"
|/ ヽ__ // / | /
mn____|___r──l__/ | /
ヽ_______|__ノ────' ──''" >689
> 理由は必要ないでしょう?安全策を取って広範囲で規制することも
> それは鯖を運用するうえで当然のことだと思いませんか?
/20だと広範囲すぎて善意の利用者までひどい目に遭うことが容易に
想像できると思うんですが。あんたのいう「安全策」ってタダの
怠慢としか思えない。
単一のIPをはじいて、周辺のIPから攻撃が来るようになったら/24なり/20
なりではじいても良いだろうけれど、攻撃してきたところが単独の
IPなのに多くをはじくのは馬鹿だろう。
> 「この範囲で絞込みをすれば絶対に大丈夫です」という明確なソースの提示を行い、
攻撃が行われたIPがその/20内からは1つであるという現状のデータからして
ソースを提示するまでもなく/20は大きすぎると言うことがわかろう。
ぷげら いずれにせよ、
>609
で書かれている規制はでかすぎ。
だって、原因の
http://qb5.2ch.net/test/read.cgi/sec2chd/1095070472/200
の書き込みをしている202.222.28.160はlolipopのサーバーで、
原因となる公開p2が202.222.16.0/20の他のブロックへ行くとは
思えないから。
# 昔、ORDBとかで日本の複数のISPのブロックがまとめてopen relay扱い
# されてたことを思い出した。InterNIC的に1つのブロックなので、
# 日本に1人でもspammerがいるとISP全体がブロックされる凶悪な事例…
そろそろ規制議論板に専用スレ立てた方が良いのかしら? >>694
ここでいいでしょ。
議論するほどのことでもなし。 >>533にもあるけど、
<Files test/bbs.cgi>
deny ナンタラカンタラ
</Files>
にしてください。 ■ このスレッドは過去ログ倉庫に格納されています