Telecom-ISAC Japanにおける情報通信事業者間のセキュリティ対応連携について

全文

(1)第９回コンピュータ犯罪に関する白浜シンポジウム REPORT. Telecom-ISAC Japanにおける情報通信事業者間のセキュリティ対応連携について Telecom-ISAC Japan 企画調整部長有村浩一ただ今ご紹介にあずかりました、テレコムアイザックジャパンで企画調整部の部長をしております、有村と申します。本日は、可能な限りセンシティブな話も入れながら、サイバーアタックのリアルな現状と、それをどう事業者間連携の中で、テレコムアイザックとしてどのように対応しているかというようなこともお話ししたいと思っております。本日は、お話しとして三つのアイテムを用意いたしました。まず一つ目です。「テレコムアイザックとは何か」ということをまずお話しないといけないと思っております。2日目の冒頭、基調講演の中で、内閣官房の情報セキュリティセンターの立石さんからもございましたように、インフォメーションシェアリング＆アナリシスセンターというのをセクターごとに作ろうとか、昨日の午後の講演にありました、米国国家安全保障省の講演の中でも、アイザックという言葉が出ております。なんとなく名前だけは、売れているような感じがしておりますが、そもそもアイザックと言うのは、何をやっているのだということをまず、お話いたします。その次です。アイザックは一言で言ってしまいますと、テレコム事業者の集まり、相互互助会みたいなものでございまして、そこでインシデントハンドリング、あるいはサイバースペースにおけるインシデントコーディネーションするのがテレコムアイザックの役目だと思っておりますが、二点目のアイテムとしまして、「その対応連携と言うのは、どういうふうに考えればいいのか」ということをお話したいと思います。今回のシンポジウムのテーマである「匿名性」という話に、ここは関連すると思いますが、ここはまだ実際に、明確な考え方が整理できているとは思いません。試行錯誤している段階だと思いますが、いわゆるそういうインシデントレスポンス、インシデントコーディネーションをアイザックという枠組みで考えたときに、どういう対策の行動をとっていくか、その戦略についての考え方をお話したいと思います。なぜかといいますと、このシンポジウムのテーマである匿名性、通信の秘密、個人情報、顧客情報、こういったものが、ゴチャゴチャの状態で出てきたり、入ったりするということになります。あるいは会員の間で、シェアしたり、あるいは何かを抑えたりしようとするときには、あらゆる国との間でのネゴシエイションしていかなければなりません。そこには、なかなか難しい問題がありますが、 79. まずは話をさせていただきたいと思っております。三点目として、実践として、大手ISP間の連携によるサイバーアタックの対処の実例をお話したいと思います。昨日もアメリカの国家安全省の方々が、少しお話しておられました。具体的に言いますと、ゾンビPC、ウィルス攻撃というのが、今、結構な勢いで大規模に起きています。先週RSAコンファレンスがありました。その基調講演はリチャードクラーク氏でした。このクリントン政権の中で、米国のサイバースペースの安全性を確保するという役職の中で政策を作り、米国内で、いろいろインフォメーションシェアリングをしようということをやっていた人ですが、この方も DDoS攻撃、ゾンビPCというのをあげておりました。第一世代はウィルス主体で、第2世代はDDoSだと言っております。ちなみに、これらの第3世代がフィッシングだと言っておられました。ちょうど今旬のそのDDoS攻撃のディフェンスやゾンビPCというものについて、事例をご紹介したいと思っております。 Telecom-ISAC Japan とはテレコムアイザックジャパンは、テレコム事業者がサービス提供に使用する情報通信網や基盤の安全性を確保するという目的で、2002年の7月に、任意団体として発足しております。現在は12社が会員として参加しています。私は2002年の7月以前の準備段階から、ずっとこの組織運営にかかわっています。通信サービスの提供を妨げる各種インシデントがあり、それを会員から情報収集したり、分析したりして、その分析の結果を会員間で共有するとともに、一社で単独に対処し切れないようなインシデント事情に対して、会員が連携しながら安全・安心を確保しようということで活動しております。昨日の立石さんのリスクのお話の中で、情報共有するために、アイザックがあるとおっしゃっておりました。情報共有という言い方をしますと、「そうしたほうがいいな」という話になるのですが、実際にやってみようと思うと非常に難しいと思います。後ほどご説明しますが、「事業に関する情報を情報共有してください。情報を出してみんなにシェアしますから。」と言っても、「ビジネスのフィールドでは、競合相手だよね」ということで、そう簡単にはいかないのが現実です。3年間の活動を通じて、日本のテレコムアイザックジャパンの合い言葉は、「情報共有」から、一社では対処しきれないような大規模なインシデントに対して、.

