Tracing hacker techniques with

honeypots on Linux
Contents
1. Introduction ................................................................................................................................2
2. What is a honeypot .....................................................................................................................3
2.1 What a honeypot entails......................................................................................................3
2.2 The purposes of honeypots .................................................................................................3
2.3 The different types of honeypots .........................................................................................4
2.4 Honeynets or Honeyfarms ...................................................................................................4
3. How do honeypots relate to intrusion detection .........................................................................5
3.1 Introduction to intrusion detection systems ........................................................................5
3.2 The relation between intrusion systems and honeypots ......................................................5
4. Test configuration setup..............................................................................................................6
5. Software tests .............................................................................................................................7
5.1 Kippo ...................................................................................................................................7
5.1.1 Description of the program ..........................................................................................7
5.1.2 Installation and configuration ......................................................................................7
5.1.3 The tests ......................................................................................................................7
5.1.4 Conclusion ................................................................................................................. 10
5.2 Honeyd.............................................................................................................................. 11
5.2.1 Description of the program ........................................................................................ 11
5.2.2 Installation and configuration .................................................................................... 11
5.2.3 The tests .................................................................................................................... 12
5.2.4 Conclusion ................................................................................................................. 13
6. General Conclusion ................................................................................................................... 14
7. Resources ................................................................................................................................. 15
 1. Introduction
In order to monitor the behaviour of black hat hackers, the concept of a honeypot was developed.
Honeypots come in various shapes with various intentions. A honeypot system usually opens several
ports to the public and then simulates the regular behaviour of the services usually found at those
ports. In this paper we will see what we can expect from a honeypot, how we can set up a honeypot,
how some software can be extended or adapted to the needs of the user, how certain attacks show
up in the logs and how we can learn from all this.

This paper was created for the OS & Security course given by Timmerman M. at the VUB in Brussels.
 2. What is a honeypot

2.1 What a honeypot entails

A honeypot can be described as a trap for detecting attempts to access or modify information in an
unauthorized way. It is a part of a system that often masks itself as being a weak link through which
access to information can be attained. The term honeypot covers a wide load of applications though.
There are honeypots available for pretty much every sort of intrusion detection. It is a dangerous
part of the system as well though: if it is not walled off completely and someone actually does
manage to get to control the honeypot, the results could be disastrous. A good honeypot however
makes sure everything is logged correctly and works with a sandbox in which users with bad
intentions can play, but from which they can’t escape. Some of the honeypot systems only provide a
framework which in itself doesn’t really do anything. For these systems, people have to write their
own modules to describe how the system should react on the input they receive on a certain
network port.

2.2 The purposes of honeypots

Honeypots are mostly used for two reasons: intrusion detection and intrusion study.

Intrusion detection is mainly performed by companies that want to protect their software better.
Some honeypots generate many virtual hosts which are actually just dummy programs that do
nothing in order to distract any malicious user from attacking the important parts of the system.
Although this is mainly security through obfuscation, it does have some effect in fending off less
experienced hackers and since they’re relatively easy to set up, they are worth spending some time
on. Some honeypots are more active by monitoring the network and redirecting hackers towards the
honeypot which partially runs the software of the real system. This could be done to prevent the
flooding of the real system in such a way that the hacker isn’t aware that his actions aren’t having
any effect. This type of honeypot is often called a “Production honeypot”.

Intrusion study is mainly performed by governments and educational institutions. These honeypots
provide a lot more information in terms of which commands were used by the hackers and are
therefore used for research, hence why they’re often called “Research honeypots”. With these
systems it is possible to see which approach is being taken by hackers, aiding the security of the
targeted products. Setting up systems like these is a lot more complicated because they have to log a
lot more details than a production honeypot and they have to mimic a lot more of the operating
system than production honeypots because the aim of these honeypots is to see how a hacker is
working as if it was a real system.

Some people argue that systems running a honeypot should always have a port through which the
attacker can see that he is dealing with a honeypot, since that may deter attackers. This seems highly
uninteresting for research honeypots but acceptable for corporate honeypots.
 2.3 The different types of honeypots
In the previous section, we already told there is a difference in honeypots in terms of their purpose,
but there are other distinctions between the available honeypot software possible, which we outline
here.

Honeypots also tend to differ in terms of technologies covered. Some honeypots allow you to
manage the security of a complete network. Those systems will monitor the traffic sent to IP
addresses that aren’t being occupied by real computers and use IP stack spoofing to redirect that
traffic to the honeypot system. Traffic on such IP’s is very likely to be malicious and most likely
caused by someone trying to form a map of the network with a tool like Nmap. After having diverted
the traffic, the honeypot would then emulate the service that was requested in such a way that it’s
hard for the attacker to determine whether he’s talking to a honeypot or a real system. Example:
honeyd.

