書き込みログのIP&リモホを見た目わからなくする方法を考えよう

サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね、

これが出来たら、乗っ取られたっていいジャン! になる。

誰か方法考えてちょ

MD5->base64変換


非現実的だけど

可逆的なのよろしくー

base64変換だけなら可逆だよ
MD5までやっちゃうと難しいけど

・別ユーザのデーモンで暗号する
・復号は別のサーバーで行う

非対称鍵

付与するキーを、別鯖から取得して暗号化。
復号時にも同じく別鯖から取得して復号化。

・・・かなぁ。。。

クラッカーホイホイですね。分かります。

公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

復号鍵は、どこのサーバ内にも保存せず、作業時に自分のPCから毎回送信するとか。
あるいは復号作業を自分のPCでやるとか。

復号鍵をおいちゃんのPCにだけ置いておくほうがいいと思う
でも鯖に侵入されたらログをみてIPやリモホは分からなくても、ログを消去される可能性が残るということをお忘れなく。

>>11
削除要請で裁判所からのIP開示に対応しないと駄目だから
個人のPCに復号鍵を置くのは、ちょっと。。

>>12
じゃぁ芋掘り出来る人全員に鍵持を持ってもらうってのはどうなのよ。
実際に芋堀りできる人がどれくらいいるのか分からないからなんとも言えないけど。
・・・この場合だと、「ある人から芋掘り権を剥奪する」という操作が不可能だな。鍵は全員同一のものになってしまうから。

あるいは、復号化鍵はqb7あたりにおいておいて、qb7の窓口から芋掘り。
qb7にはいられたら終わりだけど、qb7は堅牢だという前提で・・・。
　　芋掘り人
指示↓　↑芋
　　　qb7鯖　←復号処理
指示↓　↑暗号化芋
　　掲示板鯖

削除要請や裁判所がどう関係するのかわからない。
作業するのは1人だけじゃないって意味？
これは、IPアド閲覧権限者で復号鍵を共有することになるね。
この点は従来のアクセスパスワードを共有しているのと同じ。

まあ、ウェブサーバと個人PC、どちらが安全性が高いかっていうと、
色々な考え方ができるんだろうけども。
ただこれもパスワードのメモを保存するのと同じか。

確かに剥奪時の問題はあるんだけど、暗号化ログを取得するにも
何らかのアクセスパスワードがかかるはずだから、そこで制御するとか、
1年とか一定期間ごとに鍵を変えるとか。

ログ保存も永遠じゃないしな。

>>13
それなら、大丈夫かな。

>>14
IP開示をする作業は一人だけじゃないんだな。
http://qb5.2ch.net/test/read.cgi/sec2ch/1293072067/
↑
削除要請でこのような作業があるのよ。

qb7に鍵を置くのはいいんですけど
その鍵は一定時間ごとに変更される仕組みも必要では？

>>16
うん。
作業者が複数って端的に言えば済むところを、削除要請や裁判所を
持ち出すのは何か別の意味があるのかなと思っただけ。

>>18
書き方が悪かったかな。。ごめん。
まぁ、そういう事なんで複数の人が使う事を前提に考えなきゃ駄目なんだよ。
複数といっても、そんなに多くは無いと思う。

>>17
いっその事ワンタイムパスを（ｒｙ

>>17
一定期間ごとに自動で鍵を作り直す・・・とか？

別サーバーで、登録したMACアドレスのみアクセスできるようにするとかはダメ?

MACアドレスは参照しない方がいい。
MACアドレスは絶対にユニークな値ではないよ。
書きかえられるし。

macアドレスはいくらでも偽装出来るよ。

MACアドレスの書き換えは可能だけどほぼ生IPになる

proxy使用 -> proxy鯖のMACアドレスに置き換わる
ソケット串 -> proxy同様

やらないよりはやった方がマシなレベル

MACアドレスはユニークでないのはもちろん、どのレイヤーのものかを考えると……

PIE外に設置してる鯖とのやり取りが不可能になるか。
MACアドレスは忘れてくれ。

>>9
> 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

あらゆる意味でダメだろｗ

・ハックされて、秘密鍵側をとられたらおしまい。

・それ以前の問題として、IPアドレスなんて有限通り（３２ビット）しかないんだし、しかも、ほとんど
　日本発信のアドレスレンジはもっと狭い　→　カギ公開してたらブルートフォースで作表されてしまう。

よく考えたら、これって公開鍵暗号方式だけの問題じゃないね。

（可逆・不可逆を問わず）ハッシュ関数的なルーチン（ファンクション）かましたって、
いずれ作表されてしまう。

関数（鍵）を変えていく、としても、「そのログに対応した関数（鍵）」は一意に決まって
しまうので、逃げようがない（時間かければいずれ解かれる）。

つうことで

　　サーバ乗っ取られて書き込みログを見られてもokにしよう。
　　IPアドレスとかリモホり部分っすね

これってそもそも不可能じゃね

絶対なんて幻想にとらわれてどうするんだと＾＾；

いや「絶対」とかそういう次元の問題じゃなくて

・復号側→複数の人がIP復号化作業をする必要性があるらしいので（芋掘り、裁判所対応）
　結局、パスワードで作業管理している現状とリスクレベルあんまかわらない。

・せめてログ上、IPアドレス（リモホ文字列）だけでも暗号化できないか→母集団が少なすぎて
　ブルートフォースで作表できてしまう。表さえできれば、逆引きは一瞬ｗ


詰んだ

そもそも平文の母集団が少ないのは前提であって、それに対してイカに復号化を難しくするかってとこだろ


いやここでv6アドレスを使えば…

そもそもPIE内でMACアドレスが重複した事件とか忘れたわけじゃないよねみんな

>>32

"＜適当な乱数とかめちゃくちゃな文字列＞。ここからリモホ→<>i118-16-76-46.s10.a027.ap.plala.or.jp<>
118.16.76.4<>←ここまでリモホ。＜適当な乱数とかめちゃくちゃな文字列＞"

という超長い文字列を作ってからハッシュかける。

文字列乱数は、毎回変えれば、母集団は無限大になるので、作表は不可能。
他方、復号化したあと「人間ならば」見りゃどこがIP・リモホなのかはわかる。
どうだ？ｗ

