X
トップページ⇒開発室
202コメント86KB
書き込みログのIP&リモホを見た目わからなくする方法を考えよう
0001偽FOX ★
垢版 |
NGNG
サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね、

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

誰か方法考えてちょ
0040名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>39
なるほど。

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

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

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

>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない？
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない（掘って復号した後に除く）。
0045名無しさん＠お腹いっぱい。
垢版 |
NGNG
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

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

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

■ 復号鍵を作業者が各自で保有する場合
・作業スクリプトで、作業者を認証管理した上で、復号鍵を作業スクリプトに送信する。
・掲示板サーバや復号作業サーバで侵入や漏洩が起きても、暗号は安全。
・同じ復号鍵を、作業者全員が保有する。
・各作業者の情報管理が頼り。
└> ウェブサーバと個人PC、どちらが安全か。
・権限抹消された作業者から復号鍵を取りあげることができない。
├> 定期的な鍵の変更が必要か。
└> 作業スクリプトの認証で足りるか。
0047名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。
0048名無しさん＠お腹いっぱい。
垢版 |
NGNG
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。
0050名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう？

とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。
0051名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>34って独立した案なの？どれかの補足？

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

IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。
0052名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵（これは非対称鍵）で暗号化して、一緒に記録。

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

つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。
0053名無しさん＠お腹いっぱい。
垢版 |
NGNG
非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。

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

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

その程度で十分なんじゃないかなーと。
0054名無しさん＠お腹いっぱい。
垢版 |
NGNG
書き込みログ見れる人は
・２ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)

>>52
ハッシュでxor取ってそのあと煮るなり焼くなりすれば
同じIPからの投稿でも書き込み内容によって暗号化されたものは変わってくる
0055名無しさん＠お腹いっぱい。
垢版 |
NGNG
あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。
0056名無しさん＠お腹いっぱい。
垢版 |
NGNG
自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。

ランダムデータを付与して、普通に非対称な鍵で暗号化する場合は>>45の方法その1にあたる。
あとは復号化鍵をどう扱うか、だが・・・
0057名無しさん＠お腹いっぱい。
垢版 |
NGNG
非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が３桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

ただ、Logの暗号化をbbs.cgiでやろうとするとやっかいな点が１つ。
複数起動するbbs.cgiがそれぞれ異なる鍵（乱数）でLogを暗号化すると、
鍵の扱いがとても大変になる可能性があります。
Logを暗号化して保存するデーモンのようなものを作る必要があるかも。
0061名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が３桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

だから、とりあえずは生ログか、簡易な共通鍵暗号化しておいて、負荷の低い時間帯（朝５時～９時くらい？）
に一気に暗号化すればよい。
0062名無しさん＠お腹いっぱい。
垢版 |
NGNG
「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

ログ堀するんだから最低限 書き込み日時・IDは暗号化無しで格納する必要がある
この板は発信元とあるけどログには他の板で使われてるIDが書き込まれてる
0063名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>62
> 「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

それ、お前だけだｗ

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

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

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

「同じ鍵で暗号化された、平文と暗号文の組み合わせを無数に入手しても、
　鍵の長さとアルゴリズムから考えて、復号化鍵を予測するのは不可能である」というならいいけど。
0065名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>63
暗号化して分からなくすると言う意味であって
暗号化の元にするとは書いて無い

>57なんてIP・リモホだけじゃなくログ全体を暗号化しようとしてるじゃないか
0066名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>64
> で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの？

されない（一般的には）

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

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




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

それを避けるためには、暗号前の文章を予測不能な平文にしておく必要がある。
それがここでのメインテーマ（昨日来）。
0067名無しさん＠お腹いっぱい。
垢版 |
NGNG
これで同じ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欄に書き出す

問題点はこのスレの住人なら暗号化方法が分かってしまってる
0069名無しさん＠お腹いっぱい。
垢版 |
NGNG
いわゆるプロバイダ責任制限法では規定は無いそうだけど、一般的には90日程度
は保存して欲しいと言う要請はあるらしい。

だから最低3ヶ月分はどこでも持ってるんだろうな。
0071名無しさん＠お腹いっぱい。
垢版 |
NGNG
どっかしらに妥協点はおくことになるんだけど、
侵入が前提の安全策を考えるってとき、ソース見りゃ分かる程度の
暗号だと、簡単すぎないかな。
ソースは最初に狙われるでしょ。
0072名無しさん＠お腹いっぱい。
垢版 |
NGNG
軽い時間帯にまとめて暗号化するとすると、
その時までの最大24時間くらいは、
軽い暗号をかけるか、
生を許容するか。
0073名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>71
ハッキングした人がどれだけのスキルがあるかだよ

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

