JANOG9 Meeting Log ・題名 　「迫りくる危機　〜DDoS Attack:理論と対策〜」 ・発表者　大江将史（奈良先端科学技術大学院大学） 　　　　　山賀正人（JPCERT/CC） 　　　　　安東孝二（東京大学） ・日時 　2002年1月25日　12:30〜14:00 ・記録者　NTT-Com 藤原　和弘 ICO 清水 隆宏 -------------------------------------------------------------- ■ セッション紹介 (石田さん） ブロードバンド時代は良いことばかりではなく、それが招きうる危機的状況について会場 とのディスカッションを中心に話し合いたい。 現在ブロードバンド環境の普及で懸念されているのがDDoSアタックであり、インターネッ トのいたるところから攻撃を仕掛けサービス利用不可とするもの。過度のアクセスだけで もDDoSアタックとなりうる。 DDoSアタックは被害が甚大で影響範囲も広く、しかも根本的な対抗策はない。 また、踏み台にされるなど知らないうちに加害者になり、評判を落とすことにもなりうる。 DDoSの例としては ○2000/2/7−2/8のyahooなどの有名サイトに対する攻撃（10億ドルの被害といわれる） ○国内有名IRCサーバに断続的なDDoS攻撃（サービス停止の恐れあり） などが挙げられる。 ----- □安東さん（東京大学）「DDoSターゲットになったら」 ○自己紹介 -アプリケーションレイヤが専門で、ネットワーク運用の業務はあまりない。 -普段は学生やマシンの面倒を見ているが、東京大学は1学年3500人おり、パスワードを配 るだけで3ヶ月かかる。（これはDoSの一種ともいえる？現在は健康診断のときにパスワー ドを配るようにしている。） ○DoS/DDoSってなに？ 自分なりの定義 DoS 「正面玄関から客が1万人くる状態」 DDoS 「某掲示板を見た日本中の2ちゃんねらーが正面玄関から10万人入ってくる状態」 -メールの場合、一箇所からたくさん送られてくるのはあるが、何とか対策が取れる。 -しかし世界中のオープンリレーサーバからくると対応できない。（複数箇所からはつら い） -DoSはシンプルな力技で、DDoSはパラレルな工夫をした力技。（DDoSのほうがいやらし い。） -DoS Likeな話しは日常の中でも多い 例１）同級生全員（3500人）にメールを出す 　　　 　　　それにリプライをだす 　　　そういうことをやっちゃいけないと全員にメールを送る　など 例２）メールのピンポン 例３）年二回の有明方面の交通機関 例４）あけおめコール ○DDoSの大きな分類 -ルータCPUひいひい系 -バンド幅食いつぶし系（こっちのほうがいや） ip directed-broadcastなど、楽にパケットを増幅できる仕組みが悪用される ○東大でのSMURFの記録 -ICMPエコーリプライが世界中から送られて本郷とブランチの帯域があふれそうになった ことがあった。（70-80M） -ターゲットマシンはIRCサーバで、各地のdirected-broadcastを禁止していないルータを 利用された -発信元はなかなか対応してくれない場合もある -その時の対策 ECHO-REPLYだけ遅いネットワークを作り、ルーティングした先でHUBに突っ込む ○DDoSへの対応 -DDoS避けることはできない（対応方法に王道はない） supersinetと10Gで接続＝10Gでアタックされてしまう？ ブロードバンドな一般家庭も集まると怖い さらにCoderedやNimdaなど、本人が気づかないうちにやられるほうがもっと怖い -DDoSアタックは各種アタックの複合体であり、ネットワークレイヤだけでは対応できな い。 -全体的にわかっている人と協調しながら対応する必要がある。 ----- □山賀さん（JPCERT/CC）「DDoS -CSIRTの立場から-」 ○CSIRTとは Computer Security Incident Response Team JPCERT/CCは日本で唯一世界に認識されているCSIRT ○なぜJPCERT/CCがJANOG9に？ -今まで広報活動をあまり積極的に行なってこなかったため、何をやっている組織なのか 世間にはあまり知られていない。 ->今後はもっと知ってもらう必要ある（現在は広報活動にも力を入れている） -オペレータとのパイプは本当はとても重要なので今後もつながりを持ちたいと思ってい る。 ○スキャン、プローブ -脆弱性の情報が発見された時期とピークが重なる SSHの脆弱性が発見されると22番へのスキャン増える -情報提供が容易な仕組み（たとえばIDS＋スクリプト処理）や受付が容易な仕組みを考え ていきたい -情報の公開の形式については検討中（週報など） -受け付け体制ができたら協力してください ○DDoSのインシデント報告 -CodeRedやNimdaの感染の試みに関する報告は多数あったが、サービス停止までには至っ ていない場合が多いため、DDoSとしての報告はさほど多くは届いていない<-単なるスキャ ンにしか見えない -日本のどこかから変なアタックが来ているとの報告が海外からあった場合、ISPなどに連 絡して、踏み台にされているマシンについて対応してもらったりするが、こういった「も ぐらたたき」的やりかたでは限界がある ○そもそもDoSって何か? -どの程度からDoSか？ -JPCERT/CCとしてはわからないのが実情 報告者が「DoS攻撃を受けた」と言っていれば、それはDoSなのだと判断するしか ない 今後も皆さんからの様々な情報提供お待ちしています。 ----- 奈良先端技術大学院大学:大江さん 〜DDoS防御に向けてIPtraceback〜 ●この公演を始める前に ・率直な意見が聞きたい ＞現場の人達はどう考えているのか？ 学術と現場の人間の考えのすりあわせを行いたい。 ・今ないもの IETFによる標準化 ●DoS攻撃と対策 DoS攻撃とは? 脆弱性を付くもの CodeRedなど システムへの対策法 ベンダ提供のパッチをあてる 該当サービスの停止を行う Traffic集中によるもの 分散->集中 Trafficの特定と遮断が対策となる ＞Traffic集中型 発信元addrは詐称されている 経路特定にはtracerouteなどは使えない 非対称経路 詐称が無かったとしても、経路が異なることが多いため、攻撃フローを特定 する事は難しい。 ●対策 攻撃フローの特定を行うには ISPや企業等の協力で追跡することが必要 境界を越える追跡における時間労力 ＞特にポリシーの違う個所など ●IPトレースバック 攻撃パス/攻撃ノードの探索方法 ネットワーク上での付加機能により、攻撃パスを生成する 早めに攻撃フローが判れば、Traffic通過個所のrouterなどに対策を講じることが 可能になり、被害は押さえられる。 ●関連研究 探索方法としては以下のような方法があるが、各々に得意不得意がある。 手法の分類 ＞リンク追跡法 攻撃フローをモニタリングして追跡する方法(従来型) 順番にルータごとに調査する 1.DoS攻撃フローは何処からを調べる 2.そのIFへのfilterをかける 3.届かないようになるのはどこかを特定する 4.この結果でどこから来ているのかを特定する ISPをまたいでいるときは、その上流のISPでも同様の調査を実施する。 　 　　 この方法の改善 境界ルータから追跡ルータへのトンネルを構築する。 攻撃フローを一点に集中して調査する(集約化) 短時間で調査可能だが、連携が必要になる。 ＞逆探知パケット法 攻撃フロー特定に専用のパケットを使用する方法 ICMPトレースバック(IETF) 　　 1.各ルータが確立Pに従って、パケットを選定 2.通過ルータのアドレス等を記録したiTraceメッセージを確定されたDestinati on Addressに送信する。 3.iTraceメッセージから攻撃パスを特定する。 パケットの情報と出入りしたportの情報をICMP上のメッセージに埋め込み、送 信する。 欠点 新たにパケットが送信され、追跡用Trafficが生成されてしまう。 ＞マーキング型 現在使っているパケットのIP fieldであまり使っていない部分に必要情報を付加 して追跡する方法。 ※必要情報: 通過ルータの情報、前後ルータ関係など savage 識別子fieldへ記録 アタッカーから送られたパケットにルータを通るたびに上記情報を組み込んで いく。これらの情報を集まった段階で統計して、攻撃フローを特定する。 ただし、アタッカーがこのfieldを使った場合追跡できなくなる。 また、すべてのルータにこの機能を実装する必要がある 一番使いづらそう。 ＞ダイジェスト型 BBN社がSPIEとして提案 効率よくパケットの通過logを記録しておく。 ※効率化のために、特徴などの情報をハッシュ化してビットマップ情報を記 録する。 攻撃フローのパケットを元に、記録を照合して攻撃フロー経路を特定する。 長所 　 1パケットのlogでも追跡が可能 ＞他の追跡方法は確立に従っているので1パケットでは判断できない。 組織内追跡には有効 短所 log転送システムへの攻撃が発生 各ルータからのlogを特定のagentに対して、送付する。 ＞データバックアップシステムとの連携必要 ●各方法の弱点 　・ICMPトレースバック 　　メッセージの正しさの証明が難しい 　　＞これが実装されたらアタッカーはこのパケットを詐称してしまう。 　・マーキング 　　フラグメントIPsec,IPv6などと互換性が無い(新しいテクノロジに弱い) 　　抗トレースバック攻撃への弱さ 　　精度を上げるためにはルータの接続図を公開しないとならない。 ＞現実的には難しい 　・SPIE 実時間追跡に制約がある 変形パケットの記録には、ルータのメモリが必要 ●共通の問題 　ISP間の密接な協力体制が必要 構成情報など ネットワークトポロジなどの秘密情報が漏洩 トレースバックによりトポロジーが判ってしまう。 大規模な認証機構が必要 スケーラビリティ 配備されていないISPからの攻撃は特定できない 攻撃手法の進化 抗IPトレースバック攻撃 これらの問題をふまえて奈良先端大ではこれを提案する ・階層型IPトレースバック手法 トレース範囲を分離する 組織内/組織間 ・eIPトレースバック 攻撃NodeのASを特定する。 ・iIPトレースバック じわじわと追いかけていく ●標準化の動き 　・IPPT-BOF(OPS) 　　BBNの商用面が強い 　・iTrace-WG 　　実用性が弱い ●今後の予定 実装 プロトタイプ実装(eIP) NP ベースのハード(iIP) ----------- 質問 Q. 水越さん DDoSなどに対して答えは無いが、各パーツ(見つけ方など)の分類はできると思う 各自の善意ではなく金をかけてでも調べるべきだと思う。 通信事業社としては、だすのが難しい。 何が起きているかの情報を集める事にも力を注ぐべき アクセス事業社で終わっているDoSもある。 一業者だけでは判らない事象が発生しているような事の情報を共有しなければいけないと 思う。(報告義務をふまえて) A. JPCERT/CC 山賀さん 情報を収集することについてはJPCERT/CCとしても検討しているが、 予算上の問題などもあり、なかなか思うようにできていないのが実情。 しかし、このままではいけないので、これについては今マジメに考えている。 ボランティアの協力を募るしかないのではないか。 A. 安東さん お金が無い問題に付いては、JPCERTにお金を寄付してでもやらないといけないのではない か。 Q. 矢萩さん ブロードバンド常時接続ユーザが増えていて忙しい中でDoSアタックに備える準備をする のはかなり難しい。(手が回らない) 自分の中で閉じているものについても判らない。 同じADSL業者でもPolicyがあってtraceしづらい面もある。 義務化されると厳しいが、何とかしないといけないとは考えている。 A. 石田さん 問題意思の確認は出来たと思う 引き続いて、議論をする必要がある。 Q. 前村さん JPCERTにお金が回るための仕組みを作るべきでは。。 また、PeeringAgreementを作るときにこう言う意味を含めるのも方法ではないか。