Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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