5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

1 :偽FOX ★:2011/01/10(月) 05:28:33 発信元:??? 0
サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね、

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

誰か方法考えてちょ

2 :名無しさん@お腹いっぱい。:2011/01/10(月) 05:41:57 発信元:180.0.86.190 0
MD5->base64変換


非現実的だけど

3 :偽FOX ★:2011/01/10(月) 05:43:08 発信元:??? 0
可逆的なのよろしくー

4 :名無しさん@お腹いっぱい。:2011/01/10(月) 05:43:52 発信元:180.0.86.190 0
base64変換だけなら可逆だよ
MD5までやっちゃうと難しいけど

5 :名無しさん@お腹いっぱい。:2011/01/10(月) 05:59:43 発信元:211.131.89.204 0
・別ユーザのデーモンで暗号する
・復号は別のサーバーで行う

6 :名無しさん@お腹いっぱい。:2011/01/10(月) 06:14:13 発信元:180.0.150.47 0
非対称鍵

7 :未承諾広告※ ◆bbq.muteQGCV :2011/01/10(月) 06:45:41 発信元:219.117.239.35 0
付与するキーを、別鯖から取得して暗号化。
復号時にも同じく別鯖から取得して復号化。

・・・かなぁ。。。

8 :名無しさん@お腹いっぱい。:2011/01/10(月) 06:49:59 発信元:203.140.44.71 0
クラッカーホイホイですね。分かります。

9 :名無しさん@お腹いっぱい。:2011/01/10(月) 07:56:37 発信元:210.135.98.43 (70297) P
公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

10 :名無しさん@お腹いっぱい。:2011/01/10(月) 08:00:12 発信元:210.135.98.43 (70297) P
復号鍵は、どこのサーバ内にも保存せず、作業時に自分のPCから毎回送信するとか。
あるいは復号作業を自分のPCでやるとか。

11 :名無しさん@お腹いっぱい。:2011/01/10(月) 11:41:17 発信元:116.83.131.21 0
復号鍵をおいちゃんのPCにだけ置いておくほうがいいと思う
でも鯖に侵入されたらログをみてIPやリモホは分からなくても、ログを消去される可能性が残るということをお忘れなく。

12 :◆ANGLERlqvM :2011/01/10(月) 11:43:43 発信元:182.170.170.218 0
>>11
削除要請で裁判所からのIP開示に対応しないと駄目だから
個人のPCに復号鍵を置くのは、ちょっと。。

13 :名無しさん@お腹いっぱい。:2011/01/10(月) 11:51:55 発信元:116.83.131.21 0
>>12
じゃぁ芋掘り出来る人全員に鍵持を持ってもらうってのはどうなのよ。
実際に芋堀りできる人がどれくらいいるのか分からないからなんとも言えないけど。
・・・この場合だと、「ある人から芋掘り権を剥奪する」という操作が不可能だな。鍵は全員同一のものになってしまうから。

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

14 :名無しさん@お腹いっぱい。:2011/01/10(月) 11:54:05 発信元:210.135.98.43 (70297) P
削除要請や裁判所がどう関係するのかわからない。
作業するのは1人だけじゃないって意味?
これは、IPアド閲覧権限者で復号鍵を共有することになるね。
この点は従来のアクセスパスワードを共有しているのと同じ。

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

15 :名無しさん@お腹いっぱい。:2011/01/10(月) 12:02:55 発信元:210.135.98.43 (70297) P
確かに剥奪時の問題はあるんだけど、暗号化ログを取得するにも
何らかのアクセスパスワードがかかるはずだから、そこで制御するとか、
1年とか一定期間ごとに鍵を変えるとか。

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

16 :◆ANGLERlqvM :2011/01/10(月) 12:07:26 発信元:182.170.170.218 0
>>13
それなら、大丈夫かな。

>>14
IP開示をする作業は一人だけじゃないんだな。
http://qb5.2ch.net/test/read.cgi/sec2ch/1293072067/

削除要請でこのような作業があるのよ。

17 :名無しさん@お腹いっぱい。:2011/01/10(月) 12:13:31 発信元:210.135.100.132 (851651) P
qb7に鍵を置くのはいいんですけど
その鍵は一定時間ごとに変更される仕組みも必要では?

18 :名無しさん@お腹いっぱい。:2011/01/10(月) 12:15:24 発信元:210.135.98.43 (70297) P
>>16
うん。
作業者が複数って端的に言えば済むところを、削除要請や裁判所を
持ち出すのは何か別の意味があるのかなと思っただけ。

19 :◆ANGLERlqvM :2011/01/10(月) 12:18:09 発信元:182.170.170.218 0
>>18
書き方が悪かったかな。。ごめん。
まぁ、そういう事なんで複数の人が使う事を前提に考えなきゃ駄目なんだよ。
複数といっても、そんなに多くは無いと思う。

