ION Tokyo: Keynote Presentation -- "Can we go back to the original? A Return to the end-to-end principle" by Dr. Shin Miyakawa

Copyright © NTT Communications Corporation. All rights reserved.
我々はもともとのインターネットを取り戻せるか？
Can we go back to the original ?
- E2E原則への帰還 / A return to the End to end principle -
Dr. Shin Miyakawa NTTコミュニケーションズ（株）
Director, Technology Development Department 技術開発部担当部長
NTT Communications Corporation 博士（工学）宮川晋
2014 Nov. For ION TOKYO 平成二十六年十一月

近未来のインターネット
インターネットは変化しています。これからのThe Internetがどの
ようになるのか、また、どのようにしていけばよいのか、皆様と一
緒に考えてみたいと思います。

もともとのインターネットを振り返る
 そもそもインターネットアーキテクチャは「End-to-End原則」
に基づいて設計されています
 では、このEnd-To-End原則（End-To-End Principle）とは何で
しょうか？

End to End 原則とは？ / What is E2E principle ?
 The end-to-end principle states that application-specific
functions ought to reside in the end hosts of a network
rather than in intermediary nodes – provided they can be
implemented "completely and correctly" in the end hosts.
 From Wikipedia
 エンドツーエンド原理では、アプリケーション固有の機能がネ
ットワーク終端のホストで「完全かつ正しく」実装できるなら
、ネットワーク内の中間ノードではなく終端のホストで実装さ
れるべきだとする。
 同じくWikipedia より
 すなわち「インテリジェンス」は端末にあります。網はDumb
Networkとも呼ばれ、パケットを転送することだけを期待され
ています。

E2E
ネットワークはただ
パケットを端末に届けるだけ
端末で処理を行う端末で処理を行う

一方、いわゆる「電話網」では
 従来の電話網は、交換機と伝送装置で構成されるネットワーク
側に基本的にはほとんどの機能を持たせ、端末すなわち端末に
は従属的な機能しか持たせない構造となっています。
 すなわち「インテリジェンス」は網側にあります

電話網
色々な処理は
ネットワークで行う
端末はNWに
情報を届けて
あとはお願いする
端末はNWに
情報を届けて
あとはお願いする

End-2-End 原則があると何がよいのでしょうか？
 よく論文では通信がより障害に強くなる、といったことが利点
としてあげられていますが、私は、最大の利点は
新しいアプリケーションが、
簡単に導入できること
 であると考えています。

E2Eなネットワークなら
 電話網のような中央制御なネットワークでは、新しいアプリケ
ーションを導入するにはネットワーク全体での対応が必要です
が、E2Eなら、最低、二台の端末が合意すれば新しいアプリケー
ションを導入することができます
Network

すなわち新アプリケーション導入の敷居が非常に低いので
 どんどん新しいアプリケーションが出てくる
 FTP
 メール
 Web
 チャット、SNS
 …
 どんどん使われるようになる
 Google
 Facebook
 …

トランスポートだってそのはず！
 E2Eなネットワークなら、真ん中はパケット運ぶだけなんだから
、端末が二台合意さえすれば、UDPやTCP以外にも、もっと便
利なトランスポート(アプリケーションを支える通信の運び方の
種類)もいろいろと使えるはず！
 便利なトランスポートは、より便利なアプリケーションをつく
れるはず！
• セキュリティを高めたり(IPSec)
 移動する端末をサポートしたり(MobileIP)
 …
あれ？ホントにそうなってる？

TCPとUDP以外のトランスポートは残念な感じ
 いろいろと提案も実装もあるのですが、なかなか他のトランス
ポートは流行っていません。
 TCPの上に組み立てられたSSL、HTTP…は大流行中
 UDPの上に組み立てられたRTP、DNS、IPSec over UDP…も大
流行中
 って、結局、ほとんどTCPとUDPだけじゃないですか。。。

NAPTやファイアウォールが…
 あちらこちらに存在するNAPTやファイアウォールが、TCPと
UDP以外は通してくれないのです。
 そもそも最近はTCPやUDPだって単純には通してもらえません
Approved TCP or UDP (and ICMP) ONLY!

TCPやUDPでさえ、NAT Traversal も大変だし、
不可能なときも多い
 NATの外から「着信」させるためには工夫が必要です
 VoIPの実現のために多大な苦労をする羽目になりました
 企業網だと、わざと不可能にすることさえあります
 新しい技術のWebRTCでも苦労するだろうと予想されます