Other honeypots focus on emulating one or more services on a single computer. Some of these
honeypots are built specifically for one protocol such as SSH, POP3, SMTP, FTP and HTTP, but they
can also mimic the behaviour of a vulnerable system that was infected with a certain virus or worm.
Usually, these honeypots are extendable with scripts that add other protocols.
Examples: kippo (SSH), Spamhole (SMTP), Jackpot MailSwerver (SMTP), HoneyWeb (HTTP), Specter
(SMTP, FTP, POP3, HTTP, TELNET), KFSensor (vulnerable services and trojans).

And another type of honeypots doesn’t even emulate a specific service. They just provide a phony
response to all sorts of requests on ports that aren’t usually used by a system, making it look like
there are all kinds of services on the computer for an outsider, while causing as little stress as
possible on the hosting system. Some of these systems try to provide a response to the other
machine in such a way that the other machine will be very busy for a while trying to figure out what
it is receiving. This type of honeypot is sometimes referred to as “Sticky Honeypots”, because they
can have an effect on the attacking computer. Examples: Tiny Honeypot, FakeAP, The Deception
Toolkit, NetBait, LaBrea Tarpit, Symantec Decoy Server.

2.4 Honeynets or Honeyfarms

When honeypots are grouped together to form a network, they are often referred to as honeynets or
honeyfarms. Usually, these networks or farms also utilize analysis tools which provide additional data
for discovering and researching certain attack patterns. Within a honeynet, honeypots can be
configured to interact with each other, to further emulate a realistic network environment. These
honeynets are very complex to set up and the danger for mistakes is a lot higher
 3. How do honeypots relate to intrusion detection

3.1 Introduction to intrusion detection systems

Intrusion Detection involves detecting malicious activity on a network or a host and producing
reports about the tactic that was used to perform the attack. Some IDS systems also attempt to stop
malicious attacks as soon as they are discovered. There are roughly three types of IDS systems:

 Network intrusion detection systems: these examine the ongoing network traffic. This is
usually done by monitoring the traffic at the busiest points of the network, mostly at the
borders of the network. (e.g. Snort)
 Host-based intrusion detection systems: analyze the workings of a host by looking at how it is
acting internally. (e.g. OSSEC)
 Virtual-based intrusion systems: one of the previous intrusion detection systems deployed
inside a virtual machine.

The terminology of IDS systems is mainly working with positives, negatives, policies and alarms,
whereas honeypots usually only have to deal with requests of which it’s already almost certain that
they’re intrusion attempts and as such are usually limited to decoy and logging.

3.2 The relation between intrusion systems and honeypots

Honeypots are a tool to perform intrusion detection analysis, but they are only a part of it. Intrusion
detection involves much more than analysing network requests or occupying attackers by providing
them with fake systems. Intrusion detection often works with security policies concerning who can
be logged on to certain systems. As such, intrusion detection usually requires much more specific
application and/or network knowledge than what is needed for setting up a honeypot.

Intrusion detection systems don’t always contain honeypots, nor are honeypots always part of an
intrusion detection system. The two have an overlapping area of interest, but aren’t dependant on
one another.
 4. Test configuration setup
I will be testing some of these honeypot programs on my personal network. Considering that my
Internet Service Provider blocks the first 1024 incoming ports and some other often-used ports for
servers, it is impossible for me to set up a honeypot to attract external hackers. I did try to plead with
the company to temporarily undo those blocks for research reasons, but that argument wasn’t
strong enough in their opinion.

I’ll be using 3 computers that all have access to the network either wireless or through wire:

 Desktop computer (Windows 7) with wired connection

IP: 192.168.1.141
 Desktop computer (Ubuntu 10.04 LTS) with wired connection on an old computer
IP: 192.168.1.143
 Laptop computer (Ubuntu 10.04 LTS) with wireless connection
IP: 192.168.1.106

The network uses NAT routing and is shielded from the internet with a router firewall.

Since the honeypots will modify how the hosts look and perform on the network, I’m providing the
initial Nmap scans here so they can be compared with the results later on in the tests:

 Both Linux computers show up as online, but have all their ports closed. The OS detection
system doesn’t manage to accurately say which OS is being used since it matches too many
signatures. This is great news because it makes it harder for hackers to perform targeted
attacks on the system.
 For the Windows computer, the scan got plenty of results after a minute of profiling: OS
version, name, system time, 4 open ports (PRC, 2 x NetBios and HTTP). Since this paper
concerns honeypots on Linux and not Windows security, I’m not continuing my research in
this direction.