20 :名無しさん@お腹いっぱい。:2011/01/10(月) 14:04:15 発信元:210.130.49.155 0
>>17
いっその事ワンタイムパスを(ry


21 :名無しさん@お腹いっぱい。:2011/01/10(月) 18:34:45 発信元:59.139.61.239 0
>>17
一定期間ごとに自動で鍵を作り直す・・・とか?

22 :名無しさん@お腹いっぱい。:2011/01/10(月) 23:35:09 発信元:126.115.99.143 0 ?2BP(0)
別サーバーで、登録したMACアドレスのみアクセスできるようにするとかはダメ?

23 :◆ANGLERlqvM :2011/01/10(月) 23:40:42 発信元:182.170.170.218 0
MACアドレスは参照しない方がいい。
MACアドレスは絶対にユニークな値ではないよ。
書きかえられるし。

24 :名無しさん@お腹いっぱい。:2011/01/10(月) 23:56:24 発信元:219.121.32.73 0
macアドレスはいくらでも偽装出来るよ。

25 :名無しさん@お腹いっぱい。:2011/01/11(火) 00:05:27 発信元:114.165.66.241 0
MACアドレスの書き換えは可能だけどほぼ生IPになる

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

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

26 :名無しさん@お腹いっぱい。:2011/01/11(火) 00:10:52 発信元:220.210.188.201 0
MACアドレスはユニークでないのはもちろん、どのレイヤーのものかを考えると……

27 :名無しさん@お腹いっぱい。:2011/01/11(火) 00:17:57 発信元:114.165.66.241 0
PIE外に設置してる鯖とのやり取りが不可能になるか。
MACアドレスは忘れてくれ。

28 :名無しさん@お腹いっぱい。:2011/01/11(火) 10:10:05 発信元:113.197.147.23 0
>>9
> 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

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

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

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

29 :名無しさん@お腹いっぱい。:2011/01/11(火) 10:39:15 発信元:113.197.147.23 0
よく考えたら、これって公開鍵暗号方式だけの問題じゃないね。

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

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

つうことで

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

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

30 :名無しさん@お腹いっぱい。:2011/01/11(火) 10:54:41 発信元:180.0.150.47 0
絶対なんて幻想にとらわれてどうするんだと^^;

31 :名無しさん@お腹いっぱい。:2011/01/11(火) 11:01:44 発信元:113.197.147.23 0
いや「絶対」とかそういう次元の問題じゃなくて

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

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


詰んだ

32 :名無しさん@お腹いっぱい。:2011/01/11(火) 11:20:13 発信元:180.0.150.47 0
そもそも平文の母集団が少ないのは前提であって、それに対してイカに復号化を難しくするかってとこだろ


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

33 :名無しさん@お腹いっぱい。:2011/01/11(火) 11:21:30 発信元:202.212.71.18 0
そもそもPIE内でMACアドレスが重複した事件とか忘れたわけじゃないよねみんな

34 :名無しさん@お腹いっぱい。:2011/01/11(火) 11:45:48 発信元:58.138.21.205 0
>>32

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

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

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

35 :!omikuji!dama 株価【E】 :2011/01/11(火) 14:47:58 発信元:118.0.123.202 0
>>34
それならログに残る本文(の一部)を使えばいいと思うの。

36 :名無しさん@お腹いっぱい。:2011/01/11(火) 15:01:23 発信元:220.210.177.1 0
>>35
うむ。日付と時間含むだけでも相当散るよねw

37 :名無しさん@お腹いっぱい。:2011/01/11(火) 16:45:58 発信元:116.83.131.21 0
IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵(固定)でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。

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

38 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:03:41 発信元:58.138.31.54 0
>>37
> 芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)

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

39 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:12:13 発信元:210.130.52.122 0
>>38
最初の趣旨が何であったか思い返しましょう。

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

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


40 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:18:10 発信元:58.138.31.54 0
>>39
なるほど。

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

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

こんなとこか?

41 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:32:50 発信元:202.212.71.18 0
しかし生ログが漏れた時点で時間さえかければどうにでもなっちゃうよね。

42 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:36:45 発信元:116.83.131.21 0
>>40
でもログの形式も判明しているのだし、書き込みの何バイトがログに入るのかも分かっている。
そうするとやっぱりIPアドレスとホストぐらいしか未知要素が入り込まないわけで、尚且つIPアドレスからホスト名は
大抵の場合求めることができる。すると、1つの書き込みの、ログのバリエーションはIPアドレスの数とだいたい同じ。

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

43 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:53:55 発信元:210.135.98.43 (70297) P
User-Agent、●、P2、の情報もあるよ。
まあ、ランダムデータを混ぜる方が安全ってのはあるね。

44 :名無しさん@お腹いっぱい。:2011/01/11(火) 17:55:27 発信元:210.135.98.43 (70297) P
>>41
暗号の安全性ってのは、現実的な時間で解読できなければ、
それは安全ってことなのよ。

45 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:34:57 発信元:210.135.98.43 (70297) P
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

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

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

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

46 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:37:44 発信元:210.135.98.43 (70297) P
暗号化の負荷ってどうなんだろう。

47 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:41:04 発信元:116.83.131.21 0
>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。

48 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:41:04 発信元:210.135.98.43 (70297) P
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

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

49 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:46:04 発信元:219.30.41.43 0
siberiaの時代到来ですね

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

50 :名無しさん@お腹いっぱい。:2011/01/11(火) 18:57:50 発信元:210.135.98.43 (70297) P
>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう?

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

51 :名無しさん@お腹いっぱい。:2011/01/11(火) 19:11:23 発信元:210.135.98.43 (70297) P
>>34って独立した案なの?どれかの補足?

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

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

