Introduction

Security of computing machines and networks are increasing in importance as

more and more business is conducted via these systems. Despite decades of
research and experience, we are still unable to make secure computer systems or
even manufacture ways to measure a computer system’s level of security. The
automation of exploit scripts and massive global scanning for vulnerabilities
enable adversaries to compromise computer systems shortly after vulnerabilities
become known. One way we can strengthen our defenses against these scans and
exploit scripts is to learn from our adversaries by deploying and monitoring
computer systems on a network that we expect to be broken into. These
machines or systems we manufacture to be broken into are called Honeypots.
When studying our adversaries we need to monitor and log every connection
attempt to these machines and the known vulnerabilities present in our
deployments. A low interaction Honeypot only simulates specific parts of a host
(such as running server services and the TCP/IP stack). A high-interaction
Honeypot simulates all aspects of an operating system. The high-interaction
Honeypot is more likely to be compromised completely, with a serious side affect.
If an adversary could gain full access to the system and use it to launch further
networks attacks (such as denial of service against another host), the owner may
be liable for any damages the high interaction Honeypot has done. Therefore a
high-interaction Honeypot requires a significant amount of time for close
monitoring of the logs and the state of the machine, as well as tools used to
compromise the Honeypot.

What is a Honeypot?
A Honeypot can be characterized as a closely monitored network decoy serving
several purposes. Honeypots can be set up to run any type of operating system
and any number of services. The value of a Honeypot is directly proportional to
the amount and type of information we can successfully obtain from it. Aside
from information gathering, a Honeypot has the capabilities of distracting
adversaries from more valuable machines on a network, and can provide early
warning signs about a new type of attack or exploitation trends, and allows in-
depth examination of adversaries during or after exploitation of a host. Another
function that a Honeypot allows is the capturing the keystrokes typed by an
adversary attempting to compromise the Honeypot – this provides particularly
interesting insight if an intruder uses the compromised host as an IRC chat server.
Two levels of Honeypots are described as low interaction and high-interaction.

Their currently exist two types of Honeypots: a physical Honeypot which is a real
machine with its own IP address, and a virtual Honeypot which is simulated by
another machine that responds to network traffic. Physical Honeypots are often
labeled as high-interaction because the system can be completely compromised
and are resource expensive to install and maintain. For example - if you wanted to
implement physical Honeypots for a certain range of IPs on your LAN you would
have to build a separate instance of a Honeypot for each physical IP address.
Virtual Honeypots are often labeled as low interaction because of the low
implementation and maintenance costs. A virtual Honeypot can simulate multiple
Operating Systems, services and a separate TCP/IP stack for each instance of a
Honeypot on that one machine. Honeyd is an example of a virtual honeypot
service; simulating the TCP/IP stack of multiple target operating systems in order
to fool TCP/IP stack fingerprinting by tools like Nmap and Xprobe. Virtual
Honeypots are used more often than physical Honeypots because they require
fewer computer systems, which in turn reduces maintenance costs, and also
allows for a greater variety of hosts to be deployed and observed.

Information Capturing Mechanisms

Capturing data on a system designed for compromise must be done in a fashion
that allows for significant analysis of activity, yet is un-obtrusive and transparent
to the individual(s) who are compromising the Honeypot. Data can be captured at
three distinct points, all offering their own benefits and drawbacks:

Host-based: Data capture on the compromised host allows the greatest

potential to log incoming and outgoing connections, commands entered on
the host via the command line, and snapshots of running processes.
Unfortunately, this method also presents the greatest risk. An intruder will
often look for any logs and/or security tools, and attempt to disable them
in order to conceal their presence. This being the case, data capture could
be halted or modified, thus tainting the results of our experiment.
 Examples of tools used to log activity on a Honeypot are the operating
system’s system log (typically the first target of an intruder), any intrusion
detection system with packet capture ability, such as Snort, or a packet
capture and analysis tool such as Ethereal, both discussed below.

Network-based: A safer, but more complex solution to data capture involves