(2) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT 一致団結・連携して事に当たろうという合い言葉に実践的な変化を遂げました。最近のテレコムアイザックジャパンの具体的な活動ということで、2003年から2005年にかけての話を少ししておきます。最後の3番目のアイテムの中で、2005年あたりの話をしようと思っています。 2003年は、ワームブラスターの時代でした。ブラスターとその亜種が、夏休みの頃に立て続けに出てきまして、結構大変だった記憶がございますが、そういったものが出てきたときに、お互いの状況や情報を交換するということをしておりました。2003年から2004年にかけては、少し様子が変わってきております。さきほどのリチャードクラークの話で言うならば、第2世代ということでゾンビPC、ボットネット、大規模DDoS攻撃的なことが目立ち始めました。 2004年の8月に、北京でアジアカップサッカーがございました。リアルの世界の中で日本のチームがどんどん勝ちあがっていくにつれて上海や北京でいろんなことが起きました。それにリンクしているかどうかというのは皆さんのご判断にお任せいたしますが、準決勝の手前頃になってくると攻撃がきたということがございました。大量にトラフィックがくるというような状態ですので、何とかしないと電気通信事業者が「ISPの設備がもたない」という話もありました。2004年には、みんなでアジアカップの様子を気にしながら「こうなりそうだ」とか「何か来そうだ」とやりとり記憶がございます。2005年、まだ第三世代にはなっていないと思いますが、フィッシングの話が事例としてありました。ファーミングの話もこれから被害が出てくると思いますが、私たち現場レベルでいえば、DDoS攻撃系の話の方がまだ多いです。皆さん記憶の新しいところでは、5月の連休前の話題があると思います。サイバーフォースを通じていろいろとマスコミにも出たと思いますが、「特定のいくつかのサイトが中国から攻撃を受けている。レスポンスが遅い」という話がございました。これもきっかけはいろいろとあると思いますが、リアルの世界で起きていることが、バーチャルの中に持ち込まれるものと思っています。おかげさまでこのところ毎週末、テレコムアイザックジャパンの会員でISP事業者の方々と連絡を取り合っていうようなことをやっております。5月の連休中には、またいろいろと盛り上がるかと思ったのですが、関係各位のご尽力もあったようで、まったく攻撃がなかったとはいいませんけども連休直前に比べると静かだったというような状況を体験しています。テレコムアイザックジャパンというのは、会員制で成り立っております。日本電気、NTTコミュニケーションズ、 NIFTY、日本テレコム、パワードコム、IIJ、KDDI、ソフトバンクBB、そして松下電器。ベンダー系という意味で日立、沖電気、横河電機による会員で構成されています。この他にアライアンスメンバーというのがございまして、例えばセキュリティベンダーのラック等が入っています。また、オ. ブザーバーとして情報通信事業の主務官庁である総務省、そして独立行政法人の情報通信研究機構が参加しています。テレコムアイザックジャパンには大きなくくりとして3つの内部組織があります。1つは総会です。会員が1社につき 1名の委員を出していてテレコムアイザックジャパンの活動方針などを総意で決める最高意思決定のための組織です。つぎはステアリングコミッティです。総会の決定のもと、各種業務を行うために必要な意思決定、戦術的決定を行い、業務遂行レベルでの意思決定スピードを上げるための組織です。それから私が所属する企画調整部です。ここが会社で言えば経営企画室や総務部にあたるところです。常設的な組織で、組織運営全般に携わります。それからあと、システム運用ということで、IT的な部分、それから技術的な部分等をやっています。セキュリティに取り組むいろいろな組織が国内にありますので、それらとも連携しながら事業者の団体として一致団結して、わが国のセキュリティ概念とセキュリティを守っていこうとして活動しています。設立目的、活動指針等テレコムアイザックジャパンの設立目的、活動指針等を資料で配布しておりますが、時間のこともあるので設立目的は今は細かくご説明いたしません。ただここで言っておきたいのは、会員間の相互連携を行っていること、会員制でやっていること、それと情報共有を行っていることです。 2002年にテレコムアイザックジャパンを作ったとき、情報共有といいながら、やはり（会員は）競合他社なので情報共有は非常にしにくいということも事実ですし、そうかと言って情報共有以外のやりようがあるのだろうかと考えました。しかも、セキュリティに関する情報共有と言ったとき、 JPCERT/CCなどのすぐれた先行組織がたくさんの脆弱性情報を流す活動をしていたので、そういった方々より更にいち早く情報をキャッチすることは出来ないのではないか・そもそも無理ではないかという話がいろいろありました。ですが、会員への提供サービスとして他になかなかいいもの思い浮かびませんでした。そのたため、設立当初は、お手本としてのアメリカのアイザック同様、情報共有をメインにしていました。しかし、この2年間の活動を通じて、情報共有よりは、相互連携して脅威に一致団結してあたる活動にウェイトを置くようになっています。このあと会員間でどう連携しているのかを順々にしていきますが、何をやるにせよ「難しい」ということです。企画調整部の私としましては、会員の方々に、あるいは会員にするときに必ずお話しているのが「活動の指針」ということです。要するに健全なコンペティションをするために、通信事業者は自分だけよければいいというのではなく、持ちつ 80.