52 :名無しさん@お腹いっぱい。:2011/01/11(火) 19:45:59 発信元:116.83.131.21 0
>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵(これは非対称鍵)で暗号化して、一緒に記録。

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

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

53 :名無しさん@お腹いっぱい。:2011/01/11(火) 19:48:45 発信元:210.135.98.43 (70297) P
非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。

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

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

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

54 :名無しさん@お腹いっぱい。:2011/01/11(火) 20:14:38 発信元:114.165.65.23 0
書き込みログ見れる人は
・2ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)

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

55 :名無しさん@お腹いっぱい。:2011/01/11(火) 20:56:02 発信元:210.135.98.43 (70297) P
あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。

56 :名無しさん@お腹いっぱい。:2011/01/11(火) 22:16:49 発信元:116.83.131.21 0
自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。

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

57 :名無しさん@お腹いっぱい。:2011/01/11(火) 22:43:05 発信元:124.45.124.20 0
非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

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

58 :名無しさん@お腹いっぱい。:2011/01/11(火) 23:00:14 発信元:202.212.71.18 0
logbufferとかいうのがいたと思うからそれに手を加える事になるのかな

59 :名無しさん@お腹いっぱい。:2011/01/11(火) 23:21:46 発信元:210.135.98.43 (70297) P
やっぱ重いのかあ。

60 :名無しさん@お腹いっぱい。:2011/01/12(水) 00:45:01 発信元:14.128.110.60 0
こないだでたCPUはAESなら馬鹿みたいに速いんだよね。
専用ハードウェア内蔵だから

61 :名無しさん@お腹いっぱい。:2011/01/12(水) 08:55:42 発信元:220.210.176.141 0
>>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

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

62 :名無しさん@お腹いっぱい。:2011/01/12(水) 13:06:12 発信元:114.165.65.23 0
「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

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

63 :名無しさん@お腹いっぱい。:2011/01/12(水) 14:28:26 発信元:220.100.18.68 0
>>62
> 「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

それ、お前だけだw

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

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

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

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

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

65 :名無しさん@お腹いっぱい。:2011/01/12(水) 15:09:24 発信元:58.88.137.173 0
>>63
暗号化して分からなくすると言う意味であって
暗号化の元にするとは書いて無い

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

66 :名無しさん@お腹いっぱい。:2011/01/12(水) 15:22:57 発信元:58.138.37.83 0
>>64
> で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの?

されない(一般的には)

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

そのとおり(一般的には)




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

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

67 :名無しさん@お腹いっぱい。:2011/01/12(水) 17:19:05 発信元:58.88.137.173 0
これで同じ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欄に書き出す

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

68 :名無しさん@お腹いっぱい。:2011/01/12(水) 17:40:37 発信元:202.212.71.18 0
一般的なISPって長くてどれぐらいの期間ログ持ってるんだっけ、
その間割れない程度の強度があればいいのかな。

69 :名無しさん@お腹いっぱい。:2011/01/12(水) 17:52:49 発信元:210.130.48.97 0
いわゆるプロバイダ責任制限法では規定は無いそうだけど、一般的には90日程度
は保存して欲しいと言う要請はあるらしい。

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

70 :名無しさん@お腹いっぱい。:2011/01/12(水) 18:14:42 発信元:210.135.98.43 (70297) P
刑事訴訟法改正案で90日ってことになっているからね。

71 :名無しさん@お腹いっぱい。:2011/01/12(水) 18:18:51 発信元:210.135.98.43 (70297) P
どっかしらに妥協点はおくことになるんだけど、
侵入が前提の安全策を考えるってとき、ソース見りゃ分かる程度の
暗号だと、簡単すぎないかな。
ソースは最初に狙われるでしょ。

72 :名無しさん@お腹いっぱい。:2011/01/12(水) 18:22:29 発信元:210.135.98.43 (70297) P
軽い時間帯にまとめて暗号化するとすると、
その時までの最大24時間くらいは、
軽い暗号をかけるか、
生を許容するか。

73 :名無しさん@お腹いっぱい。:2011/01/12(水) 19:07:49 発信元:58.88.137.173 0
>>71
ハッキングした人がどれだけのスキルがあるかだよ

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

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

74 :名無しさん@お腹いっぱい。:2011/01/12(水) 19:13:43 発信元:58.88.137.173 0
>>72
それなら1時間毎にログファイル変えるとか?
この時間なら 2011011219.log のファイル名で保存
20〜21時にファイル全体を暗号化

75 :名無しさん@お腹いっぱい。:2011/01/12(水) 19:37:14 発信元:210.135.98.43 (70297) P
■ 暗号方式
(A) 難読化
 ・ソースを見られると解読
 ・軽い
(B) 共通鍵暗号
 ・暗号化と復号が同じ鍵なので、鍵を保存できない
  └> 常駐プロセスがメモリ上で鍵作成、暗号化処理
   ├> それでも鍵は確保する必要
   └> メモリの機密性
 ・比較的軽い
(C) 非対称鍵暗号
 ・暗号化と復号が別の鍵なので、暗号化鍵の扱いは杜撰でいい
 ・比較的重い

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

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

