Use VMware to build a virtual honeynets

Use VMware to build a virtual honeynets

From: http://www.xfocus.net

Honeynet Project
Http://www.honeynet.org
Last modified: 27 January, 2003

Translation: inetufo

Homepage: http://www.fz5fz.org

Email: Inetufo@fz5fz.org

Note:

This is the second article in the virtual Honeynet series I have translated. It mainly describes how to use the Virtual Machine Software VMware to build a virtual Honeynet.

Due to my limited level and time, it is inevitable that there will be some improper translations. Finally, I would like to thank Mr. San for his suggestions.

Connection: http://www.honeynet.org/papers/vmware/

Virtual honeynets is a solution that allows you to build a complete Honeynet with multiple operating systems on the same computer. It was initially discussed in the article know your enemy: Virtual honeynets. This solution has the advantages of Easier configuration and simpler management. The Honeynet project also found that VMware is significant to the development of honeynet technology. Through this article, we will teach you step by step how to use commercial software VMware to build and configure such a solution. In this case, we will use five different honeypots to build a Genii (the second generation of honeynets ). The premise is that you have read and understood some concepts discussed in Kye: Virtual honeynets and Kye: honeynets. At the same time, if this is your first Honeynet technology job, we strongly recommend that you work in an experimental environment. Finally, because you are faced with virtual software, you must be aware of the risk that attackers can identify and secretly escape from the virtual environment. The above is your suggestion.

Attack plan

The format of this article is similar to Kye: User-mode Linux, which is divided into five parts. The first part describes what is VMWare, how it works, and how to install it. The second part describes how to configure VMware and install your honeypots. The third part describes how to use iptables in VMware Honeynet for Data Control. The fourth part describes how to use Snort to capture data. Finally, in Part 5, 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 Linux in user mode, VMWare allows you to run different operating systems as long as they can run on intel X86 series. VMware is developed and sold by VMware Inc. In fact, you can choose three different software products: workstation, gsx, or ESX. We will use gsx among the three. Gsx is designed to run more than two operating systems at the same time. It supports remote management and is more powerful than workstation. However, most of the information we discuss here can be applied to workstation. In view of the purpose of this article, we will build our virtual Honeynet on the handheld computer, with the platform 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 a computer. This virtual software allows you to start and run multiple operating systems at the same time. The first operating system you installed is called Hostos. This is the operating system that VMware will install on. Once you have installed Hostos and VMWare, you can install other operating systems that will run in the virtual environment. All these other operating systems are called guestos's, because they are like 'guests' on the primary operating system '. For a better understanding of how it works, see Figure 1. Installing VMWare on Linux Hostos is very simple. You only need to install an RPM package. The command is similar:

Host# rpm-VI VMware-gsx-2.0.1-2129.i386.rpm
Preparing packages for installation...
VMware-gsx-2.0.1-2129

We can also install another software package, such as the remote management software package. However, our handheld computers do not need this software package because all management is done locally. For more information about these additional packages, see the VMware documentation.

Part II: Configure VMware and install honeypots

The next step after installation is to configure the VMware software. The configuration is completed by executing the command 'vmware-config. pl. During the configuration process, VMWare may re-compile some of its own kernel modules. This means you need to prepare the compiler and source code for the kernel. The kernel version running on our handheld computer is 2.4.18-19.7.x. Then make sure that the source code is available:

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 19 Dec 26 linux-2.4-> linux-2.4.18-19.7.x

Drwxr-XR-x 17 Root 4096 Dec 26 13:53 linux-2.4.18-19.7.x

Drwxr-XR-x 7 Root 4096 Jul 12 :52 RedHat

If you have installed the source code, you can start the installation. During the installation process, the only choice we should pay attention to is the network. Remember, our goal is to make all guestos's route through our gateway Hostos. Select a network during installation. When the installation process ends, you will be asked whether the hostonly network mode is used. Select this option to assign an IP address to the interface. This is the IP address of the Gateway. We will set it to 10.10.10.1. The following links are a series of commands executed during the configuration process.

Vmware-config.pl

After you complete the configuration, VMWare can run. However, we have a problem. When using the default configuration, VMWare allows three interfaces: vmnet0, vmnet1, and vmnet8. Among the three interfaces, we only need one interface, vmnet1. Vmnet0 is used for bridging, so guestos can directly perform network sessions through Hostos. Vmnet8 is used for Nat networks. Only vmnet1 allows us to control guestos's passing through Hostos. In this way, we have to re-run the vmware-config.pl and then use the editing tool to remove the two unwanted interfaces vmnet0 and vmnet8.

