Download ppt

HoneyStat: Local Worm
Detection Using Honeypots
Publish:
The 7th International Symposium on Recent
Advances in Intrusion Detection (RAID 2004).
Authors:
David Dagon, Xinzhou Qin, Guofei Gu, Wenke Lee,
et al from Georgia Institute of Technology
Presenter:
Jianyong Dai
Contribution
 A sample for automatic detecting
worm using high interactive
Honeypots
 A local network approach to detect
worm explosion
The rest of presentation
 Background
 Honeystat Approach
 Strength & Weakness & Possible
Extension
Outline
 Background
 Worm detection
 Honeypots
 Worm infection cycle
 Honeystat Approach
 Strength & Weakness & Possible
Extension
Worm Detection
 Worm detection based on scan rate
 Abnormal quick increase in scan rate
 Large volume of data is required to
achieve statistical stable
 So, the need for global monitoring is
obvious
 Not suitable for a small local network
Honeypots
 Configured inactive, non-public
 Almost no false positive in detecting
network intrusion
 Every event in honeypots is important
 Traditionally, honeypots require laborintensive management and review
 40 hours to analyze 1 hour traffic log for
an expert
High interaction honeypots
 Install real application, not a
simulator
 Let worm get through
 Be able to capture all activity of a worm
 Prevent malicious action
 Prevent honeypots infect other computer
Worm Infection Cycle
 Blaster worm illustration
Attacker
Victim
Port 135 exploit
ACK
Shell command
sftp get
Transfer egg
Additional
attack
Worm Infection Cycle
 Worm events within victim machine
 Memory event
 Memory crash
 Failed buffer-overflow attack
 Disk event
 Write a file into file system
 Network event
 Outbound traffic
Blaster Worm Revisit
Attacker
Victim
Port 135 exploit
ACK
Memory Event
Shell command
Network Event
sftp get
Transfer egg
Disk Event
Additional
attack
Network Event
Worm Infection Cycle
 Any of memory event, disk event or
network event in Honeypots is due to
Intrusion
 It is one of the previous inbound
packet cause the event for sure
Outline
 Background
 Honeystat Approach
 Idea
 Event Correlation
 Modeling
 Strength & Weakness & Possible
Extension
General Idea
 Every honeypot event is due to intrusion
 Memory crash
 Disk write
 Outbound traffic
 Not every incoming traffic is worm




Network administration tool
Web robots
Old worm scan
Real hacker attack
General Idea
Event
Pc
Pb
Pa
Honeypot a
Who trigger the
event?
Event
Pe
Pb
Pf
Honeypot b
Check other honeypots
to find more evidence
General Idea
 Use logistic regression to find out who
make the trouble
 Can specify a confidence level
Honeystat
 Array of full functional honeypots
 Use VMWare to create 64 virtual
machines in one physical machine
 Every WinNT VM can bind 32 IP addresses
 Every VM with 32M RAM and 770M disk
 It ends up one machine cover 64*32 =
211 IP address
Honeystat
 Wait for event, send these information when
event occurs
 OS/patch level
 Type of event
 Incoming network traffic right before the event
(within range t)
Honeystat
 When memory or disk event happens
 Wait for other interesting things
 When a network event happens
 Reset the VM, restore disk image
 Switch other VM to the OS of the
exploited VM (optional)
 Increase the chance to capture the same
event in other honeypots
Logistic Regression
 Assumption
 Only one worm attack
 The closer packet, the better
 Empirically, 5 events are needed to
confidently(95%) identify the cause
Pc
Pb
Pa
Do we need
another?
yes
Pd
Pb
Do we need
another?
yes
Pf Pe
Pb
Pa
Do we need
another?
Error
 Not every event is a worm
 Other type of intrusion
 It’s nice because we can further identify
other intrusion
 True worm, but we get wrong cause
 Need more instance
 Usually 5 events are required to identify
the cause
Modeling
 How quick can we detect worm
 IP coverage
 Number of victims needed
Internet
Worm
Honeystat
Outline
 Background
 Honeystat Approach
 Strength & Weakness & Possible
Extension
Strength
 Comparing to signature based
approach
 Do not need signature
 Can detect unknown worm
Strength
 Compare to low interactive honeypots
(honeyd)
 Can get more worm behavior
 Can detect worm confidently
Strength
 Comparing to scan based detection
 Works in small network which is
statistically unstable
 Can also identify the causing packet
Strength
 Comparing to other behavior based
approach
 Can capture more types of worms
 Only one simple assumption has been made:
take one packet, and trigger one event
Limitation
 Can not detect slow worm
 What if the worm idled for a long time
after initial exploit
 A large IP space needed
 211 means 8 class C network
 Can only detect random scan worm
 Santy: find host using google
Weakness
 Not so strong in data manipulation
 Only logistic regression has been tried
 Only use 1/tr as variable
Event
Pc Pb
Pa
tr
 Simulation is not convincing
 Using traffic log as background, add
synthetic honeypot events
Possible Extension 1
 Collaborate or global
approach
 A large IP space
coverage
Analysis node
Honeypots
Local network
Honeypots
Local network
Possible Extension 2
 Automatic fingerprint generation
 We can identify port
 Actually we also have the intrusion
packet
 Sometimes we can not block a port
 Generate fingerprint
 Is 5 event enough to generate a fingerprint
Possible Extension 3
 Using abnormal detection instead of
correlation
 By instinct, in most case, one event is
enough to identify the causing packet,
that is, the preceding abnormal packet
Abnormal? Event
Pc
Pb
Pa
Possible Extension 4
 Packet replay
 Send recent packets to another similar
honeypot
 See which one crash the honeypot
Event
Pc
Pb
Pa
Send Pa
Send Pb
Crash
replay
Question