Difference between revisions of "Talk:Lecture 12"
(→Liability in Honeypots) |
|||
| Line 3: | Line 3: | ||
== Liability in Honeypots == | == 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. | [[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. | ||
| + | |||
| + | [[Daryl Sterling Jr]] - What if a bot were created that "phoned home" and downloaded the latest version of Adaware and ran in on the "infected" computer, then deleted itself then slowly distributed itself to other machines? And it ONLY did cleaning when the machine was idle and only spread itself when the network had low usage? Also, to get around legalities, before it installed itself, it ASKED to user to click "Yes" or "Ok"...because we all know how well that works for spyware, why wouldn't it work for good stuff? | ||
Revision as of 23:42, 17 November 2005
Contents
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.
Daryl Sterling Jr - What if a bot were created that "phoned home" and downloaded the latest version of Adaware and ran in on the "infected" computer, then deleted itself then slowly distributed itself to other machines? And it ONLY did cleaning when the machine was idle and only spread itself when the network had low usage? Also, to get around legalities, before it installed itself, it ASKED to user to click "Yes" or "Ok"...because we all know how well that works for spyware, why wouldn't it work for good stuff?