Vmware-config.pl (second run)

After you complete the configuration of VMware, the next step is to install and configure each honeypots. For our Honeynet, We need to install and run five different honeypots. The requirements for running so many operating systems are not as high as you think. Think about it. No one except the attacker will use them, so there are very few active systems. At the same time, UNIX-based systems do not require a GUI. You can use the command line interface to manage the system. In this way, you do not need to run X-Windows, and the memory needs to be minimized. Each operating system only requires 2 GB of 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, do not run X-Windows)
Windows 128 (mb ram)
Windows XP (128 mb ram)
Installing each honeypots is simple. First, run the "ps aef | grep vmnet" command to ensure that the VMware Virtual software is running. Run the "ifconfig-a" command to ensure that the vmnet1 interface is used. If VMware is already running, create a new VMware window to install honeypot. The command is as follows:

Host # vmware-G &

After creating the window, you can start an existing guestos or start to install a new guestos. If you want to install a new guestos, select "Run Configuration Wizard ". In the wizard, select the type of the guestos you want to install, the Directory of the file system to be installed, create a new Virtual Disk for the operating system, and enable CDROM (if a soft drive is mounted, uninstall it) and hostonly network. After completing the configuration of guestos, insert the CDROM installation disk of the guest operating system and start the system. After that, the startup and installation of guestos are the same as those of other operating systems. Repeat these steps to install all the five guestos honeypots. After installation, you can choose to install VMware Tools on honeypots. It will solve the GUI interface. However, for Unix systems, you do not need to install VMware Tools because you can manage them through the command line. For Windows-based honeypots, VMware Tools must be installed in honeypots to facilitate management. However, it will make it easier for attackers to identify the system as a VMware Virtual System. For more information about VMware configuration and guestos installation, see the VMware documentation.

Before proceeding to the next step, you need to back up your honeypots installation. VMware stores each honeypots in a separate file. These independent files are stored in the VMware directory. You can back up each honeypot by copying these independent files. For traditional honeynets, after a honeypot has security threats, you will spend a lot of energy analyzing attack records. You must restore the honeypot before putting it back into Honeynet. This is a waste of time. However, after using VMWare, restoring honeypot is just as simple as copying your backup file. You can resume honeypots in a short time. For example, VMWare stores each honeypot image in the/root/vmware directory by default. You can copy this directory to back up all honeypots. To restore an Honeypot, you only need to 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 0:10 linux-6.2

Drwxr-XR-x 2 root Root 4096 Jan 14 19:00 linux-7.2

Drwxr-XR-x 2 root Root 4096 Jan 14 linux-7.3

Drwxr-XR-x 2 root Root 4096 Jan 25 :15 OpenBSD

Drwxr-XR-x 2 root Root 4096 Jan 25 :15 Solaris

Drwxr-XR-x 2 root Root 4096 Dec 16 08:47 win2000serv

Drwxr-XR-x 2 root Root 4096 Jan 25 winxppro

Host #

Host # cp-A/root/vmware-Backup

Part III: Data Control

The next step after completing the configuration of VMware and honeypots is Data Control. The purpose of data control is to obtain all information about attackers entering and exiting Honeynet. In particular, we allow all data entering the Honeynet System, but restrict external connections. In view of the purpose of this article, we will use iptables, an open-source firewall that comes with Linux, to solve this problem. Iptables is a highly flexible formal firewall with connection restrictions, network address translation, logging functions, and many other features. We configure iptables as a filter on our Hostos to calculate the outbound network datagram. Once the number of external connections reaches the limit, all subsequent connection attempts will be blocked to ensure that the infiltrated honeypot will not cause damage to other systems. Configuration and implementation of these performance may be very complicated. However, the Honeynet project has compiled an iptables script called RC. Firewall, which can help you complete all the work. You only need to modify the script variable to adapt to your Honeynet and then run the script.

The first thing you need to decide is whether you want the gateway to run in the layer-3 routing mode or the layer-2 Bridge Mode. The second-layer Bridge Mode (also called Genii, or 2nd generation) is the preferred method. When the gateway acts as a bridge, there is no TTL consumption of the datagram routing and datagram. It becomes an invisible filtering device, making it more difficult for attackers to discover. However, to make iptables work in the bridge mode, your kernel must be patched to support it. By default, most kernels do not support the iptables Bridge Mode. Red Hat kernel 2.4.18-3 is one of the few kernels that support this mode by default. If you want to modify the kernel, you can find the patch at http://bridge.sourceforge.net/download.html. Considering the purpose of this article, we will assume that your kernel does support the iptables Bridge Mode. If your kernel does not support the bridge mode, see the article Kye: UML for more information about configuring RC. Firewall to support layer-3 routing.