大抵の場合
１つのファイル(URL)流出 -> ファイル解析 -> 他のファイル
こんな流れ
最初から全てのファイルがある場所が分かる人なんていない
0075名無しさん＠お腹いっぱい。
垢版 |
NGNG
■ 暗号方式
(A) 難読化
　・ソースを見られると解読
　・軽い
(B) 共通鍵暗号
　・暗号化と復号が同じ鍵なので、鍵を保存できない
　　└> 常駐プロセスがメモリ上で鍵作成、暗号化処理
　　　├> それでも鍵は確保する必要
　　　└> メモリの機密性
　・比較的軽い
(C) 非対称鍵暗号
　・暗号化と復号が別の鍵なので、暗号化鍵の扱いは杜撰でいい
　・比較的重い

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

■ 復号鍵の保存場所
(A) 各サーバ内に生
　・侵入時にはログと同時に漏洩
(B) 各サーバ内に非対称鍵暗号化
　・その復号鍵の保存場所で再帰
(C) 拠点サーバに保存
　・拠点サーバの侵入で漏洩
(D) 作業者が各自で保有
　・個人環境の信頼性は
　・作業のたびに送信
　・権限抹消された作業者から復号鍵を取りあげることができない
　　├> 鍵は適宜変わる
　　├> 作業時の認証はある
　　└> (a) 復号鍵は作業者別に暗号化して鯖保存、この復号鍵を持つ (b) 放置
0077名無しさん＠お腹いっぱい。
垢版 |
NGNG
そもそも個人的には、2ch程度にログ暗号化なんていらないだろ
くらいに思ってるけど、それでも暗号化の必要があるとするなら、
B-Ba-C かな。

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

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

拠点サーバは各掲示板サーバより少し気を使う。
鯖パスはとにかく長くとか、qb6/7みたいな掲示板との混在はやめるとか、
全面basic認証とか。
0078名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>75
■暗号化時期については祭りが起きた時などに暗号化のピーク負荷が跳ね上がる気がします
あとサーバー乗っ取られたという想定なので
■ 暗号化時期は(A) 逐次しかないんじゃないでしょうか
同じく■ 復号鍵の保存場所についても（A)(B)は選択肢から外れ
消去法でC-A-CまたはC-A-D
0080名無しさん＠お腹いっぱい。
垢版 |
NGNG
まあそうなんだけど、1日くらいいいかな、って。

ところで、非対称鍵は重いから鯖が軽い時にまとめて、という話(>>57-61)
だったのに、>>77では軽い時に共通鍵で、ということになっているのは、
まとめてやるなら鍵を常時持っておく必要がないから、そのとき限りの
共通鍵でいいやと思ったからなんだけど、でもどうせ軽い時間にやるし、
重い処理でも負荷がピークを超えることはないだろうから、鍵1つで扱いが
楽な非対称鍵でいいか、とふりだしに戻って思い直してみたり。
0081名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>80
非対称鍵を採用すれば、片側は鍵自体も見ることを不可能にしてる製品も既に売られている。

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

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

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

すればかなりセキュア

問題は、通常

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

と称するので、「公開鍵」って聞いた途端に心理的に緩んじゃうんだよね。「まーバレてもいいか」的なｗ
ここがネック。
0083名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>82
そんな前提（「絶対的必須」条件）ねーよ。

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

でもおｋ
そりゃ、perlに実装できりゃいろいろ選択肢／応用増えるが、要件（要求仕様）ではない。
0086名無しさん＠お腹いっぱい。
垢版 |
NGNG
どうせならさ
IP・リモホは別鯖で保存すればいいんじゃね？

そうすれば鯖別にログ内にIP保存して暗号化なんてことしないで済む
0088名無しさん＠お腹いっぱい。
垢版 |
NGNG
新鮮なものが漏れてたら全然意味が無いわけでやるならlogbufferの段階でやるべき。
今のlogbufferって何で書いてあるか良く知らないけど。
0091名無しさん＠お腹いっぱい。
垢版 |
NGNG
C言語で書かれてるのをperlにするのは難しくない
perlで書かれてるものをC言語にするのは難しい

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

>>90
C言語で書くと書き込んでるのは>87
0092名無しさん＠お腹いっぱい。
垢版 |
NGNG
えーと、
過去にbbs.cgiをCで書くような提案があったけど
却下された経緯がある

ひ（ｒｙがソースよめない(弄れない?)から なんて理由だった気がする
0095名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>66
> 暗号前の文章を予測不能な平文にしておく必要がある。
「投稿番号と投降者名とメール欄と書き込み日時+IPアドレス」ではだめかしら？
投稿番号はなくてもいいと思うけど。
「板の名前・投稿日時・IPアドレス」だったら板の名前を工夫すれば文字数も揃えられる気がするけど・・
0097名無しさん＠お腹いっぱい。
垢版 |
NGNG
read.cgi、offlaw.cgi、anydat.so、bbsd