>>34
それならログに残る本文(の一部)を使えばいいと思うの。

>>35
うむ。日付と時間含むだけでも相当散るよねｗ

IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵（固定）でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。

芋掘り時には、秘密鍵（おいちゃんと一部の削除人保有）で、IPアドレス鍵を復号化して、
これでIPアドレス・ホストを復号化。
IPアドレス鍵はランダム生成なので十分大きい母集団を持つ。これでどうよ

>>37
> 芋掘り時には、秘密鍵（おいちゃんと一部の削除人保有）

結局、これって、現在のパスワード方式による芋掘りとリスクレベルはおんなじなんだよね。
暗号設計の問題じゃなくて、「体制」の問題と思う。
複数人で共通鍵を共有したら、クラッカーの攻撃で漏れるのは時間の問題。

>>38
最初の趣旨が何であったか思い返しましょう。

今回の話は、芋掘りしていない書き込みログそのものが見られても大丈夫な様に、
という所がスタートです。

芋掘り作業のパス漏洩とかはまた別レベルの話だと思います。

>>39
なるほど。

じゃあ、鍵ペア（ふつうなら、秘密鍵・公開鍵だが、今回は母集団問題があるので両方公開しない。鍵A・鍵B）
作って、

�@ ログ作成時に鍵Aで暗号化（したがって、鍵Aは鯖／CGI内においてある）
�A IPアドレスやリモホ文字列だと母集団問題が如実に出るので、ヘッダーとか本文の最初の２行くらいをコミコミ
　 で暗号化
�B 鍵Bは、おいちゃんと一部削除人がローカルにもつ。鯖にはおかない。
�C 必要に応じて、鍵Bを使って復号化

こんなとこか？

しかし生ログが漏れた時点で時間さえかければどうにでもなっちゃうよね。

>>40
でもログの形式も判明しているのだし、書き込みの何バイトがログに入るのかも分かっている。
そうするとやっぱりIPアドレスとホストぐらいしか未知要素が入り込まないわけで、尚且つIPアドレスからホスト名は
大抵の場合求めることができる。すると、1つの書き込みの、ログのバリエーションはIPアドレスの数とだいたい同じ。

>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない？
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない（掘って復号した後に除く）。

User-Agent、●、P2、の情報もあるよ。
まあ、ランダムデータを混ぜる方が安全ってのはあるね。

>>41
暗号の安全性ってのは、現実的な時間で解読できなければ、
それは安全ってことなのよ。

【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その1】
非対称鍵で暗号化する。

■ 復号鍵をサーバに置く場合
・作業スクリプトで、作業者を認証管理する。
・復号鍵を置いているサーバや作業スクリプトの安全性が頼り。
└> サーバの侵入や漏洩を前提にした暗号化に対して、復号作業サーバの安全性は前提にできるかどうか。

■ 復号鍵を作業者が各自で保有する場合
・作業スクリプトで、作業者を認証管理した上で、復号鍵を作業スクリプトに送信する。
・掲示板サーバや復号作業サーバで侵入や漏洩が起きても、暗号は安全。
・同じ復号鍵を、作業者全員が保有する。
・各作業者の情報管理が頼り。
└> ウェブサーバと個人PC、どちらが安全か。
・権限抹消された作業者から復号鍵を取りあげることができない。
├> 定期的な鍵の変更が必要か。
└> 作業スクリプトの認証で足りるか。

暗号化の負荷ってどうなんだろう。

>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。

【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。

siberiaの時代到来ですね

>>34-35の組み合わせがいい予感

>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう？

とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。

>>34って独立した案なの？どれかの補足？

案なら、ハッシュの復号をどうするつもりかわからない。

IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。

>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵（これは非対称鍵）で暗号化して、一緒に記録。

>>51
普通「ハッシュ」っていうと不可逆なやつだよね。多分そこを誤解して>>34は書いてるんだと思う。

つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。

非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。

侵入が前提って点は、掲示板サーバと復号作業サーバとで、
サーバパスワードは違うものを使う、
掲示板サーバと同じスクリプトを置かない、
とすれば、危険性の度合いも変わるでしょ。

削除やキャップも拠点サーバで作業するって方向みたいだし、
そういう作業用サーバは全体をbasic認証でもかけておけば、
今回の事件みたいな丸見えの危険性も低減される。

その程度で十分なんじゃないかなーと。

書き込みログ見れる人は
・２ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)

>>52
ハッシュでxor取ってそのあと煮るなり焼くなりすれば
同じIPからの投稿でも書き込み内容によって暗号化されたものは変わってくる

あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。

自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。

ランダムデータを付与して、普通に非対称な鍵で暗号化する場合は>>45の方法その1にあたる。
あとは復号化鍵をどう扱うか、だが・・・

非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が３桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

なので、Log自体は共通鍵暗号で暗号化して、その鍵を公開鍵暗号で暗号化して
保存する方法しかないだろうと思います。（SSLのような感じ。）

ただ、Logの暗号化をbbs.cgiでやろうとするとやっかいな点が１つ。
複数起動するbbs.cgiがそれぞれ異なる鍵（乱数）でLogを暗号化すると、
鍵の扱いがとても大変になる可能性があります。
Logを暗号化して保存するデーモンのようなものを作る必要があるかも。

logbufferとかいうのがいたと思うからそれに手を加える事になるのかな

やっぱ重いのかあ。

こないだでたCPUはAESなら馬鹿みたいに速いんだよね。
専用ハードウェア内蔵だから

>>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が３桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

そもそも「書いた瞬間に裁判所から仮処分」とか「直ちに芋掘り」とかありえない。

だから、とりあえずは生ログか、簡易な共通鍵暗号化しておいて、負荷の低い時間帯（朝５時〜９時くらい？）
に一気に暗号化すればよい。

「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

ログ堀するんだから最低限 書き込み日時・IDは暗号化無しで格納する必要がある
この板は発信元とあるけどログには他の板で使われてるIDが書き込まれてる

>>62
> 「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

それ、お前だけだｗ

「IP・リモホだけの暗号化」やると、母集団が小さすぎて、力技で作表されてしまうおそれがある、
というので、「暗号前に適当な文字列を混ぜる」というアイディアが出てる。

