フロー技術によるネットワーク管理

フロー技術によるネットワーク管理
進藤資訓
ヴイエムウェア株式会社
ネットワーク＆セキュリティ事業部テクニカルリーダー
mshindo@vmware.com
@motonori_shindo

I. 従来のネットワーク管理との違い

従来のネットワーク管理
• SNMPベース
– MRTG
– HP/OV
– …
• RMON or RMON2ベース
JPIXネットワーク運用管理セミナー Copyright © 2013 Motonori Shindo, All Rights Reserved. 3

SNMPによるネットワーク管理
外部ネットワーク
SNMP Manager
SNMP Agent SNMP Agent
SNMP AgentSNMP Agent
Get Req/Resp
Set Req
Trap
MIB

SNMPが提供するトラフィック情報
• （論理）インターフェース
を通過したパケット数や
バイト数
– IfInUcastPkts,
IfOutUcastPkts
– IfInOctets, IfOutOctets
– …
• “インターフェースベー
ス” or “L2ベース”のネッ
トワーク管理

SNMPが提供してくれないもの
• 誰がトラフィックを流しているのか？
– End to End トラフィックの把握
• どのようなトラフィックを流しているのか？
– アプリケーションの把握
• ネットワーク型攻撃のすばやい検知
• ピアリング分析

RMON / RMON-2
• RMON
– SNMP MIB-Ⅱの拡張
– “ネットワーク”のモニター
– L2(MAC)レベルのvisibility
• RMON-2
– RMONの拡張
– L3 / L4 レベルのvisibility

RMON / RMON-2によるネットワーク管理
RMON Management Console
RMON Probe
Get Req/Resp
Set Req
Trap
RMON MIB
RMON Probe
RMON Probe

RMON / RMON-2の問題点
• RMON
– Probe（Agent）志向
– 依然としてL3 / L4のvisibilityがない
• RMON-2
– Probe（Agent）志向
• さらに複雑な実装
– サービスプロバイダのニーズを満たしていない
– ライセンス料

Deep Packet Inspection (DPI)
• パケットの「中身」を全て見て解析する
• 理論的にはなんでも見える！

DPIの適用例
 ファイヤーウォール
 IDS / IPS
 帯域制御装置
 トラフィック・アナライザ

DPI悩み
• 見え過ぎる！？
• インライン型ゆえの取り回し
にくさ
• 膨大なログ
• 高速なインターフェースへの
追従

新たなネットワーク管理手法
• “フローベース”のネットワーク管理！
– End to End の情報の把握
– アプリケーションの把握
– すばやい攻撃の検知
– AS の情報の把握
– …

フローによるネットワーク管理
Flow Collector
Flow Exporter
Flow Record
Flow Exporter
Flow Probe
Flow Record
Flow Record

代表的なフロー・プロトコル
• NetFlow
– Ciscoが開発した技術
– Cisco, Juniper, AlaxalA, etc.
• sFlow
– InMonが中心となって開発した技術
– Foundry, Extreme, AlaxalA, Force10, HP, etc.
• IPFIX
– IETFによる標準プロトコル
– マルチベンダー
– NetFlow V9がベース

３方式の比較
SNMP DPI Flow
レイヤー L2 L1-L7 L3-L4
セキュリティー △ ◎ ○
高速追従性 ◎ △ ○
ストレージサイズ ◎ △ ○

フロー技術の適用分野
アプリケーションの把握
サービスプロバイダエンタープライズ
攻撃の検知
QoSモニタリング
将来予測
課金
ピアリングの最適化ユーザの挙動把握
フォレンジック
トラフィック・
エンジニアリング
内部統制

代表的なフロー・プロトコル
• NetFlow
– Ciscoが開発した技術
– Cisco, Juniper, AlaxalA, etc.
• sFlow
– InMonが中心となって開発した技術
– Foundry, Extreme, AlaxalA, Force10, HP, etc.
• IPFIX
– IETFによる標準プロトコル
– マルチベンダー
– NetFlow V9がベース