実は純粋なE2Eへの回帰はもはや難しい
 NAPTやファイアウォールの存在
• NAPTはv4からv6にすれば無くせる可能性が高いが
• 現在のアタックが横行するインターネットでは、IPv6の時
代になっても必ずファイアウォールは残る
 ということは、あらかじめ許可されたパターンの通信しか許さ
れない、ということになる
• 新しいトランスポートは絶望的
• 新トランスポート前提のアプリも
むつかしい

IoTや組み込み機器、古い端末があるので・・
 システムのセキュリティ脆弱性の更新を全て行い続けられるの
は理想ですが、実際には不可能といってよいので、これからは
いままで以上にホワイトリスト型ファイアウォール（基本的に
全ての通信を遮断したうえで、事前に吟味した通信のみが事前
に吟味された相手とだけ可能になるようなファイアウォール）
が流行るのではないかと思います。
 そうなると、新しいトランスポート、いえ、新しいアプリケー
ションさえ、それを導入するためには、ネットワーク側での調
整が必要になることから、どんどん阻害されていくことがあり
えます。

通信の中身をチェックする必要性が増えてきてしまった
 標的型攻撃の実態は相当なもの
• テーラーメードなマルウェアや長期間（例えば3か月以上）
市販のセキュリティ対策ソフトに引っかからないマルウェア
も大量に存在します
• 「悪性サイト」も神出鬼没です
• DPI（Deep Packet Inspection）やSandBoxによる検査な
どが必須な情勢です
 DDoSも大変な状態
• 数百Gbpsが一挙に押し寄せたりします
• 小規模な（といってもターゲットになっている身からすれば
大規模な）DoS は常に起きているとおもってください
 ネットワーク側での防御が必要

Copyright © NTT Communications Corporation. All right reserved.
マルウェアのはびこり具合
NTTコミュニケーションズ株式会社技術開発部
担当課長畑田充弘の資料「NTTコミュニ
ケーションズにおけるブラックリスト生成基盤
“CLOSER”」より

ブラックリスト（BL）
19
感染防止＝入口対策早期発見・拡散防止＝出口対策
既存サービスとのシナジーも踏まえた独自のBLでマルウェアに対抗
インターネット
FW
拠点A
拠点B
拠点C
インターネット
FW
拠点A
拠点B
拠点C
BL
マルウェア C&C
新鮮悪性根拠カバレッジ
BLの要件

“CLOSER”全体アーキテクチャ（エコシステム）
20
CLOSERWeb巡回型
ハニーポット
マルチ
ウイルススキャナ
サンドボックス
シードコレクター
FIXERFIXER
RELIEF*等RELIEF*等
BL-DB
IDS/サンドボックス等IDS/サンドボックス等
*NTT-SC研が開発・提供しているブラックリスト配信システム
http://www.ntt.co.jp/journal/1208/files/jn201208013.pdf
待ち受け型
ハニーポット

CLOSER 主要コンポーネント
 待ち受け型ハニーポット
 ワームタイプのマルウェア収集
 Web巡回型ハニーポット
 Drive-by download攻撃のWebサイト・マルウェア収集
 マルチウイルススキャナ
 収集したマルウェアをアンチウイルスソフトで検知
 サンドボックス
 収集したマルウェアの動的解析を行い通信先URLを抽出
 シードコレクタ
 外部から収集したURLやマルウェアをディスパッチ
 （FIXER）
 BLをFW等へ配信、検索・オンデマンド解析要求
21
※CLOSERはBLを生成するだけでなく製品評価や実験の基盤でもある

 マルウェア収集状況（2013/4~）
 10,000/日超のマルウェア（Confickerが大半）
 500/日程度のハッシュユニークなマルウェア
待ち受け型ハニーポットからの解析
22
0
5000
10000
15000
20000
25000
0
500
1000
1500
2000
2500
3000
3500
4000
4/1
4/8
4/15
4/22
4/29
5/6
5/13
5/20
5/27
6/3
6/10
6/17
6/24
7/1
7/8
7/15
7/22
7/29
8/5
8/12
8/19
8/26
9/2
取得回数(左軸)
ユニーク数(左軸)
ユニーク累積数(右軸)

 検知状況（2013/8/25〜9/6）
 2,200〜2,400/日のユニークURL
 長期にわたって存続するサイトあり
