honeystat: local worm detection using honeypots david dagon, xinzhou qin, guofei gu, wenke lee, et...
DESCRIPTION
The rest of presentation Background Honeystat Approach Strength & Weakness & Possible ExtensionTRANSCRIPT
HoneyStat: Local Worm Detection Using HoneypotsDavid Dagon, Xinzhou Qin, Guofei Gu, Wenke Lee, et al from Georgia Institute of TechnologyAuthors:
The 7th International Symposium on Recent Advances in Intrusion Detection (RAID 2004).Publish:
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 labor-intensive 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 VictimPort 135 exploit
ACK
Shell command
sftp getTransfer 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 RevisitAttacker Victim
Port 135 exploitACK
Shell command
sftp getTransfer egg
Additional attack
Memory Event
Network Event
Disk Event
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
PaPbPc
Who trigger the event?
Honeypot a
Event
PfPbPe
Honeypot bCheck 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
PaPbPc
Do we need another?
PaPbPc
Do we need another?
PbPd
Do we need another?
yes PaPbPf
Do we need another?
yes Pe
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 Honeystat
Worm
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
Simulation is not convincing Using traffic log as background, add synthetic honeypot events
EventPaPbPc
tr
Possible Extension 1 Collaborate or global
approach A large IP space
coverage
Local network
Honeypots
Local network
Honeypots
Analysis node
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
Event
PaPbPc
Abnormal?
Possible Extension 4 Packet replay
Send recent packets to another similar honeypot See which one crash the honeypot
Event
PaPbPc
Send Pa
Send Pb
Crash
replay
Question