(3) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT 持たれつの部分があって、必要なところではコラボレーションしましょうということで「健全なCompetitionは、高邁な Collaborationから」を合言葉で活動に取り組んでいる状況です。インシデント対応プロセスからみたT-ISAC-Jの立ち位置 2番目のお話の、インシデントコーディネーションあるいはインシデントリスポンスです。アイザックの組織運営の中でどういう考え方で、どのようなコーディネーションのプロセスを設計していくかという話をします。インシデント対応のプロセスから見てアイザックはどこにいるのだ、プロセスにおいて他の先行組織の立ち位置の違いはどこだという問いに答えながら、テレコムアイザックジャパンならではのユニークな立ち位置を探し、テレコムアイザックジャパンのコアコンピダンスを確立したいと思っています。インシデント対応のプロセスの全体像ですが、イメージとしては、いきなりワームやウィルスが発生したり、あるいはインシデントがいきなり発生したりするものではなく、事前に予兆というものがあります。具体的に言うと脆弱性の発見、その脆弱性の特定・分析、そして脆弱性の公開、情報の公開があって対策法も公開され、Exploit Codeが出て、ワームが出始めるということです。実際にワームがでてきそうだとなると、次の話として、発生を検知し、うまくいけば蔓延をある程度のところで抑え込みながら、クロージングしたいわけです。セオリーから言いますと、ワーム等が出た後、インシデントが発生し始めて、それがだんだん蔓延して、それをトラブルシューティングするなかで、蔓延を終息・回復していくという流れになります。この過程の中で我々はどんなところにいるのか。基本的にISPというのは攻撃・防御の最前線だと思っております。ISPの中には、インターネットバックボーンを運用している事業者もいます。会社、あるいはビジネスユースの企業に対して、イニシアチブを確保していることもあります。あるいはエンドユーザーに対してのイニシアチブを確保しているということもあります。その意味でいうとバックボーンの話にもタッチできます。エッジ側にいる各企業のウェブサイトあるいは各エンドユーザーも見えるという立ち位置にいると思っています。インターネットのエンドツーエンドにいる意味でいうと、ISPは攻撃・防御の最前線にいると思っております。このような攻撃・防御の最前線にいる会員の方あるいはISPの支援をするために、テレコムアイザックとして何か貢献していきたいと考えているわけです。基本的には、テレコムアイザック立ち位置、軸足としては、発生後のネットワークの防衛・対処の部分だと思っています。トラフィック制御でバックボーンへの攻撃を回避するネットワーク網運用の立場として、あるいはIPSユーザーへの顧客満足度向上の一環として、ユーザーに対策ソフ 81. トの緊急配布などの形で接触できると考えております。これがISPならではの出番の部分だと思うのです。もちろんこれを軸足にしてここだけで他のことをやらないと言っているわけではありませんが、やはり他の機関連携をして、例えばJPCERT/CCが得意とする部分についてはそこから情報等をいただくとか、そういうようなことをやっていくのが筋だろうと思います。テレコムアイザックジャパンといっておりますが、まだまだ非常に脆弱な組織でございまして、これからのところもありますので、まずは自分たちの立ち位置、軸足をしっかりさせたうえで、その軸足を補強する意味で、すでにやっておられるところと、コラボしていくことが必要かなと思います。インシデントコーディネーションのプロセスのなかで、テレコムアイザックジャパンが必要なのかどうなのか、出番があるのかどうなのか、2年間ずっと悩んでいるところで、この見解が正しいのかどうかわかりませんが、今のひとつの到達点だと思っています。たとえば、ウルトラマンの科学捜査隊も、サンダーバードの国際救助隊も出番がなければしょうがないわけで、出番があるからこそ存在するあるわけです。では、テレコムアイザックジャパンが、出番があるのかどうかということですが、2年間やった結果で言うならば、「出番はある」と確信しております。しかし、出番があると言っても、その出方や出番の判断が非常に難しいのではないかという悩みを抱えております。出番とか出方のあり方に関する判断基準ですが、これは今までの実践対応の中で勉強しております。なぜ勉強中なのかといいますと、お手本がないと思っているからです。たとえばテレコムアイザックの元祖のアメリカのアイザックは、基本的には、脆弱性情報あるいはインシデント情報を共有するということだけで、それ以上の手を打つということは、特にしてないと伺っております。ほかのテレコムアイザックと言えば、例えば韓国にもテレコムアイザックがあります。ここも韓国内のインターネットの安全確保を指向する点では、テレコムアイザックジャパンと同じようなコンセプトでやっていますが、体制が違っております。体制が違っていると言うのは、かなり前ですが、WindowsのNS の脆弱性をつかれて、かつてｋｒドメインが、インターネットの世界では消えたことがあります。それをきっかけにして、法律ができ、その法律のもとで強制的に、トップダウンにテレコムアイザック、かなりの力を持って動いていると聞いています。こうしてみると日本の今の我々がおかれた環境では、アメリカや韓国は我々のお手本とは言い難く、ということで、なかなか世界でお手本になるものがないので非常に苦労しています。むしろ日本版のアイザックのやり方を世界のお手本にしようと思いながら、日々努力をしている次第です。.