Web巡回型ハニーポットからの解析
23
悪用された脆弱性件数
MS06-014 13028
MS09-002 3134
CVE-2008-2992 184
CVE-2010-0188 71
CVE-2009-0927 37
CVE-2012-1723 35
MS06-057 28
MS10-018 21
MS06-055 17
CVE-2009-0658 11
CVE-2010-0886 4
CVE-2012-0507 1
CVE-2007-0071 1
※入口/攻撃/配布で重複するURLも含む
0
1000
2000
3000
4000
5000
8/25
8/26
8/27
8/28
8/29
8/30
8/31
9/1
9/2
9/3
9/4
9/5
9/6
マルウェア配布サイト
攻撃サイト
入口サイト

 通信先URLを抽出
 C&C、２次検体、情報送信
 抽出したURLの例
サンドボックス
24
 感染したコンピュー
タの情報を外部へ
送信
 実行ファイルを
ダウンロード
 IPアドレス/接続性
確認
www.****monetizer.com/index.php?ts=1372854696&Net1.1=&
Net2=3.5.21022.08&Net4=4.0.30319&OSversion=NT5.1SP3&Slv
=&Sysid=E1028DADC58D1944A106C96A937A9544&X64=N&a
dmin=Y&browser=IEXPLORE.EXE&exe=dflt_sample&lang_DfltSy
s=0409&lang_DfltUser=0409&screen=800x570&ver=1.1.4.38
charm.****xr.com/CHARM.exe?RND=GVVB_
checkip.dyndns.org
www.google.com

シードコレクタ
25
 外部からデータを収集
 RELIEF等のブラックリスト
 各サービスのセキュリティ機器等のログ
 FW/IDS/アンチスパム/DPI等の検知URL
 サンドボックスで解析したファイル
 同意を得た上で実ユーザトラフィックから
 セキュリティ機器等から収集したデータの再検査
 URL：Web巡回型ハニーポット
 ファイル：マルチウイルススキャン、サンドボックス
BL
：
ユーザに特化したBL生成の肝

脅威に関するカテゴリ分類
大分類中分類小分類 FW Action例
入口対策用入口サイト Alive Drop
Dead Alert
攻撃サイト Alive Drop
Dead Alert
マルウェア配布サイト Alive Drop
Dead Alert
出口対策用 2次検体取得先直近3ヶ月 Alert
3ヶ月以上 Alert
C&C、情報送信先等直近3ヶ月 Alert
3ヶ月以上 Alert
26

属性情報（抜粋）
属性内容
URL ブラックリストに登録されたURL
FQDN URLのFQDN
IP Address FQDNに対応するIPアドレス
Country 国名コード
ASN AS番号
Netname ネットワーク名
UrlClassResult 悪性判定種別
（入口サイト、攻撃サイト、マルウェア配布サイト、2次
検体取得先、C&C・情報送信先等）
Detect 検知した攻撃のCVE番号等
Sha1/MD5/Sha256 マルウェアのハッシュ値
ScanResult マルウェアのマルチウイルススキャナ検知結果
CreateTime/UpdateTime 初回検知日時/更新日時
27

評価
 あらためて
• 悪性サイトは神出鬼没です
• 市販の検知ソフトウェアに三か月以上たってもひっかからな
いマルウェアも相当数存在します
 地域によるかたよりも相当あります
• 北米でつくったリストでは、日本ではすり抜けるものが多い
• 地域別・対象別に攻撃技術が発達している模様です
 リストを際限なく大きくするとFWのルールに入りきらなくなる
ので、常に脅威を再評価して（実は結構むつかしいです）、活
動しなくなったものはリストから順次はずしていくことも大事
です

Copyright © NTT Communications Corporation. All rights reserved. 29
DDoS攻撃状況
NTTコミュニケーションズ（株）技術開発部
担当部長水口孝則資料より

DDoS攻撃とは 1/2
30
 DDoS(Distributed Denial of Service)攻撃
複数の攻撃元からの大量通信により
・インターネットサービスプロバイダ(以降ISP)
とのアクセス回線を輻輳
・サイトのサーバリソースを消費
 DDoS攻撃の分類
・量的攻撃
・アプリケーションレイヤ攻撃(不正セッション攻撃を含む)
量的攻撃
攻撃者
NTPサーバ
DNSサーバ
300Gbps
被害者
攻撃者
被害者
http request DB resource
Resource full大量トラフィック
で回線を埋めるサーバリソースを消費する
アプリケーションレイヤ攻撃
攻撃者
被害者