Now, let's detail how to configure the RC. Firewall script to implement genii. Configuration, network, and control are required in two places. In fact, the network is much simpler in the bridge mode than in the routing mode. In Bridge mode, there is no route or any network address translation problems. We only need to simply change the Hostos into a bridge, and guestos's can directly communicate with other networks. For connection problems, we need to configure how many external connections are allowed. The configuration options are as follows. First, you need to set the external IP address of the guest operating system. These are the IP addresses attacked by attackers and valid IP addresses of our honeypots. Since we have five honeypots, We need to list five IP addresses. Firewalls need to know their scope.

Public_ip = "10.10.10.201 10.10.10.202 10.10.203 10.10.10.204 10.10.10.205"

Second, you need to identify the internal Interface Name of Hostos. The default value is eth1. However, we will use the Virtual Interface vmnet1, which needs to be modified.

Lan_iface = "vmnet1"

Finally, since we want to build a Genii Honeynet, you must try to use the built-in functions of Snort to prevent known outward attacks. The description of Snort-inline is beyond the scope of this article. It will be discussed in future articles know your enemy: Genii Honeynet. You may consider using the Honeynet snort-inline toolkit, which has static, compiled binary files, configuration files, rule repository, and documents, you can find the snort-inline toolkit in the Honeynet tools section. If you really want to test this performance, you need to enable the queue option. Note: If this option is enabled, you must ensure that snort-inline has been run. Otherwise, all outbound datagram data will be discarded. If the preceding requirements are not met, do not enable this feature.

# Queue = "yes" # use experimental queue support
Queue = "no" # Do not use experimental queue support

These are the least variables you need to consider, and there may be other variables, depending on your system configuration. You can also update other options, such as remote management, restrict connections that can be initiated by the firewall, and give your honeypots unlimited DNS access. Similarly, by default, the script limits each honeypot to the following connections per hour: 9 TCP connections, 20 UDP connections, 50 ICMP connections, and 10 other IP connections. The specific content of the script is beyond the scope of this article. To better understand these variables, we recommend that you review the specific content of the script and try different configuration options in the experiment environment. Once you complete the RC. Firewall script configuration, you can achieve your goal by executing scripts. Remember, you will make your Hostos adopt the bridge mode. Therefore, your Hostos must have a bridge tool. For the Red Hat system, it is a "bridge-utils-0.9.3-4 ".

Pay attention to two points when using the bridge mode. First, you must start all guestos's before enabling the bridge. When guestos's is started, they will look for and use the vmnet1 interface. If the vmnet1 interface has been set to the Bridge Mode, guestos cannot find the interface and cannot perform network sessions. Therefore, start all honeypots before running the RC. Firewall script. The second point is time. It takes about 10-30 seconds for the bridge to take effect. You must give it time to get all Mac's addresses before the bridge forwards the datagram.

Host #/. Rc. Firewall

To ensure that the script runs successfully, we need to check several items. First, make sure that the bridge is enabled. You can check the/var/log/messages file to confirm that the kernel records the bridge mode. Second, you have to have a new interface called br0, which is your bridge. Third, run the "brctl" command to check what interfaces are bound to the bridge. Fourth, external and internal interfaces do not have IP addresses because they are currently in the bridge mode. Finally, check the iptables rules to ensure that you have filtered some connections.

Host # tail/var/log/messages

Host # ifconfig-

Host # brctl show

Host # iptables-l-N

If all of the above are successful, your data control will be completed. There are many other methods to implement data control, such as bandwidth throttling.

Part IV: Data Capture

The next step after completing data control is data capture. The purpose of data capture is to prevent attackers from discovering the situation and capture all information about their attack activities. There are many different methods to achieve data capture, but we mainly focus on two. Iptable log and snort. Iptable logs are generated by the firewall when data enters or flows out. Snort is an open-source IDs product that can be used to capture all network activities and warn against known information with attack characteristics.

For iptabels, the logging has been configured for us through the script RC. Firewall. It is configured to record all new internal and external connections to the log file/var/log/messages. Any incoming connection may be a sign of detection, scan, or attack. Any external connection indicates that the honeypot may have been intruded. The main value of iptable logs is warning. Instead of telling us enough information about what intruders are doing. For snort, We can configure it to capture every datagram in and out of honeynet. Here is a snort config file that captures and records the activity of intruders. You can see a simple snort STARTUP script, which can start snort and use the recommended snort configuration file. Do not forget to update the vmnet1 interface of the startup script to monitor Hostos. You may want to run this script every day, so you can run this script through cron.

