1 / 104

前置き

前置き. 短い時間なので 詳しいことを説明できません 250 以上のスライドを準備したので聞いてください すべての実験の結果は発表できません Burrows:0, KUMO:3, sPoW:3, Overfort:3, AI-RON-E:4 実現がある研究 KUMO, sPoW 18,526 行 + 6061 行 ( 実験 ) AI-RON-E 1,221 行 (C ライブラリー ) + 6,363 行 ( アルゴリズム＋実験 ) シミュレーションコード Overfort 1500 行.

zelig
Download Presentation

前置き

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 前置き • 短い時間なので • 詳しいことを説明できません • 250以上のスライドを準備したので聞いてください • すべての実験の結果は発表できません • Burrows:0, KUMO:3, sPoW:3, Overfort:3, AI-RON-E:4 • 実現がある研究 • KUMO, sPoW • 18,526行 + 6061行(実験) • AI-RON-E • 1,221行(Cライブラリー) + 6,363行(アルゴリズム＋実験) • シミュレーションコード • Overfort • 1500行

  2. 実世界に展開可能なDDoS攻撃防御メカニズム(Deployable DDoS Resiliency) Ph.D. Candidate: Soon HinKhor Advisor: Assoc. Prof. Akihiro Nakao

  3. 目次 • DDoSの定義と種類 • モチベーション • 目標 • 関連研究 • アプローチ • 各研究 • まとめ

  4. Distributed Denial-of-Service (DDoS) インターネット 混雑 ネットワークボトルネック サーバ ボトルネック

  5. DDoS種類 • スプーフ/ネットワークレイヤDDoS(フィルタ可能） • フィルター不可のDDoS • 経済的DDoS (economic DDoS: eDDoS)

  6. スプーフ/ネットワーク層DDoSとは スプーフDDoSの目的はトレースバックを不可能にすること スプーフ ソース 内容 $8&@ ランダム ネットワーク層DDoSの目的は輻輳 混雑 ネットワークボトルネック サーバ ボトルネック

  7. フィルター不可のDDoSとは DDoS防御 輻輳（混雑）なし DDoS防御によりアタック トラフィックをフィルターする

  8. フィルター不可のDDoSとは(cont.) 区別不可トラフィック 通常パケット を多量に送る ことで攻撃する 例えばページダウンロード DDoS防御 フィルター不可DDoS 輻輳（混雑） ネットワークボトルネック フィルター不可DDoSは 一般のDDoS防御をすりぬける サーバ ボトルネック

  9. クラウドは新しい種類のDDoS攻撃を可能にする＝＞eDDoS攻撃クラウドは新しい種類のDDoS攻撃を可能にする＝＞eDDoS攻撃 インターネット クラウドに実装されたネットワークサービス

  10. 新しい問題: 経済的DDoS (eDDoS) クラウドではユーザがアクセスした トラフィック量に応じた課金が発生 DDoS攻撃は 大量課金を意味する インターネット DDoS攻撃の トラフィックにより 帯域の従量課金が発生 $$$$ 混雑なし 帯域とサーバ処理リソースをオンデマンドに確保可能 (Elastic Computing) eDDoS クラウド オフライン

  11. eDDoS:未解決の問題 • http://developer.amazonwebservices.com/connect/message.jspa?messageID=120089 aiCache 今までのツールはeDDoSへの対策ができない(11 Mar 2009)

  12. eDDoSが起こったら。。。 • 歴史的データ • BetCrisのDDoS, Nov 2003, 1.5 – 3Gbps • DNSルートサーバのDDoS, Mar 2007, 1 Gbps • 仮定：1GbpsのDDoS, データ転送コスト：$0.1/GB • 24時間 => 24 * 3600 * $0.1/8 ~ $11,000 • インターネット予約制コスト • T3 (45 Mbps) ~ $3,000 to $12,000/月 • OC3 (155 Mbps) ~ $15,000 to $100,000/月 • http://www.broadbandlocators.com/

  13. 研究のモチベーション • エンドユーザ調査 • CSI Computer Crime 2008 • 21%回答者はDoSを受けた • インターネットプロバイダー(ISPs)調査 • ArborNetworks Infrastructure Security Report 2008 • 21%回答者によるとDDoSに管理リソースの消費が一番多い • 測定研究の結果 • 「Inferring DDoS」の論文(Savage et al.) • 2001-2004: 68,700DDoSは5,300ドメインにわたる 誰にとってもDDoSは深刻な問題

  14. 研究のモチベーション • 最近10年のDDoSの研究: • 2000: CenterTrack, Blackhole routing • 2001: DPF, Traceback ICMP, Algebraic traceback, Various traceback • 2002: D-WARD, SOS, Pushback • 2003: HCF, Capabilities, Mayday • 2004: SIFF • 2005: WebSOS, AITF, TVA, Route & Tunnel • 2006: Speak-Up, Flow-Cookies (CAT) • 2007: Portcullis • 2008: Phalanx • 2009: StopIt 実世界に展開可能なDDoS防御 メカニズムは無い eDDoSに対策 メカニズムは無い

  15. 目標 実世界に展開可能なDDoS防御メカニズム 1. 展開の敷居が低い • ルータを変更する必要がない • 自ら実現可能 • 消費リソース（時間とお金）が少ない 2. 3種類のDDoSに対策可能 実世界に展開可能なDDoS防御 メカニズムはなし 解決 eDDoSに対策 メカニズムは無し 解決

  16. 実世界に展開可能なDDoS防御 メカニズムを設計するに対する問題とは何？

  17. 最先端DDoS防御の一つ 接続リクエスト R1 R3 インターネット R2 R4 賛成証拠を支配 接続リクエスト R1,R2,R3,R4 DDoS防御技術応用 ISP A 賛成証拠を作った ISP B 正 正 正 正 正 正 ISP C

  18. 最先端DDoS防御の一つ(cont.) 認証なし DDoSパケット 盗んだ証拠 DDoSパケット R1 R3 各パケット インターネット R2 R4 ＝パケットがこの経路を通ることをサーバが認証した 認証経路ではない 混雑なし ルータを変更する 必要がある DDoS防御技術応用 ISP A ISP B サーバトラフィック コントロール 正 正 正 正 正 正 正 正 ISP C

  19. 最先端≠展開可能 時間とお金がかかりすぎる • 多くの無関心他者に依存する • 自らで実現できる • リソースの獲得が難しい • 自らのリソースで構築 • インターネットルータの変更が困難 • エッジノードを使う 実世界に展開不可 インセンティブ 3事業体 変更の容易さ 10ロケーション

  20. 展開可能性を測る指標 • Deployable Resiliencyという指標を定義 • インフラ（インターネットルータ）の変更の度合い • インセンティブ（展開するための動機付け） • 様々なDDoSに対する対策効果 1. スプーフ/ネットワークレイヤDDoS 2. フィルター不可DDoS 3. eDDoS

  21. 関連研究 目標 サーバ反応 クライアント反応 防止 抑止 変更の容易さレベル 丸のサイズ => 効果 インセンティブレベル

  22. 意義 目標 サーバ反応 クライアント反応 防止 抑止 経済的 KUMO sPoW Overfort AI-RON-E 変更の容易さレベル 丸のサイズ => 効果 Burrows インセンティブレベル

  23. eDDoS防御 質問：sPoWの研究は関連研究と比べればどこまで特殊ですか 答え#1：“mitigation eDoS”のキーワードをGoogleで検索すればTop20結果の中でsPoWが出る 判例#1：eDoSのキーワードはsPoWの論文で全然使わなかった 判例#2：“eDoS”と“eDDoS”は違う言葉です 答え#2:“mitigation eDDoS”のキーワードをGoogleで検索すればsPoWはNo.1の結果です eDDoSはかなり新しい問題です sPoWの研究は関連研究をちょっと調整して本研究になるものではない

  24. 目標 実世界に展開可能なDDoS防御メカニズム 1. 展開の敷居が低い • ルータを変更する必要がない • 自ら実現可能る • 消費リソース（時間とお金）が少ない 2. 3種類のDDoSに対策可能 実世界に展開可能なDDoS防御 メカニズムはなし どのような手法で実現可能？ 対策 eDDoSに対策 メカニズムは無し 対策

  25. アプローチ 依存関係 （〜に基づく） 目標 ??? 自らのリソースのみで実現可能 自ら実現可能な 多様なDDoSの対策 クライアントが自ら 対策可能 自らのリソースのみで実現可能 インターネットの堅牢性を向上 補足DDoS防御メカニズム

  26. 学会発表情報 • Power to the People: Securing One-Edge at a Time • ACM SIGCOMM Large-Scale Attack Defence (LSAD) Workshop 2007 • 採択率:(オフィシャル:45%) • Ovefort: Combating DDoS with Peer-to-Peer DDoS Puzzle • IEEE International Parallel and Distributed Processing Symposium (IPDPS) Secure Systems and Network (SSN) Workshop 2007 • 採択率:不明 • AI-RON-E: Prophecy of One-Hop Source Routers • IEEE Globecom Next Generation Networks (NGN) Symposium 2008 • 採択率:(内示:36.8%) • sPoW: On-Demand Cloud-Based eDDoS Mitigation Mechanism • IEEE/IFIP HotDep Workshop 2009 • 採択率:(オフィシャル:37%)

  27. 発表順番 • Burrows • KUMO • sPoW • Overfort • AI-RON-E

  28. 各研究の目次 • 意義 • 概要 • 結論 • Deployable Resiliencyが高い理由

  29. Burrows: 意義 最先端 最先端≠展開可能 Burrowsでこの三つの問題を解決！

  30. 最先端DDoS防御の一つ サーバの認証なし DDoSパケット DDoSパケット インターネット サーバの認証なし DDoS防御技術応用 ISP A ISP B ISP C

  31. 防御が多くの無関心な他者に依存する問題 サーバの認証は無し DDoSパケット DDoSパケット インターネット サーバの賛成は無し DDoS事件 DDoS防御技術応用 現在のインターネットセキュリティは様々なISPに依存する ISP A 無関心なISPは 防御を実装する 動機がない ISP B ISP C

  32. Burrowsのアーキテクチャ ルータで行っていた防御をエッジに移動 インターネット エッジノード による中継を強制する サーバには直接接続できない DDoS防御技術応用 ISP A ISPは応用しない ルータの変更は必要ない =>実装展開しやすい ISP B ISP C サーバAオーナー

  33. Burrows:アーキテクチャ 中継ノードの目的：トラフィックコントロル 例：悪いパケットを区別できればネットワークレイヤDDoSへの対策できる セキュリティを実現するために 中継ノードにしか依存しない インターネット 中継ノードを 介してサーバに接続 エッジノード による中継 DDoS防御技術応用 ISP A ルータの変更は必要ない =>実装展開しやすい ISP B 無関心な人に依存しない ISP C サーバAオーナー

  34. Burrows:アーキテクチャ 中継ノード経由経路が多くあればそれだけDDoS防御力が強くなる セキュリティを実現するために 中継ノードにしか依存しない 協調プラットホーム インターネット エッジノード による中継 エッジノード による中継 DDoS防御技術応用 ルータの変更は必要ない =>実装展開しやすい サーバAオーナー サーバBオーナー 経路数は二倍になる

  35. Burrows: 結論 Burrowsフレームワークを採用すればDeployable Resiliencyが向上する 最先端 最先端≠展開可能 中継ノードのみに依存する Burrowsでこの三つの問題を解決！ 協調プラットホーム エッジノードの利用

  36. アプローチ 目標 基づく ??? セキュリティに協調でDDoS防御リソースを集合する 展開可能性の向上

  37. KUMOアーキテクチャの意義 リソースの獲得が簡単 Burrows リソース協調プラットフォーム KUMO 自分自身のリソースのみで実現 あらゆるインターネットシステムを中継ノードとして利用可能 Pay-as-you-use DDoS防御 (ユーティリティコンピューティング)

  38. KUMO:フレームワーク Write-onceコードエクステンション: データ送信/受信 経済的なインセンティブ インターネット CDN KUMO ぜロインストール クライアントサイド IRC フォーラム （掲示板） $ KUMO サーバサイド $ $ $ Web2.0 サーバ クライアント 変更無し 変更無し あらゆる中継ノード ネットワークスタック機能 送信/受信 再送信リクエスト/再送信 分割/再構築 等。。。 変更無し

  39. KUMOクライアントとサーバサイド リスニングチャネル インターネットシステム KUMOクライアントサイド KUMOサーバサイド プラッグインリスト • IRC • Forum • I3 • Flickr • S3 • Direct • & Hybrids サーバ クライアント KUMO DNS 中継ノードリスト ダイナミックDNS

  40. KUMOサンプルサーバコード コメント ベースコード 1 # NOTE: Lines beginning with # are comments 2 @kumo_controller = KUMOCompositeChannelController.new 3 @ksside = KSside . new( @kumo_controller ) 4 @ksside.start 5 # Parameter descriptions : 6 # domain : The domain name the listening socket is for 7 # send_domain : The name of destination where reply should 8 # be sent . Usually this is just the listening ”domain” 9 # with some appended with random number to create a 10 # unique destination. 11 # output : The contents of the connection request 12 # sockid : The socket ID used to send reply 13 @ksside.register_ic_handler ( domain ) { | domain , send domain , output , 14 sockid | 15 . . . 16 # insert code to perform task when a connection request is received 17 . . . 18 } アプリケーションコード コネクションリクエスト 受信の際のコード

  41. KUMOサーバサイド サーバのベースコード インターネットシステム コネクションリクエスト受信の際のコード KUMOクライアントサイド KUMOサーバサイド プラッグインリスト • IRC • Forum • I3 • Flickr • S3 • Direct • & Hybrids サーバ クライアント リスニングソチャネルを作成 KUMO DNS Intermediary list ダイナミックDNS DNSリクェスト ハンドラー

  42. KUMOサンプルクライアントコード コメント ベースコード 1 # NOTE: Lines beginning with # are comments 2 # Parameter descriptions : 3 # send_domain : the destination domain name of the data to be sent 4 @kumo_controller.start_all_channel_sets_for_domains ( [ send domain ] ) 5 # The values of the parameters are : 6 # send_msg : The data to be sent 7 # reply : The reply from the server 8 # reply_sockid : The socket ID through which we can respond 9 # to the reply we receive 10 # processed : True if we decide to handle reply . Advance use only . 11 @kumo_controller . send ( send_domain , send_msg ) { | reply , reply_sockid , 12 processed | 13 . . . 14 # insert code to perform task when reply to data sent is received 15 . . . 16 } アプリケーションコード コネクション リクエストの 返信をもらう際コード

  43. KUMOクライアントサイド クライアントベースコード インターネットシステム コネクションリクエストの返信をもらう際コード KUMOクライアントサイド KUMOサーバサイド プラッグインリスト • IRC • Forum • I3 • Flickr • S3 • Direct • & Hybrids サーバの接続方法 サーバ クライアント KUMO DNS Intermediary list ダイナミックDNS DNSリクェスト ハンドラー

  44. 実験：目的 データ転送スピードは？

  45. 実験 =1600組み合わせ 5 x 8 x 20 i3 7k 7k 5回x1600=8000回 Flickr 22k 22k Amazon S3 51k 51k フォーラム 101k PLノード 101k PLノード IRC 449k 449k HTTP転送

  46. データ転送に要する時間 転送かかる時間(s) Criticalアプリケーションのavailabilityを提供する 適度スピード h-forum, h-flickr, h-S3 速いスピードIRC, I3 < 10kB Interactive アプリケーションを提供できる 速いスピードI3 < 100kB フィアルサイズ(log)

  47. KUMO:結論 KUMOフレームワークを採用すればDeployable Resiliencyが向上する 自分のリソースのみで構築 あらゆるインターネットシステムを利用可能 変更無し

  48. アプローチ 基づく 目標 ??? 展開可能性の向上 自ら実現可能な 多様なDDoSの対策

  49. sPoW:意義 • KUMOに基づいてDeployable Resiliencyを向上する • インフラ（ルータ）の変更無し • Pay-as-you-useシステム • 3種類のDDoS攻撃に対策可能 中継ノードとしてクラウドを使う PoWのコンセプトを採用する 自動検証PoW

  50. sPoW:クラウドを利用したKUMO DDoS不可の クラウド トラフィック コントロール 少数の中継ノード 信頼できる中継ノード ローコスト(ユーティリティコンピューティング) Amazon EC2 Cloud インタメディアリ DDoS不可の リンク スプーフ/ネットワークレイヤDDoS防御 サーバ クライアント DDoS不可の リンク DDoS不可の クラウド Google AppEngine 中継ノード トラフィック コントロール

More Related