76 :名無しさん@お腹いっぱい。:2011/01/12(水) 19:54:32 発信元:210.135.98.43 (70297) P
一番堅牢っぽいのは、C-A-Da かな。
費用対効果は悪そう。

77 :名無しさん@お腹いっぱい。:2011/01/12(水) 20:47:16 発信元:210.135.98.43 (70297) P
そもそも個人的には、2ch程度にログ暗号化なんていらないだろ
くらいに思ってるけど、それでも暗号化の必要があるとするなら、
B-Ba-C かな。

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

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

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

78 :名無しさん@お腹いっぱい。:2011/01/13(木) 01:24:19 発信元:219.30.41.43 0
>>75
■暗号化時期については祭りが起きた時などに暗号化のピーク負荷が跳ね上がる気がします
あとサーバー乗っ取られたという想定なので
■ 暗号化時期は(A) 逐次しかないんじゃないでしょうか
同じく■ 復号鍵の保存場所についても(A)(B)は選択肢から外れ
消去法でC-A-CまたはC-A-D


79 :名無しさん@お腹いっぱい。:2011/01/13(木) 15:01:00 発信元:124.85.221.28 0
A-A の後 C-Bでいいんじゃね?

3番目はノータッチ

80 :名無しさん@お腹いっぱい。:2011/01/13(木) 16:29:15 発信元:210.135.98.43 (70297) P
まあそうなんだけど、1日くらいいいかな、って。

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

81 :名無しさん@お腹いっぱい。:2011/01/13(木) 16:37:59 発信元:219.111.118.25 0
>>80
非対称鍵を採用すれば、片側は鍵自体も見ることを不可能にしてる製品も既に売られている。

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

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

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

すればかなりセキュア

問題は、通常

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

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

82 :名無しさん@お腹いっぱい。:2011/01/13(木) 17:05:54 発信元:124.85.221.28 0
>暗号方式 (共通鍵暗号・非対称鍵暗号)
cgi(perl)内で使えなければダメ

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

83 :名無しさん@お腹いっぱい。:2011/01/13(木) 17:18:11 発信元:219.111.118.25 0
>>82
そんな前提(「絶対的必須」条件)ねーよ。

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

でもおk
そりゃ、perlに実装できりゃいろいろ選択肢/応用増えるが、要件(要求仕様)ではない。

84 :名無しさん@お腹いっぱい。:2011/01/13(木) 17:21:58 発信元:124.85.221.28 0
>>82
「まとめて非ピーク時間にcron」って前提じゃんか

85 :名無しさん@お腹いっぱい。:2011/01/13(木) 17:23:28 発信元:219.111.118.25 0
>>84
おちつけw

86 :名無しさん@お腹いっぱい。:2011/01/13(木) 17:58:10 発信元:124.85.221.28 0
どうせならさ
IP・リモホは別鯖で保存すればいいんじゃね?

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

87 :名無しさん@お腹いっぱい。:2011/01/13(木) 18:00:47 発信元:210.135.98.43 (70297) P
Perlでできないかは知らないけど、Perlである必要はないんじゃないの。
Cプログラムはいくつも動いているし。

88 :名無しさん@お腹いっぱい。:2011/01/13(木) 18:06:04 発信元:202.212.71.18 0
新鮮なものが漏れてたら全然意味が無いわけでやるならlogbufferの段階でやるべき。
今のlogbufferって何で書いてあるか良く知らないけど。

89 :名無しさん@お腹いっぱい。:2011/01/13(木) 18:12:13 発信元:124.85.221.28 0
>>87
言い出しっぺがやる法則

90 :名無しさん@お腹いっぱい。:2011/01/13(木) 18:17:18 発信元:220.100.254.78 0
>>89
がんばって

91 :名無しさん@お腹いっぱい。:2011/01/13(木) 18:31:30 発信元:124.85.221.28 0
C言語で書かれてるのをperlにするのは難しくない
perlで書かれてるものをC言語にするのは難しい

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

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

92 :名無しさん@お腹いっぱい。:2011/01/14(金) 08:12:25 発信元:122.30.0.229 0
えーと、
過去にbbs.cgiをCで書くような提案があったけど
却下された経緯がある

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

93 :名無しさん@お腹いっぱい。:2011/01/14(金) 08:22:35 発信元:27.228.29.169 0
つまり今ならその障害はクリアされてると

94 :名無しさん@お腹いっぱい。:2011/01/14(金) 08:31:07 発信元:122.30.0.229 0
>>93
FOX ★の中の人がC言語扱えれば移行されるかもしれない

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

95 :名無しさん@お腹いっぱい。:2011/01/14(金) 09:15:00 発信元:211.127.9.191 0
>>66
> 暗号前の文章を予測不能な平文にしておく必要がある。
「投稿番号と投降者名とメール欄と書き込み日時+IPアドレス」ではだめかしら?
投稿番号はなくてもいいと思うけど。
「板の名前・投稿日時・IPアドレス」だったら板の名前を工夫すれば文字数も揃えられる気がするけど・・

96 :名無しさん@お腹いっぱい。:2011/01/14(金) 09:33:41 発信元:210.135.100.132 (766257) P
>>94
FOXはC言語はできるはずだよ
read.cgiいじってたりするし