(4) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT 導出過程の考え方さて、出番の考え方ですが、出てくるタイミングが難しいということです。なぜかというと軽々しく出動してはいけないし、できないということがあると思っています。出番を間違えると、例えば自由競争を阻害するというような話があります。あるいはセキュリティベンダーもいらっしゃるので、民業の圧迫という話もあります。一方、会員を護送船団的に保護していいのかという議論もあります。このシンポジウムのメインテーマであります「匿名性」の問題もあります。コンプライアンス、通信の秘密、電気通信事業法との絡み、それから顧客情報の漏洩とか、個人情報の漏洩等の重たい話がたくさん出てくるわけです。極端な言い方をすると頼みもしないのに出てきて、というようなこともありえるということです。ということで、サンダーバードの国際救助隊の出番は、やはり相当難しいと思っています。ここら辺になれば我々が出動できる、このときまではまだ出動できないとことを考えて、会員との間で出動の目安を共有しなくてはならないと思っています。出動の目安を考えるにあたって、厳しいのは、テレコムアイザックジャパンという組織がISP事業者、会員のインシデント収集能力に頼るしかないという現実です。会員各社がISP事業を行うのに整えているリソース陣容はテレコムアイザックジャパンの企画調整部、システム運用部と比べものになりません。また、我々がインシデント対応のために、会員企業以上に技術的なもの、秀でたものを持っているかというと、必ずそうではありません。テレコムアイザックジャパンは基本的には会員ISPにお願いする以外に対策実施の打ち手を持っていないわけです。そういう意味で言うと、軽々しく出動できないだけなく、出動しても役に立たずで終わることのあると思っています。次は、出方の考え方で話します。その出方は対処の内容によりいろいろあると思っています。コンプライアンスの観点とか、通信の秘密の関連等の話もありますので、出方にも制約があると思っています。これまでの取り組みの中の出方を少し整理します。先ほどよりお話しましたように、活動には情報共有と相互連携があると思っています。情報共有にもパターンがあります。たとえば、テレコムアイザックジャパンから、会員各社に対して一方向的に通知する場合です。通知するといっても、そのなかで、同一情報を外部には公開せず、しかし会員には平等に発信する場合、ニーズの原則に従って会員のうち必要なところにピンポイントに通知する場合、それから不特定多数に対してWebやマスコミを使って公開するということです。相互連携をしていくなかでもいろいろな情報共有のやり方があります。ワーキンググループを作って、特定の目的に対して集中的に対応していく方法があります。DDoS攻撃に対処する時の情報共有は複雑でした。アイザック組織と会員、会員相互のやり取りが. 多数発生しかつ、絶えまない状況フィードバックも行ったことがありました。ということでいろいろと出方と出番の組み合わせがあると思います。軽々しく出てはいけないし、なかなか簡単に出番が見つからないのが状況だと思います。セキュリティ対策行動の導出過程のフロー化私はいくつかの観点でその出方・出番のタイミングを計るプロセスを作っていかないといけないと思っております。インシデントコーディネーションやインシデントレスポンスにあたっての対策行動はこの方針に沿って導出して行くのが、望ましい姿だと思っています。個人的な仮説ですが、出方・出番のタイミングを図るにあたって5つの観点があるようにおもっています。（1）高度な信頼関係の構築位置アイザックに出てきている方々は会社の代表として来ていますが、その方々は、アイザック組織として情報共有あるいは足並みをそろえてこういうふうにやりましょうと決めたことを会社に持ち帰っていただいて、最終的には会社の中で組織に対して合意実現のための交渉をしてもらうことになりますが、会社の立場・方針・利害の違いもあるため、アイザックで決定した事項について組織合意が難しい場合もありえます。会社の合意が得られなければ、会員企業連携は破綻します。つまり、会員各社はアイザックの決定事項に対して合意することを前提にして議論しているので、参加者は相互にその期待を裏切らないと思われていなければいけません。相当高度な信頼関係を構築できていなければやっていけません。ここに至るのはなかなか難しく時間がかかる話だとは思いますが、やはり、文書での組織間のやり取りというよりは、最後は顔を見て話して相互理解するということが、泥臭い話しかもしれませんが、現実です。ただ顔を見せ合うことで、ある程度のパワーが出るのであるならば、それでも良いと思います。アイザックとしては、信頼関係にあるメンバーが各社に持ち帰って社内調整するとき、調整の苦労を軽減できるよう、どのような説得材料を持たせることができるかを考えます。以下はその話だと思って下さい。（2）会員に対するガバナンスコントロールこれも非常に悩みどころです。最終的には我々は、どういう権限で会員にお願いするのか、命令できるのか、指揮命令権はあるのか、平たく言えば「何の根拠で、ISP事業者にものを言うのだ。」ということです。しかし、有事がいったん起きた場合には、一致団結して高邁なコラボレーションで行きましょうという意味で、ガバナンスコントロールをしていきたいわけでこのところが悩みです。（3）支援根拠の確立これは先ほど「出番」のところで言いましたが、頼みもし 82.