NetFlowキャッシュ
• NetFlowはキャッシュ・ベースのテクノロジー
Src IF Src IP Dst IF Dst IP Proto Bytes … Active Idle
10 a.a.a.a 24 x.x.x.x 6 1234 327 4
15 b.b.b.b 24 y.y.y.y 17 23456 1920 25
24 c.c.c.c 3 z.z.z.z 6 5678 54 10
フロー
NetFlowキャッシュ
コレクター
・Src / Dst IPアドレス
・Src /Dst ポート番号
・プロトコルタイプ
・ToSバイト
・入力インターフェース

キャッシュなので・・・
• いつかはフラッシュする必要がある
– Inactive Timer （default = 15秒）
– Active Timer （default = 30分）
– TCP FIN or RST
– キャッシュが一杯になった時
• 実装依存
フロー
30分 15秒

NetFlowバージョン
バージョン特徴
1 最初のバージョン。現在ではほとんど使われていない。
5
最も多く使われているバージョン（と思われる）。BGP
ASとフローシーケンスをサポート。
7 Catalyst Switchシリーズのための拡張。
8
アグリゲーションをサポート。サポートしていないコレク
ターが多い。
9 テンプレートベース。IPFIXのベース。

NetFlow V5 PDU
Version バージョンフローレコード数
SysUptime
unix-_secs
unix-_nsecs
フローシーケンス番号
エンジンタイプエンジンID （サンプリングレート）
フローレコード <1>
フローレコード <n>
・
・
・
ヘッダ
フロー
レコード
0 15 16 31

NetFlow V5 フローレコード
送信元IPアドレス
送信先IPアドレス
入力インタフェース番号
nexthop
first
送信元ポート番号
パディング
出力インタフェース番号
パケット数
オクテット数
最初にフローが観測されたsysuptime
最後にフローが観測されたsysuptime
送信先ポート番号
TCPフラグ ToSプロトコル
送信元AS番号送信先AS番号
送信元ネットマスク送信先ネットマスクパディング
0 15 16 31

NetFlow V9
• テンプレート・ベース
• RFC 3954 （Informational）
• IPFIX のベースになった
– 詳しくはのちほど IPFIX のところで説明

NetFlowパフォーマンス
• オーバーヘッド
– パケットの分類
– エクスポート処理
• 多くのCiscoハードウェアはパケットの分類をハードウェ
アで処理することができる
• バージョン（V5, V8, V9）にはほぼ非依存
• サンプリングは有効！
• 例）
– Cisco 12000、100:1サンプリングの場合、7～15%
程度のCPU負荷増

sFlow
• NetFlow（Cisco流）への反発??
• RFC 3176 [sFlow V4] （Informational）

サンプリング
• sFlowは“サンプルベース”のテクノロジー
– NetFlowのようなフローキャッシュは持たない
コレクター
sFlow
エージェント
sFlow PDU
パケット
ヘッダ
I/F
NextHop
AS情報
I/F統計情報
ユーザ名
パケットキャプチャ
Etc.
インタフェース統計
サンプル
フローサンプル
１つのインターフェース
から入ってきて、スイッ
チ/ルーティングモ
ジュールを経由した後、
（1つ以上の）インター
フェースから出て行く全
てのパケット

sFlowの特徴（vs NetFlow V5）
• レイヤ２の情報を取得できる
• IPv6を扱える
• IP以外のプロトコル（IPX、AppleTalk、等）を扱える
• パケットキャプチャができる
• BGP関連機能のサポート
– BGP Next Hop
– Community
– AS PATH
– Local Preference
• カウンタのサポート
• 軽い Agent （エクスポータ）実装

ｓFlowのバージョン
バージョン特徴
2 最初のバージョン
4 BGP community の追加（RFC 3176）
5
CPU/メモリ使用率、BGP nexthop、MPLS、NATサ
ポート追加。Vendor-specific レコードで拡張可能。

IPFIX
• IP Flow Information eXport
– RFC 5101 (Protocol)
– RFC 5102 (Information Model)
• 歴史
– 49th IETF Dec. 2000, (rtfm2 – realtime traffic flow
measurement 2 BOF)
– 51st IETF August 2001 (ipfx BOF)
• 候補：ARGUS, sFlow, NetFlow, LFAP, CRANE, Diameter, etc.
• 関連WG
– PSAMP （Packet Sampling） WG
• 54th IETF July 2002