97 :名無しさん@お腹いっぱい。:2011/01/14(金) 09:59:03 発信元:210.135.98.43 (70297) P
read.cgi、offlaw.cgi、anydat.so、bbsd

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

98 :名無しさん@お腹いっぱい。:2011/01/14(金) 10:08:00 発信元:202.212.71.18 0
別に元管理人もC言語できなかったわけじゃないし…
http://qb5.2ch.net/test/read.cgi/operate/1196560836/752

99 :名無しさん@お腹いっぱい。:2011/01/14(金) 10:10:02 発信元:58.138.12.51 0
なんでここの連中は、perl から C の任意のプログラムを spawn できるの知らないんだろ?

100 :名無しさん@お腹いっぱい。:2011/01/14(金) 11:01:19 発信元:211.127.9.191 0
>>97
それは暗号化してあるデータがどのスレの何番目の書き込みかが分かっているって前提ですよね?

101 :名無しさん@お腹いっぱい。:2011/01/14(金) 11:05:27 発信元:211.127.9.191 0
>>97
それと正規の手順以外で複合化しようとする輩に対抗するために
IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・

102 :名無しさん@お腹いっぱい。:2011/01/14(金) 12:27:34 発信元:58.138.12.51 0
>>101
> IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・

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

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



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

となる。だがしかし、

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

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

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

103 :名無しさん@お腹いっぱい。:2011/01/14(金) 12:38:27 発信元:122.30.0.229 0
>>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のログはどうするんだろうなw

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

104 :名無しさん@お腹いっぱい。:2011/01/14(金) 13:02:57 発信元:113.197.243.196 0
>>102
>  <乱数(2**992)><IPアドレス リモホ>←2**1024とおり。ブルートフォースで地球が破滅するまでに解くのは困難かとw

さすがにオーバースペック(ry

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

10^9(単位:ナノ)×60秒×60分×24時間×365日×10000年= 1.15 E+23

単位でいうと、E+21 がzetta=十垓 (兆→京→垓)
二進数で表すと

1.15 E+23 = 2^77

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

105 :名無しさん@お腹いっぱい。:2011/01/14(金) 13:10:36 発信元:113.197.243.196 0
この論点で2進化は意味ないか。

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

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

106 :名無しさん@お腹いっぱい。:2011/01/14(金) 13:11:49 発信元:122.30.0.229 0
>>102
>時刻(ミリ秒単位)は公開しない
実況板逝って来い。

107 :名無しさん@お腹いっぱい。:2011/01/14(金) 13:24:21 発信元:113.197.243.196 0
>>106
実況板はログとってない

108 :名無しさん@お腹いっぱい。:2011/01/14(金) 15:01:55 発信元:122.30.0.229 0
>>107
ニュー速板とか他にもあるだろ

109 :名無しさん@お腹いっぱい。:2011/01/14(金) 15:09:29 発信元:122.30.0.229 0
>>107
これは何かな?

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

110 :名無しさん@お腹いっぱい。:2011/01/14(金) 15:57:02 発信元:123.221.184.37 0
スレの流れが狐さんが欲するものとだんだん離れていってる気がする

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

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

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


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

111 :名無しさん@お腹いっぱい。:2011/01/14(金) 20:02:34 発信元:122.30.0.229 0
>>110
そりゃ、>75のような技術的に可能な事を上げていくだけの人がいるからな

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

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

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

112 :偽FOX ★:2011/01/15(土) 05:53:41 発信元:??? 0
bbs.cgiはPealですし、

113 :名無しさん@お腹いっぱい。:2011/01/15(土) 10:11:50 発信元:175.179.239.53 0
ちがうちがうperlや

114 :名無しさん@お腹いっぱい。:2011/01/15(土) 10:19:41 発信元:123.48.61.219 0
>>112
peal

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

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

115 :名無しさん@お腹いっぱい。:2011/01/15(土) 12:51:46 発信元:222.147.50.205 0
確定事項
・perl内だけで処理可能な物
・ログ書き込みの時に暗号化する (ログ書き込み以後に暗号化はしない)

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

116 :名無しさん@お腹いっぱい。:2011/01/15(土) 13:38:36 発信元:210.135.98.43 (70297) P
所詮は、それぞれの要素に対して、どこで妥協するかという話でしかない。

117 :名無しさん@お腹いっぱい。:2011/01/15(土) 16:09:09 発信元:202.212.71.18 0
bbs.cgiじゃなくてlogbufferとかにやらせるんじゃないの?
芋ログはbbs.cgiが直接書いてるとかなら無理だけど

118 :偽FOX ★:2011/01/15(土) 16:22:54 発信元:??? 0
直接掻いています
apacheのログとは別のものです
いわゆる投稿ログです

119 :名無しさん@お腹いっぱい。:2011/01/15(土) 17:00:15 発信元:210.130.48.100 0
つまりbbs.cgiのログ書き処理を変更しようと言う事ですね。

120 :名無しさん@お腹いっぱい。:2011/01/15(土) 18:38:24 発信元:210.135.98.43 (70297) P
bbsd は bbs.cgi からデータを受け取ってファイル出力しているし、
まあ Perl でも暗号化はできるだろうし、
と。

121 :名無しさん@お腹いっぱい。:2011/01/15(土) 18:43:53 発信元:210.135.98.43 (70297) P
bbsd は root 権限がいるからなのか、趣味に合わないからなのかで、
あまり(全く?)使われていないようだけど。

122 :名無しさん@お腹いっぱい。:2011/01/15(土) 19:43:17 発信元:210.135.98.43 (70297) P
とりあえず
http://perldoc.jp/docs/modules/Crypt-CBC-2.08/CBC.pod
これを DES でやってみたら意外に簡単だった。
DESは弱いらしいけど。

123 :未承諾広告※ ◆BAILA6C886n4 :2011/01/15(土) 21:31:38 発信元:219.117.239.35 0
鯖のアカウントを取られたらどうしようもないけれど、ディレクトリが見えちゃった(照)でも良ければ。。。

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

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

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

124 :名無しさん@お腹いっぱい。:2011/01/16(日) 12:12:27 発信元:121.102.115.156 0
>>118
上の人が書いてるみたいに、「別処理じゃダメ」「Cで書いたコマンドだと使えない」って本当なの?

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

125 :名無しさん@お腹いっぱい。:2011/01/16(日) 12:18:00 発信元:202.212.71.18 0
別処理かどうかはともかく1日1回のcronじゃ意味が無いって事なんじゃないの

126 :名無しさん@お腹いっぱい。:2011/01/16(日) 12:28:37 発信元:121.102.115.156 0
>>125
1)そもそも cron だから1日1回なんて決まりないし

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

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