the Honeypot clandestinely logging activity and sending it to a remote
server for further analysis. This solution allows us to archive the data
collected by the Honeypot on a remote machine. We assume this server to
be hardened against attack, as the intruder may notice a data stream
leaving the Honeypot, and attempt to disable the collection mechanism.
Using tools such as Sebek1, we can effectively hide a data capture service
on the Honeypot, and collect data on a remote server via a UDP
connection. Sebek records the activity of the intruder and covertly sends it
to a gateway, server within the network, or server elsewhere on the
internet.

Router/Gateway-based: The final common method used for data collection is

at the actual gateway, router or firewall level of the network. As a gateway
moves all data between the hosts on a network and the internet, we have
the opportunity to log all connections and data moving from the internet to
our Honeypot(s). This offers a slight increase in risk over the Sebek solution
described above, as a gateway is typically not hidden in a network, and
itself becomes a target for attack. Additionally, this is a more hardware
 intensive solution, as you require a server to act in a gateway role. Many
small-scale or home gateways do not offer significant logging capabilities,
and cannot be used in this role.

Without robust data-capture techniques, the validity of information gathered

from the host machines is greatly reduced. One of the main goals of defensive
information warfare is to understand your opponent – the capture and analysis of
this data is the method with which we begin to accomplish this.

Information Analysis Mechanisms

Honeypots are extremely effective at containing and capturing blackhat activity.

The true potential of a Honeypot is unfulfilled unless this data is turned into
useful information. A process for capturing the data and converting it into the
tools, tactics, and motives of blackhats must be in place.2 This process is called
data analysis. During our Honeypot trials we have found that this process to the
most challenging and time consuming part of our project. In the next few
paragraphs I am going to review some of the successful methods and techniques
that we used and other practitioners over the years.

Firewall Logs

Firewalls can be useful in analyzing the incoming and outgoing connections from
your Honeypot. Any network traffic going in and coming out of your Honeypot
should be labeled as suspicious or malicious in nature. However the logged traffic
from your firewall can be tedious to parse through and gather intelligence from.
Depending upon the type of firewall you may be using for your Honeypot project,
some firewalls allow the functionality of sending alerts via email on predefined
suspicious connections from your firewall, which can decrease the amount of data
you have to parse through and make your life easier. For example you may
configure your firewall to send an alert when your Honeypot attempts to establish
an outbound FTP connection. As we know this kind of signature outbound
connection is often associated with the case that the Honeypot has been
compromised and the attacker is now trying to establish an outbound connection.
IDS Analysis

Intrusion Detection Systems like Snort provides its users with basic sources of
information and also depending upon the console you are using with your IDS it
has the capability grouping similar types of alerts, types of network traffic, and
grouping events in chronological order or even characterizing a group of events as
unique alerts.
The three basic sources of information an IDS provides it user are the following:
IDS alerts when suspicious activity has been triggered by a signature, captures
packets of the stored suspicious activity and finally Snort logs ASCII sessions or the
ASCII data detected in the packet payload. For our Honeypot trials these three
sources of information proved to be useful and were stored on our data
capture/store machine. This was accomplished by configuring the data store
machine to log any suspicious activity coming in or going out of the Honeypot. An
important note when analyzing the information provided from the Snort logs is to
also compare the Snort logs against the firewall logs to add layers of confidence
from any conclusions being made from the logs. In our case we compared our
Snort logs to the logs from our router to gain intelligence on time of possible
backdoor attacks or time of compromise of the Honeypot. Generally when an
attacker compromised our Honeypot, the attacker tried to establish an outbound
connection which was easily noticed.
A useful tool that can be used to capture IRC traffic is a tool called privmsg.pl .
Max Vision developed this tool that quickly and efficiently extracts critical
information from IRC chat sessions. IRC or Internet Relay Chat is often used for
hackers to communicate between one another during their attempts to
compromise machines, therefore you should seriously think about trying to log
any IRC traffic that be coming in or out of your Honeypot. Although we were not
fortunate enough to log any kind of IRC traffic it is still an important piece for
better understanding attacker’s motives and next moves.

