This will be a new two-part series looking back at some of the project work I was involved in. One of the more intriguing pieces was designing and hosting a honeypot (Wikipedia) in an effort to attract attackers.
The purpose of this project is to outline the design, configuration, and testing plan used for our team’s honeynet. By using multiple virtual machines, networked together using a virtual switch, we are able to deploy a sophisticated network within a single physical machine. The network is designed to look like a poorly secured combination of Linux based web server and Windows server. Both machines are left vulnerable to various exploits, ranging from well known (easy) attacks, to more obscure and sophisticated ones.
Each machine listed below is running within a virtual machine, and has been configured to fulfill a specific role within the honey network. The design goals of each machine are important, as they provide a guide for the specific services installed.
Firewall / Gateway / Logging Machine
- Linux-based (ClearOS, rebuild of Fedora/RHEL)
- Firewall to prevent unlimited external access to the network
- Logging of all incoming communication to all machines using IDS system (Snort, Barnyard)
- Provides port forwarding for internal services running on multiple honeypots
- Windows 2000 Server machine
- Appear to be running Active Directory & IIS which would be vulnerable to many attacks
- Linux machine (CentOS, based on RHEL)
- Uses Apache HTTPD default with default configuration
- Contains wordpress content management system, running on Apache
- Wordpress using simple dictionary password
- Runs an outdated, vulnerable FTP server
- Hosts a fake company website
- References IP of Machine 1 in /etc/hosts
All virtual machines are created and being run with VMware Workstation 9, and will share the same physical machine. This is done to simplify the networking configuration between the virtual machines. The two honeypot VMs are connected to the gateway VM via VMware’s virtual switch. This configuration resembles a normal networking setup from inside any of the machines, making it ideal for a honey network.
Host Machine Details
Below we list the hardware specifications for the host machine, which is running the three virtual machines listed above. This hardware has proven to be sufficient for our needs, as we do not intend any heavy computation while the Honeynet is in operation.
- CPU Intel Core i3 2100 (Sandy Bridge)
- Motherboard Gigabyte Z68MA-D2H-B3 with Gigabit Ethernet
- RAM Kingston 4GB DDR-1333 (single DIMM)
- GPU MSI GeForce 210 512MB DDR3
- HDD Seagate 250GB 7200rpm SATA
As seen in the network diagram below, this honeynet will be exposed outside of a home router firewall. This will leave the network fully exposed, and allow the VM gateway machine to regulate all traffic to/from the vulnerable network. To an outside attacker this network should appear to be part of a legitimate organization, while still shielding the home network from attack.
Firewall / Gateway
The gateway VM will provide the only external access point to the VM network. In order to ensure that the other virtual machines do not have any external access outside of the gateway, this gateway will have access to the only bridged connection available on the host machine. The gateway will assign network interface eth0 to the bridged external interface, while eth1 will be used for all LAN traffic. Below is a summary of the important networking details for the gateway machine.
- eth0: External interface, provided IP via external ISP
- eth1: Internal LAN interface, static ip of 192.168.119.128
- Port Forwarding: Yes, via iptables
Both honeypot machines will be running inside virtual machines on the same shared hardware. These machines will be protected behind the Firewall / Gateway VM, and will not have any direct external access. Instead, they will be using host-only connections which will be routed through a virtual ethernet switch. Only services forwarded by the gateway machine will be accessible to external attackers, and these will be limited to those listed in the services section below. All network traffic will be routed through eth0, mapped to the internal network of 192.168.119.xxx.
Each machine will have a minimum set of services installed to allow an attacker the ability to run intended exploits. Additional services may be added, but the list below are tested and will be the best candidates for tracking an attacker’s activities.
Firewall / Gateway
This machine will function as the gateway, firewall, and IDS for the network. To enable this activity, the following services listed below should be installed. It should be noted that the default IDS provided by ClearOS was not included here, as their snort configuration did not allow for packet logging. In order to rectify this we have manually installed the latest Snort / Barnyard2 combination.
Table 1.0 - ClearOS Services
Windows 2000 Server
This honeypot is designed to look like a default installation of Windows 2000 Server, with very little added security. It will be running an outdated, unpatched version of IIS, printer services, and Active Directory. To an attacker, this machine should appear to be a partially configured (under construction) internal website, with some additional exposed services.
Table 1.1 - Windows 2000 Server Services & Ports
CentOS 5 Honeypot
This machine will be running as a partially configured web server, with an external website running on the default http port 80. It will also house an FTP service and database, and will also have Java, PHP, and Wordpress running.
Table 1.2 - CentOS 5 Services & Ports
In the next part, I'll be discussing more about the Reconnaissance and Profiling work that was done as well as highlighting some interesting statistics. Be sure to stay tuned.