DDoS攻撃とは 2/2
31
 量的攻撃
※Prolexic Global DDoS Attack Report Q2 2014
 アプリケーションレイヤ攻撃
アクセス回線が輻
輳するため、ISP
での対策
IPS・WAFなどお客
様サイト内
機器での対策
独自システム
(SAMURAI)で
対策
“Bizマネージドセキュ
リティサービス”
をご提供
NTT-
Com
DC/企業

DDoS攻撃の傾向 1/8
32
 非重要アプリケーション
(eg ICMP,UDP)
 少ないソース
（eg 1-100台のPC）
 小規模アタック
（eg 10Ks pps）
異常トラヒックの規模
規模はどんどん拡大：
 ネットワークインフラに対し
てISP全体、国・地域全体の
通信断
 10Mpps、400Gbps以上
 10万以上のゾンビPCから
 マルチベクターの攻撃
 重要なアプリケーション
 アドレス詐称
 大規模ソース
（eg 1万のゾンビPC）
 大規模アタック
（eg 100Ks pps）
 複合アタック
現在
社会インフラ
の破壊
金銭目的
の犯罪
愉快犯
■異常トラヒックの規模の推移(出展：Arbor社)
http://pages.arbornetworks.com/rs/arbor/images/WISR2014.pdf
ホストからネットワーク・
インフラへ攻撃に
より強力・広範囲に
より複雑・悪質化

33
日時継続時間攻撃対象影響内容
2013年3月 4日間 Spamhaus/Cloudflare 300Gbps以上の攻撃
3月22日には、ロンドン、アムステルダム、フランクフルト、
香港のIXがトラフィック輻輳が発生、欧州全体に影響
2014年2月不明 Cloudflareの顧客 NTP増幅攻撃により、400Gbps弱の攻撃
2014年2月不明フランスOVHの顧客 350Gbps以上の攻撃。サービス停止
2014年5〜6月 14日間 K-optcom社
eo光 DNSサーバ
Web閲覧、メール送受信などに時間がかかる、または表示不可
2014年7月 5日間以上 K-optcom社
eo光 DNSサーバ
Web閲覧、メール送受信などに時間がかかる、または表示不可
2014年6〜7月 28日間セガ
「ファンタシースター
オンライン2」サービス
当該期間は、サービス停止
6月27日から、一次サービスを再開
2014年6月数時間 Evernote 400Gbps以上のDDoS攻撃を受け、サービスに支障が出た
金銭要求
2014年6月半日 Feedly Evernoteとほぼ同時にDDoS攻撃を受け、サービス停止
金銭要求。米国ISP等の協力により、サービス復旧
2014年8月数時間 PlayStation Network
(PSN)
ネットワークに接続障害。サービス利用停止

34
※Worldwide Infrastructure Security Report 2014, Arbornetworks
最近の主なDDoS攻撃：
Spamhaus(スパム対策組織)が標
的となった事例(2013/3月)
・過去最大300Gbps超のDDoS攻撃
・1週間以上にわたって継続
・DNSリフレクター攻撃を利用
セガのゲームサーバが標的と
なった事例(2014/6月)
・規模は明らかにされていないが、
帯域を埋め尽くされ、ゲームサー
バへの接続が不能に

35
大規模なDDoS攻撃増加の原因：
DNSだけでなく、NTPやChargen
など、あらゆるUDPパケットを利
用したリフレクション攻撃が増加
100Gbpsを超える攻撃の50%が、
NTPリフレクション攻撃
ブロードバンドルータなどの一般
ユーザの機器の脆弱性を利用し、
攻撃者は少ないリソースでも、
ごく簡単に大規模トラフィックを
生成することが可能

36
・データセンター事業者の約3/4がDDoS攻撃を受けたと報告し、前年
の45%から増加
・36%がインターネット回線の帯域を超える攻撃を受けたと回答し、
それは前年の約2倍
・81%がビジネスへの影響として運用費の増大を報告
・他に35%が顧客の離散、27%が売上げの減少と報告

37
※2013 Global Application and Network Security Report, Radware
DDoS攻撃は、標的型攻撃(Advanced Persistent Threat:APT)と
組み合わせて行われるようになる(=マルチベクタ化)
5つ以上の手法を組み合わ
せた攻撃が全体の5割以上

38
・業界別のDDoS攻撃分布
・ゲームなどのソフトウェア業界への攻撃が約7割を占めている

