メモ@inudaisho

君見ずや出版 / 興味次第の調べ物置き場

実際に岡崎市中央図書館の新着情報を全件取得してみた

librahack

(8/25追記とかやんのめんどくさくなってきたのでそのうちこの関係の記事全部ここにまとめてかきなおす。まぁこんな反応のない記事書きなおしたって誰も気にしないだろうからひどめに書きなおしとくわwww)

librahack氏のスクリプトの検証
（2年ほど仕事をしていない無職が偉そうにlibrahack事件を語るためにまず）
実際に岡崎市立中央図書館の新着情報を全件舐めてみた。

  • 逐次実行でタイムウェイトなし
  • 図書館の業務時間外にやる
  • 詳細情報を取得するが、DB処理なんてめんどくさいことしない
  • librahack氏とおなじphp
1回目 2241件
開始 2010/06/24 23:19:39
終了 2010/06/25 00:22:40
実行時間 : 3781366.542ms 約63分
反応が返ってこなかったリクエストが8件

2回目 2241件
開始 2010/06/25 06:27:32
終了 2010/06/25 07:18:29
取得 2231件 失敗 10件
実行時間 : 3056825.37ms 約51分
反応が返ってこなかったリクエストが10件

データ:http://www.megaupload.com/?d=G65MKVB6

反応が返らず握りっぱなしだったリクエストは見切るまで120秒あまりかかっています*1。それをはぶいてしまうと、

  • 一回目 3781 - 120 * 8 = 2821秒(ç´„47分) 2821/(2241-8)= 1.263秒
  • 二回目 3057 - 120 * 10 = 1857秒(ç´„31分) 2821/(2241-10)=0.832秒

3月4月頃は利用率がすくなかったと仮定し、そのころは2回目（朝）並みのアクセスだったと好意的にみても、一回の処理に0.8秒くらいかかっています。これにはローカルのDBに書きこむ時間など入ってないので、実際のlibrahack氏の一件あたりの処理にはもうほんのすこし時間がかかっていたことでしょう。
librahack氏は

#自分側サーバの負荷限定：30分間ぐらいで終わるように。約2,000リクエスト / 1,800秒 = 約1リクエスト/秒
# 単位時間あたりリクエスト数を限定：リクエストとリクエストとの間に適当な時間間隔（ウエイト）を作る

と称していますが、ウェイトおかずにループで処理をブンブン回してもそれくらいかかることになります。弁解のために言っただけのことで、本当は入れてないんじゃないでしょうか。
もしlibrahack氏がその言葉通りのことをphpで実装していたのなら、

usleep(900000 - $実行時間)

とかになるんでしょう。

しかし、librahack氏はweb屋らしいんですが、web屋なら、でかいテーブルを何個もくっつけたり妙に小細工したページをつくったためにページの表示に時間がかかり、8秒ルールとか6秒ルールとか3秒ルールなんかに汗したような経験があるはずです。librahack氏が日曜プログラマとかphp覚えたての高校生なら、自分も警察ひどいMDISうんこ連呼列に加わっていたとおもいますが、librahack氏がプロにしてはやってる事がお粗末すぎるので、MDISになにか恨みでもあってわざとギリギリのことをして嫌がらせでもしたんじゃないかと思ってしまいます。librahack氏が書いている内容をそのまま受けとれば、単純に不注意なWeb屋だったということになります。

設計のまずさも気になります。りぶらの新着情報が一覧形式で日付順にならんでいないのはそのとおりですが、新着一覧は分類別に10ページなので、10回舐めたら一意のコード(toscode)が取れます。あとはローカルのDBと照合し、新規だけあらためて詳細情報をとってくればよいだけです。たしかにそれだと予約情報はとれないんですが、読みたくもない本の予約情報まで全件取得してどうするんでしょうか。しかもリアルタイムではありません。

