Know your enemy: Learning with VMware
Built virtual Honeynets with VMware
Honeynet ProjectHttp://www.honeynet.orglast Modified:
27 January, 2003
Translation: inetufo
Homepage: http://www.fz5fz.org
http://www.thugx.com
Email: inetufo@fz5fz.org
Translator Note:
This is the second article in the virtual Honeynet series of articles I translated, mainly telling how to use virtual machine software VMware to build virtual Honeynet.
Since I have limited level and time, it is inevitable that there is an unstoppable place, but also the ax is being. Finally, I would like to thank San's opinions.
Original connection: http://www.honeynet.org/papers/vmware/
Virtual Honeynets is a solution to a complete Honeynet that allows you to build a complete HoneyNet with a variety of operating systems on the same computer. Initially been discussed in article Know your Enemy: Virtual Honeynets, this program has a configuration, and more simple management. HoneyNet Project also found that VMware has significant the development of Honeynet technology. Through this article, we teach you how to build and configure this solution with business software VMware. In this case, we will build a Genii (second-generation Honeynets) with 5 different Honeypots. The premise is that you have read and understand some of the concepts discussed in Kye: Virtual Honeynets and Kye: Honeynets. At the same time, if this is your first Honeynet technology, we strongly recommend that you work in an experimental environment. Finally, because in the face of virtual software, you must realize that the attacker identifies and secretly escapes the risk of the virtual environment. The above is the recommendation to you.
Attack plan
The format of this article is a bit similar to Kye: user-mode linux, which is divided into 5 parts. The first part we will describe what is VMware, its work mode, and how to install it. The second part, we will describe how to configure VMware and install your Honeypots. The third part we will describe how to use iptables in the VMware Honeynet to implement data control. The fourth part we will describe how to use Snort to implement data capture. Finally, in the fifth part we will describe how to test your various settings.
Part i: vmware
VMware is a virtual software that allows you to run multiple operating systems at the same time. Unlike user mode Linux, VMware allows you to run different operating systems as long as they are able to run on the Intel X86 series. VMware is developed and sold by VMware INC, in fact you can choose from three different software products: Workstation, GSX, or ESX. We will use the GSX among the three. GSX is designed to run more than two operating systems at the same time, support remote management, more powerful than Workstation features. However, most of the information we can discussed here is on WorkStation. In view of this purpose, we will build our virtual Honeynet on the handheld, platforms for IBM ThinkPad T23, PIII 1G processor, and 768MB memory. The operating system is RED HAT 7.3.
VMware works by installing virtual software on your computer. This virtual software allows you to start and run multiple operating systems at the same time. The first operating system you install is called Hostos. This is the operating system that VMware will be installed. Once you have installed Hostos and VMware, you can install other operating systems, which will run in the virtual environment. All of these other operating systems are called GuestOS's because they are "the 'guest' on the main operation system. For a better understanding of its work, please refer to Figure 1. Installing VMware on our Linux Hostos is very simple, you just need to install an RPM package. Command is similar to: Host # rpm -vi vmware-gsx-2.0.1-2129.i386.rpmpreparing packages for installation ... VMware-GSX-2.0.1-2129
We can also install additional packages, such as remote management packages. However, our handheld does not need this package because all management is done locally. To learn more about these additional packages, please refer to the VMware documentation.
Part II: Configuring VMware and Installing Honeypots
The next step after installation is to configure VMware software. The configuration is done by executing 'VMware-config.pl'. In the configuration process, VMware is likely to recompile some of its core modules. This means you have to prepare the compiler and source code for the kernel. The kernel version running on our handheld is 2.4.18-19.7.x. Then we make sure there is a source code:
Host #uname -r
2.4.18-19.7.x
Host #
Host #RPM -QA | GREP SOURCE
KERNEL-SOURCE-2.4.18-19.7.x
Marge $ LS -L / USR / SRC
Total 8
LRWXRWXRWX 1 root root 19 DEC 26 13:53 Linux-2.4-> Linux-2.4.18-19.7.x
DRWXR-XR-X 17 root root 4096 DEC 26 13:53 Linux-2.4.18-19.7.x
DRWXR-XR-x 7 root root 4096 JUL 12 11:52 redhat
If you have already installed the source code, you can start installing. In the installation process, the only choice we have to pay attention to is the network. Keep in mind that our goal is to make all GuestOS's route through our gateway Hostos. Select the network during the installation process. When the installation process is to end, you will be asked if you use the Hostonly network mode. Select this item to assign an IP address to the interface. This is the IP address of the gateway, we will be set to 10.10.10.1. The following link is a series of commands executed during the configuration process.
VMware-Config.pl
When you complete the configuration, VMware can run. However, we have a problem that VMware allows three interfaces: VMNET0, VMNET1, VMNET8 when using default configuration. In these three interfaces, we only need an interface, VMNet1. Vmnet0 is used for the bridge, so Guestos can use Hostos to directly network sessions directly. VMNET8 is used in NAT networks. Only VMNET1 allows us to control GuestOS's through Hostos. In this way, we have to re-run VMware-Config.PL, then use the editing tool to remove two unwanted interfaces VMNET and VMNet8.
VMware-Config.pl (second run)
When you complete the configured VMware configuration, the next step is to install and configure each HoneyPots. For our Honeynet, we have to install 5 different Honeypots. The requirements required to run so many operating systems are not as high as you think. Think about it, no one will use them outside of the attacker, so the event is very small. At the same time, unix-based systems do not require GUI, you can manage the system through the command line interface. This will not need to run x-windows, and the needs of memory reach the least. Each operating system only needs no more than 2GB disk space. Red Hat Linux 8.0 (64 MB RAM, not running X-windows) Solaris8 x86 (64 MB RAM, not running X-Windows) openbsd 3.1 (64 MB RAM, not running X-Windows) Windows2000 (128 MB RAM) WindowsXP (128 MB RAM)
Each HoneyPots install is very simple. First, use the command "PS AEF | GREP VMNET" to ensure that the VMware virtual software is running, with the command "ifconfig -a" to ensure that the VMNet1 interface is used. If VMware has run, create a new VMware window to install Honeypot. The command is as follows:
Host #VMware -g &
Once you have created a window, you can choose to start an existing guestOS or start installing a new GuestOS. If you want to install new guestos, select Run Configuration Wizard. In the wizard, select the type of GuestOS you will install, the directory of the file system to be installed, create a new virtual disk for the operating system, enable CDROM (if you hung drive, uninstall) and Hostonly network. After completing the Guestos configuration, insert the CDROM installation disk of the guest operating system, then start the system. Thereafter, the startup and installation of Guestos are the same as that of other operating systems. Continue repeating these steps to install all these 5 Guestos Honeypots. Once the installation is complete, you can choose to install VMware Tools on Honeypots. It will solve the GUI interface. But for UNIX systems, you don't need to install VMware Tools because you can manage it through the command line. For Windows-based HoneyPots, you need to install VMware Tools in HoneyPots to make it easy to manage, but it will make the attacker's more easier identification system is a VMware virtual system. To get more information about the VMware configuration and GuestOS installation, please refer to the VMware document.
Before performing the next step, you need to back up your installed Honeypots. VMware stores each HoneyPots in a separate file, which is placed in the VMware's own directory. You can back up each honeypot by copying these independent files. For traditional Honeynets, after a HoneyPot has a security threat, you will spend a lot of energy to analyze attack records, you must restore them before putting your Honeypot back to Honeynet. This is very wasteful. However, after using VMware, restore Honeypot just copy your backup file as simple as you. You can make your HoneyPots to run in a very short time. For example, by default, VMware stores each HoneyPot image under directory / root / vmware. You can back up all HoneyPots by copying this directory. When you want to recover a Honeypot, you can only copy the directory containing all the HoneyPot image files.
Host #ls -l / root / vmware
Total 28
DRWXR-XR-X 2 root root 4096 Oct 10 01:10 Linux-6.2drwxr-xr-x 2 root root 4096 Jan 14 19:00 Linux-7.2
DRWXR-XR-X 2 root root 4096 Jan 14 22:14 Linux-7.3
DRWXR-XR-X 2 root root 4096 Jan 25 15:15 openbsd
Drwxr-xr-x 2 root root 4096 Jan 25 15:15 Solaris
DRWXR-XR-X 2 root root 4096 DEC 16 08:47 Win2000Serv
DRWXR-XR-X 2 root root 4096 Jan 25 15:15 WinXPRO
Host #
Host #cp -a / root / vmware / root / vmware-backup
Part III: Data Control
The next step after completing the VMware and HoneyPots configuration is that the data is controlled. The purpose of data control is to get an attacker to enter and export all information about HoneyNet. In particular, we allow all data to enter the Honeynet system, but limits the external connection. In view of this purpose, we will use iptables that own the firewall with this Linux comes with an open source of open source. Iptables is a fairly high-flexible formal firewall, with connection restrictions, network address translation, logging features, and many other features. We configure iptables into a filter on our Hostos, calculating datagrams that flow out network. Once the external connection arrives at the number of restrictions, all of the connection attempts will be blocked, ensuring that the invaded Honeypot does not cause damage to other systems. Configuration and implementation of these properties may be very complicated. However, HoneyNet Project has written a iptables script called Rc.firewall, which can help you complete all your work. You just need to modify the script variable to adapt it to your Honeynet and then run the script.
One thing you want to decide is that you want to make the gateway run in the third layer of routing mode, or the second layer of bridge mode. The second layer bridge mode (also known as genii, or 2nd generation) is the preferred method. When the gateway plays the role of the bridge, there is no data report route and the TTL consumption of the datagram. It has become an invisible filtering device that makes the attacker make it harder. However, if you want to make iptables in the bridge mode, your kernel must patch to support it. By default, the vast majority of the kernels do not support the bridge mode of iptables. Red Hat Kernel 2.4.18-3 is one of the few kernels that support this mode by several by default. If you want to modify the kernel, you can find a patch at http://bridge.sourceforge.net/download.html. Considering the purpose of this article, we will assume that your kernel does support the bridge mode of iptables. If your kernel does not support bridge mode, please refer to article KYE: UML to get more information about configuring rc.firewall to support third layer routing.
Now let's talk more about how to configure the rc.firewall script to implement Genii's functionality. There are two places that need to be configured, network, and control. In fact, the network is far more than the routing mode in the network bridge mode. In bridge mode, there is no route, or any network address conversion problem. We only need to simply turn Hostos to bridge, GuestOS's can communicate directly with other network. For connection issues, we need to configure how much external connections are allowed. The options we need to configure are as follows. First, you need to set the external IP address of the guest operating system. These are the IP address of the attacker to attack, which is the valid IP address of our HoneyPots. Since we have five honeypots, we need to list five IP addresses. The firewall needs to know their scope. Public_ip = "10.10.10.201 10.10.202 10.10.10.203 10.10.10.204 10.10.10.205"
Second, you have to identify the name of the internal interface of Hostos. The default is Eth1. However, we will use virtual interface VMNet1, you need to modify this variable.
Lan_iface = "VMNet1"
Finally, since we have to build a Genii HoneyNet, you must consider using the Snort's own feature to prevent known outward attacks. Description Snort-inline has exceeded the scope of this article, it will be discussed in the future article Know your Enemy: Genii Honeynet. You may consider using the HoneyNet Snort-Inline toolkit, which has static, compiled binary, with configuration files, rules and documents, you can find the Snort-Inline toolkit in HoneyNet Tools Section. If you really want to test this performance, you need to enable Queue options. Note: If you enable this option, you must ensure that Snort-Inline has been run, and all outgoing datagrams will be discarded. Do not enable this feature if you don't have the above requirements.
# Queue = "yes" # @ use experimental queue supportqueue = "no" # do not use experimental queue support
These are the least variables you need to consider, there may be other variables, which will depend on your system configuration. You can also update other options, such as remote management, limit the connection that the firewall can initiate, give your HoneyPots unlimited DNS access. Similarly, by default, the script limits each HoneyPot external connection, 9 TCP connections, 20 UDP connections, 50 ICMP connections, and 10 other IP connections. The specific content of the script exceeds the category of this article. In order to better understand these variables, we recommend that you review the specific content of the script and try different configuration options in the experimental environment. Once you have completed the rc.firewall script configuration, you can implement your goals by performing scripts. Remember, you will make your Hostos use bridge mode. Therefore, your Hostos must have a bridge tool. For the Red Hat system, it is "Bridge-Utils-0.9.3-4".
Pay attention to two points when using bridge mode. First, you must start all GuestOS's before enabling the bridge. When GuestOS's is started, they will find and use the VMNet1 interface. If the VMNet1 interface has been set to bridge mode, then guests will not find the interface and cannot be internetable. So, start all Honeypots before running the RC.FireWall script. The second point is time, the bridge takes effect takes approximately 10-30 seconds. You must get all the Mac's addresses before the bridge forwards the datagram. Host # /. rc.firewall
In order to ensure that the script is successful, we need to check a few things. First, it is determined that the bridge is enabled. You can confirm by checking / var / log / messages files, the core will record the bridge mode. Second, you have to have a new interface called "BR0", this is your bridge. Third, use the command "BrCTL" to see what the interface between the binding bridge is. Fourth, the external and internal interfaces no longer have IP addresses because they are now using bridge mode. Finally, check the iptables rules to make sure you filter some connections.
Host #tail / var / log / messages
Host #ifconfig -a
Host #brctl show
Host #iptables -l -n
If the above is successful, then your data control is also completed. There are many other ways to achieve data control, such as Bandwidth Throttling.
Part IV: Data Capture
The next step after completing the data control is data capture. The purpose of data capture is to capture all the information of their attack activities without letting an attacker. There are many different ways to achieve data capture, but we mainly pay attention to two. IPTable logs and Snort. The iptable log is a log generated by the firewall when there is data into or outflow. Snort is an open source IDS product, we can use it to capture all network activities, issue a warning for known attack characteristics.
For IPTabels, logging has been configured with script rc.firewall. It is configured to record all new pairs and external connections to log files / var / log / messages. Any incoming connection may be signs of detection, scanning, or attack. Any external connection indicates that Honeypot may have been invaded. The main value of the iptable log is warning. Not to tell us enough information about the invader being doing. For Snort, we can configure it to capture each datutical newsletter of the HoneyNet. Here is a Snort configuration file Snort Config File that captures and records intruders. You can see a simple Snort boot script here, which can start SNORT and use the recommended Snort configuration file. Don't forget to update the startup script to monitor the VMNet1 interface of Hostos. You may want to run this script every day, then you can run this script through cron.
Host #. / Snort-Start.sh
Since this is the second-generation Honeynet, you can consider using more advanced data capture techniques, such as Sebek. It allows you to capture the activity information of the attacker through the kernel. Of course, there are other various ways to achieve data capture, but they exceed the category of this article. For other ways, please refer to HoneyNet Tools Section.
Part V: Test your VMware Honeynet
The fifth step of our VMware Honeynet is also the final step is to test our configuration, especially for data control and data capture. We must ensure that our Honeynet is the same as the expected situation. The test of data control is relatively simple. We want to make sure that Honeypot is intempting any connections initiated outwards to be recorded and controlled. By recording, all connected attempts are recorded in / var / log / messages, warning we have an outward connection, and HoneyPot may have been invaded. At the same time, once the connection restriction is reached, we want to make sure that any more outward connections are prohibited. Here is a test of HoneyNet, since we use bridge mode, we need another computer to make it act as an attacker. If the bridge cannot convert the destination IP into a valid MAC address, it will not forward any datagram. If there is no datagram to forward, we will not test iptables. For those who don't have excess computers (or those who are reluctant to spend money), you can start the UML system virtual out the second computer. The UML system will bind to the TAP0 virtual interface, and all of our VMware HoneyPots will bind to the VMNet1 virtual interface. In this way, your Hostos will connect two different virtual networks on the bridge. Please don't forget, you have to modify the rc.firewall script to make TAP0 into an external interface. To learn more about running UML, please refer to the article Kye: UML. UML can be used as an attacker to detect VMware Honeypots. In view of the purpose of this article, we will demonstrate just testic concepts. Our UML attacker's IP address will be 10.10.10.100. It does work :). We will test the external TCP connection. The default configuration can only initiate 9 external connection attempts per hour. In order to test this, we need to open two terminal windows. First, we open a terminal window on Hostos and monitors the iptable log in / var / log / messages. When we try to initiate an external connection from GUESTOS, we will find that the connection attempt will be recorded in the log. This information is warning, indicating that Honeypot may have been invaded, an attacker (or some automated attack tool) is trying to connect. When initiating the 10th connection, the TCP connection will be blocked (because the maximum connection limit) and record are reached. Below is the command you want to execute before you try any external connection.
Host #tail -f / var / log / messages
Next, open a terminal on our guestos, Honeypot system. To an external IP, a variety of external TCP connections are hereby 10.10.10.100 (our UML system). You are likely to try a few times.
TRYING 10.10.10.100 ... Telnet: Connect To Address 10.10.10.100: Connection Refused
If you see the connection attempt to be recorded, the connection after the connection limit is blocked, then you have successfully implemented data control. Next, we will ensure that data captures normal work, especially ensuring that the Snort process captures all Data reports that enter and export HoneyNets and all of them. The SNORT process should monitor the internal interface of Hostos, especially VMNet1. For testing, we will try the external system where it is also 10.10.10.100.
Guest #ping -c 3 10.10.10.100
The SNORT process should have captured three ICMP ECHO request datagrams and all of them. It should record the activity in the form of a TCPDUMP binary log. We check the log file to confirm, the following is an example. It is worth noting that you are not just capturing every datagram and packet head, but caught all the loads of each datagram. Host #snort -vdr * Snort.log
It's it. Now, you only completed the most basic testing of data control and data capture performance. You can also try to perform more advanced tests, such as using another independent computer as a system on the Internet, then communicating with Honeypot. However, this is beyond the scope of our article.
Note: This article is coming soon, we now make a final review, we use other characteristics of VMware's to do a further disclosure analysis. Especially the hanging function of VMware. The suspend feature allows you to hang a guests (or Honeypot) image one by one. It will freeze all the running processes and save the memory image in a file. This is, you can hang your Honeypot, close your computer, then open it again, reload Honeypot, just like it is time it is running. It has some unimaginable applications. We save the hang image of the attacked computer and transfer these images to other places. This allows us to analyze it when an attacked Honeypot is still in its operational state. It should be noted here that when analyzing the occurrence of the image, you must guarantee that it is in an isolated network. Otherwise, the attacked Honeypot will try to connect to any system that will communicate with it before hang.
in conclusion
The purpose of this article is to talk about how to use VMware virtual software to build a virtual Honeynet. Our goal is to build a complete Honeynet on a computer. The advantage of VMware is that you can run many different types of operating systems at the same time. If you want to try to build your own VMware Honeynet, you can get a trial version of VMware at http://www.vmware.com/download/#eval.