文字列自体が乱数でもいいのだが、最大行数までの整数Nを発生させて、「ランダムに本文N行
含めて暗号化する」というのが暗号としては堅牢。

・・・というのがここまでのあらすじｗ

>>63
> 文字列自体が乱数でもいいのだが、最大行数までの整数Nを発生させて、「ランダムに本文N行
> 含めて暗号化する」というのが暗号としては堅牢。
本当？
例えばいま、「あ」と1行だけ書かれた本文があったとすると、ログに含まれる本文は「あ」以外に考えられないから、
日時、名前、UA、IPアドレス、ホスト名、本文を合わせて、完全な平文が手に入る。
で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの？

「同じ鍵で暗号化された、平文と暗号文の組み合わせを無数に入手しても、
　鍵の長さとアルゴリズムから考えて、復号化鍵を予測するのは不可能である」というならいいけど。

>>63
暗号化して分からなくすると言う意味であって
暗号化の元にするとは書いて無い

>57なんてIP・リモホだけじゃなくログ全体を暗号化しようとしてるじゃないか

>>64
> で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの？

されない（一般的には）

> 「同じ鍵で暗号化された、平文と暗号文の組み合わせを無数に入手しても、
> 　鍵の長さとアルゴリズムから考えて、復号化鍵を予測するのは不可能である」というならいいけど。

そのとおり（一般的には）




ここで、「一般的には」というのは平文の内容が十分散らばっていて予測不能なとき、であって、
平文のパターンが２の３２乗以下、実査、日本初のアドレスだと大したレンジ幅ない、となると、
「クラックされて暗号化関数が奪われた場合（これは鯖側においてあるのでその可能性は高い）」
考えられる値→暗号化した後の文字列、の表を作られてしまう、ってこと。

それを避けるためには、暗号前の文章を予測不能な平文にしておく必要がある。
それがここでのメインテーマ（昨日来）。

これで同じIPからの書き込みでも書き込み日時によって可変になる (逆をやれば複合化可能)
リモホは誰かやってくれ

$id = "xxxxxxxx0"; #書き込みID
$btime = pack("L1",$time); #書き込み日時 unixtime
$ip = "192.168.11.2"; #書き込みIP

($ip1,$ip2,$ip3,$ip4) = split /\./,$ip;
$ip32bitbin = pack("C4",$ip4,$ip3,$ip2,$ip1);
$ip32bitstr = uc(unpack("H2",substr($ip32bitbin,3,1))).unpack("H2",substr($ip32bitbin,2,1)).uc(unpack("H2",substr($ip32bitbin,1,1))).unpack("H2",substr($ip32bitbin,0,1));
$xorip = $ip32bitstr ^ $id;
$xorip = $xorip ^ $btime;
$ipstr = unpack("H2",substr($xorip,3,1)).uc(unpack("H2",substr($xorip,2,1))).unpack("H2",substr($xorip,1,1)).uc(unpack("H2",substr($xorip,0,1)));

$ipstrをログのIP欄に書き出す

問題点はこのスレの住人なら暗号化方法が分かってしまってる

一般的なISPって長くてどれぐらいの期間ログ持ってるんだっけ、
その間割れない程度の強度があればいいのかな。

いわゆるプロバイダ責任制限法では規定は無いそうだけど、一般的には90日程度
は保存して欲しいと言う要請はあるらしい。

だから最低3ヶ月分はどこでも持ってるんだろうな。

刑事訴訟法改正案で90日ってことになっているからね。

どっかしらに妥協点はおくことになるんだけど、
侵入が前提の安全策を考えるってとき、ソース見りゃ分かる程度の
暗号だと、簡単すぎないかな。
ソースは最初に狙われるでしょ。

軽い時間帯にまとめて暗号化するとすると、
その時までの最大24時間くらいは、
軽い暗号をかけるか、
生を許容するか。

>>71
ハッキングした人がどれだけのスキルがあるかだよ

●ハッキングには詳しいけどプログラム読めない・(C言語からperl等)変換できない・プログラム書けない
●プログラム読める・書ける・変換できるけどハッキング知識無し
とか普通にいても変じゃない

大抵の場合
１つのファイル(URL)流出 -> ファイル解析 -> 他のファイル
こんな流れ
最初から全てのファイルがある場所が分かる人なんていない

>>72
それなら１時間毎にログファイル変えるとか？
この時間なら 2011011219.log のファイル名で保存
20〜21時にファイル全体を暗号化

■ 暗号方式
(A) 難読化
　・ソースを見られると解読
　・軽い
(B) 共通鍵暗号
　・暗号化と復号が同じ鍵なので、鍵を保存できない
　　└> 常駐プロセスがメモリ上で鍵作成、暗号化処理
　　　├> それでも鍵は確保する必要
　　　└> メモリの機密性
　・比較的軽い
(C) 非対称鍵暗号
　・暗号化と復号が別の鍵なので、暗号化鍵の扱いは杜撰でいい
　・比較的重い

■ 暗号化時期
(A) 逐次
　・ピーク負荷が上昇
(B) 鯖が軽い時にまとめて
　・負荷分散
　・暗号化まで最大24時間
　　└> それまでは (a) 生 (b) 別の軽い暗号化

■ 復号鍵の保存場所
(A) 各サーバ内に生
　・侵入時にはログと同時に漏洩
(B) 各サーバ内に非対称鍵暗号化
　・その復号鍵の保存場所で再帰
(C) 拠点サーバに保存
　・拠点サーバの侵入で漏洩
(D) 作業者が各自で保有
　・個人環境の信頼性は
　・作業のたびに送信
　・権限抹消された作業者から復号鍵を取りあげることができない
　　├> 鍵は適宜変わる
　　├> 作業時の認証はある
　　└> (a) 復号鍵は作業者別に暗号化して鯖保存、この復号鍵を持つ (b) 放置

一番堅牢っぽいのは、C-A-Da かな。
費用対効果は悪そう。

そもそも個人的には、2ch程度にログ暗号化なんていらないだろ
くらいに思ってるけど、それでも暗号化の必要があるとするなら、
B-Ba-C かな。