(5) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT ないのにとか、あるいは民業圧迫とか、法的な問題等々に対しては、相当な注意をはらっているので、支援根拠の確立が必要になります。つまり、1社で手に負えているときには、手を出すわけにはいかないと思っております。 1社で手に負えなくなって、「助けてくれ、国際救助隊」と言ってもらって、初めて出動だろうと思っております。「出動にあたっての批判・リスクを避けるために、わが国の」という観点での支援根拠をもつということです。. これを支援根拠の確立・確保の一例として紹介させていただきます。2つ目は、実はDDoS攻撃を受けて、それがなかなか止まらず、実は去年にお話をいただいているのですが、今も月のうち3分の2ぐらいWebが止まっているということです。3番目です。そのDDoS攻撃にたまりかねて、 URLは変更して使っていました。具体的に、wwwなんとかを、www2なんとかというURLに変更しています。これで攻撃が回避できると思っていましたところ、相手側はwwwにもwww2にも攻撃をしてきてなかなか解決できないということです。この攻撃にもだいぶ慣れましたけども、防御の経験を1つ1つ積み重ねていく中でいろいろなことを考えていかなくてはいけないと思っています。まず、1番目のところ、どんなことが起きたのからお話いたします。ある時、ある会員のISPが運用する設備側のDNSで負荷が急速に上がりました。状況をみると通常のトラフィックの6倍が殺到していました。設備的にはある程度の負荷に対する余裕を持っていますが、いきなりこれだけのトラヒックがバンと来きたことに事業者としてはうろたえたというか困った状況になりました。この事態を回避するために設備を急きょ調達して増強した会員事業者もいました。急激な負荷を受けた会員事業者は原因をいろいろ調べました。その結果、どうやらワームらしいということ、そのワームはある特定サイトにアクセスしようとしていこと、そのサイトではワームからの一斉アクセスを回避するために、自分側のDNSからAレコードを削除していたことなどがわかりました。この時点ではまだ「何のワームなのか」はわかりませんでしたが、たった一つのウェブサイトに対する DNSクエリで事業者の通信設備が倒れそうになったことだけは明らかでした。サイト側のDNSのAレコード削除がどうして通信設備を倒しかねない事態になったのか？その理由はこうでした。サイト側は自分のサイトを守るためにAレコードを削除したのですが、そうすると当然ISP側のほうに対してはAレコードを引きに行った結果のトラフィックが戻ってきます。「そんなレコードないよ」となるわけです。このワームの場合、名前解決ができるまで無限にAレコードをDNSに問い合わせる作りになっていました。そのため、ワームが広がるにつれてDNS問い合わせが累積的に急増して、冒頭のアクセス爆発に至りました。先ほどのページの第1行目にあった「DNSのA レコードを削除する際の注意点」はテレコムアイザックジャパンの HPでサイト管理者に対して広報したものであると同時に、支援要請を受けるための根拠確立も意図して出しました。つぎは、この告知をみた会員やエンドユーザーが対処の申告をしてきた時の、ISP事業者としての技術的対処方法についてご紹介します。要は、このDNSリクエストが来たときに限り、トラヒックをあるところに全部吸い込んでしま. （4）支援と根拠の確立の確保これは、フォレンジクスではございませんが、「支援の要請を受けました。」という事実を確保しておくことです。支援要請は被害者の申告が基本になりますが、我々は活動を通じて直接ビジネスをしているわけではありませんので、例えば企業のような1エンドユーザーから「助けてくれ」と直接言われても対応するわけにはいかないだろうと思います。やはり会員を経由して「攻撃されているのだが当社一社で手におえない」という支援要請をうけて初めて行動できると思います。では、会員から受けた支援要請の全てに応じることができるでしょうか？会員が連携して対処するにはそれだけ、正当化された、かつ強い根拠が必要に思います。根拠としては、エンドユーザーが被害を受けているという程度ではなく、ISP事業者がサービス運用する通信設備に障害が発生し、安全・安定な運用ができないなど、ある意味で我々の行為を正当化できる理由が必要です。我々の行為を正当化でするために、どのような理由や証拠を集めておくべきか、日頃から考えて、ルール化しておくことが必要だと思っています。（5）技術的な話とマネージメントの話のセット先ほどの話で言うと出方の問題だと思います。我々としてはいろいろな選択肢を持ちたいと思っておりますが、セキュリティに関する技術革新は早く、我々がこういう手を打つと、誰かがそれを回避するようなことを考える、イタチごっこになります。そういう意味で対処技術の導入とか、その定着するということも大切ですし、そして新たな状況が起きたときには、それにキャッチアップしていくようなことをしていかなければなりません。絶え間ない技術進歩のなかで、自分たちがどういうカードを引くかということを考えていかなくてはならないと思っております。大規模DDoS攻撃対応事例の紹介ここからは、テレコムアイザックジャパンの対応事例の紹介として、DDoS攻撃の防御の実例をお話したいと思います。内部事情の話はなかなか出せませんが、とりあえずこの事例に関連した公開情報を時系列的に列挙します。これに沿ってお話を進めます。また、先程来お話してきた、支援根拠の確立・確保の例をこの公開情報と関連づけて説明しようと思います。 1番目の、DNSのAコードを削除する際の注意ですが、 83.