IPFIX アーキテクチャ
Metering
Process 1
Observation
Point 1
ExportingProcess
Metering
Process n
Observation
Point m
Metering
Process 1
Observation
Point 1
Metering
Process n
Observation
Point m
Collector
Observation
Domain 1
Observation
Domain K
Collector
IPFIX機器
パケット
・・・
・・・
・・・
・・・
・・・
ある期間のあ
いだに、ネット
ワーク中の“観
測ポイント”を
通過したIPパ
ケットの集合
パケット

テンプレート
• テンプレート・セット
– データセットの“設計書”のようなもの
– 拡張性を持たせる手段
• TLV でも実現できたが、オーバーヘッドが問題
• オプション・テンプレート・セット
– フローには直接関係ないメタな情報を伝える

Template Flowset & Data Flowset の例
FlowSet ID = 0
Length = 28 bytes
Template ID = 256
Field Count = 5
IPv4_SRCADDR
Length = 4
IPv4_DSTADDR
Length = 4
IPv4_NEXT_HOP
Length = 4
IN_PKTS
Length = 8
IN_BYTES
Length = 8
FlowSet ID = 256
10.10.0.1
10.20.0.30
10.254.0.1
34947
5434325
Length = 60
10.10.0.3
10.33.5.124
10.254.0.1
3434
95048
Template Flowset
Data Flowset
16bits 32bits
Rec#1
Rec#2

IPFIX の新機能（NetFlow V９と比較して）
• SCTP/PR-SCTPが必須のトランスポートになり、
UDP・TCPがオプションに
• フィールド指定フォーマットの導入
– ベンダー拡張が可能
• 可変長IEのサポート
• テンプレートを明示的に消去するTemplate
Withdraw Messageの導入
• セキュリティー
– IPsec or TLS （オプション）

サンプリング
• 目的
– エクスポータのCPUやメモリの節約
– ネットワーク帯域の節約
– コレクターの性能の節約

サンプリング方式
• Systematic Sampling
– Count-based
– Time-based
• Random Sampling
– n-out-of-N
– Uniform or Non-Uniform Probabilistic
N N N
N N N

設定上の注意点
• SNMPとは根本的に違う考えをする必要があ
る！

設定上の留意点
• フローは原則 “Ingress” のインターフェースで
効く
– 一部、Egressで効く機器や設定可能な機器もある
FlowがenableなIF
FlowがdisableなIF

Active timeout
• Ciscoのデフォルトは30分、設定可能最小値
は1分
• ルータの負荷が心配？
– 1分にするとフローレコードはどれくらい増えるの
か？
• 結論：可能なら1分、最低でもコレクターの統
計粒度以下にすべし！
– ip flow-cache timeout active 1

Catalyst 6500系
• 最も多く使われているエクスポータと思われ
る
• 不幸な事に、フローの設定に関しては一番複
雑なハードウェア

Catalyst 6500アーキテクチャ
MSFC
PFC

Cat6500固有の事情
• MSFC, PFCそれぞれにフローの設定が必要
– MSFCはサンプリングできない場合があり
– V9以前のNetFlowでは１筐体で異なるサンプリン
グレートを扱う事ができない！
• フローマスクという概念がある
– OutのifIndexが0で出てしまう
– “interface-full” にすべし
• TCPフラグを出せない
– DoS検出時に注意が必要

期待したようにトラフィックが見えない
• 全く出ない
• SNMPと（若干）異なる

全く見えない場合
• インターフェースに設定が入っていない
• OutのifIndexが出ない
• 物理 vs 論理インターフェース
– Link Aggregation、VLAN
– IPインターフェース（Juniper）
• Active timeoutの罠
• ifIndexが変わってしまった！
– snmp-server ifindex persisit

SNMPとの差異要因
• L2ヘッダオーバーヘッド
• Non-IPトラフィック
• ブロードキャスト＆マルチキャスト
• Origin or Destinedトラフィック
• ACL
• サンプリング誤差

FAQその１
• 最適なサンプリングレートはどれくらいです
か？
– フローの使用目的によって異なる
– ハードウェア・アシストの有無
– 典型的なのは1/100～1/数1,000
– 当然失われるものもある
• フロー数
• スキャン等の振る舞い
• ・・・