The most important thing to remember here is that the Linux computers by default don’t have any
ports open. This will be a big contrast with how they will look when the honeypots are running on
them.
 5. Software tests

5.1 Kippo

5.1.1 Description of the program

Kippo is an open source SSH honeypot that tries to mimic all possible interactions that an attacker
could have with the shell of a Linux system. The makers say their program is inspired by Kojoney, but
not based on it. The project page and source can be found at http://code.google.com/p/kippo/.

The program is based on Twisted, which is a networking framework that can be plugged into.

The nice thing about the program is how easy it to set up and how well it performs its task. Attackers
are presented with a completely fake filesystem in which they can make as many adjustments as
they want, the most common system commands are available (but will often only give the
appearance of performing the requested task), logs get stored containing all the details of how the
attacker tried to interact with the system, and if the attacker tries to download something with wget,
the file gets stored in a different folder for later inspection.

5.1.2 Installation and configuration

Installing the program on a Linux computer isn’t too hard. There are clear instructions on the
project’s wiki page and following those steps results in an installation in under 5 minutes.

Next up is configuring the client. The default settings are acceptable, since a password of “123456” is,
according to research, the second most-used password (the first being root). I could easily adjust this
password in the configuration file should I want to though. If I would want to make this honeypot
live, I’d better do so, since somewhat more seasoned attackers will quickly realise that this is a
honeypot due to the default password that matches, which we want to avoid at all costs if we want
to see which attack strategy the hackers use.

In this case, Kippo is installed on the Linux laptop, enabled on port 2222. If we’d want to set up the
system so external potential attackers can find it at the usual port 22, we either have to make local
changes to the iptables or let the network router reroute traffic of port 22 to port 2222 of the host.
Since this doesn’t affect our tests, we’ll not dive further into that.

5.1.3 The tests

First we’ll perform an Nmap scan, as this is how most casual attackers pick their targets. The results
from the Nmap scan of the laptop with kippo running as a background task on the laptop can be seen
in figure 1. It is clear that port 2222 is now available and that it hosts an SSH service. It now also
seems to be possible to have a guess at which operating system is being used as it can figure out that
the machine runs Linux.

The next step for an attacker would be trying to get into the SSH service by trying out several
common username and password combinations – sometimes spread over several days to prevent
getting caught. We skip this step as it isn’t part of the test and just proceed by starting up an SSH
client like PuTTY and log in as we would in any SSH service (see figure 2).
Figure 1: Nmap results of kippo-running system

Nmap scan report for 192.168.1.106