(6) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT うという仕組みを検討しました。試してみるとこれでいけそうだなという話しになったのですが、実はこのワーム、一つのISPの利用者から出ているだけではなく、多数のISP 利用者から出ていました。ということは、自分のところから出てくるのを一生懸命吸い込んでも他のISPのところからどんどん来るので、最悪の場合、吸い込みきれないリスクがありました。自分のところで設定を変えて一生懸命吸い込んでも、やっぱりどうしようもないということです。どうしようもないというのは、他のISPも連携しないといけないということなので、ここで初めてテレコムアイザックとして出番がきました。あるISP会員からテレコムアイザック会員に呼びかけをしてほしいと連絡がありまして、皆さんに相談し各社に持ち帰っていただき、社内調整した結果「よしやろう」ということで各社一斉に対策を実行する連携状況に到達しました。一社でも手に負えなくなったというような中で、いろんなことを積み重ねた結果として、いよいよ出動かなという状況に至ったわけです。会員連携の調整をすると一方で、ワームの特定をアライアンスメンバー等の協力を得ながら進めました。最初は何のワームかよくわからなかったのですが、どうやらアンチニーというワームだということでだんだんその素性がわかってきました。アンチニーというのは毎月第一月曜日、あるいはゾロ目の日、7月7日とか4月4日に攻撃を行うのが特徴だというようなことがわかりはじめてきました。この解析結果をもとに、攻撃発生予定日前に一斉に段取りして、当日はみんなでブラックホールにトラヒックを吸い込むことを行いました。その結果、それまでは悲鳴をあげていた運用設備が救われたと聞いております。ですが、このサイトはまだ依然としてアクセスできない状況であるので、このサイトを助ける手段を検討する話に移ります。当然、我々としても、今後こういうDDoS攻撃は頻繁に起きるだろうという意識がありますので、実態を解明していこう、この攻撃からサイトを救うための技術的検討にアイザックとして取り組んでいる次第です。テレコムアイザック内で取り組むぞということですので、会員にその実施方策を相談しました。「このサーバーを救うためには、どうすればいいのだろう」ということで、「とりあえず現状どれだけのトラヒックがこのサイトに来ているのか実測してみよう」という話になりました。方法としては、図にあるようにかなり太い回線を用意し攻撃トラヒックを受けるだけ受けられるようにして、そのトラヒックに耐えられるルーターやスイッチを用意し、サーバーもダミーサーバーを用意しました。このようなサイトを用意するとなると費用が馬鹿になりませんが、このころになるとこの攻撃を通じてアイザック会員の間にある種の連帯感、一体感が生まれていて、持ち寄れるリソースを持ち寄って実測用のサイトを構築しました。例えば、ギガクラスの回線の現物支給とか、機器設置のために空きスペースを貸すとか、検証用で余っていたスイッチを期間限定で貸. すなどです。そして攻撃日には合図を待って会員がワームから受けたトラヒックをブラックホールに捨てるのではなく、そこに向けて一斉転送しました。で、どうだったか。この図がその時の測定結果です。瞬間的に700MbpsぐらいのDoS攻撃があって、設備的にはだいぶ余裕を持たせたつもりですが、その設備もぶっ倒れそうになるぐらいでした。通常700MBpsのトラフィックを一般ユーザーあるいは、小規模な企業が受けたときには、簡単に秒殺できると思いますが、このような規模のDos攻撃が、いともたやすくインターネットの世界で起きるということです。テレコムアイザックジャパンではいろいろこういう事象を直接観測し、分析をしています。ゾンビPC等を利用したDDoS攻撃アイザックの会員の方々、あるいはパートナーアライアンスの方々と話していると、最近ゾンビPCが多く話題になります。これはDDoSの攻撃ツールとして恐いなというのが皆さんの共通の感想なので、ここですこしご紹介しておきます。昨日のアメリカの国家安全省の方が、アンダーグラウンドサイトでゾンビPCを時間貸しするサイトがあると言っておられました。ユーザーのつなぎっぱなしでセキュリティ対策がされずに放置されたPCが乗っ取られて、ゾンビ化しております。今までのDDoS攻撃パターンでいうならば、少数のIPドレスから大量のパケットを出しているので、特定もしやすく、ひとつつぶせば攻撃がかなり減るので扱いやすかったのですが、ボットネットは様子がちがっています。3000台とか5000台のPCがのっとられゾンビ化してそれをボットネットに組み込みます。ボットネットでは DDoS攻撃開始のコマンドをボットネット配下のPCに出せば、ゾンビPCが一斉にDDoSを開始する仕組みになっています。これまでとちがいやっかいなのは、4桁相当のIP アドレスから攻撃がくること、一台のPCの出す攻撃パケットは非常に少なく、目立たないようになっていること、でもそれが攻撃目標に集中したときに、800メガという大きな攻撃になります。これまでと違い、攻撃元をつぶしにくい状況なので、かなり手強い訳です。あるいはこのゾンビ PCとボットネットを使ってフィッシングの大量メールを分散して投げることなど、いろんな悪用ができると思います。アイザックを運営側の立場で言うと、ゾンビPC、ボットネットに対して何か考えなくてはいけないと思っております。単純な情報共有は「こういう事象がおきました。皆さんにお伝えします。おしまい。」だと思います。実際にインターネットの世界で起きていることを、事実を伝えるということは非常に大事だとは思いますが、インターネットのリスクを減らしたいという本来の目的を達成するためには、単純な情報共有だけではなく、もう少し高度な仕組みの構築が必要だと考えています。すなわち、アイザックと会員間、会員相互、会員とISPサービス利用者との間で、それぞれフィードバックグループをもち、実施した対策の効果 84.