127 :名無しさん@お腹いっぱい。:2011/01/16(日) 14:44:58 発信元:122.30.15.33 0
>>123
想定してるのは今回のハッキングと同様の事 (bbs.cgiとかの流出)
なんで、http経由を制限しても無意味

>>124
しつこいぞ

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

128 :名無しさん@お腹いっぱい。:2011/01/16(日) 15:12:59 発信元:122.30.15.33 0
>>126
スレタイを一億と2千万回読み直せ

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


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

129 :名無しさん@お腹いっぱい。:2011/01/17(月) 10:42:22 発信元:113.197.193.189 0
やれやれ。結局、「cron じゃダメ」だの「Cだと採用されない」とか連呼してるのは能力の低い馬鹿1名だけか。
FOX★もこの馬鹿には同調してないし。


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

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

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

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

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

130 :名無しさん@お腹いっぱい。:2011/01/17(月) 10:46:31 発信元:220.210.183.230 0
> ・したがって、鯖負荷の低い時間帯にまとめて処理

ここだな。問題は。

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

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

131 :名無しさん@お腹いっぱい。:2011/01/17(月) 11:37:22 発信元:210.130.48.83 0
>>129
あなたにも同調されて無いですが?

> つまり、ログ盗まれても■解読できない■(我々が生きてる間に)ようにしる!

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

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

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

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

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

132 :名無しさん@お腹いっぱい。:2011/01/17(月) 12:13:55 発信元:211.127.9.191 0
ここでそういう争いをしない方がいいよ。
夜勤さんはそういう騒動があるスレを一切無視して前に進む人だって、この板の住人なら知ってるんじゃないの?

133 :名無しさん@お腹いっぱい。:2011/01/17(月) 14:54:51 発信元:123.198.147.37 0
とりあえず乗っ取られても大丈夫な暗号化芋の話で
Perlのモジュールが足りないなら入れればいい

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

134 :名無しさん@お腹いっぱい。:2011/01/17(月) 17:23:12 発信元:210.135.98.43 (70297) P
ここの議論結果が結論となるわけでなし。
ここでできるのは、選択肢と論点と考え方を提示することくらい。

135 :名無しさん@お腹いっぱい。:2011/01/17(月) 17:27:57 発信元:211.127.9.191 0
と言うかよく考えたらこのスレの大前提である「書き込みログを見られない様に」って本当に必要なの?

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

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

136 :名無しさん@お腹いっぱい。:2011/01/17(月) 18:08:58 発信元:114.165.66.156 0
>>133
(希望する機能がある)Perlのモジュールがあればいいのだが

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

137 :名無しさん@お腹いっぱい。:2011/01/17(月) 18:15:33 発信元:114.165.66.156 0
>>129
あんたがCで書け
責任取れ。

138 :名無しさん@お腹いっぱい。:2011/01/17(月) 18:30:28 発信元:114.165.66.156 0
公開鍵方式 にこだわってる低脳なバカが一匹いるな
それにもう一匹に噛み付きまくってる

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

139 :名無しさん@お腹いっぱい。:2011/01/17(月) 20:33:01 発信元:210.135.98.43 (70297) P
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)}
});

140 :名無しさん@お腹いっぱい。:2011/01/17(月) 20:34:59 発信元:210.135.98.43 (70297) P
結果
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で実装することによって改善することができるでしょう。

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

141 :名無しさん@お腹いっぱい。:2011/01/17(月) 21:32:00 発信元:210.135.98.43 (70297) P
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)

大して変わらなかった。

142 :名無しさん@お腹いっぱい。:2011/01/18(火) 16:22:05 発信元:114.165.61.214 0
>>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以外からの接続拒否

143 :名無しさん@お腹いっぱい。:2011/01/18(火) 22:02:53 発信元:210.135.98.43 (70297) P
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)}
});