Host is up (0.00092s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
2222/tcp open ssh OpenSSH 5.1p1 Debian 5 (protocol 2.0)
MAC Address: 00:13:02:14:61:24 (Intel Corporate)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.17 - 2.6.35
Uptime guess: 0.027 days (since Mon Jan 31 14:58:00 2011)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=206 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux

TRACEROUTE
HOP RTT ADDRESS
1 0.92 ms 192.168.1.106

Figure 2: We seem to be in, or are we really?

The SSH certificate that is provided along with Kippo will of course not match the certificate needed
for the used computer/server. In PuTTY, we fix that by adding it as an exception, but if we install it on
a server, this may be a telltale sign to attackers that this isn’t the regular SSH service that gets used. If
the target is a professional website, hackers will not expect this kind of inaccuracy in security and
may not fall for the trap.

Hackers usually download a script from somewhere and run everything through that script. But
because Kippo downloads the script and stores it somewhere out of their reach, hackers are unable
to use their script and we can examine the script later on. In the SSH client, I download the
mysqltuner perl script from http://blog.mysqltuner.com/, just to try out the downloading feature.

At this point, the hacker can already see that something didn’t go as planned (see figure 3). The
download didn’t result in a .pl file, but in an index.html file. This index file also appears in the
directory where the command was executed. Opening the file doesn’t work since all kinds of errors
like “Segmentation faults” are generated instead of executing the program. Trying to install programs
through apt-get appears to work, but again: errors occur when the program gets executed. This is of
course the work of Kippo, which is only trying to give the impression that the attacker is interacting
with a real system.

When we now look in the /dl directory of kippo, we can take a look at the downloaded script, which
name has been timestamped so duplicates won’t overwrite each other.
Figure 3: Yes, there’s my perl script, oh wait... what?

When we take a look at what is stored in the logs, we get the commands back that we used, as well
as IP’s, timestamps and used services (these have been removed for readability reasons):

login attempt [root/123456] succeeded

root authenticated with keyboard-interactive
starting service ssh-connection
got channel session request
channel open
pty request: xterm (24, 80, 0, 0)
Terminal size: 24 80
getting shell
Opening TTY log: log/tty/20110131-170039$
CMD: ls
Command found: ls
CMD: cd ..
Command found: cd ..
CMD: ls
Command found: ls
CMD: cd home
Command found: cd home
CMD: ls
Command found: ls
CMD: cd richard
Command found: cd richard
CMD: ls
Command found: ls
CMD: wget mysqltuner.pl
Command found: wget mysqltuner.pl
Starting factory <HTTPProgressDownloader$
Updating realfile to dl/20110131172137_http___mysqltuner_pl
Stopping factory <HTTPProgressDownloader:
http://mysqltuner.pl/mysqltuner.pl>
CMD: ls
Command found: ls
 5.1.4 Conclusion
Kippo does exactly what it promises to do, although a somewhat more seasoned attacker could very
quickly see that something fishy is going on from the moment that he logs in. Some common
features, like “autocompletion on tab key” are missing, which make the whole experience a bit less
trustworthy. Still, if you want a quick and easy tool to get a view on the scripts and techniques used
by hackers, Kippo seems to be a good choice.

There aren’t too many other features available in the program apart from its core task. It’s possible
to store the logs in a database and it is possible to extend the amount of available commands
through text files and scripts. Should something more advanced be needed, there are other
honeypots out there or, if you really want to, you could expand the code of the program yourself
considering it is open source. You may want to take a closer look at the BSD license before you go
into that though.
 5.2 Honeyd
5.2.1 Description of the program
Honeyd allows you to create a complete virtual network with virtual hosts, all with their own
personality and interaction possibilities. This is done with a technique called IP stack spoofing. It was
released in 2002 by Niels Provos, who now works for Google and designed the Google Website
Malware scanning service. When the program was released, it was the first of its kind to go so far in
its possibilities. The program can be found at http://www.honeyd.com/.

It’s possible to provide scripts to simulate each type of necessary service. On the website, several of
these scripts are available for download, but all in all it is not too difficult to write one up yourself
with the provided structure. Also, the program is completely open source with a GNU General Public
License, so the system can be adjusted at will, as long as you inform the creator of the changes
you’ve made.

5.2.2 Installation and configuration

The program relies on arpd, a daemon that listens to ARP requests and allows you to modify the
output that it would usually provide. Therefore, it has to be installed and ran first. There are two
ways of making the system ready to run honeypot: a simple and an advanced one. Both are
described here.

The simple solution is using the Honeyd Linux Toolkit compiled in 2003 which can be found at
http://www.tracking-hackers.com/solutions/. The only problem with that solution is that it will
usually generate errors on most of the latest Linux distributions. If you would want to try it anyway,
all that you need to do is unpack the latest version of the toolkit, go into the terminal window and
execute the start-arpd.sh and start-honeyd.sh shell scripts. This will automatically set up the arp
daemon and will provide you with a basic testing virtual network and will set the logging directory for
you.

Since the simple approach didn’t work for me, I had to go for the advanced solution: compiling the
program myself. Download the source file from the program’s website, unpack it, open up a terminal
window and browse to the directory where it was unpacked. Next up is installing the dependencies
for honeyd. These are libevent, libdnet and libpcap. They can usually be located through apt-get
under the names libevent-dev, libdnet-dev and libpcap-dev. Since we will also need arpd, you could
include the arpd package in the apt-get request now. Once these have been installed, all we need to
do is perform “./configure“ in the directory, then “make” and then “make install”.

Configuring honeyd is slightly more complicated than what we had to do in Kippo. The honeyd
command allows us to include a configuration file, which we’ll name honeyd.conf as per Linux
programming conventions. This file contains the structure of the whole virtual network that honeyd
should emulate for us. The file contains with several “profiles”, which each represent one or more
nodes in the network. After defining the personality and services of each node, we just need to bind
them to an IP on the network and then we’re all set. I should also mention that it is possible to
provide routes in the configuration file as well, which helps to make the system more scalable.
In order to run the compiled version, I advise to copy over everything from the toolkit but the two
compiled programs (honeyd and arpd). All you need to do is change the honeyd.conf file and you
should be set.

Here is an example of a configuration file:

### Windows computers

create windows
set windows personality "Windows NT 4.0 Server SP5-SP6"
set windows default tcp action reset
set windows default udp action reset
add windows tcp port 80 "perl scripts/iis-0.95/iisemul8.pl"
add windows tcp port 139 open
add windows tcp port 137 open
add windows udp port 137 open
add windows udp port 135 open
set windows uptime 3284460
bind 192.168.1.101 windows
This part of the configuration creates the windows profile, which mimics the network activity of a
windows server. The personality obtained from Nmap is first applied and afterwards the rules are set
for the tcp and udp ports. The second to last line sets the virtual uptime for this computer, so it looks
a bit more realistic. And the very last line binds the IP 192.168.1.101 to the windows personality. It is
possible to bind more than one IP at the same time here, should this be needed.

5.2.3 The tests

Honeyd has been installed and made running on the Linux desktop. When performing an Nmap to
the desktop’s IP from the Laptop or the Windows desktop, the result remains unaltered. When we
perform an Nmap to one of the previously unused IP’s instead, the outcome is quite different. Where
we used to get the understandable “host is not up” message in the past, we now get an actual
reading:

Host 192.168.1.101 is up (0.024s latency).

Interesting ports on 192.168.1.101:
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
80/tcp open http?
|_ html-title: Under Construction
139/tcp open netbios-ssn?

Host script results:

|_ nbstat: ERROR: Name query failed: TIMEOUT

Sadly enough, the outcome isn’t exactly correct for the system, but this doesn’t really concern us
since it just has to do with plugins – which can always be improved. In its current state though,
attackers can very easily spot that this isn’t a live system since those wouldn’t result in such errors.
There may be a couple of them who will be intrigued to see errors and investigate further since they
might hope that the system itself is vulnerable, but most attackers won’t bother according to me.
Interestingly though, if we open the IP in our browser, we get presented an HTML page, which means
that the IIS server script goes quite far in its emulation:

There were other machines defined in the honey.conf configuration file. Most of them worked a bit,
but they also had some strange readings for certain services. The concept itself seems to work
acceptably fine. For better results, it is better to set these IP’s in the router configuration. Every once
in a while when I pinged one of the virtual machines, the first ping took about a second, while the
others were under a millisecond. This sort of behaviour could be used by attackers to identify virtual
hosts, which we want to prevent as much as possible.

The logs provided by honeyd aren’t very readable by humans because they simply list all the requests
made to all the virtual hosts. Through the clutter I was able to find the requests that Nmap makes, as
well as the HTTP request from the browser. With proper analysis tools, it should be possible to pick
out the attackers from these logs, but it doesn’t seem too easy to me.

5.2.4 Conclusion
Honeyd is a very advanced program that allows us to set up a big virtual network with just one
computer. It is however a bit harder to configure and due to the current state of the project, several
scripts have become outdated. This makes it easier for an attacker to distinguish between a real and
a virtual machine.

With the help of honeyd, a network administrator can set up a big virtual network with relative ease.
Once the configuration file is ready, most of the work is over. Sadly enough, I’ve had to experience
that mistakes are easily made and that the program doesn’t always provide the best error reports,
which makes finding mistakes even harder.

Still, in overall, this program must have made quite an impact in the honeypot community back in the
day. Some of these features must have trapped quite a few attackers or at least uncovered some of
their tools’ workings.
 6. General Conclusion
Honeypots are a great solution for all kinds of problems in network safety. They can cooperate
between each other, but they can also generate a lot of virtual machines that will shroud the actual
systems from attackers. While I have only tested out two programs for this paper, I’ve seen lists of
programs that often have some sort of unique capability. The amount of available software out there
is staggering, though it seems that most of the development took place at least 5 years ago.

With the help of honeypots, a lot of attack tactics have been revealed, but I couldn’t find any cases of
evidence against attackers in court that was gathered from honeypots. It seems to me that either the
hosts using them don’t want to get it out to the public or that honeypots are still mainly used for
research and less for enforcement. It might also be that the honeypots were part of an Intrusion
Detection System and as such weren’t mentioned in news articles.

My hunch is that honeypots were partially a craze of the moment, which would explain why so many
honeypots are no longer maintained today. I think it is a bit of a shame because without a honeypot
it is really hard to predict what kind of hack some attacker may try to pull on your systems. I guess it
also just scares off network administrators to open up certain ports to potential evil-doers.

There is still future for these honeypots because no matter which new services are added, it is always
possible to emulate them in a honeypot, to see how attackers are trying to communicate with them.
The concept may have been forgotten by quite a few, but it will remain available whenever we would
need it again.
7. Resources
 http://code.google/p/kippo/
 http://www.honeyd.org/
 http://www.symantec.com/connect/articles/open-source-honeypots-learning-honeyd
 http://www.tracking-hackers.com/solutions/
 http://en.wikipedia.org/wiki/Honeypot_(computing)
 http://en.wikipedia.org/wiki/Intrusion_detection_system
 http://www.honeypots.net/honeypots/products
 http://nmap.org/