(7) 第９回コンピュータ犯罪に関する白浜シンポジウム REPORT を測定・評価して次の打ち手につなげるような仕組みの構築を目指したいと思います。このフィードバックグループを法的にも、世論的にも満足するような形で構築することは非常に難しい問題だとは思いますけども、ここがある意味、日本流のアイザックのやり方ではないかなと思っています。例えば今の事例で言いますと、攻撃がきているという中で、その攻撃がゾンビPCといわれるところにあるとしてときに、そのゾンビPCをどういう形で叩き潰していくのでしょうか。もちろん、確信犯的にやっているのと、そうではなく、知らない間に乗っ取られてやっていたというのとは、全然違う話になるわけですが、いずれにしても対策のためのゾンビPCへのアプローチをどうするのか、という話があると思っています。情報を一方通行的に出すだけであとは自然に任せて直るまで待つやり方は限界で、一社で手に負えない脅威が日常的に発生している現状では、自然任せ、あなた任せではなく、何かうまく還元するような形に考えていかないといけないと思っています。. い大規模なサーバー攻撃が結構身近にあります。そもそも「テレコムアイザックジャパン、何？」という話とともに、「要らないのでは？」という話があると思うのですが、今のような実例があって、実践的にやっていることを考えると、やはり、テレコムアイザックジャパンのような仕組みは必要で出番があると思っております。ただ、今日お話しましたように、テレコムアイザックの出番・出方というのは、けっこう難しいと思っています。その難しさについて、とりあえず悩みながらもやってみましたというものをご紹介いたしました。この資料を作って提出する直前に、ファイナルファンタジーのオンラインのゲームサーバーがDoS攻撃を喰って、倒れたというような話が分かっています。面白半分でやっているうちはいいでしょうが、これは会員制でオンラインゲームをやっているわけですし、金銭的な被害ももちろん直結する事態になってきているという訳です。そのぶんDDoS攻撃も、巧妙かつ複雑になってきていて、その例としてゾンビPC、ボットネットをご紹介しました。これらうまく対抗していくためには、こういうテレコム事業社間の連携が、不可欠ではないかと思っています。ちょっと時間が超過しましたが、私からの話これで終わらせていただきます。ありがとうございました。. まとめ本日はテレコムのアイザックジャパンの概要をご紹介致しました。テレコムアイザックジャパンの今の活動の実例をお話いたしましたが、ISP事業社1社では手に負えな. 85.

(8)