144 :名無しさん@お腹いっぱい。:2011/01/18(火) 22:04:45 発信元:210.135.98.43 (70297) P
結果

短い方
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 が増えて、効率が下がったせいかな。

145 :名無しさん@お腹いっぱい。:2011/01/18(火) 22:21:33 発信元:210.135.98.43 (70297) P
サーバ侵入に備えての暗号化で、復号鍵(とか復号に必要なもろもろ)を
サーバに保存するには、復号作業用サーバの安全性が問題になるわけだけど、
ここのところの各機能の開発状況を見ていると、qb7 が一般サーバより
安全になるとは思えないんだよねえ。
この先変わるのかな。

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

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

146 :未承諾広告※ ◆BAILA6C886n4 :2011/01/18(火) 23:58:13 発信元:219.117.239.35 0
どれもまんどくさそうねぇ。。。

147 :名無しさん@お腹いっぱい。:2011/01/21(金) 02:04:14 発信元:114.155.141.253 0
やっぱりログファイル丸ごと負荷の少ない時間に暗号化するのが現実的なのかな
OSの機能で暗号化するとおそらくハッキングに対しては無力だし、書き込みのたびにログを暗号化すると負荷がどれ位掛かるのか判らない

148 :名無しさん@お腹いっぱい。:2011/01/22(土) 06:47:01 発信元:118.9.218.132 0
>>147
書き込みログの形式にもよるけどな

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

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

149 :名無しさん@お腹いっぱい。:2011/01/23(日) 03:41:12 発信元:210.135.98.43 (70297) P
(A)
投稿時には、1294604913_20110123.log のようなスレ・日単位で生ログファイルを作成。
暗号化時には、ファイルごと暗号化し、生ログを削除。

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


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

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

150 : ◆A/T2/75/82 :2011/02/05(土) 16:37:45 発信元:114.160.23.32 0
みんなの意見をいろいろ考えてみた。
まずは一歩踏み出してみることにしよう。

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


151 :名無しさん@お腹いっぱい。:2011/02/05(土) 17:34:58 発信元:67.227.82.48 0
拡張子を.logにしない
おとりファイルを作る

152 : ◆A/T2/75/82 :2011/02/05(土) 18:43:25 発信元:114.160.23.32 0
myanmar yangon sakhalin @dso が自分でPerlのモジュールを入れられないなぁ
qb5 もかぁ・・・

こりゃちと面倒だなぁ

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

153 : ◆A/T2/75/82 :2011/02/05(土) 19:10:21 発信元:114.160.23.32 0
toki , hibari , yuzuru のPerlを再インストールしなきゃならないらしい。
そのときはサーバ止める予定。

154 : ◆A/T2/75/82 :2011/02/05(土) 19:29:13 発信元:114.160.23.32 0
ふむふむ、こうやればいいのか

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

155 :名無しさん@お腹いっぱい。:2011/02/05(土) 22:09:58 発信元:220.107.3.28 0
これを実施したことによって影響でそうなのものは

Boo
Boo2BBQ
こらこら

この辺りかな

156 :名無しさん@お腹いっぱい。:2011/02/05(土) 22:11:48 発信元:124.103.116.107 0
Rockは?

157 :名無しさん@お腹いっぱい。:2011/02/05(土) 22:12:17 発信元:220.107.3.28 0
そうだった
ROCK周りもダメになるな

158 :名無しさん@お腹いっぱい。:2011/02/05(土) 22:14:26 発信元:114.171.38.174 0
BBM
p2
とかは?

159 : ◆SGypsyBBQM :2011/02/05(土) 22:40:05 発信元:211.1.219.232 0 ?BRZ(10081)
書き込みログを利用しているものが影響するので、
BBM,p2 は問題ないです。 (共に登録するだけ)

160 : ◆A/T2/75/82 :2011/02/05(土) 23:17:26 発信元:114.160.23.32 0
この改造により修正したもの

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

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

161 : ◆A/T2/75/82 :2011/02/05(土) 23:22:55 発信元:114.160.23.32 0
>>160 くばった

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

162 : ◆A/T2/75/82 :2011/02/05(土) 23:30:35 発信元:114.160.23.32 0
みごとに、ここdsoは500になっちゃった
元に戻した @dso

163 :名無しさん@お腹いっぱい。:2011/02/05(土) 23:31:27 発信元:124.99.205.150 0
改造前と、改造後の報告は、混同しちゃだめ?
改造前のログは掘れる?


164 :名無しさん@お腹いっぱい。:2011/02/05(土) 23:32:22 発信元:124.99.205.150 0
qb5もエラー吐いてるな

165 : ◆A/T2/75/82 :2011/02/05(土) 23:33:41 発信元:114.160.23.32 0
もとにもどした @qb5

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

166 :garnet ★:2011/02/05(土) 23:43:30 発信元:??? 0
がっくしでは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'));
   }
  }
 }
}


167 :名無しさん@お腹いっぱい。:2011/02/05(土) 23:46:38 発信元:180.0.150.47 0
libプラグマとかどうでしょ
use lib "/path/to/library";
あとopenはopen(fh, mode, filename);

168 : ◆A/T2/75/82 :2011/02/05(土) 23:48:22 発信元:114.160.23.32 0
てすと用のプログラムではうまく行ったのよ
たぶん speedy_cgi のせいだと思うのだ。