System Logs
All system activity on your Honeypot is logged locally to a syslog file depending
upon the types of Operating Systems you may choose to use for your Honeypot.
Systems like UNIX, versions of Microsoft Windows, and a few other Operating
Systems have the capability of logging all system activity on the local machine
remotely from another machine. This capability is very useful when trying to find
how an attacker gained access to your Honeypot, where the attack was coming
from, types of system activity that may be suspicious such as reboots, services
being stopped or started, and accounts being disabled or created. Also since this
system activity is being logged remotely we can compare the syslogs of the
Honeypot against the remote server to discover if the attacker may of deleted or
modified the syslog file on the local Honeypot machine. Also as I said above the
information we gather from the syslog can be used to compare against other
logged information from our Firewall and IDS.

Forensics of the Compromised Machine

Forensics is another technique that allows us to do a far more detailed analysis of

the compromised Honeypot machine. We can recover processes, files, or even
tools that blackhat may have used to compromise the machine, allowing us to
rebuild user activity or identify activity that other analysis methods may have
missed.2 In order to perform forensics on the Honeypot we have to have copies
of the Operating System image to be used as a comparison tool when we start the
recover process. A common way to make byte-by-byte copies of the Honeypot
Operating System during its lifetime is to use a common command line tool called
NetCat. Copying the image of the Honeypot is done first by creating an instance of
NetCat listening on a trusted system. For example the following command to get
an instance of NetCat listening on a certain port is nc –l –p 5000 >
honeypot.hda1.dd. Basically what this does is that it opens the port (5000) on the
trusted system for listening and anything sent to that port will be piped out to the
file honeypot.hda1.dd. Once the trusted system is listening then you can copy a
partition from the compromised system and send it to the listening trusted
system by the following command /partition/nc trusted_system 5000 –w 3.

Advanced Forensics of the Compromised Machine

As I said above data recovery is a crucial part of analyzing the activity of the
Honeypot. If the Honeypot had been compromised by an attacker then there is a
good chance that the attacker may have deleted some vital information that
could be of importance if recovered. Often hackers will try to cover up their tracks
after exploiting a machine by deleting files that they may have created to gain
access or deleting files that may in fact incriminate the attacker if these files were
found. Therefore it is important to have a method of recovering deleted files in
your arsenal of tools. A tool by the name of icat has the capability of recovering
once deleted files. Also an advanced option called unrm takes a given partition
and gives you all of the deleted space from that partition for further analysis.

Deployment Procedures
Deploying a physical Honeypot can be very time intensive and expensive as
different operating systems may require specialized hardware. Additionally, every
Honeypot requires its own physical system and numerous configuration settings.
Below are some generalized steps used to deploy a basic Honeypot. These steps
are specific to the authors’ situations - they are based on our experiences and the
types network devices, tools and software applications available for our research.

Select Hardware for the Host

The first step for deploying a Honeypot is finding a machine that you are willing to
sacrifice for the cause of being exploited, hacked and potentially purged of all
data. This can be any computer capable of running the software for data capture
and control.

Operating System Installation

The second step includes either making the necessary modifications to the
current Operating System or performing a clean installation of a base operating
system onto the machine. A clean installation of your target operating system
offers the best method of controlling what vulnerabilities exist in the soon to be
deployed host.
 If you decide to keep the current operating system settings you should be
aware of the dangers of someone exploiting this machine while it is
configured as a Honeypot and released into the wild. For example: sensitive
information about you or someone else may be stored on the machine -
this information may be corrupted, deleted, or stolen during its lifetime as
a Honeypot. If you have chosen to keep the current operating system
configuration you may want to perform additional configurations to the
machine in order to attract malicious traffic. Some common procedures to
make your Honeypot more attractive and susceptible include opening
known vulnerable ports, starting known vulnerable services, creating
network shared drives, using weak passwords and usernames (if any!), and
disable antivirus or firewall software.

 If you decide to perform a disk wipe (format) and clean installation of the
operating system your flexibility and range of options increase for the
Honeypot. You won’t have to worry about the disclosure of any sensitive
information previously stored on the host’s hard drive that the attacker
may disclose if he or she gains access. If you decide to go down this path
then some of the common tools you may need include the following: a
common disk wipe utility such as WIPE, boot disk to create partitions and
repartition your wiped hard drive, operating system installation disks, and
any other software or applications you prefer to put on the machine. Keep
in mind additional software packages may include vulnerabilities useful to a
potential intruder.