FAQその２
• サンプリングレートが〇〇だとどれくらいの誤
差で収まりますか？
– サンプリングレートで誤差率が決まるわけではな
く、 “サンプル数”で決まる！

サンプリング理論
• 理論誤差= 196×sqrt( 1/c )
注: 信頼区間95%の場合

具体例
• 前提
– トラフィック： 1Gbps
– 平均パケットサイズ： 250バイト/パケット
– 統計粒度: 5分
• 計算
$ irb
>> 196 * Math::sqrt(1/(1.0*1000*1000*1000/8/250*5*60/1000))
=> 0.506069823904436
>> 196 * Math::sqrt(1/(1.0*1000*1000*1000/8/250*5*60/10000))
=> 1.60033329861834
>> >> 196 * Math::sqrt(1/(1.0*1000*1000*1000/8/250*5*60/4000))
=> 1.01213964780887

サンプリングレート高い？低い？
• 言う人によってまちまち！w
• 「レート」なので、
– 1000、2000、とか言うのは正しくない。正しくは
1/1000、1/2000と言うべき
– 従って、1/2000より1/1000のほうが“高い”サンプ
リングレート

ダブルカウント問題
• １つのフローに関する
情報を2つ以上のエク
スポーターがエクス
ポートしてしまい、コレ
クターがそれらを重複
してカウントしてしまう
問題
Flow Record
Flow Record

ダブルカウント問題解決方法（１）
• 単純に考えると・・・
– 同一フローに関するフローレコードをコレクターが
消しこむ
• が、一般的には難しい
– サンプリングの可能性
• ハッシュベースのサンプリングで解決は可能だが、ま
だ実装がない
– 同一のコレクターに捕縛されるとは限らない

ダブルカウント問題解決方法（２）
• モデル化による解決
– フローを“境界”で捕縛する
– 境界を通過するフローの挙動が“予測可能”であ
るようにネットワークをモデル化する

モデル化による解決の例
インターネット
インターネット境界
ホームネットワーク

ASトラフィック分析
• ピアリングの最適化に絶対必要な情報
– コスト・セービングにつながる
• “Origin” vs “Peer” AS
AS 1
AS5
AS2 AS4AS3
AS6
AS7
Src Orig AS
Src Peer AS Dst Peer AS
Dst Orig AS

Src AS問題
• Dst {Orig/Peer} ASについては、フローレコード中の
dst IP addrをBGP経路テーブルでルックアップすれば
よい。
• Src {Orig/Peer} ASをはっきり特定することはできない。
– 経路の非対称性
– Src IPのSpoofの可能性
– フローレコード中のsrc IP addrをBGP経路テーブルでルック
アップして、そこから来たであろうと「仮定」する（しかない）。

Src Peer AS問題解決方法
• Src Peer ASオーバーライド
– BGP経路テーブルをルックアップせず、特定のインターフェースから
入ってきたトラフィックは、特定のAS Peerトラフィックであると認識する。
– プライベートなPeerの場合は良いが、IXでPeerしているような場合は
解決できない。
AS 1
AS5
AS2 IXAS3
AS6
AS7
Src Orig AS
Src Peer AS
AS8

商用コレクター製品（アルファベット順）
• AdventNet – NetFlow Analyzer (N, I)
• ARBOR Networks – peakflow (N, S, I)
• Fluke Networks – NetFlow Tracker (N, S, I)
• Foundry Networks – IronView (S)
• GenieNRM – GenieATM (N, S, I)
• InMon – InMon Traffic Sentinel (S, N, I)
• Lancope – StealthWatch (N, S)
• Plixer – Scrutinizer (N, S)

フリーコレクター製品（アルファベット順）
• CAIDA – cflowd (N)
• flow-tools & FlowScan(N)
• InMon – sflowtools (S), sFlowTrend (S)
• nfdump & NfSen (N)
• ntop – ntop (N, S, I)
• Many More!!!