1日1回、毎回作る共通鍵で暗号化。常駐不要。
鍵は拠点サーバに送信。
暗号化までは生で妥協。
拠点サーバに置かれる鍵の数は、鯖数×保存日数。

ログ掘り作業は、拠点サーバで認証、各サーバから暗号化ログを取得し、
鯖・日に対応する鍵で復号、煮るなり焼くなり。

拠点サーバは各掲示板サーバより少し気を使う。
鯖パスはとにかく長くとか、qb6/7みたいな掲示板との混在はやめるとか、
全面basic認証とか。

>>75
■暗号化時期については祭りが起きた時などに暗号化のピーク負荷が跳ね上がる気がします
あとサーバー乗っ取られたという想定なので
■ 暗号化時期は(A) 逐次しかないんじゃないでしょうか
同じく■ 復号鍵の保存場所についても（A)(B)は選択肢から外れ
消去法でC-A-CまたはC-A-D

A-A の後 C-Bでいいんじゃね？

３番目はノータッチ

まあそうなんだけど、1日くらいいいかな、って。

ところで、非対称鍵は重いから鯖が軽い時にまとめて、という話(>>57-61)
だったのに、>>77では軽い時に共通鍵で、ということになっているのは、
まとめてやるなら鍵を常時持っておく必要がないから、そのとき限りの
共通鍵でいいやと思ったからなんだけど、でもどうせ軽い時間にやるし、
重い処理でも負荷がピークを超えることはないだろうから、鍵1つで扱いが
楽な非対称鍵でいいか、とふりだしに戻って思い直してみたり。

>>80
非対称鍵を採用すれば、片側は鍵自体も見ることを不可能にしてる製品も既に売られている。

鍵ペアをA・Bとして、Aは物理的に見ることができない（ハードとしてUSB経由でもらった平文を
暗号化／署名して返すだけ。鍵の値は誰も見ることができない）

鍵Bは通常の数値だから、見たり、コピーしたり可能だけど、今回はこっちも公開しない。

そして、完全秘密の鍵Aを使って暗号化
　↓
おいちゃん以下数人だけが知ってる鍵Bで復号化

すればかなりセキュア

問題は、通常

　鍵A→秘密鍵
　鍵B→公開鍵

と称するので、「公開鍵」って聞いた途端に心理的に緩んじゃうんだよね。「まーバレてもいいか」的なｗ
ここがネック。

>暗号方式 (共通鍵暗号・非対称鍵暗号)
cgi(perl)内で使えなければダメ

なんて前提を忘れてる気がする

>>82
そんな前提（「絶対的必須」条件）ねーよ。

　暗号化→まとめて非ピーク時間にcron
　復号化→ローカルで処理、

でもおｋ
そりゃ、perlに実装できりゃいろいろ選択肢／応用増えるが、要件（要求仕様）ではない。

>>82
「まとめて非ピーク時間にcron」って前提じゃんか

>>84
おちつけｗ

どうせならさ
IP・リモホは別鯖で保存すればいいんじゃね？

そうすれば鯖別にログ内にIP保存して暗号化なんてことしないで済む

Perlでできないかは知らないけど、Perlである必要はないんじゃないの。
Cプログラムはいくつも動いているし。

新鮮なものが漏れてたら全然意味が無いわけでやるならlogbufferの段階でやるべき。
今のlogbufferって何で書いてあるか良く知らないけど。

>>87
言い出しっぺがやる法則

>>89
がんばって

C言語で書かれてるのをperlにするのは難しくない
perlで書かれてるものをC言語にするのは難しい

perl固有の特徴
・宣言無しで変数が使用可能 (もう１つあるけど略)
・仮想配列 ( $temp{$tmp} なんてもの 他の言語だと代用は可能だけど著しく面倒)

>>90
C言語で書くと書き込んでるのは>87

えーと、
過去にbbs.cgiをCで書くような提案があったけど
却下された経緯がある

ひ（ｒｙがソースよめない(弄れない?)から なんて理由だった気がする

つまり今ならその障害はクリアされてると

>>93
FOX ★の中の人がC言語扱えれば移行されるかもしれない

注意として
>87が流出したbbs.cgiをC言語で書く必要がある

>>66
> 暗号前の文章を予測不能な平文にしておく必要がある。
「投稿番号と投降者名とメール欄と書き込み日時+IPアドレス」ではだめかしら？
投稿番号はなくてもいいと思うけど。
「板の名前・投稿日時・IPアドレス」だったら板の名前を工夫すれば文字数も揃えられる気がするけど・・

>>94
FOXはC言語はできるはずだよ
read.cgiいじってたりするし

read.cgi、offlaw.cgi、anydat.so、bbsd

>>95
本文等はスレ上に出ちゃってるというわけで、ランダムデータを混ぜようってな
話になっているわけだね。
暗号化が、投稿1件ずつか、ファイルごとか、というような部分でも事情は
違ってくるけど。

別に元管理人もC言語できなかったわけじゃないし…
http://qb5.2ch.net/test/read.cgi/operate/1196560836/752

なんでここの連中は、perl　から　C　の任意のプログラムを spawn できるの知らないんだろ？

>>97
それは暗号化してあるデータがどのスレの何番目の書き込みかが分かっているって前提ですよね？

>>97
それと正規の手順以外で複合化しようとする輩に対抗するために
IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・

>>101
> IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・

根本的に勘違いしてるなｗ

　＜IPアドレス　リモホ＞だけ ← 2**32とおり。日本発信限定ならもっと小さい。

を

　＜乱数(2**992)＞＜IPアドレス　リモホ＞←2**1024とおり。ブルートフォースで地球が破滅するまでに解くのは困難かとｗ

となる。だがしかし、

　＜固定文字列　ないし　”既に公開されてる文字列”＞＜IPアドレス　リモホ＞←やっぱ2**32とおり。日本発信限定ならもっと小さい。

乱数の導入は必須。
なお時刻（ミリ秒単位）とかでもほとんど予測不能になる（もちろん時刻（ミリ秒単位）は公開しない）

総合すると、時刻を seeds にして→超簡単なアルゴリズムによる高速化乱数生成が吉。

