ふぅ
ちょっと出かけてきました。
アレな話をひととおりして、そして出た某Documentの邦訳話。
ぼちぼちやるかなー。
Subversion耐久試験(w
ふとしたことから、以下のような感じで耐久試験を試みる。
- まずは1個のファイル(a.txt)を新規リポジトリにimport
svn import . http://www.example.net/svn
- 次に、リポジトリからチェックアウト
svn co http://www.example.net/svn
- 以下のようなスクリプトを実行
やってることはすごく単純で
while true
do
echo a >> a.txt
svn ci -m `date +%D%H%M%S`
done
-
- a.txtを変更
- コミット時のメッセージを含めてコミット
というもの。
最初に動かした時は、rev 20482までコミット成功したが、その後がダメだった。
何かがデッドロックしてるような感じだったがよくわからん…。
もじら組、namazu project、Rubyの各サーバクラック
Slashdot Japanでもすでに既報(もじら組、namazu)(Ruby)、5/29のMatzにっきには、少し詳しい状況が記されている。
Rubyのサーバクラックからの妄想(1)
クラックされてしまったこと自体は非常に気の毒だが、クラッカーの意図はともかく
- バックドアポートへのアクセスはフィルタリングされていた
というのは非常にポイントが高い。
フィルタのログが残っていれば、そこに残っているIPアドレスからの追跡が可能になる。もっともこれにも条件があって、
- フィルタは他のルータなどの機器で実施されている
- ログはクラックされたマシンとは別のものに取得されている
というあたりだが。
chroot環境のみ荒らされたとのことだが、改ざんされていないことが明らかでない以上は、クラックされたマシンに残っている情報のみを頼りにするのは危険だろう。
もちろん、
- そこまでに踏み台にされているマシンがない
という前提だが…。
Rubyのサーバクラックからの妄想(3)
もちろん、注意に注意を重ねていても、おきるものはおきる…。
Matzにっきには、
- 「不正アクセス禁止法」による立件
が示唆されていたが、この件に関しては(というかこの件こそ)そのほかにも
- 「電子計算機損壊等業務妨害」による立件
も可能なんじゃないかと思う。オレは弁護士でもなんでもないんで、本職な方々には「このあたりの解釈は甘い」と言われるかもしれないけど…。
今はじめて知ったけど、威力業務妨害より罪が重いのね。>電子計算機損壊等業務妨害*1。
「アップデートを〜」のくだりはあるものの、昨今の事例を鑑みるに、不正アクセスそのものでしょう。これは…。
で、不正アクセス行為の禁止等に関する法律と照らし合わせると、今回の内容は「第三条第一項の規定に違反した者」となることから、1年以下の懲役か50万円以下の罰金か。
*1:「威力〜」は「3年以下の懲役又は50万円以下の罰金」、「電子計算機等〜」は「5年以下の懲役又は100万円以下の罰金」
Rubyのサーバクラックからの妄想(4)
やっぱり、「アップデートをさぼっていた」というくだりが非常に気になる今日この頃。でも、
- 何をして(何をしないで)クラックの原因となるセキュリティホールをFIXできてない状態になったかを把握し
- そしてそれによる非(?)を素直に認める
あたりはさすがです。
これを機に(別にこれを機にしなくてもいいけど)、個人/法人/団体を問わず、外に見えるようにしているサーバ類についてはセキュリティチェックしたほうがいいんじゃねぇか…?とか思います。
メンテナンスが行き届いてると思われていたマシンが次々とクラックされる状況だとなぁ…。
ウチでの状況
ざっとふだんの動きをチェックしてみました。あくまでサーバもしくはそれに類したマシンのみの話ですが。
- apt-get update;apt-get upgrade securityを1日1回は実行
- Advisoryが流れたタイミングでapt-get update;apt-get upgrade securityを実行
というあたりですかね。メンテナンスが面倒なんで、クリティカルなものをDebianにしたというのもあるんですが、快適。あとは、
- 不要なポートは開けず、あいてるポートで動かしてるサーバプログラムのセキュリティ情報をチェックする
- 外部にヘタにさらすようなことはしない
というあたりかなぁ。
サービスポートを変えるのは、ピンポイントでクラック候補にされるような場合はあまり有効ではないかと…。>誰となく
Subversion耐久試験その後
現在、3つのクライアントで3つの別々のファイルに対して変更→コミットという耐久試験をやってます。
rev 13000は超えました。
Subversion耐久試験その後(2)
rev 50000を超えてなおコミット中です。
Subversion耐久試験その後(3)
rev 80000overでいったんとめました(w。
どうせならば、ということで、そこまでに作成されたリポジトリをダンプして*1おき、新たなリポジトリを作ってloadしてみる。感じとしては
- リポジトリをダンプして圧縮
svnadmin dump moge | gzip > moge.dump.gz
- リポジトリを新規作成
svnadmin create moge_fsfs --fs-type fsfs
- 圧縮されたリポジトリを展開
gzip -dc moge.dump.gz | svnadmin load moge_fsfs
という感じっすね。
*1:多分ダンプ結果は2GBくらい行ってるけど、圧縮してるのでよくわからないです(w
なぜwakatono?
某所で聞かれたのもあり、簡単に…。
当時バイトしてた先の社長(このお方)に、「ペンネームみたいなもんを自分につけようとしてるんですがー」と相談したところ、
- 「もう『との』しかないだろう、それは」
というリアクションが(笑)。
その直前に、日光江戸村に行ってとのさま写真を撮ってきたちうのもあり、まずはクリア(クリア?)。
当時、出入りしてたNifty Serveのフォーラムに同名がいないだろうなぁ〜とチェックしたら…いました。
というわけで、「わか」をつけて、「わかとの」になったわけです*1。
プライベート色が強いマシンのアカウントなどは、これで作っていますが、そこからwakatonoになり、そっちを多く使うようになりました〜*2。