英文原文：
Learning with VMware
VMware to make an excellent development environment for Honeynet
technologies. In this paper, we will take you through step-by-step how to build
and deploy such a solution using the commercial software VMware . In this case,
we will build a GenII (2nd Generation) Virtual Honeynet with five different
honeypots. It is assumed you have read and understand the concepts discussed in both KYE: Virtual Honeynets and KYE: Honeynets . Also, if this is the first time you have ever worked with Honeynet technologies, it is highly recommended you work in a lab environment. Last, as with all virtual software, you need to be aware of the risk of attackers identifying, and potentially breaking out of, the virtual environment. You have been warned.
Plan of Attack
The format of this paper is similar to KYE: User-Mode Linux , its broken down
into five parts. In the first part we will describe what VMware is, how it
works, and how to install it. In the second part, we describe how to configure
VMware and install your honeypots. In the third part we describe how to
implement Data Control on your VMware Honeynet using IPTables. In the fourth
part we describe how to implement Data Capture using Snort. Finally, in the
fifth part, we describe how to test your setup.
Part I: VMware
VMware is virtualization 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 can run on Intel X86 architecture.
Developed and sold by VMware Inc , there are actually three different software
products you can choose; Workstation, GSX, or ESX. Of the three, we will be
using GSX. GSX is more powerful then Workstation, designed to run more then two operating systems at the same time and supports remote administration. However, most of the information discussed here can also be applied to Workstation. For the purpose of this paper, we are going to build our Virtual Honeynet on a laptop, specifically an IBM Thinkpad T23, utilizing a PIII 1Ghz processor and 768 MB RAM. The base operating system is Red Hat 7.3.
VMware works by installing virtualization software on your computer. This
virtualization software then allows you to boot and run multiple operating
systems at the same time. The very first operating system you install, the base OS, is called the HostOS. This is the operating system you install VMware on. Once you have installed the HostOS and VMware, you can then install additional operating systems that run within the virtual environment. All of these additional operating systems are called the GuestOS's, as they are 'guests' on the Host operating system. To get a better understanding of how this works, refer to Figure 1 . Installing VMware on our Linux HostOS is very easy, you simply install a single RPM package. The command looks similar to this.
Part II: Configuring VMware and Installing your Honeypots
Once installed, the next step is to configure the VMware software. Configuration is done by executing the command 'vmware-config.pl'. During the configuration process, VMware will most likely have to recompile several of its own kernel modules. This means you need both a compiler and the source code for your kernel. On our laptop, we are running kernel
Part III: Data Control
Once you have setup VMware and the honeypots, the next step is Data Control. The purpose of Data Control is to contain what the attacker can do inbound and outbound of the Honeynet. Typically, we allow anything inbound to the Honeynet systems, but limit outbound connections. For the purpose of this paper, we will use IPTables, an OpenSource firewall solution that comes with Linux. IPTables is a highly flexible stateful firewall, including the ability for connection limiting, network address translation, logging, and many other features. We will configure IPTables to act as a filter on our HostOS, counting outbound packets.
Once a limit has been met for outbound connections, all further attempts are blocked, preventing the compromised honeypot from harming other systems.
Configuring and implementing these capabilities can be extremely complex.
However, the Honeynet Project has developed an IPTables script called rc.firewall that does all the work for you. You merely have to modify the script variables as they apply to your Honeynet, then run the script.
The first thing you have to decide is if you want your gateway to run in layer three routing mode, or layer two bridging mode. Layer two bridging (also known as GenII, or 2nd generation) is the preferred method. When your gateway is acting as a bridge, there is no routing or TTL decrement of packets, it acts as an invisible filtering device, making it much more difficult for attackers to detect. However, for IPTables to work in bridging mode, your kernel must be patched to support it. By default, most kernels do not support IPTables in bridging mode. Red Hat kernel
Lets cover how to configure the rc.firewall script to implement GenII
functionality. There are two critical areas to configure, the networking issues and control issues. Actually, networking is much simpler in bridging mode then in routing mode. In bridging mode there is no routing, nor any Network Address Translation issues. We simply convert the HostOS to a bridge, and the GuestOS's interact directly with other networks. For connection issues, we have to configure how many outbound connections we allow. The options we will have to configure are as follows. First, you will need to set the public IP addresses of the Guest operating systems. These are the IP addresses that hackers will attack, the valid IP addresses of our honeypots. Since we have five honeypots, we will need to list the five IP addresses. The firewall filters need to know who they are. PUBLIC_IP="
Second, you will need to identify the name of the internal interface of the
HostOS. By default, this is eth1. However, we are using the virtual interface
vmnet1, and have to modify this variable.
LAN_IFACE="vmnet1"
Third, since we are building a GenII Honeynet, you may want to consider trying Snort-Inline capabilities to drop known outbound attacks. It is beyond the scope of this paper to describe the details of Snort-Inline, that will be discussed in the future paper Know Your Enemy: GenII Honeynet . However, you may want to consider using the Honeynet Snort-Inline Toolkit, which has static, precompiled binaries, configuration files, rulebases, and documentation, which you will find . in the Honeynet Tools section . If you do want to test this capability, you will need to enable the QUEUE option. NOTE: If you enable this option, you MUST be running Snort-Inline, or ALL outbound packets will be dropped. If you are not sure at this point, do NOT enable this feature. #QUEUE="yes" # Use experimental QUEUE support QUEUE="no" # Do not use experimental QUEUE support#QUEUE="yes" # Use experimental QUEUE support QUEUE="no" # Do not use experimental QUEUE support
These are the minimum variables you will want to consider, there may be others depending on the configuration of your system. There are additional options you can update, such as remote management, limiting what connections the firewall can initiate, and giving your honepyots unrestricted DNS access. Also, by default, the script limits each honeypot to the following outbound connections per hour; 9 TCP connections, 20 UDP connections, 50 ICMP connections, and 10 IP other. Details of the script are beyond the scope of this paper. To better understand these variables, we recommend you review the script in detail and try out the different options in a lab environment. Once you have configured the rc.firewall script, you implement it by executing the script. Remember, you are going to be putting your HostOS into bridging mode. For this, your HostOS must have the bridging utilities. For Red Hat systems, this is known as "bridge-utils-
Part IV: Data Capture
Once we have completed Data Control, the next step is Data Capture. The purpose
of Data Capture is to capture all of the attacker's activity, without them
knowing. There are a variety of methods to implement this, however we will focus on two, IPTable logs and Snort. IPTable logs are the logs generated by the firewall whenever there is an inbound or outbound connection. Snort is an OpenSource IDS solution which we will use to capture all network activity, and generate alerts for known attacks.
For IPTables, the logging has already been configured for us with the
rc.firewall script. It is configured to log all new inbound and outbound
Connection to /var/log/messages. Any inbound connection is an indication of a probe, scan, or attack. Any outbound connection indicates that a honeypot has been compromised. The value of IPTable logs is one primarily for alerting. The logs do not have enough information to tell us what the attacker is doing. For Snort, we configure it to capture every packet and its full payload that enters or leaves the Honeynet. Linked here is a Snort config file that will capture and log attacker activity.. You will find a simple Snort startup script that starts Snort and uses the recommended Snort config file. Be sure to update
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] ... 下一页 >>