>>97
$xxx =~ /([a-z0-9]+)\.2ch\.net\/test\/read.cgi\/([0-9A-Za-z]+)\/([0-9]+)/;
if(!$1 || !$2 || !$3) {&htmlOut("Good bye 1333 URLがおかしい、そんな板スレッドはない");}
$ita = $2;
$key = $3;
$cmd0 = $2 . "dat/$3";
$fName = "../../test/ggg/$cmd0" . ".cgi";
if(!(-e $fName)) {&htmlOut("Good bye 1444 ログがなかった。");}

このスレなら /test/ggg/sakhalindat/1294527532.cgi
場所は変更になってるだろうけどログ形式の変更はしてないはず

2chの書き込みログじゃなくapatchのログはどうするんだろうなｗ

>>100
書き込み日時・IDがあればどうとでもなる

>>102
> 　＜乱数(2**992)＞＜IPアドレス　リモホ＞←2**1024とおり。ブルートフォースで地球が破滅するまでに解くのは困難かとｗ

さすがにオーバースペック（ｒｙ

・暗号化１回につき、１ナノ秒（！）で済む高速マシンないしクラウド分散処理
・すべての可能性について作表するのに１万年（10^4年）とすると：

10^9（単位：ナノ）×60秒×60分×24時間×365日×10000年= 1.15 E+23

単位でいうと、E+21 がzetta＝十垓　（兆→京→垓）
二進数で表すと

1.15 E+23 = 2^77

だから、ざっと80ビット程度ばらける乱数をインクルードしとけば生きてる間に作表はできまい。

この論点で２進化は意味ないか。

要するに、平文の IP、リモホ文字列 に前置（又は後置）して、23桁の乱数十進数(0〜9)を置くか、
BASE64化して、13桁の乱数英数字(0〜9、a〜z、A〜Z、+/)を置くか。

BASE64にしても桁数大差ないなｗ

>>102
>時刻（ミリ秒単位）は公開しない
実況板逝って来い。

>>106
実況板はログとってない

>>107
ニュー速板とか他にもあるだろ

>>107
これは何かな？

犯罪予告をするアフォな人。 part3
http://qb5.2ch.net/test/read.cgi/sec2ch/1192508451/2

スレの流れが狐さんが欲するものとだんだん離れていってる気がする

狐さんが欲しているのは「鯖にやさしい暗号化cgi」ではないかと。
暗号の強度が高くても鯖に負担を強いる方法じゃ却下だろうな

そして「投稿があったら１レスごとにその場でIPとホスト部分を暗号化」。
「あとでまとめて」なんて考えられない

あと、Cじゃ却下だろうな。Perlだ


「あとでまとめて暗号化〜」「Cで〜」なんて議論だったらするだけ無駄になるから
しない方がいいよ

>>110
そりゃ、>75のような技術的に可能な事を上げていくだけの人がいるからな

あとは一般的に強固な暗号化を好んで使う人が多い
無線LANでさえWEPはぼろくそ言われてるが(省略されましたw)

ソース見れば分かってしまうような単純な物で妥協しろや

IP・リモホだけじゃなくUAも暗号化した方がいいかも (for p2.2ch.bet向け)

bbs.cgiはPealですし、

ちがうちがうperlや

>>112
peal

音節peal 発音記号/pi?l/音声を聞く音声を聞く
【名詞】【可算名詞】
1a
〔鳴り渡る鐘の〕響き 〔of〕.
b
〔雷・大砲・笑い声・拍手などの〕とどろき 〔of〕.
2a
(音楽的に調子を合わせた)ひと組の鐘.
b
鐘の奏鳴楽，鐘楽.

合ってるような間違ってるような・・・ｗｗｗ

確定事項
・perl内だけで処理可能な物
・ログ書き込みの時に暗号化する (ログ書き込み以後に暗号化はしない)

狐さんの書いて無いこと
暗号化後の容量 (IPアドレスなら最大15Byteだけど暗号化後何Byteまで膨れ上がらせていいのか？)
追加インストール(perlのあれ)していいか？

所詮は、それぞれの要素に対して、どこで妥協するかという話でしかない。

bbs.cgiじゃなくてlogbufferとかにやらせるんじゃないの？
芋ログはbbs.cgiが直接書いてるとかなら無理だけど

直接掻いています
apacheのログとは別のものです
いわゆる投稿ログです

つまりbbs.cgiのログ書き処理を変更しようと言う事ですね。

bbsd は bbs.cgi からデータを受け取ってファイル出力しているし、
まあ Perl でも暗号化はできるだろうし、
と。

bbsd は root 権限がいるからなのか、趣味に合わないからなのかで、
あまり（全く？）使われていないようだけど。

とりあえず
http://perldoc.jp/docs/modules/Crypt-CBC-2.08/CBC.pod
これを DES でやってみたら意外に簡単だった。
DESは弱いらしいけど。

鯖のアカウントを取られたらどうしようもないけれど、ディレクトリが見えちゃった（照）でも良ければ。。。

./test/tane
というファイルに『種』値を各鯖（各板）に書いて、、、
./test/.htaccess に
<Files tane>
deny from all
</Files>
とすれば、ひとまずhttp経由では中身までは見えなくなると思うのです。

その『種』をキーにして単純に暗号化するだけでもひとまずの効果は出ないかな？

♯漏れたときにはまたその時に考えようって事で♪

>>118
上の人が書いてるみたいに、「別処理じゃダメ」「Cで書いたコマンドだと使えない」って本当なの？

cron の設定とか狐さんできないの？

別処理かどうかはともかく1日1回のcronじゃ意味が無いって事なんじゃないの

>>125
１）そもそも　cron だから１日１回なんて決まりないし

２）鯖乗っ取られたらリアルで（乗っ取られてから気づいて鯖電源落とすまでｗ）の投稿IP取られちゃん
　だから、「最終cron から乗っ取り時点までのIP取られる」ということがさほど重要なこととは思えない。

３）むしろ、「負荷」考えたら、暗号化時間はずらした方が吉。リアルタイムにこだわって、鯖負荷低減の
　ために、暗号強度下げるのは本末転倒。全ログ解読されかねない。

>>123
想定してるのは今回のハッキングと同様の事 (bbs.cgiとかの流出)
なんで、http経由を制限しても無意味

>>124
しつこいぞ

そんなにやりたっかたら自鯖でやってろ