flow-tools
• ツールの集合
– flow-{capture, cat, dscan, expire, export, fanout, filter, gen,
header, import, log2rrd, mask, merge, nfilter, print, receive,
report, rpt2rrd, rptfmt, send, split, stat, tag, xlate}
• NetFlow V1, V5, (V6), V7, V8
• 例）
% ./flow-receive 0/0/9990 | ./flow-print | head -10
Sif SrcIPaddress Dif DstIPaddress Pr SrcP DstP Pkts Octets
60 206.204.84.9 00 10.0.135.63 06 15 5f0 2 88
00 10.0.135.63 60 206.204.84.9 06 5f0 15 16 787
60 206.204.84.9 00 10.0.135.63 06 15 5f0 13 1742
00 10.0.155.25 60 204.62.245.167 06 50 bae5 15 948

FlowScan
• cflowd / flow-tools / argus / lfapd (collector) + RRD
(D/B) + RDDTools (visualization)
• Platform : UNIX
http://www.caida.org/tools/utilities/flowscan/index.xmlより引用http://www.caida.org/tools/utilities/flowscan/index.xmlより引用

NfSen
• nfdumpのフロントエンド
• Platform : UNIX
http://http://nfsen.sourceforge.net/details-graphs.pngより引用

GenieATM 6000
http://www.fivefront.com/products/genie/atm6000/function.htmlより引用

Fluke NetFlow Tracker
http://www.flukenetworks.com/enterprise-network/network-monitoring/OptiView-NetFlow-Trackerより引用

ARBOR peakflow
http://www.arbornetworks.com/products_x.phpより引用

InMon Traffic Sentinel
http://www.msol.co.jp/it/Inmon/i-tokucho.htmlより引用

Plixer Scrutinizer
http://www.plixer.com/products/netflow-sflow/scrutinizer-netflow-sflow.phpより引用

フローを使った適用事例
• AS間トラフィック把握
• 社内ネットワークのトラフィック把握
• DDoS検知およびmitigation
• ネットワーク費用按分（課金データ）
• フォレンジック・データとしての使用

アプリケーションの把握

ヘビートーカーを探せ！

ワームの発見～異常発生～
アラーム
発生

ワームの発見～PPS・FPSの上昇～
Packet per second
Flow per second

ワームの発見～アプリケーションの分析～
特定のインターフェー
スを指定
アプリケーションでの
分析を指示

ワームの発見～原因判明～
犯人はこ
れだ！

ワームの発見～攻撃者と被害者の特定～
攻撃者被害者

Blackhole Routing (a.k.a RTBH)
Regional Network
Regional Network
Flow Collector
フローで攻撃を検出1
BGP announcement2
ip route 192.1.1.2 255.255.255.255 Null03
3
ip route 192.1.1.2 255.255.255.255 Null0
攻撃者
被害者
192.1.1.2

Clean Centerを使ったソリューション
Regional Network
Regional Network
Clean Center
Flow Collector
Protected
Network Zone1
フローで攻撃を検出1
5 きれいになったトラ
フィックをネットワー
クに戻す
攻撃者
被害者
192.1.1.2
Clean Centerへトラ
フィックをフォワード
4
BGP announce3
保護したいZoneの有効化
2

DDoS mitigationにフローを使うことのメリット
• そもそもSNMPでは不可能
– 「何か」が起こっていることは分かるが、「何」が起
こっているか分からない
– 何が起こっているか分からないと対策できない
• 分散検出することができる
– インラインなソリューションよりスケールする

仮想化環境の可視化（１）
http://blog.sflow.com/2010/02/virtual-routing.htmlより引用

仮想化環境の可視化（２）
http://openvswitch.org/より引用
Open vSwitchの例

参考資料
• NetFlow 関連情報
– http://www.cisco.com/en/US/products/ps6601/products_i
os_protocol_group_home.html
• NetFlow V9 RFC 日本語訳
– http://www.fivefront.com/technology/flow/rfc3954-
jp.html
• ｓFlow 関連情報
– http://www.sflow.org/
• IPFIX
– http://www.ietf.org/html.charters/ipfix-charter.html
• 各種ツール
– http://www.switch.ch/tf-tant/floma/software.html

フロー技術によるネットワーク管理

More Related Content

What's hot

Similar to フロー技術によるネットワーク管理

More from Motonori Shindo

フロー技術によるネットワーク管理