bbs.cgi再開発プロジェクト5
レス数が950を超えています。1000を超えると書き込みができなくなります。
peko鯖の稼動によりボトルネックの一つである事がより明らかになった
bbs.cgi作り直しプロジェクトです。
【開発環境の工事現場】
また挑戦。@2ch掲示板 http://dso.2ch.net/myanmar/
また挑戦2。@2ch掲示板 http://dso.2ch.net/yangon/
関連スレなどは >>2-5 くらい そうか,それは残念
unix板のwizard連中に見せればなにか妙案も思いつくとおもったんだけどね。
>>852
実名明かしたメールをひろゆきに送れば1年後に検討してもらえるかもしれない live16のbbs.cgiがしょっちゅう反映されなくなる
そのたまカキコ数に波が出る >>853
1年以上経過したけれども何の音沙汰もありません♪ ほんとは外部設計書みたいなのあればいいんだよね。
セキュリティ上明らかにできない機能はブラックボックスでいいから。
やっつけ仕事なので人に見せられるレベルでないとかなんとかw いろいろと荒らしがでるとかいってたんだけど。
「ソース隠すことはセキュリティ対策にはならない」と論破されてからは特に有効な反論も出なくて
のらりくらりと話をスルーしている。
見せる義理。たしかにないですね。
ではbbs.cgi再開発がんばってください。 見てやる義理のある方々に任せておけばいいでしょう。 IDの後ろに投稿回数の表示とか出来ないかなぁ…ID:xxxxxxxx0 (このIDによる投稿は12レス目)
みたいな…
そうすれば専用ブラウザに一定回数以上のIDを荒らしと見なして自動あぼーんする機能とか
出来そうでいいなぁとか思ってみたり。 そんなに連投多いですか?
個人的には、ちょっとうるさいな、と感じたら
手動であぼーんするだけで十分足りるような気がするけど ふとSETTING.TXT見たら
BBS_BG_SOUND=
なにこれ変態じゃないの? 「ソース隠すことはセキュリティ対策にはならない」
これって神話でしょ。 をを!とうとう公開しちゃうのかな?o(^-^)o ワクワク
お掃除ならやってみたいかもかも。 そのとおり。
正しいのは
「ソース隠せばセキュリティ対策は万全」 >>872
ひろゆきの言いたい事は、ソースを隠すことには
セキュリティの観点から見てそれなりの利点がある、ということでしょ そんなことよりおまいら、mozillaのソースコードが流出したらしいですよ。
ttp://www.hyuki.com/tf/?20040401145329 HTTPサーバの動きとかCGIの起動原理とかまでひっくるめてまで隠せるんならな。 1「ソース隠すことはセキュリティ対策になることもある」
2「ソースオープンにすることはセキュリティ対策になることもある」
んで、まだ動いてないシステムであれば、2の可能性はありますが、
既に動いてるシステムであると1の可能性が高いのですな。
オープンしたとたんにソースを見なければわからない脆弱性で
いきなり攻撃される可能性もあるわけです。
これは、つまり公開しないってことですよね。
それはそうと、書き込み時間の取得のタイミングを変更する
ことは無いですかね?あまり実益が無いですけど、書き込み時刻と
スレ番号がずれることがなくなると思うのですが。 みんなbbs.cgiのソース見たいだけだよ。何に使うのかは知らんが。 実益のないことにリソースを使ってもしょうがないような、、、 漏れが言いたいのはセキュリティ対策に「万全」「完璧」など存在しないということ。
永遠に努力を強いられる過酷な問題です。
ここの場合、ソース隠してもCGI仕様に則ってるので少なくともインタフェース仕様は公開されているも同然。インターフェースのみ分かっているブラックボックスのセキュリティホールをどうやって見つけられるかというとこに焦点が集まる。 永遠に見つからないセキュリティホールはセキュリティホールではない。
永遠に見つからない保証はないよ?
で、話戻すとインターフェースのみ分かってるブラックボックスの突付き方はまずいろんなアクセスを試みること。なので次にやらなければいけないのは外部からのアクセスの監査になります。それはやってるのかな? >>882
ソース隠せば、2ちゃんのセキュリティホールをわざわざ解析してまで
攻撃しよう、と思うハッカーが少なくなるんじゃないか、ということではないでしょうか
まあ、2ちゃんがどの程度セキュリティ対策を重視しているのか
甚だ疑問ですけどね。そんなに大事なら、サーバ別負荷の統計とか
狐さんの実験とか、全部やめさせてしまえばいい。もっと安全になりますよwww >>881
確かにそうですね。遊べるし、困っているわけでも無いですし。
こんなことが出来て面白いので。 >>878
アバウトなアーキテクチャぐらいは公表してもいいかと思います。
ログ記録部分とか秘密にしなければならない部分は非公開が鉄則です。
まあそれでも見せたくなければNDAでも結んで見てもらうっていう手もありますがね
某有名RMSが激しく抗議しそうですがw もともとセキュリティ対策ってのは実益が無いのに注力しないといけない類の活動ですよ。
アーキテクチャは公表してもいいんじゃないですか?
ただ、ソースを読める人がアーキテクチャをいちいち書くのを
嫌がらなければの話ですが、、、
RMSってなんですか? >>890
RMS=個人名イニシャルです。むむむさんあたりなら確実にぴんと来るでしょう。
>ただ、ソースを読める人がアーキテクチャをいちいち書くのを
>嫌がらなければの話ですが、、、
そんなにむずかしいことじゃないはずですよ。
整形する
datにかく
なんてことをかいていけばいいので。 アーキテクチャって bbs.cgi でいうと何ですか? そうそう、時間のことは結局下記のようなことです。
だからどうしたと言われたらおしまいなのですが。
とりあえず、故意に時間がずらせると言うことだけです。
http://qb5.2ch.net/test/read.cgi/operate/1111551639/749-751 アーキテクチャはいきあたりばったりでソース主導で書いたと吐露されても困るな。w >>892
どーゆー手順で処理しているか、ということです
アルゴリズムといったほうが正しかったかもしれない。 それは既に流出しているような
それも何回も、
それ以来変わっていません。 再度書いて見ました
2ちゃんねる bbs.cgi アーキテクチャ
1) 始まり
↓
2) 各種パラメータ取得
↓
3) パラメータチェック(この処理超巨大) → byebye
↓
4) dat書き込み
↓
5) index.html subject.txt subback.html 更新
各鯖ごとの/dev/random先頭16byteを公開して下さいお願い >>900
それ公開したら、書き込む前にID分かるようになるんだっけ? っていうかIDの算出方法そのものも教えて下さい>< >>902
そんなの公開されてるでしょ
というかスレ上で公開でみんなでわいわいやったんだから >>899
故意と言っても数分程度しかずらすことは出来ないのですが、先ほどの内容で説明しますと・・・
まず、サーバに接続して、HTTPのヘッダ情報を送ります↓
POST /test/bbs.cgi HTTP/1.0
Host: qb5.2ch.net
Content-length: 129
Referer: http://qb5.2ch.net/operate/
User-Agent: Monazilla/1.00
Cookie: PON=****.***.co.jp; expires=Friday, 01-Jan-2010 00:00:00 GMT; path=/
Connection: close
↑ここまで送ると書き込み時間が決定します。
その後、↓の内容を時間をかけて送信すると、その時間差が生じて書き込まれてしまう。
bbs=operate&key=1111551639&time=1104688508&submit=%8f%91%82%ab%8d%9e%82%de&FROM=&mail=sage&MESSAGE=%82%b1%82%f1%82%c8%8a%b4%82%b6
ただ、↑の情報を送信している間に誰かが書きこまないと、時間がずれているか分からないです。
とりあえず、これだけのことなんですが。 >>907
低速回線環境(PHSなど)と高速回線環境(FTTHなど)が混じったときの
タイムマシーン現象に似せているわけですね。
少なくともこの現象は、もう何年も前からありました。
TCPのパケットを故意に分割して、タイムアウトするまで引っ張るという感じですね。
>>909-911
そうです。ただ、これによって著しく不利益が生じるわけではないと
思うので、特に問題ではないですよね。
実際、この方法でコネクションを引っ張り過ぎるとエラーで
切断/書き込まれないようなので最高でも数十分?くらいかな。 コネクション引っ張る(= 受付嬢を占有する)のはサーバにとっては、コスト高いですね。
だって、受付の人数って決まっているし。
遅い携帯が受付を占領してhttpdがまずしくなるのと、おなじりくつかと。
というかそうか、こういう場合に遠慮なく切っちゃうようにタイムアウト入れるのは、
効果あるのか。 切っちゃっていいんじゃないですか?
数十分も引っ張って迷惑するのは投票所w ちなみに、携帯系サーバは既にTimeout 5にしてあります。
相当効果あったと、記憶しています。
#
# Timeout: The number of seconds before receives and sends time out.
#
#Timeout 300
Timeout 5 (知っている人は気付いていたのだろうけど)この方法が公になったので、
同じ事を利用してリソースを食いつぶそうという愉快犯が出てくるかもしれない。
タイムアウトを設定する手段は準備しておいた方がいいと思われます。
失礼。いつでもコーイということでしたか。(;^ ^
>>917
まぁ、ステータスログは逐次的にとっているので、
問題になるようなら、ぼちぼち >>916 を掲示板サーバにも入れるってことで。 重くなると十分単位で書き込みがずれたり
入れ替わったりするですね 自作PC板の日付表示、ず〜っと、あのままですか?
いゃ、自分はアムダーなんで今のままで良いんですけどね。 >>917
時間ずらしは前にもテストスレで(◆MIPS.kHN86さんが?)実験してたから
知っている人は多そう。(少なくとも、自分はそれを見て気付いた。) >>923
2週間くらい前のでしたらきっと自分です。テストスレで試していました。
実況では時間がずれることはよくあるので、この現象自体は皆さん
知っていると思います。
しかし、実際のところ、これには少し準備が必要なわりに反応が鈍いせいか
やってる人を見たことないですね。 低負荷時にindex更新頻度を上げるってのはできないんだろうか? ってゆうか、
「3分以上古かったらindex更新」とかにしたら?
index生成って結構処理おっきいと思うんだけど。 index作成はbbs.cgiから切り離して、index作成cgiをcronで動かす。 cronでもコストが大きいからdaemonにしちゃうとか。
タイマとキューを使って細かく制御できればベター index と subject.txt はどう違うのでしょうか? >>898
2) 各種パラメータ取得
↓
3) パラメータチェック(この処理超巨大) → byebye
これを順番を適切にするだけでかなり違うような希ガス
・軽くて重要なチェック(たとえばBBQ)を前に
・重くてあまりはねる確率の少ないものを真ん中に
・統計用を最後に
といったかんじで。
で、ぜんぶOKになってはじめてdatをひらく、と(もっともこれは既にやっていると思いますが)。 1) 適切ってのが具体的にわからない。
2) わかったとしても、順番を並び替えるとたぶん動かないだろう。。。
という二重苦だったりします
BASIC (80年代初頭) で組んであると思ってください。 BASIC......ですか、なにもかもなつかしい。 Fortran77
C(78年)
ADA(79年) >>931
subject.txt は、更新順(sage考慮)に並べてある。
index.html はその上位 10 個を HTML 化した、トップのページと。
bbs.cgi は Perl で書かれている。
こんなところであっていますか? 全部白紙に戻すような話だけど、
xmlで全掲示板を構成すれば、鯖の負担も少ないし(2ch程度の大規模サーバーだからの話ですが・・・)、容量も負担しない。
上手くいけば、今のdatの3/4の容量削減が出来ると思われ。
read.cgiの再開発プロジェクトの住民に悪いが、read.cgiもいらなくなる。
WebProg板とWeb製作板の住民に協力を依頼すれば、たくさんの住民が食いついてくるし・・・
ひろゆき・root両氏の降臨キボンヌ
>946多分あってる。 その論理はちょっとおかしい気が
xmldb(?)で〜
ならまだわかるけど まぁdatや、subject.txtにある、<>が必要なくなるのでw
subject.txtのsubject.csvに変えて<>→,にすれば無問題。
>949氏等へ
専門的な話をしてスマソ。
root氏やFOX氏なら直ぐに話が分かるような気がしますが・・・
とりあえず、管理団の回答を待ってます。 レス数が950を超えています。1000を超えると書き込みができなくなります。