>>126
スレタイを一億と２千万回読み直せ

翻訳されて分からなくなっていれば十分なんだよ
解読されにくくするとは書かれてない。


それに芋掘りとかbooの方から流出したらIP丸出しだからいくら暗号化強化しても無意味

やれやれ。結局、「cron じゃダメ」だの「Cだと採用されない」とか連呼してるのは能力の低い馬鹿１名だけか。
FOX★もこの馬鹿には同調してないし。


馬鹿を無視して、まとめるぞ：

【要求仕様】
> サーバ乗っ取られて書き込みログを見られてもokにしよう。
> IPアドレスとかリモホり部分っすね、
>
> これが出来たら、乗っ取られたっていいジャン! になる。
> 誰か方法考えてちょ

つまり、ログ盗まれても■解読できない■（我々が生きてる間に）ようにしる！

【現在出ている最有力案】
・リアルタイムでこれを満たすのは不可能
・したがって、鯖負荷の低い時間帯にまとめて処理
・暗号化はいわゆる公開鍵暗号方式と同じ技術＝暗号鍵と復号鍵が別
・ただし、ブルートフォースかけられる可能性があるので公開鍵側も（積極的には）公開しない。
・また、IP・リモホ部分には、十進整数23桁程度 >>104-105 の乱数を暗号前に前置しておく。

”perl連呼馬鹿” は無視（透明あぼ〜ん）して、この案をベースに意見クレクレ

> ・したがって、鯖負荷の低い時間帯にまとめて処理

ここだな。問題は。

cronが前提になってるぽいが、文字通り　「鯖負荷が低い時に自動ディスパッチ」　できないの？
Windows なんかの「アイドルタイム・ウィルスチェック」みたいやつ。

UNIXではどうやるんだたけ？

>>129
あなたにも同調されて無いですが？

＞ つまり、ログ盗まれても■解読できない■（我々が生きてる間に）ようにしる！

括弧内はあなたの勝手な後付では？

＞ ・リアルタイムでこれを満たすのは不可能
＞ ・したがって、鯖負荷の低い時間帯にまとめて処理

この時点で要求仕様から乖離している事が理解出来ない？

＞ ”perl連呼馬鹿” は無視（透明あぼ〜ん）して、この案をベースに意見クレクレ

あなたもその馬鹿と一緒ですよ。

ここでそういう争いをしない方がいいよ。
夜勤さんはそういう騒動があるスレを一切無視して前に進む人だって、この板の住人なら知ってるんじゃないの？

とりあえず乗っ取られても大丈夫な暗号化芋の話で
Perlのモジュールが足りないなら入れればいい

後の事はニュー速に入れてみてからでもいいのでは
Cで書くとか定期実行とか方法変えるとか
専門板だけ実装という手もあるし

ここの議論結果が結論となるわけでなし。
ここでできるのは、選択肢と論点と考え方を提示することくらい。

と言うかよく考えたらこのスレの大前提である「書き込みログを見られない様に」って本当に必要なの？

今まで通り基本非開示で裁判所の命令とか荒らし対策とかで開示する、って運営じゃダメなの？
「基本非開示だけど外的要因で2ちゃんねるの意図ではなく開示されてしまうことがある」って書いておけば良いんじゃね。
というか書かなくてもよいんじゃね？あくまでも外的要因だから。「IP非開示は保証の限りではない」位で？

簡単に実装出来てかつ負荷無く動作するんなら有った方が良いんだろうけど・・・
それともやはり匿名性は可能な限り確保したいのかな。それが2ちゃんねるの売りでもあるから

>>133
(希望する機能がある)Perlのモジュールがあればいいのだが

Base64の機能があるとは知らず自前で作ってしまった

>>129
あんたがCで書け
責任取れ。

公開鍵方式 にこだわってる低脳なバカが一匹いるな
それにもう一匹に噛み付きまくってる

躾のなってない基地外か。

use Benchmark;
use Crypt::CBC;
use Crypt::OpenSSL::RSA;

# CBC / Blowfish の準備
my $Blowfish = Crypt::CBC->new({'key' => 'angokey', 'cipher' => 'Blowfish'});
# RSA の準備
my $Rsa = Crypt::OpenSSL::RSA->generate_key(1024);

my $count = 100000;
my $UserInfo = 'user0721.isp.2ch.net<>127.0.0.1<>marumaru<>Monazilla/1.00';

timethese($count, {
'Nama' => sub{$UserInfo}, # 何もしない
'CBC-Blowfish' => sub{$Blowfish->encrypt($UserInfo)},
'OpenSSL-RSA' => sub{$Rsa->encrypt($UserInfo)}
});

結果
CBC-Blowfish: 20 wallclock secs (15.98 usr + 3.30 sys = 19.28 CPU) @ 5186.18/s(n=100000)
Nama: 0 wallclock secs (-0.00 usr + 0.00 sys = -0.00 CPU) @ -28147497671065600000.00/s (n=100000)
OpenSSL-RSA: 8 wallclock secs ( 7.94 usr + 0.00 sys = 7.94 CPU) @ 12599.22/s(n=100000)


Blowfishの方が重いのは、

http://perldoc.jp/docs/modules/Crypt-CBC-2.08/CBC.pod
> 暗号と復号の処理は同等の(Cでコンパイルされた)SSLeayプログラムよりも
> 10分の1ほどの速度です。
> これをCで実装することによって改善することができるでしょう。

という部分の差ってことなのかな。

OpenSSL::Blowfish もあったので

# CBC / OpenSSL / Blowfish の準備
my $OsslBlowfish = Crypt::CBC->new({'key' => 'angokey', 'cipher' => 'OpenSSL::Blowfish'});

'CBC-OSSL-Blowfish' => sub{$OsslBlowfish->encrypt($UserInfo)}

を追加して試す。

結果

CBC-Blowfish: 19 wallclock secs (15.53 usr + 3.31 sys = 18.84 CPU) @ 5307.01/s(n=100000)
CBC-OSSL-Blowfish: 18 wallclock secs (14.50 usr + 3.28 sys = 17.78 CPU) @ 5623.66/s (n=100000)
Nama: 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU) @ 100000000.00/s (n=100000)
OpenSSL-RSA: 8 wallclock secs ( 7.83 usr + 0.00 sys = 7.83 CPU) @ 12774.66/s(n=100000)

