Honeypot

Presented by-

Tandel Vishal

P.

Objectives

Case Study includes the different types of honeypots. With

evaluation and different types of honeypots including the

low interaction and high interaction.

Abstract

This Case Study presents an evaluation of honeypots used for gathering

information about the methods used by attackers to compromise a host. Honeypots

are an important utility to learn more about attackers. There are several types of

honeypots which can be used for gathering information about the tools and

methods used by attackers to compromise a server. This paper will evaluate these

honeypots.

The focus will be on the virtual honeypots, because they are a rather new concept.

We will compare them to the other types of honeypots to find out if the

information gathered from the virtual honeypots is just as useful as from the other

honeypots. We will see that there are even more possibilities with virtual

honeypots than with low interaction and high interaction honeypots.

Introduction

Countermeasure to detect or prevent attacks

Know attack strategies

Gather information which is then used to better identify,

understand and protect against threats.

Divert hackers from productive systems

Study

A Honeypot is a security resource whose value is in being probed, attacked or

compromise.

A honeypot is a resource which pretends to be a real target. A honeypot is expected to be attacked or compromised. The main goals are the distraction of an attacker and the gain of information about an attacker, his methods and tools.

Study cont.

In this section we will discuss the criteria which will be used to evaluate different

types of honeypots. We will come to these criteria by distilling the information from

the literature we found on the topic of honeypots.

A big difference between honeypots is the degree on how much control an attacker

can get once he compromised a honeypot. The more control an attacker can have, the

more you can learn about his motives and techniques. This criterion will be used in

the evaluation of different types of honeypots.

Methodology

Two categories of Honeypots methodology

Low Interaction - Low interaction honeypots are limited in their extent of

interaction. They are actually emulators of services and operating systems,

whereby attacker activity is limited to the level of emulation by the

honeypot. This keeps the host operating system uncompromised. Logs of

the attacker are kept on the host’s file system, relatively save from

manipulation. The deployment and maintenance of these systems are

simple and do not involve much risk. Unfortunately low interaction

systems log only limited information and are designed to capture known

activity. An attacker can detect a low interaction honeypot by executing a

command that the emulation does not support.

Eg. Specter, Honeyd and KFSensor.

Methodology cont.Specter, low interaction honeypot software

Next we will look into the deployment of a low interaction honeypot. McGrew et al deployed the low interaction

honeypot Specter ([GV06]). With this honeypot they tried to gather information on the network of the Mississippi State

University about the type and source of attacks as well as the amount of time that a machine can expect to be online

before being attacked. They deployed the honeypot on the network behind the university’s firewall and on an IP

address outside of the university’s firewall.

The results of the research done by are about two situations, the honeypot behind the firewall and the honeypot directly

connected to the internet. The results from the tests with the honeypot behind the firewall were not interesting. In the

two-week period no activity was logged by the low interaction honeypots behind the firewall.

More interesting were the results of the honeypots directly connected to the internet. The first week of the Solaris

honeypot, the first anomalous connection was observed after 2 hours and 40 minutes after connecting to the internet.

The second week the honeypot emulated a Windows XP host. After 14 minutes the first anomalous connection was

observed. The Solaris honeypot logged an average of one attack every 1 hour and 26 minutes, during a period of 7

days. The Windows XP honeypot also logged for a period of 7 days and had an average of one attack every 48 minutes.

The most attacks on the Windows XP honeypot were on the Microsoft IIS web server service.

Honeyd, low interaction honeypot framework

Another research on low interaction honeypots has been done by Provos [PROV04]. Provos used the

Honeyd framework for their research. They limited attackers to interacting with their honeypots only at the

network level. They did not emulate every aspect of an operating system. Instead they choose to simulate

only the network stack of a certain operating system. The main reason for this approach is that an attacker

never gains complete access to the system even if he compromises a simulated service.

With this approach they are still able to capture connection and compromise attempts.

High Interaction - . High interaction honeypots utilize actual operating systems rather than emulations

like the low interaction honeypots. Because actual operating systems are utilized, the attacker gets a more

realistic experience and we can gather more information about intended attacks. This makes high interaction

honeypots very useful in situations where one wishes to capture details of vulnerabilities or exploits that are

not yet known to the public. These vulnerabilities or exploits are being used only by a small number of

attackers who discovered the vulnerability and wrote an exploit for it.It is very important to find and

publicize these vulnerabilities quickly, so that system administrators can filter or work around these

problems. Also vendors can develop and release software patches to fix these vulnerabilities.

High interaction honeypots provide information on the motives, tools, and techniques of the attackers. This is

another advantage of these types of honeypots. Other systems like firewall logs, IDS alerts, and low

interaction honeypots can log a large number of attacks. A large percentage of these attacks will effectively

be not interesting.

A generation II high interaction honeypot

The most difficult issue of these honeypots is the provisions that must be made for data control and

data capture. Because these systems are complete operating systems, if an attacker takes control over

this system, appropriate measures must have been taken to limit the attacker’s ability to launch attacks

from this honeypot system. If attacks targeting other production machines, whether within the

organization or outside the organization, the honeypot becomes a major liability. That is why some put

a firewall in front of the high interaction honeypots, which blocks all outbound connections. These

limitations can hinder the progress of the attacker, resulting in less informative data being captured

and potentially alerting attackers to the possibility that they are being watched.

McGrew et al used “Generation II” techniques for data control ([HOG05]). This involves a machine

separate from the honeypot acting as a layer 2 bridging firewall, called a “Honeywall”. Out-bound

connections from the honeypot are restricted by this Honeywall. The Honeywall utilizes a special in-

line version of the Snort IDS to detect known attacks and either block or “mangle” them by modifying

