2010年07月12日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・ robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100621S1][セキュリティ][プライバシー]次の記事 >> このエントリーをはてなブックマークに追加

岡崎図書館事件について その1[http://takagi-hiromitsu.jp/diary/20100710.html#p01] として、高木先生の日記で触れられている。
DoS等で業務妨害罪とされた過去の報道事例[http://takagi-hiromitsu.jp/diary/20100710.html#p02] がまとまっていて、今回のケースの 最初の報道[http://www.nantoka.com/~kei/diary/?20100526S2] で感じた違和感の正体が良く分かる。
最後に挙げられている、 山形の事件[http://yamagata-np.jp/news/200809/04/kj_2008090400060.php] については、同じ記事に行き当たって不思議に思っていたところ。
女は、短時間に大量のアクセス操作ができるコンピューターソフトを使ったとみられ、攻撃で同社のサーバーコンピューターは容量オーバーになり、機能が停止。復旧した後、女は再び攻撃を繰り返していた。調べに対し、容疑を認めているといい「HPの掲載内容に不満があった」などとする趣旨の供述をしているという。捜査当局は、刑事責任能力の有無について慎重に調べている。今年6月、県警生活環境課サイバー犯罪対策室に相談が寄せられた。
掲載内容への不満から掲示板への書き込みや、電話での苦情などのやり取りを経ているのではないかと想像したのだけれども、これが事実であれば、事前に、 HPの掲載内容に不満があって、 短時間に大量のアクセス操作ができるコンピューターソフトを使って、 攻撃をしていたということが、逮捕前に分かっていたという点が違うということになる。
刑事責任能力の有無について慎重に調べているという記述と、実名報道されていない点が、逆恨みというか、筋の通らない怨恨を伺わせるのだけれども、これはやや深読みしすぎかも知れない。
山形在住の方で、図書館等で当時の山形新聞にあたる等できる方がいないだろうか。

■ 関連記事

■2私が「iなんとか」を買わずにAndroidを買った3つの理由[Android][desire][携帯端末]<< 前の記事 このエントリーをはてなブックマークに追加

しばらく前に、 HTC DesireをGet[http://www.nantoka.com/~kei/diary/?20100604S1] したのだけど、その少し前までは、「最近流行だから、iPadなりiPhoneなりの携帯情報端末を持って、流行に追いつけるようにしないとなぁ」という程度のことを考えていた。
ただ、良く考えてみると、せっかく買ったからにはコードも書いてみたいし、より色々いじりたい。とすると、ソースが公開されている点。手持ちの環境でも開発できる点。マーケットの自由度が高い点。そういうところが魅力的に思えて、Androidに興味が湧いてきた。
だけれども、日本においてはまだまだiPhoneやiPadが主流で、周りにAndroid携帯を持っている人はいないばかりか、ソフトバンクショップに行っても「なんですかそれ」と言われる程度の認知度だ。
こんなものを買ってしまって良いのかと随分迷ったのだけど、いずれAndroidが主流になると信じてAndroidを選んだ。
理由は3つある。
1つ目。iなんとかを作るのは、Apple一社であり、Apple社の価格戦略、Apple社のデザインに乗った製品しか出荷されることはない。つまり多様な生態系は生まれえないということ。Androidは、安いのも高いのも、高級感のあるデザインもキッチュなデザインも各メーカーから多様性を持って供給されることになるに違いない。
2つ目。 山寨機[http://ja.wikipedia.org/wiki/%E5%B1%B1%E5%AF%A8%E6%89%8B%E6%A9%9F] メーカーの存在。偽物携帯ではなく、正真正銘本物のAndroid携帯を作り、そこに自由なカスタマイズを施して自社のオリジナル製品を作ることができる。彼らがこんな市場を放っておくだろうか。
3つ目。Appleによるコンテンツのコントロールの厳しさ。アプリやコンテンツを販売するのに、完成させた後に審査を受けなければならず、しかも発売後に取り消しを受けるなどというリスクを負いたくないアプリプロバイダやコンテンツプロバイダは多いはずだ。
といったところが、Android携帯を買ってしまった後ででっち上げた後付けの理由であるが、近い将来、「iなんとか携帯のガラパゴス化」という現象が必ず起こると私は確信している。 βのビデオデッキを、Digital8のムービーカムを、Hi-MDのプレーヤーを買った私が言うのだから間違いはない。

■ 関連記事

詳細はこの日の詳細から

2010年07月13日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1Sledgeを試してみる[WebApp][Perl][Sledge]次の記事 >> このエントリーをはてなブックマークに追加

ちょっとしたWebアプリを作ることにしたので、今日は Sledge[http://sl.edge.jp/] を試してみる予定。
前段階で、Portsをどこどことupdateして環境を整えるなど。

portupgrade大会:

しばらくさぼっていたので、大騒ぎしながらupgradeするなどした。

p5-Bundle-Sledge:

# portinstall p5-Bundle-Sledge
一発。すんごいお手軽。

mod_perl:

そうか。mod_perl2対応していないのか。うーん。いじれば動きそうだけど、後々が面倒になったらフレームワークに乗るお手軽さが半減するなぁ。

Catalyst:

にするかなぁ。ちょっと牛刀割鶏感があるんだよなぁ。

■ 関連記事

■2他のサイトのパスワードを聞き出すことを禁止できないものだろうか[セキュリティ][mashup]<< 前の記事 このエントリーをはてなブックマークに追加

「夢ふくらむプロジェクト事務局」なるところが、「株式会社 電通イーマーケティングワン」が登録したドメイン、YUME-FUKURAMU-PROJECT.JPを使って、 夢ふくらむプロジェクト[http://yume-fukuramu-project.jp/] という、Twitter連携企画をやっていることを知った。
夢ふくらむプロジェクトログイン画面
ユニクロのフィッシング詐欺風サイトに見る群集心理[http://www.nantoka.com/~kei/diary/?20100526S3] で書いたような嫌な予感がしたのだが、全くその通りで、Twitterの生のパスワードを入力させ、これをサーバに送信した上で、サーバ側がそのパスワードを使って、ユーザに成りかわって、Tweetを生成するという仕組みの様だ。
ユーザ名・パスワードの入力ユーザ名・パスワードの送信
ユニクロのフィッシング詐欺風サイトに見る群集心理[http://www.nantoka.com/~kei/diary/?20100526S3] でも書いたが、 この様なサービスが増えてしまうと、社会全体のフィッシング詐欺耐性が著しく低下する し、世の中 全てのサービスで全く関連の無いパスワードを設定している人ばかりでは無い から、Twitterのパスワードだけでなく、そこから検索で紐付くメールのパスワード、メールに保存していた各種通信販売サイト、クレジットカード、オンラインバンキング等のパスワードが芋づる的に知られてしまう人も出てくる恐れがある。
それだけ社会を危険にさらしてやるべきキャンペーンであるとはとても思えないし、百歩譲ってそれをやるならば、十分なリスクの説明も必要だろうし、結果に対して責任を負う覚悟も必要であろう。
例えばの話。デバッグ用に残っていたコードがあって、サーバのlogin-debug.txtファイルにユーザ名とパスワードの組が記録されていて、かつ、誰からも見える状態になっていたために、ユーザ名とパスワードが流出し、一部のユーザはそのパスワードを他のサービスにも使っていたため、メールが盗み読まれたり、オンラインストレージのプライベートな写真が流出したり、ネットショップで大量の買い物をされたりする様な被害が出た時に、その責任を負う覚悟があるだろうか。
一切の責任は負いません
そういう心配をすれば、とてもこういうサービスは作れないと思うのだが、責任を利用者に押し付けて、こういうサービスを作り出す人がやはりいるようだ。
それこそ、ガイドライン等で、他のサイトのパスワードを聞き出すことを禁止できないものだろうか。

7月15日追記[http://www.nantoka.com/~kei/diary/?20100715S1]:

素早く対応頂いたので追記した。

■ 関連記事

詳細はこの日の詳細から

2010年07月14日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・クロールとDoSの違いと業務妨害罪と[http://www.nantoka.com/~kei/diary/?20100624S1][電子自治体][DoS][セキュリティ] このエントリーをはてなブックマークに追加

6月24日の日記[http://www.nantoka.com/~kei/diary/20100624.html] に追記。
日記の最後の方で、
確認した限りでは、岡崎市立図書館だけが、 件の謎の挙動[http://www.nantoka.com/~kei/diary/?20100621S1#T201006211S1] を示すようだ。
と書いたのだが、他の図書館でも、一度タイムアウトすると、同じCookieを持ってアクセスすると応答がなくなるという同様の現象が発生するところが見つかった。
気づいたのはたまたまだったのだが、 岡崎市立図書館と同じ、MELILを採用している図書館のリストが、 日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] にあり、この中で検索ページが.aspになっているものでは同じ現象が発生する様で、発生条件もかなり緩く、
  1. 検索などでのタイムアウト発生
  2. 応答が遅かった場合のキャンセル
  3. 検索結果ページを閲覧していて、画面内の戻るボタン以外でページ遷移を行った場合
に、以降の応答がなくなるという症状が発生する様だ。
検索ページが.aspxになっているものでは、確認した範囲では発生を見ていないので、これは後に改修されたのだろう。
Cookieを削除してやればアクセスできるようになるから、1回程度確認しただけで即座にサーバが停止するということは無いことは確認したが、後述するように私は、 多数回にわたって繰り返せば、何らかの不具合が顕在化してサーバ停止につながるバグを抱えているのではないか と推測しているので、その推測を持っていながら繰り返すことは、それこそDoSとみなされる危険があるので、最低限の回数しか確認はしていない。
この挙動については、 岡崎市立図書館蔵書検索システムの謎[http://www.nantoka.com/~kei/diary/?20100621S1#T201006211S1] で書いたが、なぜこうなったかを、クライアント側でのtcpdumpでの観測からやや大胆に推察すれば、
  1. 「1クライアントからのリクエストを、同時に1つに制限する」というリクワイアメントがあって、Cookieでセッション管理をすることにした。
  2. 各ASP処理の最初で、Cookieに対して他のASP処理が「実行中」かどうかを調べる。「実行中」だったら、「実行終了」まで待つ。
  3. 実行中でなければ、そのCookieに対して「実行中」として処理を行う。
  4. 処理を完了したら、「実行終了」とする。
の様な構造になっていて、タイムアウトやクライアントからの切断等のエラーが発生したときに、エラー処理に何らかの不手際があって、4.の「実行終了」ができていないのでは無いかと推察される。 こうなると、2.が無限か恐らく相当に長いタイムアウトまで待ちに入ってしまう。
この作りは明らかにまずいし、そもそも最初のリクワイアメントが、単に負荷を考えたものならば分かるけれども、 全体が「同時に複数やられると困ったことになる」作りになっているために、それを防ぐためにこのリクワイアメントが出てきたのだとしたら、全体が相当にまずい *1 。 そうだとすると、 Cookieを食わないでアクセスしただけで、困ったことになる からだ *2 。 たいていのクローラはCookieを食わないから、つまりこれは、クロールされただけで困ったことになるということを意味している *3
インターネットに公開することを考えて作られたシステムであれば、最初からこんな設計にはしなかっただろうし *4つぶやいた[http://twitter.com/keikuma/status/16781256147] 様に、 汎用機端末→VB,Accessクラサバ→Webイントラと、実現手段が代替わりする間に、上位設計のやり直しをしないで来て、さらにこれを同じWebだと思ってインターネットにつないでしまったシステム という感じが激しくする。
だとすると、他のMELILを採用している図書館でも、定期的にダウンしたり、館内の検索端末から検索がしばらくできなくなったりという不具合が出ているのではないか。
もし、そうだとすれば、システムの欠陥をたまたま露呈させてしまったからと言って、逮捕される人が出るのは本当に気の毒であるし、そもそも逮捕者が出るのは許されることではない。

netcraftのuptime[http://uptime.netcraft.com/up/graph?mode_u=on&site=www.library.okazaki.aichi.jp&mode_w=off&avg_days=360&submit=Redisplay+Graph]:

netcraftによるuptimeグラフ
Netcraft[http://news.netcraft.com/] というところが、様々なサイトの連続稼働時間の調査を行っている。 定期的にサイトにアクセスをして、前回の起動からの日数 *5 をグラフ化しており、どの程度安定的にサーバが稼働しているのかを知る手がかりにすることができる。
Libra[http://www.libra.okazaki.aichi.jp/] のサーバもその調査対象にたまたま入っている。
残念ながら、今年の5月ごろからしか調査データが無いが、27回ほど計測して、その全てが「0日」という結果になっている。
この調査を信じればだが、そもそも毎日、再起動を行う運用になっているのかも知れない。

Cookieを食わないブラウザ:

世の中にはCookieを食わないブラウザもあるし、やたらとCookieは食べないことにしている人もいるのだけれども、そういう状況でアクセスするとどういう表示がされるのか確認してみた。
結果。何の表示も警告もなく使える。但し、例えば検索結果の一覧から詳細に移動して戻った時等に、検索結果を忘れてしまうという現象が発生する。パラメータを引き渡す術がないのだから挙動は理解できる。
ところが、例えば新着図書一覧等のリンクを辿った時に、 Cookieを食べない様にしていると、結果が表示されるのが遅い ことに気付いた。実測してみると、確かに100msec程余計に時間が掛かっていた。
Cookieを食べるようにした場合、初回の要求はCookieを食べない時と同じで、2回目以降は100msec程度短縮されることになる。
これを素直に解釈すれば、 セッション開始時にDB接続を行って、ページを移動してもそのセッションに紐付いたDB接続を使いまわしている ということだろう。100msecは新たなDB接続に掛かる時間だ *6
だとすると、 Cookieを食わずにアクセスするのは非常にまずい 。 毎回、新たなDB接続が行われて、使い終わったDB接続は、そのままタイムアウトまで解放されないことになることが予想されるからだ。
それでも、エラー処理が完全であれば、順次、セッションがタイムアウトしていって、いずれは定常状態に戻るはずだが、エラー処理に漏れがあって、途中まで構築したオブジェクトを破棄せずに終了してしまうといった何らかの問題があって、二次災害を引き起こすのかも知れない。
従って、 ASP版のMELILにアクセスする場合は、Cookieを受け付ける設定にしておかないとサーバ停止を招きかねない *7 。注意が必要だ。

念力デバッグ:

「念力デバッグ」という仕事があって、ごく稀にお仕事を頂く。
念力デバッグというのは、安楽椅子探偵に似たようなデバッグで、デバッガやデバッグ用のコードを使わずに、直観と論理に基づく推理だけでバグを探すデバッグだ。
通常のデバッグでは、デバッガを用いたり、デバッグ用のコードを走らせたりできるので、念力デバッグの出番はあまりないのだが、既に仕様書やソースコードが存在しなかったり、実機に触れることができなかったり、その全てがなくて、バグレポートだけでバグ解析して運用回避手段を見つける必要があったりという状況があって、そういう場合に、念力デバッグの登場となる様だ。
念力デバッグの結果は、材料が少ないときは特に占いめいていて、「午前2時に、おにぎりを大量に買ってみて下さい。日配品の集計モジュールを書いた人が、コードを書いた当時に経験が浅かったとしたら、集計タイミングに売上が発生する可能性を考慮しておらず、一貫性が保てなくなった可能性があります。推理が正しければ、件の現象が再現すると思われます。」といったレポートを書いて、推理が当たれば一件落着となる訳だ。
閑話休題。今回のケースを念力デバッグしてみると、
  • DB接続をCookieに基づくセッションによって管理する作りになっている。
  • Cookieを食わないクライアントからリクエストを受けると、リクエスト毎にDB接続が生成される。
  • DB接続を含めたサーバリソースは、タイムアウトによってセッションが破棄されるまで解放されず、確保されたままになる。
  • DB接続に必要なサーバリソース(DB接続の上限あるいはコネクションプールと思われる)が不足した状態でリクエストを受け付けると、リソース確保時にエラーが発生するが、このエラー処理が不完全なため、途中まで構築されたオブジェクト等の何らかの別のリソースの解放処理が行われない。
  • このため、エラーが発生している状況でさらにアクセスを行おうとすると、エラー処理の漏れによって、タイムアウトで解放されない形でサーバリソースが枯渇して、ASPの停止に至る。
ということだと思われる。
確認は容易だが、万が一、真似する人が出て「教唆だ」等と言われるとたまらないので、あえて書かない。しかし、その方法は、一般的なクローラの挙動そのものだ。
しかも、この推理が当たっていれば、DB接続の上限に達するまでは、ほとんどサーバの応答時間は変わらないであろうし、エラーが発生したとしても、順次タイムアウトで解放されていくリソースがあるために、散発的にしかエラーが観測されないということが起こり得る。まさに、最後の一アクセスがサーバダウンの引き金を引くロシアンルーレットだ。しかも、停止するのがASPサービスだけだったとしたら、こういう内部事情に気づけと言うのは、それこそ 魔法を要求している[http://twitter.com/rocaz/status/18508517455] に等しい。ネットは魔法使いの世界ではないはずだ。
まだこの結論を信じられない自分がいるのだが、もし本当に、 こんなバグを抱えているのだとしたら、これはもはや、インターネットにはつないではいけないレベルの製品だと言わざるを得ないだろう。
ASP版のMELILを導入していて、実証のためにサーバが停止する可能性があるアクセスを許容してくださる図書館の関係者の方がいらっしゃれば、日時等の実験条件は当然、指定に従うので、ぜひ連絡を頂けないだろうか。

7月23日追記[http://www.nantoka.com/~kei/diary/?20100722S1]:

その後の情報で、「念力デバッグ」の推察をアップデートした。
シリーズ・クロールとDoSの違いと業務妨害罪と(5) - その後の念力デバッグ[http://www.nantoka.com/~kei/diary/?20100722S1] を参照頂きたい。
*1: 例えば、ページを開くたびにDBに接続しに行っていては遅いから、ADOオブジェクトをSessionオブジェクトとして保持しているとか。
*2: 例えば、接続毎にADOオブジェクトを新規に作って、破棄の方はSession_OnEndに任せていたりすると、タイムアウト(デフォルトでは20分)まで、DBセッションが解放されないことになる。
*3: robots.txtが激しいのは、これを問題だと認識していたからだろうか。
*4: 館内検索端末など、台数と操作が限定された端末のみあれば、「例えば」と書いた実装でも、問題が表面化することなく動作するケースが多いだろう。
*5: 恐らくTCPのシーケンス番号を用いているのだと思われる。
*6: 素直でない解釈としては、Cookie食べることを控えめに要求するために、100msecのペナルティを与えているとか?
*7: 当然、この記事を読んで、「試しにCookie無しでアクセスしてみよう」というのは慎んで頂きたい。

■ 関連記事

詳細はこの日の詳細から

2010年07月15日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・他のサイトのパスワードを聞き出すことを禁止できないものだろうか[http://www.nantoka.com/~kei/diary/?20100713S2][セキュリティ][mashup]次の記事 >> このエントリーをはてなブックマークに追加

旧ログイン画面新ログイン画面
「さすが電通」と言っても良いだろう。件のサイトの仕様が変更されており、Twitterのホームから直接、書き込む形式になっていた。
当然、パスワードを第三者サイトで入力する必要はないし、このサービスの場合、その場限りの書き込みだから、OAuthよりも好ましいだろう。
この変更によって、第三者サイトでパスワードを入れるのに抵抗があった人も、このサービスが利用できるようになったことだろう。
この方法が、Twitterとハッシュタグを連携したキャンペーンを実装する際のデファクトスタンダードになることを期待する。

■ 関連記事

■2 シリーズ・クロールとDoSの違いと業務妨害罪と(3)[http://www.nantoka.com/~kei/diary/?20100714S1][電子自治体][DoS][mashup][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

タイトルを付け直そうかと思ったが、まだ続くかも知れないのでシリーズ化することにした。
初出の時に
サーバ側から観測した時に、相手が行っているのが過剰なクロールか、あるいはDoSなのかは、Webサーバのログでも大体見当は付く
と書いたが、この点を改めて強調しておきたい。

レガシー世界とインターネット:

インターネットでは、専用線接続やクラサバとは根本的に異なり、ネットの向こうには何があるのか分からないというのがスタートラインだ。これは、インターネット全盛の今にあっては当たり前のことだが、レガシー世界からすると、クライアントが何かも分からないというのは確かに別世界だ。
レガシー世界のサーバとクライアントは一対のものとして実装され、お互いの挙動を把握しながら動いていた。
ところが、インターネットの世界では、 RFC[http://ja.wikipedia.org/wiki/Request_for_Comments] で提案されたプロトコルを拠り所に、サーバとクライアントがばらばらに実装される。
プロトコルが決められていると言っても、 全銀協手順[http://ja.wikipedia.org/wiki/%E5%85%A8%E9%8A%80%E5%8D%94%E6%A8%99%E6%BA%96%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB] とか、ISO 8583とか、 CAFIS *1 の様な厳密さは無いし、ましてや接続のための認定等もない。
それでも動いているのは、サーバ - クライアント共に、なるべく広い相手と話せるように努力した結果だし、話せなければそれでも良いという割り切りの結果でもあるだろう。
これだけ別世界だと、レガシー世界の方から、 サービス提供側が意図しない使い方をして被害が生じれば罪になる[http://twitter.com/hatsanhat/status/18574777672] とか、 提供側が意図しない使い方を戒めて欲しい[http://twitter.com/hatsanhat/status/18575234658] といった、インターネット以降の常識からすると、首を傾げるような意見が出てくるのだが、これは、まさに世界観の違いによるものなので仕方がない。
今回の事件が、図書館に置いてある検索端末を意図しない使い方 *2 をして、検索端末が使えなくなったとか、システムが使えなくなったという話であれば、まだレガシー世界の話かも知れないが、 今回はインターネットで起きた話なので、インターネット以降の常識をベースに話を進めたい。レガシー世界の方は、別世界の話にしばしお付き合い頂きたい。

サーバが落ちるということ:

サーバにどれだけの能力が要求されるかについては、キャパシティプランニングとして、今も昔も上流工程で検討される事項の一つであろう。
レガシー世界では、キャパシティは絶対のスペックであって、それを超えるとシステムが動作しないというのは、望ましくは無いけれども仕方がない事だった *3 。 万が一、キャパシティをオーバーする可能性が生じたら、利用者に協力してもらって、運用で回避をするしかなかった *4
インターネットでは、何しろサービスの利用者はネットの向こうにいるのだから、いつ、どれだけアクセスが来るかは分からない。アクセスが集中して困ったとしても、アクセスをやめてもらう方法も無い。
処理できないほどのアクセスが来たらどうするか。 答えは簡単で、 処理できるようになるまで待ってもらうか、返事をしないか、余裕があればエラーだけ返すかだ *5 。 インターネットでは、できないときはできる範囲でやるというポリシーによって、リソースを有効活用しており、このポリシーがあるからこそ、高速なインターネット接続を、専用線とは比べ物にならないほどの低価格で利用できている。
もしも、年に一度あるかどうかのアクセス集中時にも遅延なくインターネットが使えなければならないとしたら、月額数十万円払って128Kbpsという世界で、多くの人の手元にインターネットは届いていないに違いない。 できないことはできる範囲でやる、ベストエフォートというポリシーがネットの低価格化と普及を実現し、今日のインターネットの隆盛がある。
サーバについても同様だ。 インターネットに対してサービスを提供する以上、処理能力を超えたアクセスの集中は必ず起こるとして、処理できないアクセスが来たら、待ってもらうか、返事をしないか、エラーを返し続けて、アクセスの集中が去れば定常状態に回復するというのが、インターネットに接続されるサーバとしての要件だ。
遅くなっても、返事をしなくなっても、それは処理能力の一時的な低下であり、それは「落ちた」とは言わない。一方、アクセス集中という原因が取り除かれても、なお復旧しない様な障害が発生した時に「サーバが落ちた」と言う。
今回のケースについては、報道等を通じて見る限りでは「サーバが落ちた」と言うのは事実のようだが、これまで述べたように、 アクセス集中によってサーバが落ちるのは、インターネットに向けてサービスを提供するサーバとしての要件を欠いている と言わざるを得ない。

ブラウザとクローラとヒトとロボットとネコ:

「Webサービスとは何か」と突き詰めて行くと、究極的には「HTTPサービスです」ということになる。「Webサーバ=HTTPサーバ」と言い直せるくらいだ。
HTTPサービスを利用するためのプログラムは、「HTTPクライアント」で、ブラウザもクローラも、HTTPクライアントであるという点に違いは無い。
当然、HTTPサービスを提供する側から見ても、HTTPクライアントである点に違いは無い。
一方、HTTPクライアントを使って、サービスを受けているのが、ヒトかロボットかネコかということも、HTTPサービスを提供からする側から見れば、みな「HTTPサービス」を受けているという点で等価だ。なおこのネコは後に重要な役目を帯びて再登場する。
サーバが提供するのは「HTTPサービス」であって、「IEサービス」でも「FireFoxサービス」でも無い。HTTPサービスを提供するということは、HTTPクライアント向けのサービスを提供するということであって、その中には、行儀が良いのも悪いのも *6 、実装にバグがあるものも、標準と違う動きをするものもあるけれど、そういう多様なクライアントからアクセスされるのが、インターネット上のサーバだ。
もちろん、一つ一つのクライアントに合わせてサーバを実装するわけではないし、そんなことができるはずもない *7 。サーバは、ただHTTPサービスを提供すれば良い。
この様に、通信プロトコルとユーザーインターフェイス等の表現を分離したところも、Webが広く普及した理由の一つであると考えられるが、とにかく、ここで理解して頂きたいのは、 Webサーバ(=HTTPサーバ)は、HTTPサービスを提供するサーバである ということに尽きる。
従って、 Webサービス(=HTTPサービス)を提供することは、HTTPサービスを提供すること になる。
そもそも「HTTPサービス」を提供しているのだから、HTTPクライアントからアクセスされることが想定されていて、 同じHTTPクライアントである、ブラウザとクローラを分けて考えることには無理がある。 この問題には、ヒトとロボットを判断する際にも直面して、その技術的な解決の一つとして CAPTCHA[http://ja.wikipedia.org/wiki/CAPTCHA] が使われているが、これも前述したように、ブラウザとクローラを判断するのが難しいからこそ利用されている技術である。

アクセスとアタックと:

原点に帰ろう。「ブラウザかクローラか」は、実はどうでも良い問題で、 焦点は「アクセスかアタックか」だったはずだ。
アクセスなのかアタックなのかはサーバ側で見当が付く[http://www.nantoka.com/~kei/diary/?20100624S1] という趣旨のことを書いたが、ここをもう少し詳しく書いてみたい。
パターンとしては、大まかに次のパターンが考えられる。
  1. ブラウザによる通常のアクセス
  2. クローラによる目立たないアクセス
  3. ブラウザによる過激なアクセス(だが、DoSではない)
  4. クローラによる過激なアクセス(だが、DoSではない)
  5. ブラウザによるDoSを意図したアクセス
  6. クローラによるDoSを意図したアクセス
1,2の中には、「怨念を込めて密かに1日1回アクセスを繰り返すことによって、サーバの負荷を上げてやろう」というものが混じっているかも知れないが、実害は生じないので無視することにして良いだろう。そもそも、霊感が無ければログから怨念を感じ取ることは不可能なので、気づかないケースがほとんどだろう *8
実際に問題になるのは、3,4と5,6を分離することだろう。 どこに違いが生じるかと言えば、 リクエストしたデータを利用しているかどうか だ。
例えば、常識的に更新頻度が高いことが想定されない同じページを、ノーウェイトで取得していれば、これは怪しいと見ていいだろう *9
クローラの場合、リクエストしてくるURLが異なると判別が難しいかも知れないが、クライアントまでのRTT *10 を得て、ローカルで同じページをアクセスした時に掛かる時間と足せば、クライアントからWebページを取得したときの大まかなRTTが分かる。これより長い間隔でのアクセスであれば、迷惑ではあるかも知れないが、恐らく意図はクロールだと判断できる。
今回のケースは恐らくこのパターンだったはずで、この程度の検証もしないで攻撃だと判断したのも、それを鵜呑みにして逮捕したのもあまりにも杜撰だ。
一方、これより短い間隔でアクセスしてくるとしたら、複数プロセスあるいはスレッドを使っているか、バグっているか、アタックしようとしているかだろう。サーバの応答時間を長くして、リクエスト数が変わらない様だったら、怪しいと見て良いだろう。
怪しいケースについては、あくまで「怪しい」であって、これが直ちにアタックの証拠になるものでは無い。バグによるものだったかも知れないし、「ブラウザでF5アタック」と思ったら、キーボードの上にネコが寝ていただけかも知れない。
IPアドレスやUserAgentで弾くことができないような形で続く様だったら、アタックと見なすことになるかも知れない。
なお、専用の攻撃ツールを使うと、効率的にアタックできる分、アタックとしか考えられない挙動を示すので、この場合は一回でアタックだと判断できるだろう。
*1: (7月24日)PIAFSとtypoしていたのを修正。
*2: 勝手にプログラムをインストールしたとか、設定を変えたとか。
*3: 例えば、夜間バッチ処理は、翌朝の業務開始までには絶対に完了していなければいけないだろう。
*4: 極端な例を取り上げております。
*5: HTTP Error 500のInternal Server Errorだが、文字通り、内部で何らかのエラー(リソースの不足、あるはずのファイルが見つからない、内部矛盾)を検出して、詳細は伝えない(攻撃に悪用される恐れがあるから、クライアントにはあえて詳細な原因を通知しないことが多い。)ながら、エラーが発生したという事実を正しく応答している。あくまで、クライアントに向けて、期待した応答が返せない理由として通知する「エラーコード」であって、サーバの管理者に対してのエラーでは無い。致命的な障害をクライアントに通知したからと言って、クライアントにはサーバを救う手だては無い。
*6: クローラが行儀が悪い訳ではない。ブラウザが行儀が良い訳でもない。無関係に、行儀が良いのも悪いのも存在する。
*7: 細かく言えば、ブラウザ向けに最適化することはあるが、本筋ではないので割愛。
*8: 不能犯になりそうでもあるし。
*9: 一方、ある時刻に予約の受付開始を行うようなサイトでは、リロードを繰り返すのは、当然、想定される操作だろう。
*10: 目安であるから、tracerouteして、クライアントよりいくつか手前でも構わない。

■ 関連記事

詳細はこの日の詳細から

2010年07月16日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 レガシー脳の恐怖[http://www.nantoka.com/~kei/diary/?20100715S2] このエントリーをはてなブックマークに追加

昨日の日記[http://www.nantoka.com/~kei/diary/?20100715S2] を書いていて、レガシーモデルの置き換えでWebシステムを捉えている人を揶揄するような流れになってしまった *1 。後悔はしていない。
レガシーのC/Sモデルでインターネットを理解して、この問題を議論したりするのは弊害 が大きいし、その他、インターネットが絡む全てを正しく理解できないのだから、この際、新しいモデルを理解しておくべきだ。
新しく出てくる様々な技術を、レガシーなモデルになぞらえて納得するのは、表層的な受け入れは早いかも知れないが、 根本的な部分の理解を抜きになぞらえるのは、 レガシーマイグレーション[http://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%83%9E%E3%82%A4%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3] と同じで様々な問題を後に残しやすい。
しかも、それを繰り返すうちに、脳がレガシー化していく。新しい考え方を受け入れることがさらに難しくなり、例えに無理が出てきて、しかもそれに気づかないようになってしまうのだ。
「クラウドって、あれでしょ。VANでしょ。」とか言い出す前に、思考をオープン化しよう。

■ 関連記事

詳細はこの日の詳細から

2010年07月18日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(4)[http://www.nantoka.com/~kei/diary/?20100715S2][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

情報ネットワーク法学会 - 第1回「技術屋と法律屋の座談会」[http://in-law.jp/bn/2010/20100716.html] 関連のTweetで、事実関係が新たにいくつか明らかになった様なので、メモしておく。
まず、 貸出業務等に目に見えた支障はなかった[http://twitter.com/tetsutalow/status/18800959731] ということが判明した。
一部には、 館内業務が止まるほどの被害が出たのだから、警察は逮捕して当然[http://twilog.org/Sikushima/date-100628] という見方をする人もあって、システムの構成から *1 考えれば、いくらなんでも館内業務に影響は出ないだろうと思って、何を根拠にこういう主張をしているのかと訝っていた。
館内の業務に影響がなかったのであれば、同氏も、
岡崎図書館は館内業務も止まっていた前提で書いています。 館内業務が止まってないのに逮捕はやり過ぎです。
と書いている様に、「逮捕はやり過ぎ」という感覚を理解いただけたのではないかと思う。
また、図書館側の対応が、時系列でもう少し明らかになっている。
以下、要約する。
  1. (3月中旬)新着図書ページがある時間になると閲覧不能になるという苦情があり、調査したところ、実際に閲覧不能になっていた。 [http://twitter.com/tetsutalow/status/18796534863]
  2. この時点での図書館の認識は「何か普通でないことを機械的にされている(ので困る)」という認識。 [http://twitter.com/tetsutalow/status/18796741940]
  3. アクセスはURL決め打ちだったので、URLの一部を動的に変化させる様にした。 [http://twitter.com/tetsutalow/status/18796741940]
  4. 動的に変化といっても1文字変化する文字をURLに加えるだけだったので簡単に対応された。 [http://twitter.com/tetsutalow/status/18796927113]
  5. IPアドレス遮断をこの時点で考え始めた模様である。 [http://twitter.com/tetsutalow/status/18796927113]
  6. 「このアクセスを行っている人物はこの図書館の利用者か」を調べるために、IPの逆引き結果からISPを調べ、そのドメインを持つメールアドレスがLibraの登録者DBにあるか探した。 [http://twitter.com/tetsutalow/status/18797135716]
  7. 警察に簡単な相談 [http://twitter.com/tetsutalow/status/18797578659]
  8. (3月末)当時はレンタルサーバを使用していたため、前述の方法で図書館の利用者ではないと判断し、IPをブロックした。 [http://twitter.com/tetsutalow/status/18797289839]
  9. (4月上旬)違うアドレスから同様のアクセスが来たため、同様にアドレスからドメインを調査したところ、Libraにも多くユーザがいるドメインだったため、遮断は容易にできなかった。 [http://twitter.com/tetsutalow/status/18797826472]
  10. 警察に任意でアクセスログを提出して相談 [http://twitter.com/tetsutalow/status/18798035052]
  11. (4月中旬〜下旬)警察が事件として捜査できると判断したので、被害届を提出。 [http://twitter.com/tetsutalow/status/18798239953]
6.は、9.と考え合わせると、「このアクセスを行っている人物はこの図書館の利用者か」というよりも、「このIPアドレスを遮断すると図書館の利用者に影響が出るか」という確認だったと思われるが、いずれにせよ、今日においては、IPアドレスとメールアドレスの紐付きを期待するは無理があるので、中途半端な確認だったと感じる。
10.については、 6月22日に電話を掛けて確認したこと[http://www.nantoka.com/~kei/diary/?20100622S1] と食い違うように感じる。ひょっとすると、ログの抽出から提出まで、図書館側はノータッチだったという可能性もあるが、それはそれで、利用者のプライバシーに密接に結び付くものを、そこまで業者任せにして良いのかという疑問が残る。
*1: 対外系のWebサーバと、館内業務向けのWebあるいはアプリケーションサーバを兼用する構成にはさすがにしないはず。

■ 関連記事

詳細はこの日の詳細から

2010年07月19日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 Androidが中国で大躍進する理由―影響は世界に及ぶ[http://jp.techcrunch.com/archives/20100718android-china/][Android][desire][携帯端末] このエントリーをはてなブックマークに追加

先日、 私が「iなんとか」を買わずにAndroidを買った3つの理由[http://www.nantoka.com/~kei/diary/?20100712S2] で書いた、山寨機メーカーの話。彼らが、偽Windowsモバイルや、偽iPhoneではなく、本物のAndroid端末を作る様になったら、相当の競争力を持つことになるに違いない。
そういった、高性能で低価格な端末が、SIMフリー化された国内市場にも入って来るようになった時、ガラパゴス生態系はどうなるのだろうか。

■ 関連記事

詳細はこの日の詳細から

以上、10 日分です。

指定日の日記を表示

前月 2010年07月 翌月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

最近の日記

2017年02月21日

BIGの投票内容(発番)につきまして(2017.02.20)

2016年06月29日

「SEI-Net」不正侵入事件にみる佐賀県教育委員会の杜撰

2015年11月26日

武雄市図書館から“地方自治”を考える!

2015年11月21日

シリーズ武雄市TSUTAYA図書館(34) - 「第3のツタヤ図書館にデキレース疑惑 内部資料を独占入手!」落ち穂拾い

2015年10月30日

シリーズ武雄市TSUTAYA図書館(33) - 海老名市ツタヤ館運営の行方

2015年10月26日

シリーズ武雄市TSUTAYA図書館(32) - 10月26日付 文化通信「TRC、CCCとの関係解消へ」

2015年10月25日

シリーズ武雄市TSUTAYA図書館(31) - 続・検証「9つの市民価値」

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project