大して変わらなかった。

>>139
文字数が多くなっただけ重くなるとか？

長いリモホ
CPE00248c15080f-CM0014e82750b2.cpe.net.cable.rogers.com
長いUA
Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

極端に重くなるようだったら暗号化鯖でも作ってソケット経由で丸投げした方がいいかもしれん
複合化鯖はqb7以外からの接続拒否

use Benchmark;
use Crypt::CBC;
use Crypt::OpenSSL::RSA;

# CBC / Blowfish の準備
my $Blowfish = Crypt::CBC->new({'key' => 'angokey', 'cipher' => 'Blowfish'});
# RSA の準備
my $Rsa = Crypt::OpenSSL::RSA->generate_key(1024);
# CBC / OpenSSL / Blowfish の準備
my $OsslBlowfish = Crypt::CBC->new({'key' => 'angokey', 'cipher' => 'OpenSSL::Blowfish'});

my $count = 100000;
my $UserInfo = 'user0721.isp.2ch.net<>127.0.0.1<>marumaru<>Monazilla/1.00';
timethese($count, {
'CBC-Blowfish' => sub{$Blowfish->encrypt($UserInfo)},
'OpenSSL-RSA' => sub{$Rsa->encrypt($UserInfo)},
'CBC-OSSL-Blowfish' => sub{$OsslBlowfish->encrypt($UserInfo)}
});

$UserInfo = 'CPE00248c15080f-CM0014e82750b2.cpe.net.cable.rogers.com<>127.0.0.1<>marumaru<>
Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10';
timethese($count, {
'CBC-Blowfish' => sub{$Blowfish->encrypt($UserInfo)},
'OpenSSL-RSA' => sub{foreach($UserInfo =~ /.{1,86}/g){$Rsa->encrypt($_)}},
'CBC-OSSL-Blowfish' => sub{$OsslBlowfish->encrypt($UserInfo)}
});

結果

短い方
CBC-Blowfish: 19 wallclock secs (15.73 usr + 3.00 sys = 18.73 CPU) @ 5337.89/s(n=100000)
CBC-OSSL-Blowfish: 17 wallclock secs (14.39 usr + 3.24 sys = 17.63 CPU) @ 5673.76/s (n=100000)
OpenSSL-RSA: 8 wallclock secs ( 7.83 usr + 0.00 sys = 7.83 CPU) @ 12774.66/s(n=100000)

長い方
CBC-Blowfish: 27 wallclock secs (23.77 usr + 3.20 sys = 26.97 CPU) @ 3707.96/s(n=100000)
CBC-OSSL-Blowfish: 25 wallclock secs (22.19 usr + 3.16 sys = 25.34 CPU) @ 3945.71/s (n=100000)
OpenSSL-RSA: 24 wallclock secs (23.95 usr + 0.00 sys = 23.95 CPU) @ 4174.67/s (n=100000)

まあ大きくなれば遅くなるわね。
RSAでは、一回分の大きさを超えてしまったので、分割して暗号化。
差が縮まったのは、このせいで padding が増えて、効率が下がったせいかな。

サーバ侵入に備えての暗号化で、復号鍵（とか復号に必要なもろもろ）を
サーバに保存するには、復号作業用サーバの安全性が問題になるわけだけど、
ここのところの各機能の開発状況を見ていると、qb7 が一般サーバより
安全になるとは思えないんだよねえ。
この先変わるのかな。

作業者に復号鍵を持たせるのは面倒じゃないか、
暗号化の重さに見合う利益はあるか、
侵入対策が侵入されたら解読される程度でいいのか。

何をしても費用対効果は悪いねえ。

どれもまんどくさそうねぇ。。。

やっぱりログファイル丸ごと負荷の少ない時間に暗号化するのが現実的なのかな
OSの機能で暗号化するとおそらくハッキングに対しては無力だし、書き込みのたびにログを暗号化すると負荷がどれ位掛かるのか判らない

>>147
書き込みログの形式にもよるけどな

apacheのようなログであれば(時間毎などで)分割すればいいけど
2chブラウザが取得してるようなdatファイルに追記してるならファイル丸ごとなんてことは不可能

それに負荷が低い時にまとめてとあるけど
負荷が高いまま数十時間やられたらどうしようもないな
特に、実況板(ログとって無いとかほざくやつは実況板で犯罪予告してこいや)

(A)
投稿時には、1294604913_20110123.log のようなスレ・日単位で生ログファイルを作成。
暗号化時には、ファイルごと暗号化し、生ログを削除。

(B)
投稿時には、従来通りスレ単位の生ログファイルを作成。
暗号化時には、投稿1件分ずつ暗号化して、暗号化ログファイルに追記、生ログを削除。


Aだと、投稿内容とか暗号化の必要がないものも暗号化することになるし、
復号もファイル全体になるので、効率が悪いかな。

Bなら、ログの内からIPアド等の非公開部分だけ暗号化すればいい。
復号も投稿1件ずつすることが可能。
ランダムデータを付加するとしても、データ量はAよりは少ないか。

みんなの意見をいろいろ考えてみた。
まずは一歩踏み出してみることにしよう。

一歩目は、書き込みログが外に漏れても普通の人はよくわからなくする。
IPアドレスとリモホ(●やbeの情報を含む)の部分だけやってみるだす。
漏れても解析にそれなりの時間がかかるような方法にしてみるです
そのサーバが乗っ取られてもすぐには何もできないように他のサーバにアクセスしなきゃ
いけないっていうのもハードルが一つ上がるのでやってみようと思っていまーす

拡張子を.logにしない
おとりファイルを作る

myanmar yangon sakhalin @dso が自分でPerlのモジュールを入れられないなぁ
qb5 もかぁ・・・

こりゃちと面倒だなぁ

use Crypt::CBC ;
とかやりたいんだけど、Perlで CBCモジュールが入っていたらとかって
記述できるの?

toki , hibari , yuzuru のPerlを再インストールしなきゃならないらしい。
そのときはサーバ止める予定。

ふむふむ、こうやればいいのか

sub check_module {
my $module = $_[0];
# モジュールが存在すれば読み込む
eval "use $module;";
if ($@) {
return 0;
} else {
return 1;
}
}

