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

CLOSER Web巡回型ハニーポット

マルチウイルススキャナ

サンドボックス

シードコレクター

FIXER FIXER

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/1

5

4/2

2

4/2

9

5/6

5/1

3

5/2

0

5/2

7

6/3

6/1

0

6/1

7

6/2

4

7/1

7/8

7/1

5

7/2

2

7/2

9

8/5

8/1

2

8/1

9

8/2

6

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/2

5

8/2

6

8/2

7

8/2

8

8/2

9

8/3

0

8/3

1

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&admin=Y&browser=IEXPLORE.EXE&exe=dflt_sample&lang_DfltSys=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

Copyright © NTT Communications Corporation. All rights reserved. 40

NTT Comのネットワークにおける取り組み

〜SAMURAIによる対策〜


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を邪魔しないようにしながら防護のためのインテリジェンスを導入しましょう

具体的にどうすればよいのかは、これからも皆さんと御一緒に考えて取り組んでいきたいと考えております

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