the startup script to monitor the vmnet1 interface of the HostOS. You will most likely want to run this script daily, running the script from cron. host #./snort-start.sh Since this is a GenII Honeynet, you may want to consider using more advance Data Capture techniques, such as Sebek. This allows you to capture the attacker's activities from kernel space. There are also a variety of other options for implementing Data Capture which are beyond the scope of this paper. For additional options, check out Honeynet Tools Section .

Part V: Testing Your VMware Honeynet

The fifth, and final step, of building our VMware Honeynet is to test our configuration, specifically Data Control and Data Capture. We want to ensure that our Honeynet requirements are behaving as expected. Testing Data Control is relatively simple. We want to ensure that any attempt by the honeypot to initiate an outbound connection is both logged and controlled. By logged, all connection attempts should log an entry to /var/log/messages, alerting us that an outbound connection has been initiated, and the honeypot has most likely been compromised. Also, once the limit has been met, we want to ensure that no more outbound connections are allowed. There is one trick to testing our Honeynet, since we are bridging we need a second computer, the attacker. The bridge will not forward any packets if it cannot match the destination IP to a valid MAC address. If no packets are forwarded, we cannot test IPTables. For those of you who don't have a second computer (or who are just hard core geeks), you can run a second computer virtually by starting up a UML system. The UML system will bind to the tap0 virtual interface, while all of our VMware honeypots will bind to the vmnet1 virutal interface. This way your HostOS is bridging two different virtual networks. Remember, you will have to modify your rc. Firewall script with tap0 being the external interface. To learn more about running UML, refer to the paper KYE: UML . The UML can be the attacker, probing the VMware honeypots. For the purpose of this paper, that is the testing concept we will demonstrate. Our UML attacker's IP address will be 10.10.10 .100. Yes, this really does work :)

Note: As this paper was going through the final review phase, the Project has begun using one of VMware's other features for advance forensic analysis.

Specifically, the Suspend feature of VMware. Suspend allows you to literally

suspend a GuestOS (or honeypot) image. It freezes all the running processes and saves the memory image to a file. This means you can Suspend your honeypot, turn off your computer, turn it on a week later, bring back up the honeypot,

un-suspend it, and you will have it exactly where it was before. This has some

incredible forensic applications. The Project has begun saving suspended images of hacked computers, then sending those images to others for analysis. This allows us to analyze a hacked honeypot while its still in its running state. The concern here is when analyzing suspended images, you have to ensure you are doing this on an isolated network, or your hacked honeypot will attempt to connect to any systems it was communicating with before being suspended.

Conclusion

The purpose of this paper was to describe step by step how to build a virtual

Honeynet using VMware virtualization software. The goal is to build an entire

Honeynet on a single computer. The advantage with VMware is you can run many

different types of operating systems at the same time. If you would like to try building your own VMware honeynet, you can get an eval copy of VMware at

http://www.vmware.com/download/#eval

 << 上一页  [21] [22] 下一页