これを実施したことによって影響でそうなのものは

Boo
Boo2BBQ
こらこら

この辺りかな

Rockは？

そうだった
ROCK周りもダメになるな

BBM
p2
とかは？

書き込みログを利用しているものが影響するので、
BBM,p2 は問題ないです。 (共に登録するだけ)

この改造により修正したもの

1. わたしの芋掘り機
2. 削除人さん用芋掘り機
3. こらこら
4. boo (hatoに改造したのあります、配っていません)

の四つです。
まずこれらを全サーバに配ってきます。　(4は除く)

>>160 くばった

ではいよいよbbs.cgiを全サーバにくばりまーす

みごとに、ここdsoは500になっちゃった
元に戻した　@dso

改造前と、改造後の報告は、混同しちゃだめ？
改造前のログは掘れる？

qb5もエラー吐いてるな

もとにもどした　@qb5

このサーバPerlモジュールが足りないのよネ
それで >>154 っぱく作ったつもりなんだけど、うまくいかなかったと。

がっくしではPerlモジュールの処理をこんな風にしていたり。

sub EnableGzip
{
　foreach (@INC) {
　　if (open(LIB, '<' . $_ . '/Compress/Zlib.pm')) {
　　　my $is_zlib = grep(/sub memGunzip/, <LIB>);
　　　close(LIB);
　　　if ($is_zlib) {
　　　　$CONFIG{'enable_gzip'} = 1;
　　　　return(require('Compress/Zlib.pm'));
　　　}
　　}
　}
}

libプラグマとかどうでしょ
use lib "/path/to/library";
あとopenはopen(fh, mode, filename);

てすと用のプログラムではうまく行ったのよ
たぶん speedy_cgi のせいだと思うのだ。

pinkにモジュール入れてもらうの忘れてた、
ということでpinkもbbs.cgi元にもどしましたー

166はSpeedyでも動くコードだったり。汎用っぽくしてみた。

my $is_CryptCBC = &LoadModule('Crypt::CBC');

sub LoadModule
{
　my $module = shift;
　$module =~ s/::/\//g;

　if (my ($path) = grep(-f "$_/$module", @INC)) {
　　return(require($path));
　}
}

って、向こうでSunOSさんがやってました。。。orz

へへへっ

やってもらっちゃった。
そしてdsoでうまく動いた。

再度全サーバに配ってくる

配った。

現在、規制中でもfusianasanすれば書ける板に
fusianasanしても書けなくなっているようです

http://yuzuru.2ch.net/accuse/

＞175
携帯のcidrやってるので、ついでに見てみますー。

規制関係ですね。

_BBS_ihou_\.ne.jp
http://toki.2ch.net/test/read.cgi/ihou/1219460465/567

しまった、、。 ●のままだ。
>>177 はなしで。

access板をスルー処理が効いてなかったところがあったので、
スルーするようにコメントアウトしました。
現時点でoperateとaccessでfusianasanしたら書けるはずです。

で、もしaccess板でfusianasanしても書けないのが仕様だったら、
コメントアウトを外してください。。。

>>179
対応、乙でした

s/accsess/accuse/g で。。。
（素で間違えた

>>179
対応をありがとうございました。書き込みできるようになったようです。
http://yuzuru.2ch.net/test/read.cgi/accuse/1294318630/721

cobra2245にもCrypt-CBC-2.30は入っていなかったのであった♪
なので、hato鯖は未対応中♪

よろしくお願いしまーす

さっきまで一瞬書き込みからIPアドレス見ようと思えば見れたわけか・・・ｗ

今回Crypt-CBC-2.30は全鯖に入れるのか？というか入るのか？

pinkもCBCはいっていませーん
明日入れてもらう予定ではあります

qb7と同じモジュールが入るのかしら？
use Crypt::Blowfish が有効なら喜び組（qb7では入ってるです）。

@cobra2245
%perl -e 'use Crypt::CBC'
Can't locate Crypt/CBC.pm in @INC (@INC contains: perlのpathがずらずら) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

%perl -e 'use Crypt::Blowfish'
Can't locate Crypt/Blowfish.pm in @INC (@INC contains: perlのpathがずらずら) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

だす♪

♯以下root貰っちゃいなっていうのは禁止♪

よくわからんけど、

ぼうはつした。

思想は・・・

作成の思想は、各サーバにログフィルをあさって
ipアドレスを探してくるスクリプトがある。
boo.2ch.netはそれぞれのサーバにそのipアドレスを問い合わせる。

私は hatoでその実験をしました。　つまり Cobra2245 にはCBCは入っている必要はないかと、

入っていないサーバはbbs.cgiを見てもらえば分かりますが、Cryptされた部分が
Cryptされずに生々しく入っているという話です。
それでsunOsさんにCrypt::CBCが入っているかどうかで動きを変えるというのを教えてもらいました。

あ、今頃了解しました。早とちり（汗）
・・・のでbooのhato鯖対応復帰♪

>>192
hack72.2h.netを作ろうとしているので
新しい「串」が見つかったら呼んで欲しいのです。

hack72.2ch.net建設予定地
http://dso.2ch.net/test/read.cgi/sakhalin/1297008073/

フォレンジック分析から投稿者を守るためには、ログサーバを
海外に置いてログサーバのディスクを暗号化してからそこに
ログを置けばいいと思うのです。

もともと海外だろ

アメリカは暗号化解除を強要できるらしいからﾀﾞﾒﾀﾞﾅ

結局できたの？

　　　　　 _
　　　　　 |O＼
　　　　　 |　　 ＼　ｷﾘｷﾘ
　　　　∧|∧ 　　＼　ｷﾘｷﾘ
ｸﾞｸﾞｩ>（；⌒ヽ　　　 ＼
　　　　∪　　|　　 　　(~)
　　　　　∪∪　　 γ´⌒｀ヽ
　　　　　）　）　　 　{i:i:i:i:i:i:i:i:}
　　　　 （　（　　　　(　´･ω･)、
　　　　　　　　　　　(O ⌒　)O
　　　　　　　　 　 　⊂＿)∪

あ

ログを全部平文で保存してたせいで大惨事か…

てす