169 : ◆A/T2/75/82 :2011/02/05(土) 23:55:48 発信元:114.160.23.32 0
pinkにモジュール入れてもらうの忘れてた、
ということでpinkもbbs.cgi元にもどしましたー

170 :garnet ★:2011/02/05(土) 23:55:59 発信元:??? 0
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));
 }
}

171 :garnet ★:2011/02/05(土) 23:58:33 発信元:??? 0
って、向こうでSunOSさんがやってました。。。orz

172 : ◆A/T2/75/82 :2011/02/05(土) 23:59:06 発信元:114.160.23.32 0
へへへっ

173 : ◆A/T2/75/82 :2011/02/05(土) 23:59:51 発信元:114.160.23.32 0
やってもらっちゃった。
そしてdsoでうまく動いた。

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

174 : ◆A/T2/75/82 :2011/02/06(日) 00:03:50 発信元:114.160.23.32 0
配った。

175 :名無しさん@お腹いっぱい。:2011/02/06(日) 07:26:14 発信元:61.202.71.102 0
現在、規制中でもfusianasanすれば書ける板に
fusianasanしても書けなくなっているようです

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

176 :garnet ★:2011/02/06(日) 07:56:58 発信元:??? 0
>175
携帯のcidrやってるので、ついでに見てみますー。

177 : ◆SGypsyBBQM :2011/02/06(日) 08:12:32 発信元:211.1.219.232 0 ?BRZ(10081)
規制関係ですね。

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

178 : ◆SGypsyBBQM :2011/02/06(日) 08:19:21 発信元:211.1.219.232 0 ?BRZ(10081)
しまった、、。 ●のままだ。
>>177 はなしで。

179 :garnet ★:2011/02/06(日) 08:20:57 発信元:??? 0
access板をスルー処理が効いてなかったところがあったので、
スルーするようにコメントアウトしました。
現時点でoperateとaccessでfusianasanしたら書けるはずです。

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

180 :名無しさん@お腹いっぱい。:2011/02/06(日) 08:22:44 発信元:61.202.71.102 0
>>179
対応、乙でした

181 :garnet ★:2011/02/06(日) 08:23:41 発信元:??? 0
s/accsess/accuse/g で。。。
(素で間違えた

182 :名無しさん@お腹いっぱい。:2011/02/06(日) 08:30:53 発信元:210.135.98.43 (618493) P
>>179
対応をありがとうございました。書き込みできるようになったようです。
http://yuzuru.2ch.net/test/read.cgi/accuse/1294318630/721

183 :未承諾広告※ ◆BAILA6C886n4 :2011/02/06(日) 22:12:50 発信元:219.117.239.35 0 ?PLT(23505)
cobra2245にもCrypt-CBC-2.30は入っていなかったのであった♪
なので、hato鯖は未対応中♪

184 : ◆A/T2/75/82 :2011/02/06(日) 22:13:50 発信元:114.160.23.32 0
よろしくお願いしまーす

185 :名無しさん@お腹いっぱい。:2011/02/06(日) 22:15:46 発信元:61.89.15.136 0
さっきまで一瞬書き込みからIPアドレス見ようと思えば見れたわけか・・・w

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

186 : ◆A/T2/75/82 :2011/02/06(日) 22:17:44 発信元:114.160.23.32 0
pinkもCBCはいっていませーん
明日入れてもらう予定ではあります

187 :garnet ★:2011/02/06(日) 22:24:16 発信元:??? 0
qb7と同じモジュールが入るのかしら?
use Crypt::Blowfish が有効なら喜び組(qb7では入ってるです)。

188 :未承諾広告※ ◆bbq.muteQGCV :2011/02/06(日) 22:28:08 発信元:219.117.239.35 0 ?PLT(23505)
@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貰っちゃいなっていうのは禁止♪

189 : ◆A/T2/75/82 :2011/02/06(日) 22:28:36 発信元:114.160.23.32 0
よくわからんけど、

190 : ◆A/T2/75/82 :2011/02/06(日) 22:29:25 発信元:114.160.23.32 0
ぼうはつした。

思想は・・・

191 : ◆A/T2/75/82 :2011/02/06(日) 22:34:37 発信元:114.160.23.32 0
作成の思想は、各サーバにログフィルをあさって
ipアドレスを探してくるスクリプトがある。
boo.2ch.netはそれぞれのサーバにそのipアドレスを問い合わせる。

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

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

192 :未承諾広告※ ◆bbq.muteQGCV :2011/02/06(日) 22:48:28 発信元:219.117.239.35 0 ?PLT(23505)
あ、今頃了解しました。早とちり(汗)
・・・のでbooのhato鯖対応復帰♪

193 : ◆A/T2/75/82 :2011/02/07(月) 17:22:01 発信元:114.160.23.32 0
>>192
hack72.2h.netを作ろうとしているので
新しい「串」が見つかったら呼んで欲しいのです。

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

194 :今日も雲孤 ◆bKaGbR8Ka. :2011/05/24(火) 02:25:22.40 発信元:118.3.231.160 0

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

195 :名無しさん@お腹いっぱい。:2011/05/26(木) 07:11:36.20 発信元:124.103.41.137 0
もともと海外だろ

67 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)