39

DDoS攻撃の監視方法
41
・Netflow、Firewall Log、SNMPが上位
・DPIやSIEMも40%が使用
SAMURAIでも採用

SAMURAIにおけるトラフィック解析
42
＜ポイント＞
・Flow解析によりトラフィックのボリュームだけではなく中身を知る
（送受信アドレス、送受信ポート(アプリケーション)、送受信IF毎など）
・ネットワーク全体のトラフィックトレンドを把握する
・特定のトラフィックフローからDDoS攻撃などを検知し、瞬時に異常
トラフィックの詳細を特定
アプリケーション解析 IF別解析OCN

SAMURAIにおけるDDoS検知機能
43
某ISP某ISP
お客さま
ネットワーク
PC
Web Server
Netflow v5/9
sFlow v2/4/5
snmp
Attacker
某ISP某ISP
お客さま
ネットワーク
■検知技術
• アノーマリトラフィック検知
• IPベースライン異常検知
• 帯域超過検知
• ヘビーユーザ検知
異常トラフィック検知

DDoS攻撃の防御方法
44
DDoS Mitigation装置、ACL、Firewall、Blackhole Routingが中心
SAMURAIでも採用

SAMURAIにおけるDDoS防御連携機能
45
GWルータ
ユーザ収容ルータ
顧客ルータ
ユーザ
③DDoS軽減装置
での防御指示
手法特徴巻込費用
① ブラックホール
ルーティング
大規模アタックに対する対処。ネットワークの入口で
特定IP宛の全てのトラフィックを全て破棄
② ルータアクセス
制御設定
通常の運用対処で利用されている。入口、出口のルータで
ACL設定にてIP+Portでパケットを破棄
③ 軽減システムへ
の防御指示
きめ細やかなDDoS対処が可能。DDoS軽減専用装置に指
示を送り、トラフィックを吸い込み防御実施
3つのDDoS防御連携機能
DDoS
Mitigation装置
①ブラックホール
ルーティング
②アクセス制御
（ACL）設定
異常検知＆防御指示

というわけで
 今のネットワークには、ネットワーク側に機能を入れていかな
いと、特にセキュリティ問題から逃れられません
 IPv6の導入により、NAPTの弊害からは逃れることができたとし
てもファイアウォールやセキュリティ対策製品の必要性は変わ
らないと思われます
• IoTの端末に強力なセキュリティ防護を入れるのは困難
• インターネットに接続されるすべての端末をソフトウェアの
更新が可能にしてメンテし続けることは望ましいが、無理
→ なんらかの防護をネットワーク側からする必要があります
 CDN（Contains Delivery Network)もまたネットワークの大事
な機能です。これもインテリジェンス。

元々のE2Eには戻れない。だがその精神は大事。
ネットワークはパケット
を端末に届けるだけの
機能に集中して余計な
ことはしない（あるいは
気が付かせない）が必
要な防護は提供
端末で処理を行う
自分でできる防護は
なるべく頑張る
端末で処理を行う
自分でできる防護は
なるべく頑張る

というわけで結論
 引き続きアプリケーションの導入を容易にするための努力を。
• 可能であれば新トランスポートの導入も容易にするべき
（難しいけれど、これができれば、さらに、もっと面白いア
プリが作れます）
 さもなければインターネットの発展はありえません。
 なるべく最大限E2E原則をまもれるようにネットワークを作り運
用すること。ネットワークへはE2Eを邪魔しないようにしながら
防護のためのインテリジェンスを導入しましょう
 具体的にどうすればよいのかは、
これからも皆さんと御一緒に考えて
取り組んでいきたいと考えております

ご清聴ありがとうございました

ION Tokyo: Keynote Presentation -- "Can we go back to the original? A Return to the end-to-end principle" by Dr. Shin Miyakawa

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ION Tokyo: Keynote Presentation -- "Can we go back to the original? A Return to the end-to-end principle" by Dr. Shin Miyakawa

Similaire à ION Tokyo: Keynote Presentation -- "Can we go back to the original? A Return to the end-to-end principle" by Dr. Shin Miyakawa (20)

Plus de Deploy360 Programme (Internet Society)

Plus de Deploy360 Programme (Internet Society) (20)

Dernier

Dernier (10)

ION Tokyo: Keynote Presentation -- "Can we go back to the original? A Return to the end-to-end principle" by Dr. Shin Miyakawa