Talk:Lecture 12

From CyberSecurity
Revision as of 06:56, 17 November 2005 by Fleizach (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Liability in Honeypots

Chris Fleizach - Here's my idea to prevent liability issues in honeypots. What you want is your infected computer to communicate with the master (and issue IRC commands for example) so it appears to be an active bot, but you don't want it to participate in infection and DDoS attacks. So when data comes in, it's allowed to infect a computer. Any further data that it produces gets sent to a buddy computer and a gateway. The gateway holds up the data. The buddy computers runs network services in sandboxes that allow it to examine what happens to the system. If surreptitious files are created or modified, sockets opened or memory changed in unpredictable ways, then we assume the data coming from the infected bot is malicious, so we tell the gateway to discard that output. If nothing happens (ie an IRC command is sent), then the buddy computer notifies the gateway and allows it to proceed. The same idea applies for a DDoS, but it should be easier to identify since a dramatic increase in bandwidth can be noticed quickly. One issue that this doesn't address immediately is what if an infected bot then sends out exploits that affect other OS's (ie. Win 2000 or WinXP SP2 and the buddy is running SP1). So the buddy computer won't get infected and allow it to proceed, possibly causing problems. The immediate solution is to multiplex your buddy to run various versions of OS's, which shouldn't be that difficult with virtual machine software (VMware, Xen), but could raise complications if you need to model various patch states.