(ここに追加するべきことなので追記：詳細ページには予約情報があるので、書誌データのような静的データ（過去のDBの構造をそのまま継承したりしてんじゃないのかな）と予約情報貸し出し情報の動的データをおさめたテーブルは別になっている可能性があり、さらに、予約件数をどういうふうに計算して保持しているのかわからない。静的データ100万件、動的データ100万件、予約件数の背後には図書館の利用者n万件。そんなに速くない原因はここじゃないか。）
(追記：ここで推測したDBのテーブル設計がウンコだったのではないかというのよりもcloseし忘れらしい。)

(もひとつ追記：要するに公開されている情報が少ないので誰も真相がわからんわけです。librahack氏の情報も、自分に都合のいいことしか書いてない。実際のとこどういう動きをするものを書いて、どう運用していたのかが見えてこない。上で調べたのは一回一秒とかいってるけどほんまかということ。あと意味がわからんのは三月と四月でphpを鯖からノートでの運用に変えたこと。どれだけ図書館側も鯖をどれだけいじってたのかもわからん。)

MDISの小細工
MDISも事件後なにか改修したのでしょうか。その前がわからないのでなんともいえませんが、現状小細工が数個あります。

  1. 新着の分類別一覧ページのファイル名に0201u.aspのようにアルファベットが一文字挿入され、なにかのタイミング（たぶん日替わり）でかわるようになっている。
  2. 一覧ページから詳細ページのリンクがJavascript（プ *2
  3. 詳細ページはある条件を加えてアクセスしないと弾くようになっている*3。

librahack氏によると、以前は詳細ページへのリンクはべた書きだったそうなので、そこは改修点の一つでしょう。librahack氏は三月中新着取得スクリプトを鯖上のcronで実行させ、四月以降は手持ちのノートパソコンのEclipseから実行させたとのことで、なぜそんなことをしていたのか意味がわからなかったのですが、もしひとつめの対策が4月からほどこされていたのなら、librahack氏お粗末説を補強します。librahack氏がお粗末なために、分類別一覧ページの上のページからファイル名を取得するというようなことをせず、スクリプト内にベタ書きしていたため毎日いちいち書きなおしていたとすれば、Eclipseからわざわざ実行させていたのもうなづけます。
（追記：もし故意がどうこうというなら三月と四月の違いのあたりでしょう。）


あと、二回の試行のなかで、合計18回リクエストを握ったまま応答を返さないことがありました*4。なにか内部エラーがあったときには応答を返さないように改修したのかもしれません。そのおかげで、今回二回ためしてみても落ちなかったのかもしれません。
もしこれが改修点のひとつだとすると、これだけでとりあえずしのげていたかもしれません。こちらからは内部のことがわからないので、ひょっとしたら外部公開用の鯖を新たに立てたりしているかもしれませんが、それだと費用が発生するのでしてないんでしょうね。きっと。MDISをdisりたい人は、アクセスの結果を解析してみるといいんじゃないでしょうか*5。
MDISが被害届を出す前にできることはいっぱいあったというのは他の人が言っているしこれからも書く人がいるでしょうから、そちらに譲ります。内部矛盾をすべてlibrahack氏におしつけたと疑われてもしかたないでしょう。警察についても、いきなり逮捕はどうかとおもいますが、このへんは印象で言うだけになるので、他の人が言うべきことでしょう。

とにかくこんなしょぼいDOS攻撃の先例をつくったlibrahack氏とMDISと警察のお粗末さに、ネットが山間僻地にまで普及したこの現代日本でも、まだまだIT未開地が広がっていることに思いをいたした次第でした。

ちなみにうちの田舎にはまだADSL来てないです。

(追記）：asahi.com（朝日新聞社）：図書館ＨＰ閲覧不能、サイバー攻撃の容疑者逮捕、だが… - 社会
プログラム自体に違法性なんかあるわけなかろうに。

*1:file_get_contentsでやったんでなんかエラーだったことしかわからないのですが、どいつもこいつも120秒かかっていたのでそうだと推測しました。ちがってたら指摘してください

*2:6/27現在では直リンクにもどっている

*3: http://twitter.com/bulkneets/status/17102720527 マジぱねぇっすww(6/27) http://twitter.com/bulkneets/status/17758823817 今はそれなくなったらしい(7/5)

*4:注1参照のこと

*5:それぞれの処理の実行にかかった時間しかわかりません