Transcript H1_snd_SYN

インターネットの測定技術に
基づくセキュリティ診断
後藤 滋樹
グローバルCOEプログラム
アンビエントSoC教育研究の国際拠点
（早稲田大学 理工学術院）
概要
インターネットのトラフィックが増大するにつれて、生の
データを直接に測定することが難しくなった。これを解決
するためにサンプリングを行なったり、特徴 を簡単に表
現する方法が提案されている。
ここでは我々の提案を紹介する。ネッ トワークの測定を
行なうと、教科書に載っているような整ったデータだけで
はなく、奇妙なパケットやフローが現れる。これは多くの
場合には不正なアクセスや ウィルス、ボット、spamメー
ルなどに起因する。講演の後半では、セキュリティ に関
する検知を能率良く行なう方法について説明する。
2
本資料の構成
背景
1.1 サンプリングによる測定
1. 測定
1.2 End-to-end の測定方法
2.1 異常トラフィックの抽出
2. セキュリティ
2.2 ＯＳのフィンガープリント
3
（背景）広帯域ネットワークの利用増
→
測定が難しくなる
• 対象とするデータ量が膨大になる
例：早稲田大学のSINET対外接続は10Gbps
もし使用量１.６Gbps＝０.２ＧＢ/sec としても
１時間のデータ（６０秒×６０分） ７２０ＧＢ
• 個々のパケットではなくフローとして把握（2.1）
• サンプリング（1.1）, フィルタリング（2.1）
• できるだけ即時に処理（2.2）
• 多地点のデータを分散管理（1.2）
4
1.1 サンプリングによる測定
• 電気通信普及財団 テレコムシステム技術賞
２０１０年３月１５日 授賞式
• T. Mori, T. Takine, J. Pan, R. Kawahara.
M. Uchida, and S. Goto, Identifying HeavyHitter Flows From Sampled Flow Statistics,
IEICE Transactions on Communications, Vol.
E90-B, No.11, pp. 3061--3072, Nov. 2007.
• 電子情報通信学会 論文賞
２００９年５月２９日 授賞式
5
電気通信普及財団賞
ネットワーク内を流れるトラフィックをチェックし
て、長時間大量のパケットを流すフローを識別
することは重要な問題である。この研究は、す
べてのパケットではなく、サンプリングにより高
精度且つスケーラブルにそのようなフローを特
定する理論的手法を確立し、実トラフィックデー
タを用いて実証したもので、実社会で求められ
ている優れた仕事である。
6
1.1 サンプリングによる
エレファントフローの特定
• エレファントフロー とは「巨大なフロー 」
– P2Pによって発生したフロー
– 今日では巨大フローは一般ユーザーが発生する
• CATV,DSL, FTTH 加入者
– 帯域の消費が著しい
– ネットワークによらない普遍的な現象 (2:8の法則)
• エレファントフローを検出・制御すると
– 制御対象とするフロー数が少なくて済む
– 制御する効果が大きい
7
分析の対象とするデータ
•
•
•
•
•
OC48c パケットトレース(PMA project, NLANR)
N=10,000,000 (約2分の片道トラフィック)
総フロー数: 737,800
エレファントフロー数 (Xj >= 10,000) : 167
エレファントフローのトラフィック量占有率 : 59.3%
Pr[Xj = x]
8
パケットサンプリングとフロー計測
• パケットサンプリング
– Nパケットに1パケットをサンプルする
– フロー計測のコストを削減することが目的
• メモリ消費量、アクセススピード
– 超高速ネットワークに対するスケーラビリティ
を提供
– 標準化、実装が進んでいる技術
– サンプリングにより、フロー統計情報の一部は
失われる
9
課題とアプローチ:
• 課題
– サンプルしたパケットからエレファント
フローを特定する
 エレファントフローを特定するためには