key elements of the attack to prevent them from being successful. The Honeywall prevents the

honeypot from being used as a significant contribution to denial -of-service attacks by limiting the

bandwidth and the number of established connections of the honeypot.

File system changes on high interaction honeypots

This gives some great opportunities for evidence reconstruction. For example to obtain all the files

created by an attacker, once he compromised the system. Or a report can be generated of all the files

altered by the attacker, with the content of the alteration. Another possibility is to create a timeline,

containing the complete evolution of a set of files or even the entire file system. However, for making

a complete evolution timeline of the entire file system, a local copy of the honeypots original file

system is needed, for the evidence reconstruction.

Virtual Honeypots

In the previous section we talked about high interaction honeypots. When you want to deploy a

complete honeynet with high interaction honeypots running different operating systems, this can

become quite expensive. Because you will need a physical machine for every honeypot. Today,

server virtualization is emerging as one of the most popular options for reducing costs ([ITB06]).

Virtualizations offers also some other useful possibilities for honeypots. This is why virtual

machines are becoming more common as honeypots. Software used for the virtualization include

VMWare ([VM06]), User Mode Linux ([UML06]), and Microsoft’s Virtual PC ([MSV06]).

One of the advantages of using virtual servers is

that they are easy to fix and isolate, and that you

can emulate several systems on a single

machine. Numbers like two or three virtual

systems per physical machine are very common.

This makes it possible to create a complete

honeynet on one physical machine, a virtual

honeynet

The Honeynet Project defines two types of virtual honeynets, self-contained and hybrid ([HOV03]). A self-

contained virtual honeynet is an entire honeynet network onto a single machine, see figure 1. This means that

both the Honeywall and the honeypots are on the same machine. This also brings a risk. If an attacker somehow

discovered the host machine andcompromised it, your complete honeynet will be useless. So you have a Single

Point of Failure. If something goes wrong with the hardware for example, your whole honeynet will be down.

Figure 1. A self-contained virtual honeynet setup

There is the hybrid virtual honeynet. With hybrid virtual honeynet, the Honeywall is a separate machine,

illustrated in figure 2. All the honeypots are on running on the same machine using virtualization. This solution

is more secure, because the attacker could only access the other honeypots on the virtual machine. The

Honeywall will be save on a separate machine. But this makes this solution also less portable then a self-

contained virtual honeynet.

Figure 2. A hybrid virtual honeynet setup

Examples of honeypotsExamples of freeware honeypots include:

1. Deception Toolkit6: DTK was the first Open Source honeypot released in 1997. It is a collection of Perl

scripts and C source code that emulates a variety of listening services. Its primary purpose is to deceive

human attackers.

2. LaBrea7: This is designed to slow down or stop attacks by acting as a sticky honeypot to detect and trap

worms and other malicious codes. It can run on Windows or Unix.

3. Honeywall CDROM8: The Honeywall CDROM is a bootable CD with a collection of open source

software. It makes honeynet deployments simple and effective by automating the process of deploying a

honeynet gateway known as a Honeywall. It can capture, control and analyse all inbound and outbound

honeynet activity.

4. Honeyd9: This is a powerful, low-interaction Open Source honeypot, and can be run on both UNIX-like

and Windows platforms. It can monitor unused IPs, simulate operating systems at the TCP/IP stack level,

simulate thousands of virtual hosts at the same time, and monitor all UDP and TCP based ports.

Examples of honeypots.

http://www.all.net/dtk/index.html

http://labrea.sourceforge.net/labrea-info.html

http://www.honeynet.org/tools/cdrom

http://www.honeyd.org/

5. Honeytrap10 : This is a low-interactive honeypot developed to observe attacks against network

services. It helps administrators to collect information regarding known or unknown network-based

attacks.

Examples of honeypots cont.

6. HoneyC11: This is an example of a client honeypot that initiates connections to a server, aiming to

find malicious servers on a network. It aims to identify malicious web servers by using emulated

clients that are able to solicit the type of response from a server that is necessary for analysis of

malicious content.

7. HoneyMole12: This is a tool for the deployment of honeypot farms, or distributed honeypots, and

transport network traffic to a central honeypot point where data collection and analysis can be

undertaken.

ConclusionA Valuable Resource

To be Compromised

Gains Info. About Attackers and their Strategies

Need for Tight Supervision

Honeypot is primarily a research tool, but also has a real commercial applications. The

honey pot set in the company's Web or mail server IP address on the adjacent, you can

understand that it suffered the attack.

reduce the data to be analyzed. For the usual website or mail server, attack traffic is

usually overwhelmed by legitimate traffic. Thus, browsing data to identify the actual

behavior of the attacker also much easier.

References[DVK+06] P. Defibaugh-Chavez, R. Veeraghattam, M.Kannappa, S. Mukkamala, A. H. Sung,

“NetworkBased Detection of Virtual Environments and low Interaction Honeypots”, In 2006 IEEE

InformationAssurance Workshop, pages 283-289, IEEE, 2006.

[GV06] R. McGrew, R.B. Vaughn, Experiences With HoneypotSystems: Development, Deployment, and

Analysis,System Sciences, 2006. Proceedings of the 39th Annual Hawaii International Conference, pages

220a-220a, IEEE, 2006.

[HOG05] The Honeynet Project, Know Your Enemy: GenIIHoneynets,

http://www.honeynet.nl/papers/gen2/index.html (07-12-2006), The Honeynet Project 2005.

[Hon06] Honeynet Project, “Know your Enemy: Honeynets”,

http://www.honeynet.nl/papers/honeynet/index.html, (3-10-2006), Honeynet Project, 2006.

Thank You…