2010年07月15日(木) << 前の日記 | 次の日記 >>
これまでの07月15日 編集

■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して、クライアントよりいくつか手前でも構わない。

■ 関連記事

今日のつぶやき

  • そういえば、ホメオパシーに保険適用って話があったな。プロジェクトチームどうなったんだろう。 http://www.zakzak.co.jp/society/politics/news/20100215/plt1002151633004-n2.htm2010-07-15 01:51:14 Tween
  • Browsing: 厚生労働省統合医療プロジェクトチーム資料 http://bit.ly/aGPCNe http://bit.ly/cuzg8k2010-07-15 01:53:32 Tween
  • あるあるw - ツイッターなど、イタいセルフブランディングから脱却せよ!「当たり前」の積み重ねが差別化を生む http://bit.ly/cIcgwi2010-07-15 08:07:14 Tween
  • Browsing: 情報ネットワーク法学会 - 第1回「技術屋と法律屋の座談会」 テーマ:岡崎市立中央図書館へのアクセスはDoS攻撃だったか? http://bit.ly/9j0BYH #Librahack2010-07-15 12:44:10 Tween
  • @minemaz @kazkun CAL周りはライセンス担当も間違うとMSのヒトが言ってたくらいですから、複雑怪奇。でも、IISを(Windows認証を使わずに)普通にインターネットサーバとして使うケースにはCAL要らないはず。2010-07-15 13:49:54 Tween minemaz宛て
  • @gutei その論理に乗るのは危険だと思いますよ。Webを通じてサービスを提供する以上、提供側が受容しないといけないことがあるはずで、クロールも受容しなければならないのではないでしょうか。宅配業者も「善意」で提供しているのではなく、Webを使うメリットを享受している筈です。2010-07-15 14:01:00 Tween gutei宛て
  • @gutei 「税金を払っているからOK」という主張に見えてしまう気がしたのでコメントしました。「税金を払っていない他の自治体にやったらNGだ」と主張しているとか曲解して言い出す人が出てきかねないので。2010-07-15 14:10:15 Tween gutei宛て
  • 例えば、文庫本の切り取った表紙と100円を送ると電子版がダウンロードできるとか、雑誌を定期購読すると電子版もダウンロードできるとか、電子版の割引チケットが閉じこまれているとか、vsではなくてwithのビジネスがたくさん出てくるとうれしい。2010-07-15 14:17:43 Tween
  • @hatsanhat なぜ「100人が同じスクリプトを流せば落ちる事は自明」なのですか?1人が流して落ちたからですか?では、落ちる前は落ちるかどうか分からないということですよね。 #librahack2010-07-15 15:01:32 Tween hatsanhat宛て
  • @mitsugu_oyama 「以下に掲げるブラウザ以外の使用、ブラウザ設定を標準状態から変更してのアクセス、プラグイン等の利用を禁止します」ってテンプレ書くだけで良いですね! #librahack2010-07-15 15:05:19 Tween mitsugu_oyama宛て
  • ブラウザ技術適合認定試験制度を作って、技適を通ったブラウザでしか官公庁や自治体のサイトに接続できない様にして、ブラウザを改造する行為を違法化したら良いねという話になってる? #librahack2010-07-15 15:10:46 Tween
  • @mitsugu_oyama その紳士協定なるものは、無断リンク禁止教の新宗派を生みませんか?2010-07-15 15:19:47 Tween mitsugu_oyama宛て
  • @mitsugu_oyama それなら分かります。API公開はまさにその方向で、規約を守らない場合にペナルティを与える方法もあります。ただ全てのサービスにAPIの提供を求めるのは不可能なので、その溝をクロールやスクレイピングで埋めているのが今の状況ですよね。 #librahack2010-07-15 15:23:00 Tween mitsugu_oyama宛て
  • 紳士協定と言えば、robots.txtがあるのだけど、あれはロボットにとって立ち入り禁止の柵を作るというより、道案内を立てている感じ。ここから先に行くと、無限に動的リンクが生成されていますよ、みたいな。本当に立ち入り禁止にしたければ弾くわけで。 #librahack2010-07-15 15:33:09 Tween
  • @tanayuki @yasunori_sugii @ennuihage @hastorang @mao3mao3 「超流通」という懐かしいキーワードが!2010-07-15 15:35:10 Tween tanayuki宛て
  • 画期的なコンテンツ配布方法を思いついた気がしたのだけど、つぶやいて公知になる前に、念のため先行技術調査をしてみることにするなど。2010-07-15 15:40:19 Tween
  • @yao_yokagoto @nekonyauri 昔は薬を他人に勧める困った素人がいて、本物の薬よりは、それこそ毒にも薬にもならないので安全ということでレメディーが流行ったそうなのですが、どこかから、レメディーだけで治すべきだと変な方向に発展してしまったのでしょうね。2010-07-15 15:56:58 Tween yao_yokagoto宛て
  • @yao_yokagoto @nekonyauri お祈りやお参りが受験勉強の代わりにはならない感じで。2010-07-15 16:07:08 Tween yao_yokagoto宛て
  • どっかのベンダーがインターネットを作っているという、すんごいレガシーな妄想を読んだ気がした。気のせい。気のせい。 #librahack2010-07-15 17:02:05 Tween
  • どっかのベンダーがインターネットを作っているという、すんごいレガシーな妄言を読んだ気がした。気のせい。気のせい。 #librahack2010-07-15 17:03:56 Tween
  • インターネットでは、ネットの向こうには何があるか分からないのがスタートライン。クラサバとは違うのだよ!クラサバとは! #Librahack2010-07-15 18:33:13 Tween
  • ネットの向こうからアクセスして来ているのが、ブラウザなのかクローラーなのか、操作しているのがヒトなのかロボットなのかを判断したり規定したりしようとするから話がおかしくなって、DoSなのかそうでないのかを判断するべき。 #Librahack2010-07-15 18:37:47 Tween
  • @hatsanhat 落ちるか落ちないかを知ることは、実際には不可能だと思うのです。経験上は、動的ページであってもこの程度のアクセスでサーバが落ちることはまずありません。遅くなるかエラーを返し始めるかです。なぜ「自明」とされたのかをお伺いしたかったのです。 #Librahack2010-07-15 19:10:14 Tween hatsanhat宛て
  • @hatsanhat そのISPでは、負荷が高くなるとInternal Server Errorを返すようなシステムを構築されていたのですね。そして、それを無視してアクセスを続けるとサーバが落ちると。2010-07-15 20:56:55 Tween hatsanhat宛て
  • @hatsanhat だとすると、そのシステムは「インターネット向け」のシステムでは無いと思うのですが、インターネット向けのシステムだったのでしょうか。2010-07-15 21:00:16 Tween hatsanhat宛て
  • 500もらったら、パラメータに起因するエラーとみて飛ばして次でしょうね。いずれにしても、500って言う応答を正しく返してくるのだから、サーバが落ちることになると判断するのは難しいでしょう。 #Librahack2010-07-15 21:07:17 Tween
  • ひょっとして、「Internal Server Errorを発生させた=業務妨害。何度もやったんだから悪質に決まっている。」という論理の人が他にもいないだろうなぁ。心配になってきた。 #Librahack2010-07-15 21:40:06 Tween
  • 思いがけない人からプレゼンの極意を学んだ。「1)押し付けは良くない。事前の関係構築が大事。2)与えたいものではなく、相手が求めるものを。3)後味良く。負担ではなく感動を。」良く聞いたら、プレゼントの極意だったけども。2010-07-15 21:46:24 Tween
  • @hatsanhat 「裁判になったら無罪になる」という判断なのに、「起訴されるはず」なのは矛盾していませんか? #Librahack2010-07-15 23:23:56 Tween hatsanhat宛て
  • @hatsanhat もう一点。「サービス提供者の意図しない利用方法」とありますが、利用者としては、「Webサーバとして公開されているのだから、HTTPでアクセスされることを意図しているのだろう」と言うこと以上は、通常、知りえないのではないですか。 #LifeHack2010-07-15 23:29:27 Tween hatsanhat宛て
  • 興味深い「WEBシステムの流行が続いていますが、操作性はC/S型に分があることは確実」「通信負荷もサーバ負荷も大きいWEBにこだわる理由が本当にありますか?」「あるソフト会社が、これらを解決するフレームワークを持っています」 http://bit.ly/9tBnxM2010-07-15 23:38:13 Tween
以上、1 日分です。

指定日の日記を表示

前月 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

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
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