パケットカウントの閾値をどのように
定めれば良いか？
• 本研究のアプローチ
ベイズの定理を用いる
10
ベイズの定理:
• フロー j
– 元のパケット数: Xj
– サンプルパケット数: Yj
– エレファントフロー Xj >= Xe
Pr[ Yj = Y’ | Xj = Xe] : 超幾何分布
ベイズの定理により、次式を計算可能
Pr[ Xj = Xe | Yj = y’]
※ ただし、事前分布Pr[Xj = x]が必要
11
ベイズの定理
フローj: 母集団におけるパケット数が Xj=x である条件
のもとでサンプルしたパケット数が Yj=y である確率
(A)
(超幾何分布)
フローj: サンプルしたパケット数が Yj≧y である条件の
もとで母集団におけるパケット数が Xj≧x である確率
（i.e., フローｊがエレファントフローである確率）
(B)
12
False probabilities:
フローjについてサンプルしたパケット数が
を満たしたらエレファントフローであると特定する
• False positive ratio:
誤って検出
= Pr [特定したフローがエレファントでない]
=
• False negative ratio:
見逃し
= Pr [エレファントフローが特定されない]
=
=
13
False率のトレードオフ
f=1/1,000
f=1/10,000
サンプリングレートが低いほど、トレードオフが顕著
14
応用例: False positive を小さくする (≦ 0.05)
f=1/1,000
f=1/10,000
False positive 小  特定したフローは高確率でエレファント
ただし、未検出のエレファントフローが増える
15
精度の評価例: (false positive < 0.05)
理論
同様の値をとる
サンプリング
レート
エレファントフローを特定するための閾値
実験 (実際のパケットサンプリング)
特定したフロー数
トラフィック占有率 > 20 %
特定フローのうち、実際に
エレファントフローである数
元のエレファントフロー数 = 167
16
事前分布と閾値
• 閾値 の算出には，事前分布の情報が必要
• 事前分布の情報をどのように得るか？
1. 同一ネットワークの近い時間帯でのデータを使う
-
予め，測定しておく
2. サンプルしたフローの分布から、元の分布を推定
-
Yjの分布からXjの分布を推定 [Duffield,SIGCOMM’03]
3. 分布の普遍的な性質を利用する
–
–
多くの場合，Xj の分布は形状母数≒1.0 のパレート分布で
近似可能
算出された閾値は、広い範囲の分布に対して同じ値
17
様々な事前分布：
•
経験分布 (計測データ)
–
–
•
OC48c link [PMA, NLANR]
GbE link [PMA, NLANR]
理論分布 (パレート分布)
beta=0.5
beta=0.75
Pr[Xj > x]
beta=1.0
beta=1.25
beta=1.5
x
18
評価結果: false率
false-positive false-negative
false-positive false-negative
f=1/1,000
f=1/10,000
経験分布
パレート分布
19
評価結果: 閾値
min
s.t. FPR< 0.05
経験分布
パレート分布
20
エレファントフロー特定の応用例
• PD (Priority discarding), WFQ (Waited Fair
Queueing) 等のキュースケジューリングアルゴリズム
と併用
– ネットワーク輻輳時に、帯域を支配しているエレファントフロー
に属するパケットを優先的に廃棄/低優先キューに割り当て
• CSFQ (Core Stateless Fair Queueing)等の
スケーラブルなネットワーク制御アーキテクチャに適合
– エッジノードはエレファントフローマーキング。コアノードは
マークを元に diffserv 的な制御を実施。
• 極端なエレファントフローの発生を検出したら、迅速に
オペレータに通知する (anomaly detection)
21
1.1 のまとめ
• サンプルしたパケットからエレファントフローを特
定する方法を提案し、実データにより評価した
• アイディアの要点： フロー毎にサンプルされるパ
ケットカウントと、そのフローがエレファントフロー
である確率の関係を事前に算出
– ベイズの定理を利用。事前分布の情報が必要。
• 実データおよび理論分布を用い、提案手法の
有効性を示した
– 本手法で計算した閾値 は、他のネットワークに
対しても有効 (非一様性の普遍性より)
22
1.2 End-to-end の測定方法
1. Introduction
– Background and Motivation
– Applications
2. Overview of i-Path
– Data Collection
– New Software
3. More Applications
4. Conclusion
23
The Goal of i-Path project
 Accessible Information between the hosts
 Observing the information disclosure policy of
all stakeholders along the path
24
Introduction
Background
Growing demand for backbone bandwidth
Network performance fluctuation (e.g. throughput)
Routers keep rich information
•Routing table, Link utilization
•Temperature, Location, Contact point, Supply voltage etc.
Not easy to collect right information and
to utilize information along the path
• Because of …
– Observe the information disclosure policy
– Status of network depends on variety of factors
25
Introduction
Motivation
• Disclosing information leads to improved
End-to-End visibility
• End-to-End visibility provides benefit to
end hosts and network operators
– Monitoring network status
– Reporting events and troubleshooting
– Reduction in operational cost
• Providing transparency of underlying networks
26
Introduction
Applications
Enhanced Congestion Control
Best peer selection in
P2P communication applications
Adjust optimal bit rate in VoD
Dynamic network configuration
(e.g. according to Time zones)
Selection of the appropriate path
(e.g. Not violating policies related to content
management)
27
Overview
Data Collection
• Explicit Network Information Collection Along a Path
• SIRENS *(Simple Internet Resource Notification Scheme)
– Based on the cross layer approach



Bottleneck bandwidth
Interface queue capacity
Corruption losses etc.
– Scalable network information measurement
* K. Nakauchi and K. Kobayashi. An explicit router feedback framework for high
bandwidth-delay product networks. Computer Networks, 51(7):1833–1846, 2007.
28
Overview
Structure of shim-header
Inserted between the network and transport headers
29
Overview
Information Disclosure
• Prohibit to access some Information on routers
• Unwilling to disclose inside network status
– Security
– Cost
• Each ISP has a disclosure policy
• End hosts have their disclosure policy
Negotiation: requests and responses
OK to Disclose?
OK to Disclose?
OK to Disclose?
30
Observing Information Disclosure Policies
Selective requests and responses
 Policy:
Alice & Bob allow to disclose
beyond 3rd hop router.
 Implementation:
• Alice does not send req. for her
neighbor & the next neighbor
routers, i.e.,1st & 2nd hops.
• Bob does not send back res.
same as Alice, i.e., 6th & 7th hops.
 Results:
• Alice obtains 3-5 hops data.
• Bob obtains 3-7 hops data
31
New Software Tools
(a)
Send a SIRENS
request packet
TCP Data
TCP Data
TCP Data
TCP Data
(b)
Receive the request
packet and reply
Sender
(c)
Receive the reply
packet and
make xml files
i-Path Router
TCP Data
Developed
software
Receiver
TCP Data
xml
32
Snapshot of the Visualization Tool
• Dark colored (Blue) routers
– Data Collection: Enabled
• Gray colored routers
– Data Collection: Not enabled or Not Exist
33
More applications
Network Threat Detection
S.Nogami, A.Shimoda and S.Goto, Detection of DDoS attacks by i-Path flow
analysis, (in Japanese, to appear) 72nd National Convention of IPSJ, Mar. 2010.
DDoS Packets
destination: TARGET
Source IP Address: Spoofed IP Address
TARGET
IP address : X.X.X.X
Internet
Attackers
Back Scatter Packets
destination: Spoofed IP Address
Source: TARGET
extraneous hosts/servers
34
More applications
NAT traversal
Different kind of NATs:
full cone, restricted cone, port restricted cone, symmetric
K.Tobe, A.Shimoda and S.Goto, NAT traversal with transparent routers,
(in Japanese, to appear) 72nd National Convention of IPSJ, Mar. 2010
symmetric NAT
35
Current Status and Future Plans
• i-Path project wiki
http://i-path.goto.info.waseda.ac.jp/trac/i-Path/
• Dai Mochinaga, Katsushi Kobayashi, Shigeki
Goto, Akihiro Shimoda, and Ichiro Murase,
Collecting Information to Visualize Network Status,
28th APAN Network Research Workshop,
pp.1—4, 2009.
• Network application utilizing collected information
• Demonstration on R&D testbed: JGN in Japan
• Demonstration at SC09, Portland, OR, Nov. 2009
36
1.2 Conclusion
• We proposed new method disclosing
network information
• i-Path
– Offering end-to-end visibility, transparency
– Observing privacy protection
– Respecting disclosure policy
37
2.1 異常トラフィックの抽出
• Analyze packet by packet
• Limitation of simple packet analysis
– Malicious activities—in normal packets
• DoS (Denial of Service) attack
• Port Scan
38
Flow Analysis and Protocol Machine
• Flow — a sequence of packets
• Source and destination IP address (or AS#)
• Port numbers (application)
• Valid flow and Invalid flow
– A flow is classified by the protocol
machine.
39
Flow Analysis and Protocol Machine
• The original protocol machine for TCP
– Defined in RFC 793
– Deterministic automaton
• Our new extended protocol machine
– Non-deterministic automaton
– It covers packet losses and duplicated packets.
CLOSED
CLOSED
passive OPEN/
create TCB
CLOSE/delete TCB
CLOSE/
delete TCB
H2_snd_SYN
active OPEN/
snd SYN
LISTEN
ε
H1_snd_SYN
SYN_RCVD_0_1
rcv SYN/
snd SYN ACK
LISTEN
CLOSE/
snd FIN
SEND/
snd SYN
rcv ACK of SYN/
x
FIN_WAIT_1
rcv ACK of FIN/
x
FIN_WAIT_2
rcv FIN/
snd ACK of FIN
H1_snd_SYN_ACK
SYN_RCVD
rcv SYN/
snd ACK of SYN
SYN_RCVD
CLOSE/
snd FIN
H1_snd_ACK_of_SYN
SYN_RCVD_0_2
ε
H2_snd_ACK_of_SYN
ESTABLISHED_0
H1_snd_FIN
rcv FIN/
snd ACK of SYN
rcv FIN/
snd ACK of FIN
CLOSING
ESTABLISHED
LAST_ACK
rcv ACK of FIN/
x
H1_snd_ACK_of_SYN
H1_snd_FIN
CLOSE/
snd FIN
rcv ACK of FIN/
x
H2_snd_FIN
FIN_WAIT_1
CLOSE_WAIT_0
H2_snd_FIN
H2_snd_ACK_of_FIN
H1_snd_ACK_of_FIN
CLOSING_0
H1_snd_ACK_of_FIN
CLOSED_2
CLOSE_WAIT
FIN_WAIT_2
H1_snd_FIN
CLOSING
LAST_ACK
H2_snd_FIN
H2_snd_ACK_of_FIN
2MSL
timer
SYN_SENT
H2_snd_SYN_ACK
CLOSE_WAIT
TIME_WAIT
H2_snd_SYN
SYN_SENT
rcv SYN/
snd ACK of SYN
ESTABLISHED
H1_snd_SYN
ε
TIME_WAIT_0
H1_snd_ACK_of_FIN
RESETTING
H1_snd_RST
TIME_WAIT
ε
H2_snd_ACK_of_FIN
CLOSED_2
40
2.1 異常トラフィックの抽出
An Improved Protocol Machine for
Flow Analysis and Network Monitoring
Heshmatollah Khosravi,
Masaki Fukushima and Shigeki GOTO ,
“An Improved TCP Protocol Machine for
Flow Analysis and Network Monitoring”,
IEICE Transaction, Vol.E86-B No.2
pp.595-603, February, 2004.
41
Protocol machine — Finite states
• Formally defined specification
e.g. RFC793.
Finite state automaton (automata)
– Well established method in mathematics
– Packets are treated as input symbols.
– An automaton accepts a sequence of
packets, if it matches the specification of
the protocol, i.e. TCP.
42
The original machine in RFC793
CLOSED
passive OPEN/
create TCB
• RFC793 state
CLOSE/
snd FIN
– Two packets
– One packet
rcv ACK of FIN/
x
TCP specification
FIN_WAIT_2
rcv FIN/
snd ACK of FIN
active OPEN/
snd SYN
SEND/
snd SYN
rcv SYN/
snd ACK of SYN
rcv ACK of SYN/
x
FIN_WAIT_1
• Automaton &
– One packet
LISTEN
SYN_RCVD
transition with
– Zero packet
CLOSE/
delete TCB
rcv SYN/
snd SYN ACK
diagram:
CLOSE/delete TCB
SYN_SENT
rcv SYN/
snd ACK of SYN
ESTABLISHED
CLOSE/
snd FIN
rcv FIN/
snd ACK of SYN
CLOSE_WAIT
rcv FIN/
snd ACK of FIN
CLOSE/
snd FIN
CLOSING
LAST_ACK
rcv ACK of FIN/
x
TIME_WAIT
2MSL
timer
rcv ACK of FIN/
x
CLOSED_2
43
The extended machine
• Two machines are used for
a client and a server.
• One packet at a time
– New states are inserted.
• Invisible transitions (ε)
– Internal operations in the machine
– No packets are associated.
44
Two Machines
• RFC793 Model:
state diagram of an end node
– A client
H1
– A server
or
H2
• In our Analysis:
Two machines are needed
– A client & A server
45
One Packet at a-time
• one packet is sent, and the response
is sent back
– A transition with two input symbols
Adding a new state Recv SYN
Recv/Send
a new state
Send SYN ACK
46
Invisible transitions
• Internal operation of the machine
– Passive Open: just is in LISTEN state
– no packets are associated
Indicating ε-move
Passive
Open
ε
ε means empty.
47
Invisible transitions (2)
• Internal operation of the machine
– CLOSE : Close( ) system call on a socket
– no packets are associated
Indicating ε-move
CLOSE
ε
ε means empty.
48
The extended machine
CLOSED
H1_snd_SYN
ε
• One transition is
H2_snd_SYN
associated with either:
– Only one packet
LISTEN
ε
H1_snd_SYN
SYN_RCVD_0_1
H1_snd_SYN_ACK
SYN_RCVD
H1_snd_ACK_of_SYN
SYN_RCVD_0_2
H2_snd_SYN
SYN_SENT
ε
H2_snd_SYN_ACK
H2_snd_ACK_of_SYN
– Empty （ε-move）
ESTABLISHED_0
H1_snd_FIN
• A client and a server
H1_snd_ACK_of_SYN
ESTABLISHED
H1_snd_FIN
H2_snd_FIN
FIN_WAIT_1
CLOSE_WAIT_0
H2_snd_FIN
– Direct product of
H2_snd_ACK_of_FIN
H1_snd_ACK_of_FIN
CLOSING_0
H1_snd_ACK_of_FIN
the two machines
CLOSE_WAIT
FIN_WAIT_2
H1_snd_FIN
CLOSING
LAST_ACK
H2_snd_FIN
H2_snd_ACK_of_FIN
TIME_WAIT_0
H1_snd_ACK_of_FIN
RESETTING
H1_snd_RST
TIME_WAIT
ε
H2_snd_ACK_of_FIN
49
CLOSED_2
Classification of flows (1)
• Valid Flow :
– Sequence of packets that can be mapped
to the set of input symbols ∑ of protocol
machine. It starts with SYN, and end
normal with ACK_of_FIN or RST.
• Invalid Flow :
– Sequence of packets that can not be
mapped to the set of input symbols ∑ of
protocol machine. It starts with SYN, but
dose not continue to end due to packets
getting lost, dropped, truncated etc.
50
Classification of flows (2)
• Accepted Flow :
– Sequence of packets that can be mapped to the
set of input symbols ∑ of protocol machine, and
also are accepted by the machine.
– Accepted Flows ⊆ Valid Flows
• Not-Accepted Flow :
– Sequence of packets that can not be mapped to
the set of input symbols ∑ of protocol machine,
and also are not accepted by the machine.
– Invalid Flows ⊆ not-Accepted Flows
51
Measurement and Evaluation (1)
• Real TCP Packets were captured at:
– The Waseda Unv. Entrance link (100Mbs†)
Waseda Unv.
Entrance
100Mbs
CISCO Systems
SERIAL 4 (A/S)
SERIAL 5 (A/S)
SERIAL 6 (A/S)
SERIAL 7 (A/S)
SERIAL 0
SERIAL 1
SERIAL 2 (A/S)
SERIAL 3 (A/S)
SERIAL 8 (A/S)
LINK
ETHERNET 0
AUI
Packet
Capturing PC
ACT
10BT
BRI 0
PWR
The Internet
SD
Input: 100-240VAC
Freq: 50.60 Hz
Current: 1.2-0.6A
Watts: 40W
SERIAL 9 (A/S)
CONSOLE AUX
Cisco
2522
ALR
O
1
ALR
Business Station
† 当時の通信速度
52
Measurement and Evaluation (2)
•
Captured packets:
–By tcpdump
–Input to Protocol Machine
•
Result :
–Total flows:
171,162
–Valid flows:
155,489
–Invalid flows:
15,673 (9%)
–Accepted flows:
118,882
53
Flow Analysis (1)
Valid and Accepted flow with FIN Flag
Destination IP & Port
205.138.3.82:80
Control Sequence Number & Flag description
Source IP & Port
133.9.4.206:2419
Port No.
From > to
2419>80
80>2419
2419>80
2419>80
80>2419
2419>80
2419>80
80>2419
Flag
...S.
.A..S.
.A....
.AP...
.AP..F
.A....
.A…F
.A....
545282610:545282611(1) 0
0:1(1) 545282611
545282611:545282611(0) 1
545282611:545283069(458) 1
1:530(529) 545283069
545283069:545283069(0) 530
545283069:545283070(1) 530
530:530(0) 545283070
H1_snd_SYN
H2_snd_SYN_ACK
H1_snd_ACK_of_SYN
H1_snd_ACK
H2_snd_FIN
H1_snd_ACK_of_FIN
H1_snd_FIN
H2_snd_ACK_of_FIN
54
Flow Analysis (2)
Valid and Accepted flow with RST Flag
Source IP & Port
133.9.4.205:2650
Destination IP & Port
202.239.178.240:80
Port No.
From > to
Sequence Number & Flag description
2650>80
80>2650
2650>80
Control
Flag
....S.
.A..S.
...R..
4010838473:4010838474(1) 0
H1_snd_SYN
2986790084:2986790085(1) 4010838474 H2_snd_SYN_ACK
4010838474:4010838474(0) 0
H1_snd_RST
55
Flow Analysis (3)
Valid but Not-Accepted flow
Source IP & Port
133.9.81.26:3636
Port No.
From > to
3636>80 ....S.
80>3636 .A..S.
3636>80 .A....
3636>80 .AP...
80>3636 .A....
80>3636 .A...F
80>3636 .AP...
3636>80 .A....
3636>80 .A....
3636>80 .A...F
80>3636 .A....
Control
Flag
Destination IP & Port
207.200.89.227:80
Sequence Number & Flag description
2219807304:2219807305(1) 0
H1_snd_SYN
3992619421:3992619422(1) 2219807305
H2_snd_SYN_ACK
2219807305:2219807305(0) 3992619422
H1_snd_ACK_of_SYN
2219807305:2219807736(431) 3992619422
H1_snd_ACK
3992619422:3992619422(0) 2219807736
H2_snd_ACK
3992619542:3992619543(1) 2219807736
H2_snd_FIN **
3992619422:3992619542(120) 2219807736 H2_snd_ACK **
2219807736:2219807736(0) 3992619422
H1_snd_ACK_of_SYN
2219807736:2219807736(0) 3992619543
H1_snd_ACK_of_FIN
2219807736:2219807737(1) 3992619543
H1_snd_FIN
3992619543:3992619543(0) 2219807737
H2_snd_ACK_of_FIN
56
Flow Analysis (4)
Invalid and Not-Accepted flow
Destination IP & Port
Source IP & Port
133.9.184.28:42959 211.16.112.162:80
Port No.
From > to
42959>80
80>42959
42959>80
42959>80
80>42959
Control
Flag
....S.
.A..S.
.A....
.AP...
.A....
Sequence Number & Flag description
H1_snd_SYN
1313868213:1313868214(1) 116761213
H2_snd_SYN_ACK
116761213:116761213(0) 1313868214 H1_snd_ACK_of_SYN
116761213:116761827(614) 1313868214 H1_snd_ACK
1313868214:1313868214(0) 116761827
H2_snd_ACK
116761212:116761213(1) 0
Connection did not continue to the End !
57
Intrusion Detection (Host Scan)
Destination IP & Port
Source IP & Port
Time
Port
No. Control
From > to Flag
Sequence Number & Flag description
133.9.186.134:1195 > 68.15.87.75:80
12:24:05.861884 1195>80
....S.
1453198176:1453198177(1) 0
H1_snd_SYN
....S.
1455468312:1455468313(1) 0
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
133.9.186.134:1218 > 216.20.43.220:80
12:24:10.376513 1218>80
133.9.186.134:1219 > 34.164.140.234:80
12:24:04.758418 1219>80
....S.
1455631285:1455631286(1) 0
12:24:10.777759 1219>80
....S.
1455631285:1455631286(1) 0
12:24:07.668272 1238>80
....S.
1457095247:1457095248(1) 0
12:24:13.687155 1238>80
....S.
1457095247:1457095248(1) 0
12:24:04.959942 1239>80
....S.
1457232651:1457232652(1) 0
12:24:07.968711 1239>80
....S.
1457232651:1457232652(1) 0
12:24:13.988093 1239>80
....S.
1457232651:1457232652(1) 0
133.9.186.134:1238 > 44.26.145.182:80
H1_snd_SYN
H1_snd_SYN
133.9.186.134:1239 > 43.83.175.170:80
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
133.9.186.134:1519 > 123.120.112.157:80
12:24:58.732804 1519>80
....S.
1481888379:1481888380(1) 0
12:25:01.742352 1519>80
....S.
1481888379:1481888380(1) 0
12:25:07.761570 1519>80
....S.
1481888379:1481888380(1) 0
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
58
Intrusion Detection (SYN Flooding)
Source IP & Port
Time
Port
No. Control
From > to Flag
Destination IP & Port
Sequence Number & Flag description
133.9.6.11:10000 > 210.59.230.36:8
20:31:07.235354 10000>80 ....S.
20:31:13.136070 10000>80 ....S.
20:31:19.139384 10000>80 ....S.
20:31:31.144618 10000>80 ....S.
20:31:55.155404 10000>80 ....S.
2977713084:2977713085(1) 0
2977713084:2977713085(1) 0
2977713084:2977713085(1) 0
2977713084:2977713085(1) 0
2977713084:2977713085(1) 0
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
133.9.6.11:11000 > 210.59.230.36:80
20:39:23.328052 11000>80 ....S.
20:39:28.929763 11000>80 ....S.
20:39:34.931938 11000>80 ....S.
20:39:46.937454 11000>80 ....S.
20:40:10.948974 11000>80 ....S.
3167296764:3167296765(1) 0
3167296764:3167296765(1) 0
3167296764:3167296765(1) 0
3167296764:3167296765(1) 0
3167296764:3167296765(1) 0
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
133.9.6.11:11077 > 210.59.230.36:80
20:40:18.353750 11077>80 ....S.
20:40:23.954192 11077>80 ....S.
20:40:29.957267 11077>80 ....S.
20:40:41.962696 11077>80 ....S.
20:41:05.973358 11077>80 ....S.
3185166899:3185166900(1) 0
3185166899:3185166900(1) 0
3185166899:3185166900(1) 0
3185166899:3185166900(1) 0
3185166899:3185166900(1) 0
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN
H1_snd_SYN59
Intrusion Detection
Source IP & Port
Time
Port
No. Control
From > to Flag
(DNS Attack – Port 53)
Destination IP & Port
Sequence Number & Flag description
195.232.50.17:53 > 133.9.1.2:53
20:02:10.214662 53>53
....S.
83676657:83676658(1) 1257861604
H1_snd_SYN
195.232.50.17:53 > 133.9.1.223:53
20:02:12.025809 53>53
....S.
1391296960:1391296961(1) 1568819523
H1_snd_SYN
195.232.50.17:53 > 133.9.16.100:53
20:02:36.751313 53>53 .
...S.
884733909:884733910(1) 885168932
H1_snd_SYN
195.232.50.17:53 > 133.9.129.34:53
20:05:48.574003 53>53
....S.
33640593:33640594(1) 1867004457
H1_snd_SYN
195.232.50.17:53 > 133.9.160.203:53
20:06:42.062425 53>53
....S.
787223951:787223952(1) 351462936
H1_snd_SYN
195.232.50.17:53 > 133.9.189.224:53
20:07:30.373708 53>53
....S.
824496919:824496920(1) 1114978554
H1_snd_SYN
1335095281:1335095282(1) 741695530
H1_snd_SYN
*And continued up to the following flow:
195.232.50.17:53 > 133.9.107.255:53
20:05:12.253487 53>53
....S.
60
Intrusion Detection (SYN Attack)
A
B
Compaq
Compaq 
DeskPro
Compaq
Compaq 
DeskPro
l
Attacker can now
act as B and
establish a
connection with A
SYN attack causes
B to be unable to
reply to A
Attacker
Compaq
Compaq 
DeskPro
l
l
61
Link Congestion (Measurement diagram)
Gigabit
Switch
NCC
OC-12 (622 Mbps)
Packet
Capturing PC
Gigabit
Switch
ALR
O
1
ALR
Business Station
NCC : 国立がんセンター東病院
National Cancer Center
NIRS
NIRS : 放射線医学総合研究所
National Institute of Radiological Sciences
62
Valid / Flow %
Link Congestion (Bandwidth = 622Mbps)
120
100
80
FTP
RCP
60
40
20
0
0
200
400
600
800
Cross Traffic - Mbps
Cross traffic jam : 200Mbps, 400Mbps, and 600Mbps
63
COMPARISON
Method
Standard
IDS
TCP Protocol
Machine
Intrusion
Detection
Network
Congestion
Supported
Supported
Not
Supported
Supported
Flow
Analysis
Not
Supported
Supported
64
Conclusion in 2.1
• Extended machine is built based
on RFC793 (TCP protocol).
•
The extended machine can be
used for Multiple purposes.
– Flow analysis
– Intrusion detection
– Link congestion monitoring
65
2.1 OSのフィンガープリントによる
悪意のある通信の分析
• ボットの脅威の拡大、検出の難しさ
• カーネルマルウェアの増加
– 最も権限の高いレベル（Ring0）で動作し、メモリ、
CPU 命令、すべてのハードウェアデバイスへの
フルアクセスが可能なマルウェア
– すべてがカーネルモードドライバで実装され，コ
ードのすべてがRing0 で実行されるものをフルカ
ーネルマルウェア(FKM) と呼ぶ
– FKMは既存OSのTCP/IP実装とは異なる独自の
ネットワークドライバを実装
※Ring0：CPU の動作モードの中で最も高いレベル。一
般にOSのカーネルはRing0で動作する。
66
研究の目的
• TCPヘッダを分析することにより、FKM（フル
カーネルマルウェア）の可能性がある感染ホ
ストを検出する手法を提案 する
• 今回は、CCC DATAsetからFKMの可能性
があるシグネチャを抽出し、その有効性を
CCC DATAset およびその他の実計測デー
タで示す
（＊） ＣＣＣ サイバークリーンセンター
木佐森幸太, 下田晃弘, 森達哉, 後藤滋樹,
TCPフィンガープリントによる悪意のある通信の分析, コンピュータセキュ
リティシンポジウム2009, pp.553--558, October, 2009.
67
分析手法
• FKMは既存OSとは異なる独自のネットワー
クドライバを実装しているため、TCP/IP ヘッ
ダを分析することで識別できるケースがある
• cf. The Rise and Fall of Reactor Mailer
http://projects.csail.mit.edu/spamconf/SC2009/Hen
ry_Stern/
• CCC DATAsetの攻撃通信データを分析する
ことで、既存OSと異なる実装による（FKMの
可能性がある）通信を抽出、分析する
• 分析の手段としてPassive TCP
fingerprintingを用いる
68
Passive TCP fingerprinting
• TCP/IP の仕様はRFC で定義されているが，
OS 毎にその実装は異なる
• fingerprintingとは、通信の特徴から対象システ
ムのOSを推定する技術
– active：対象システムに対して通信を行い、得られた
データからOSを推定する（nmapが有名）
– passive：対象システムに対して通信を行わず、取得
済みの通信データを分析してOSを推定する
• 今回はp0fというツールを用い、Passive
fingerprintingを実行
69
p0f
• p0fにはいくつかのモードがあるが、今回用いた
のはSYNパケットを分析対象とするモード
• 判定に用いるのは以下のデータ
–
–
–
–
–
ウィンドウサイズ
TTL の初期値
Don’t Fragment ビット
SYN パケット全体のサイズ
TCP オプション（NOP、EOL、ウィンドウスケール、最
大セグメントサイズ、SACK、タイムスタンプ等）
– その他特徴的な点など
• これらを集約し、シグネチャとしてデータベース
化する
70
CCC DATAsetの分析
• 分析対象：CCC DATAset 2008，2009の攻撃通信デ
ータ
• p0fを適用した結果、既存のOSではない、
UNKNOWNであると判定されたシグネチャが多数得
られた
– TTLを2の累乗の値に切り上げ、初期値として推定、集約
– アウトバウンド1種、インバウンド43種のシグネチャが得ら
れた
• UNKNOWNのシグネチャを総称して、MWSシグネチ
ャと呼ぶこととする
• 以後、インバウンドの通信のみを分析対象とする
71
MWSシグネチャの例
• 60352:64:0:52:M1240,N,W2,N,N,S:.:MWS:60352_1
–
–
–
–
–
ウィンドウサイズが60352バイト
TTLの初期値が64
Don’t Fragmentビットが0
SYNパケット全体のサイズが52バイト
以下のオプションが設定されている
• 最大セグメントサイズ、NOPオプション、ウィンドウスケールオプション、
SACK
– その他の特徴はなし
– OSの名称、詳細（バージョン等）
• 今回は、ウィンドウサイズの値により分類し、名称を付けた
72
CCC DATAsetの分析：全体(1)
• 既存シグネチャ、MWSシグネチャのSYNパケット数の比較
– 2009年度は2008年度に比べ全体的に通信量が減少している
– 両年度とも、SYNパケットの半分以上がMWSシグネチャによるもの
73
CCC DATAsetの分析：全体(2)
• シグネチャ毎の送信元IPアドレス数
– SYNパケット数ほどではないが全体的に減少している
– 送信元ホストの半分以上がMWSシグネチャによる通信をして
いる
74
CCC DATAsetの分析：
シグネチャ別SYNパケット数(1)
• シグネチャ毎のSYNパケット数(2008)
75
CCC DATAsetの分析：
シグネチャ別SYNパケット数(2)
• シグネチャ毎のSYNパケット数(2009)
76
CCC DATAsetの分析：
シグネチャ別送信元IP数 (1)
• シグネチャ毎の送信元IP数(2008)
77
CCC DATAsetの分析：
シグネチャ別送信元IP数 (2)
• シグネチャ毎の送信元IP数(2009)
78
CCC DATAsetの分析：
MWSシグネチャの送信先ポート
(2009) (1)


両年度を通じて登場頻度の高いシグネチャについて、
2009年のデータにおける送信先ポートを分析
左： 16384_1、右： 53760_4
79
CCC DATAsetの分析：
MWSシグネチャの送信先ポート
(2009) (2)


左： 60352_3、右： 60352_6
135、139、445、 1433、2967の各ポートについては、
それぞれに応じた脆弱性があることが知られている
80
CCC DATAsetの分析：
頻度の高い通信パターンの分析(1)
• ホストAはMWSシグネチャ60352_6で通信
– 以下SYNパケットのみ
21:26:41 ホストA:9109 -> ハニーポットA:135 (scan)
21:26:41 ホストA:9110 -> ハニーポットA:135 (rpc)
21:26:43 ホストA:9197 -> ハニーポットA:135 (rpc)
21:26:43 ホストA:9203 -> ハニーポットA:1013 (シェルコード送信)
21:26:43 ハニーポットA:1028 -> ホストA:3450 (malware 要求)
21:26:43 ハニーポットA:1028 -> ホストA:3450 (malware 要求)
※各行冒頭はタイムスタンプ
81
CCC DATAsetの分析：
頻度の高い通信パターンの分析(2)
• ホストBはMWSシグネチャMWS 53760_4で通信
00:35:11 ホストB:56101 -> ハニーポットB:135 (rpc)
00:35:13 ハニーポットB:1027 -> ホストB:47602 (malware 要求)
00:35:13 ハニーポットB:1027 -> ホストB:47602 (malware 要求)
• CCC DATAsetの攻撃元データに、ダウンロードが成
功した記録が残されている
2009-03-13 00:35:13, ハニーポットB,1027, ホストB,47602,
TCP,c925531e659206849bf7********************,
PE_VIRUT.AV,C:\WINNT\system32\csrs.exe
82
CCC DATAsetの分析：
頻度の高い通信パターンの分析(3)
• ホストCは、最初のSYNパケットのみMWSシ
グネチャ16384_1で通信
• 2つ目・3つ目のSYNパケットはWindowsのシグネチャであ
った
00:57:09 ホストC:6000 -> ハニーポットB:135 (scan)
00:57:13 ホストC:3197 -> ハニーポットB:135 (rpc)
00:57:15 ホストC:4139 -> ハニーポットB:135 (rpc)
83
CCC DATAsetの分析：
シグネチャ毎の通信内容


一度以上通信が成立したシグネチャについてまとめた表
MWSシグネチャではftpとshellコード送信が多く、他はほと
んどないことがわかる
シグネチャ
ftp
http
irc
shell
smb
sql
MWS 60352_6
232
0
0
558
0
0
MWS 53760_4
50
1
0
307
0
0
MWS 60352_3
38
0
0
66
0
0
MWS 65535_7
12
0
0
21
0
0
MWS 60352_2
0
0
0
18
0
0
MWS 60352_1
0
0
0
6
0
0
694
563
202
1660
9234
723
すべての通信
84
他のネットワーク通信データの分析：
早稲田大学(1)
• 早稲田大学の対外接続回線におけるすべての通
信データ （SYNパケットのみ、7/1～7/7）を分析
• 今回抽出したシグネチャを適用したところ、44種
のうち20種が検出された
• 全送信元IPアドレス954,100 に対し、MWSシグ
ネチャを有するものは280（約0.03%）程度
• 多く発見されたシグネチャやその送信先ポートな
どの傾向はCCC DATAsetとは大幅に異なった
– ファイアウォールの内側でデータの収集を行ったため
と考えられる
85
他のネットワーク通信データの分析：
早稲田大学(2)
• MWSシグネチャはすべてDFビットが0であったが、これ
を1に変更して再度p0fを適用
• 44種のうち31種が検出された
• 全送信元IPアドレス954,100 に対し、これらのシグネチ
ャを有するものは5300（約0.5%）程度に増加した
• CCC DATAsetにて検出されたシグネチャは、既存OS
のものも含めすべてDFビットが0であった
• DFビットは経路上のルータ等で書き換えられる可能性
がある。もともとはDFビットが1であった可能性がある
– DFビットが1だとしても、MWSシグネチャと既存のシグネチ
ャとはやはり異なる
86
他のネットワーク通信データの分析：
企業のsmtpデータ
• ある企業網の電子メールサーバに接続したネットワー
クセグメントで収集したTCP ヘッダデータ（SYNパケッ
トのみ、3/1～3/31）を分析
• 全通信元IPアドレス1,230,830に対し、MWSシグネチ
ャを有するものはわずか53
• これらのIPから発信されたものはほとんどスパムメー
ルであった
– マルウェアの構成によってはスパム送信モジュールを搭
載するものもあると考えられる
• MWSシグネチャのDFビットを1にして再度p0fを適用
したところ、これらのシグネチャを有するIPは2877（約
0.23%）まで増加した
87
2.2 まとめ
• CCC DATAsetからFKMの可能性がある（既存の
TCPスタックと異なる実装である）シグネチャを抽出、
通信の分析を行った
• これらのシグネチャによる攻撃通信が多数見られた
• 他のネットワーク上でもこれらのシグネチャが見られ
ることが確認できた
– 割合としては、各々送信元IPの1%未満
– CCC DATAsetは、実ネットワーク上の通信に比べ、これ
らのシグネチャによる通信の割合が非常に高い
• 今後の課題
– シグネチャの詳細な検討、さらなる集約
– ハニーポットを利用したFKMの収集と分析
– 他のネットワーク通信データの詳細分析
88