>>95
本文等はスレ上に出ちゃってるというわけで、ランダムデータを混ぜようってな
話になっているわけだね。
暗号化が、投稿1件ずつか、ファイルごとか、というような部分でも事情は
違ってくるけど。
0101名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>97
それと正規の手順以外で複合化しようとする輩に対抗するために
IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・
0102名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>101
> IPアドレス以外のデータを付与して文字数を大幅に増やすのはそれだけで複合化されにくくするメリットがあるような・・

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

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

を

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

となる。だがしかし、

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

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

総合すると、時刻を seeds にして→超簡単なアルゴリズムによる高速化乱数生成が吉。
0103名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>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があればどうとでもなる
0104名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>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ビット程度ばらける乱数をインクルードしとけば生きてる間に作表はできまい。
0105名無しさん＠お腹いっぱい。
垢版 |
NGNG
この論点で２進化は意味ないか。

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

BASE64にしても桁数大差ないなｗ
0110名無しさん＠お腹いっぱい。
垢版 |
NGNG
スレの流れが狐さんが欲するものとだんだん離れていってる気がする

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

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

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


「あとでまとめて暗号化～」「Cで～」なんて議論だったらするだけ無駄になるから
しない方がいいよ
0111名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>110
そりゃ、>75のような技術的に可能な事を上げていくだけの人がいるからな

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

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

IP・リモホだけじゃなくUAも暗号化した方がいいかも (for p2.2ch.bet向け)
0112偽FOX ★
垢版 |
NGNG
bbs.cgiはPealですし、
0114名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>112
peal

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

合ってるような間違ってるような・・・ｗｗｗ
0115名無しさん＠お腹いっぱい。
垢版 |
NGNG
確定事項
・perl内だけで処理可能な物
・ログ書き込みの時に暗号化する (ログ書き込み以後に暗号化はしない)

狐さんの書いて無いこと
暗号化後の容量 (IPアドレスなら最大15Byteだけど暗号化後何Byteまで膨れ上がらせていいのか？)
追加インストール(perlのあれ)していいか？
0118偽FOX ★
垢版 |
NGNG
直接掻いています
apacheのログとは別のものです
いわゆる投稿ログです
0123未承諾広告※ ◆BAILA6C886n4
垢版 |
NGNG
鯖のアカウントを取られたらどうしようもないけれど、ディレクトリが見えちゃった（照）でも良ければ。。。

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

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

♯漏れたときにはまたその時に考えようって事で♪
0124名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>118
上の人が書いてるみたいに、「別処理じゃダメ」「Cで書いたコマンドだと使えない」って本当なの？

cron の設定とか狐さんできないの？
0126名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>125
１）そもそも　cron だから１日１回なんて決まりないし

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

３）むしろ、「負荷」考えたら、暗号化時間はずらした方が吉。リアルタイムにこだわって、鯖負荷低減の
　ために、暗号強度下げるのは本末転倒。全ログ解読されかねない。
0127名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>123
想定してるのは今回のハッキングと同様の事 (bbs.cgiとかの流出)
なんで、http経由を制限しても無意味

>>124
しつこいぞ

そんなにやりたっかたら自鯖でやってろ
0128名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>126
スレタイを一億と２千万回読み直せ

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


それに芋掘りとかbooの方から流出したらIP丸出しだからいくら暗号化強化しても無意味
0129名無しさん＠お腹いっぱい。
垢版 |
NGNG
やれやれ。結局、「cron じゃダメ」だの「Cだと採用されない」とか連呼してるのは能力の低い馬鹿１名だけか。
FOX★もこの馬鹿には同調してないし。


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

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

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

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

”perl連呼馬鹿” は無視（透明あぼ～ん）して、この案をベースに意見クレクレ
0130名無しさん＠お腹いっぱい。
垢版 |
NGNG
> ・したがって、鯖負荷の低い時間帯にまとめて処理

ここだな。問題は。

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

UNIXではどうやるんだたけ？
0131名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>129
あなたにも同調されて無いですが？

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

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

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

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

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

あなたもその馬鹿と一緒ですよ。
0132名無しさん＠お腹いっぱい。
垢版 |
NGNG
ここでそういう争いをしない方がいいよ。
夜勤さんはそういう騒動があるスレを一切無視して前に進む人だって、この板の住人なら知ってるんじゃないの？
0133名無しさん＠お腹いっぱい。
垢版 |
NGNG
とりあえず乗っ取られても大丈夫な暗号化芋の話で
Perlのモジュールが足りないなら入れればいい

後の事はニュー速に入れてみてからでもいいのでは
Cで書くとか定期実行とか方法変えるとか
専門板だけ実装という手もあるし
0135名無しさん＠お腹いっぱい。
垢版 |
NGNG
と言うかよく考えたらこのスレの大前提である「書き込みログを見られない様に」って本当に必要なの？

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

簡単に実装出来てかつ負荷無く動作するんなら有った方が良いんだろうけど・・・
それともやはり匿名性は可能な限り確保したいのかな。それが2ちゃんねるの売りでもあるから
0139名無しさん＠お腹いっぱい。
垢版 |
NGNG
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)}
});
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況