Host #./snort-start.sh

Since this is the second generation of Honeynet, you can consider using more advanced data capture technologies, such as sebek. It allows you to capture attack activity information through the kernel. Of course there are other methods to implement data capture, but they are beyond the scope of this article. For more information, see Honeynet tools section.

Part V: Test Your VMware honeynet

The fifth and last step of building VMware Honeynet is to test our configuration, especially the test of data control and data capture. Make sure that our Honeynet is in the same situation as expected. Data Control Testing is relatively simple. We need to ensure that any connection initiated by the honeypot attempt is recorded and controlled. Through record, all connection attempts are recorded in/var/log/messages, warning that an external connection is initiated and honeypot may have been intruded. At the same time, once the connection limit is reached, we want to ensure that more external connections are prohibited. Here is a technique for testing Honeynet. Since we use the bridge mode, we need another computer to let it act as an attacker. If the bridge cannot convert the destination IP address into a valid MAC address, it will not forward any datagram. If no datagram is forwarded, we cannot test iptables. For those who have no excess computers (or those who are reluctant to pay for the computers), you can start the UML system to virtualize the second computer. The UML system is bound to the Virtual Interface tap0, and all of our VMware honeypots are bound to the Virtual Interface vmnet1. In this way, your Hostos will bridge two different virtual networks. Don't forget. You have to modify the RC. Firewall script to make tap0 an external interface. For more information about running UML, see Kye: UML. UML can be used as an attacker to detect VMware honeypots. In view of the purpose of this article, we will demonstrate the concept of testing. The IP address of our UML attacker will be 10.10.10.100. It does work too :).

We will test the external TCP connection. By default, only nine external connection attempts can be initiated every hour. To test this, we need to open two terminal windows. First, open a terminal window on Hostos and monitor iptable logs in/var/log/messages. When we try to initiate an external connection from guestos through the host gateway, we will find that the connection attempt will be recorded in the log. All these information is warning, indicating that honeypot may have been intruded, and attackers (or some automated attack tools) are trying to connect to the outside world. When 10th external connections are initiated, the TCP connection is blocked (because the maximum connection limit is reached) and recorded. The following is the command you want to execute before trying any external connection.

Host # tail-F/var/log/messages

Next, open a terminal on our guestos, namely, the honeypot system. Initiate various external TCP connections to an external IP address. Here is 10.10.10.100 (Our UML system ). You may try it several times.

Trying 10.10.10.100...
TELNET: connect to address 10.10.10.100: Connection refused

If you see that the connection attempt is recorded and all connections that have reached the connection limit are blocked, you have successfully implemented Data Control. Next, we will ensure that the data capture function works normally, especially that the Snort process captures all data packets in and out of Honeynet and all their loads. The Snort process should monitor the internal interfaces of Hostos, especially vmnet1. In order to test, we will try to ping the external system, and here it is also 10.10.100.

Guest # Ping-C 3 10.10.10.100

The Snort process should have captured three ICMP echo request data packets and all their loads. It should record the activity in the form of tcpdump binary logs. Check the log file for confirmation. The following is an example. It is worth noting that you are not only capturing each datagram and packet header, but also capturing all the load of each datagram.

Host # snort-vd * snort. Log

It is. Now, you have only completed the most basic test of Data Control and Data capture performance. You can also try more advanced tests, such as using another independent computer as a system on the Internet and then communicating with honeypot. However, this is beyond the scope of our article.

Note: This article is coming to an end. Now we will make a final review. We will use other features of VMware's for further public analysis. In particular, VMWare's suspension function. The suspend function allows you to suspend the guestos (or honeypot) images one by one. It will freeze all running processes and save the memory image to a file. This means that you can pause your Honeypot, shut down your computer, open it one week later, and reload the honeypot, just as it was running before. It has some unimaginable applications. We save the suspended images of the attacked computers and then transfer these images to other places for analysis. This allows us to analyze an attacked honeypot when it is still running. Note that when you analyze pending images, you must ensure that they are performed in an isolated network. Otherwise, the attacked honeypot tries to connect to any system that communicates with it before it is suspended.

Conclusion

The purpose of this article is to demonstrate step by step 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 build your own VMware Honeynet instance, you can download a specific version of vmwareat http://www.vmware.com/download/?eval.htm.

About us:

Fz5fz is mainly engaged in the study and research of network/system security, in-depth analysis and discussion of programming technology, persistence in originality, and pursuit of sharing.
Fz5fz home: http://www.fz5fz.org