Hisham shares his experiences with building a virtual honeynet on his existing Linux box. He describes data capture and control techniques, the types of honeynets, and configuration changes to get one running on your system.


Creating a virtual honeynet is no more than configuring a number of virtual networked systems to log all activity heading to it, while looking as inconspicuous as possible. Don't worry if you feel you can't afford the resources needed to run the honeynet. Virtual honeynets are cheap, powerful and easy to administer. This paper includes an account of my experiences, which should make the process of configuring your own virtual honeynet easier. Before getting started, there are a few points that may require some explanation.

Both the UML and OpenSSH definitions were taken from their respective homepages.

Honeynet Data Capture and Data Control Tools

What does DCAP and DCON mean and what are their uses? Data CAPture (DCAP) tools are tools made specially for the purpose of capturing data streams whether network or host-based activity. These tools are placed everywhere in your honeynet to capture every little spouse made by the attackers.

Data CONtrol (DCON) tools are devices or systems built for the purpose of controlling the activity of specified sources, in other words, a firewall that limits the amount of allowed outbound connections is considered a form of DCON.

So when the paper talks about firewalls, that is Data Control. When the paper talks about SNARE, that is one form of Data Capture.


What is an IDS?

Intrusion Detection Systems are technologies that detect/reduce risk, but do not eradicate it altogether. Mr. Danny Rozenblum's goes pretty deep into the subject of intrusion detection through his paper Understanding Intrusion Detection Systems.


Honeypot or Honeynet?

A honeynet is only one type of honeypot which is supposed to emulate a real production network, while a honeypot is a single host designed as a lure-and-log system (i.e. a system with a packet sniffer and a keylogger to log all activity on it, and most likely programs that simulate vulnerable services).

This email address is being protected from spambots. You need JavaScript enabled to view it. has written a more in-depth paper which discusses the definitions and value of honeypots. It also covers various honeypot solutions you can download and try on your own.


What is OpenSSH?

OpenSSH is a free implementation of the SSH protocol suite of network connectivity tools that increasing numbers of people on the Internet are rely on for secure remote communications. Many users of telnet, rlogin, ftp, and other such programs might not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, OpenSSH provides a myriad of secure tunneling capabilities, as well as a variety of authentication methods.


User-Mode Linux and the Honeynet

User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup. User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.


What are the advantages and disadvantages of a honeynet?

  • If your honeynet was connected to your production network, most attackers would trip over your honeynet before reaching your real systems. (i.e. the honeynet will detect attacks in their early stage).


  • After a while of monitoring the activity of your honeynet, a more accurate security policy could be created.


  • A honeynet could teach you something about incident response, if a honeypot was compromised, the forensics that you would do to understand how the attack happened could be a nice way to hone your incident response skills, before a real system gets compromised and you don't know where to start.


  • Some attackers take honeynets as a challenge to their powers, with this little tip, you could clone your real network, mainly the DMZ, and create a honeynet out of it, that way you could make sure no miss-configurations may lead to a unwanted compromise (consider it as a free pen-test).


If you don't consider any of the points above to be advantages, then maybe you would like to go for a research honeynet to learn more about the tactics and methods of the blackhat community.


  • Having your systems rooted is bad but having them used to launch future attacks is even worse. If a honeynet was successfully compromised, the attacker could use it as a hop to start other attacks or as a hop for an attack against one of your real systems, this is considered the main disadvantage of a honeynet (having your honeynet attack a third party could start some unwanted trouble).


  • Honeynets may lead to wrong decisions related to enhancing your security policy (i.e. maybe you consider telnet to be insecure because it transmits data in the clear, but installing a ssh1 server may represent a bigger threat as ssh1 is known to have a number of problems that usually lead to system compromises).


Types of honeynets

There are various types of honeynets, but due to the limited space of this paper, I will only discuss the commonly used types.


  • Classic Honeynets -- A classic honeynet is created using real (physical) systems per honeypot, this method is not encouraged for price and difficulty administrating reasons, so admins usually drop the idea of having a honeynet after two months of headaches caused by this type of honeynet.


  • Virtual Honeynets -- A virtual honeynet is a group of virtual systems, each run within an emulator, that when networked together creates a virtual production environment, this type of honeynet overcomes the disadvantages of classic honeynets without losing any of its power or flexibility, This email address is being protected from spambots. You need JavaScript enabled to view it. of the Honeynet Project has written a nice paper that covers this topic.


There are some important points that we have to keep in mind before starting.


  • The honeynet should be as basic as possible with the least modifications to the system (i.e. the attacker should never find out that the media he is on is actually a honeynet).


  • As mentioned in the first disadvantage of honeynets, a honeynet could be used to start future attacks, therefore a solution to limit the attackers chance of successfully attacking a third party should be decreased (limiting the number of outbound connections is one way of decreasing the risk).


  • The honeynet should follow the Honeynet Definitions, Requirements, and Standards stated by the Honeynet Research Alliance.


Preparing the Honeynet

Pentesting MethodologyThere are a number of tools that will help us in creating our virtual honeynet. Many of these are likely already installed on your system. These tools include:



Now we are completely ready for creating the honeynet, so let's get started!!


Creating the Host

Because all our honeynets are going to run off one system, we should prepare that system to act as a gateway, firewall, and router for our virtual honeynet.

The first step is to prepare Firewall Builder. Installing fwb is pretty straight, assuming fwbuilder-0.9.7.tar.gz (the latest version as the time of writing) is in /usr/local/downloads.

# cd /usr/local/downloads
# tar -zxf fwbuilder-0.9.7.tar.gz
# cd fwbuilder-0.9.7
# ./configure
# make && make install

This will perform the install in /usr/local/bin. Assuming X is running on your system, fwbuilder should appear as a new item in your Menu. Start the GUI (assuming the install went ok, the GUI should load without any troubles) and define localhost as the target fw to push the security policy to, then create network objects as follows (this honeynet is based on SFHN's honeynet, take the tour here. For the sake of simplicity, I will consider routable addresses and I will also consider the firewall, snort management and syslog server to be on the same machine.




IP or Group items




honeynet administrator



This system is running the Roxen webserver instead of running an IIS



This is our DNS server



This is our mailserver



This is another webserver running beside Roxen, it would be nice to find vulnerabilities in it




These are our honeypots

Security Policy

Now that we have all our systems defined, we should create our rulebase, but first we need to outline our security policy.


  • Any host may connect to "Firewall" using ssh or MySQL.
  • Any host could connect to our honeynet.
  • Our honeynet is allowed to access any host.
  • Anything else should be dropped.
  • Everything that passes our firewall should be logged.

Now we must define the rulebase.











ssh or MySQL





















Now that our system is ready to pass connections to and from our honeynet, we should move on to the next step.


Configuring the Remote Log Server

There are two types of logging that can be used.

  • MySQL
  • ssyslogd

Assuming mysql-3.23.28-gamma-pc-linux-gnu-i686.tar.gz is in /usr/local/download, perform the following steps to configure.

# cd /usr/local/download
# tar xzf mysql-3.23.28-gamma-pc-linux-gnu-i686.tar.gz
# ln -s mysql-3.23.28-gamma-pc-linux-gnu-i686 mysql
# cd mysql
# ./mysql install db

Start MySQL with:

# cd /usr/local/mysql/bin/safe mysqld &

Now setup a password for user root (the word password "mypass" will be our password).

# ./bin/mysqladmin -u root password mypass

Finally, create a user for snort and another for ssyslogd and give them INSERT, DELETE, USAGE, SELECT for their respective databases.


# echo CREATE DATABASE snort | mysql -u root -pmypass
# echo CREATE DATABASE ssyslog | mysql -u root -pmypass
# mysql -u root -pmypass
# mysql> grant INSERT,SELECT on snort.* to root@*
# mysql> grant INSERT,SELECT on ssyslog.* to root@*;
# mysql> quit

This should have everything MySQL related done, we only have one last point related to logging which is installing ssyslog (our first level of DCAP). Assuming msyslog-pre 1.08f.tar.gz is in /usr/local/downloads, perform the following steps.

# cd /usr/local/downloads
# tar -zxvf msyslog-pre 1.08f.tar.gz
# cd msyslog-pre 1.08f
# ./configure
# make && make install

This will install msyslogd, the default configuration is pretty fine, we only have to do one more thing which is telling it to use MySQL as its default logging method, so, we simple copy the syslog.mysql.conf file to syslog.conf and change the logserver, user and password to whatever suits your environment.

So far, so good. Now for the IDS.

The IDS (our second level of DCON)

As this is a honeynet, there will be too much activity to analyze by hand, that's why IDS are installed on most honeynets nowadays, but which type of IDS should we use? Answering this question requires some understanding of the types of IDSs.


Types of IDS

There are two common types of IDSs, Network-based (NIDS) and Host-based (HIDS). Network-based methods record communication packets and attempt to identify attacks thru network traffic. NIDS are easy to manage and transparent to users (which is important in a honeynet environment). However, NIDS aren't scalable to large networks and tend to generate more false positives than HIDS. On the other side, Host-based methods deploy a monitor on each system, which is a more scalable solution than NIDS, but harder to manage. Still, Intrusion detection is easier on the system level and the accuracy rate is better than that of NIDS.


Making the Decision

In order to choose whether to go for a HIDS or a NIDS we should outline what we want our IDS to do, well since this is a research honeynet our primary goal will be to log all activity on both the system and network level. Yet, a HIDS on the real (physical) system would be of no use, as most attacks would be against the honeynet and most attackers just don't target the firewall in normal circumstances. So, I will not have an advanced HIDS on the real (physical) system, instead, I will only prevent it from loading a shell with super-user privileges and use snort on it to log and detect attacks against any virtual system.


The HIDS : Eye On Exec

As I said before, there is no need for an advanced HIDS on the real (physical) system, but for prevention reasons, I will install EoE which is a basic HIDS that detects any attempt made by a process to start a shell with super-user privileges, kills the shell and either prints a warning, e-mails the administrator or both.


Setting up EoE

Installing EoE is the basic and usual. Follow the steps outlined below.

# cd /usr/local/downloads
# tar -zxvf eoe-2.51.tar.gz
# cd EoE
# make && make install

eoe.pl is the configuration file, its defaults are pretty good, just change the e-mail address that should be used to your current e-mail. EoE will prevent a huge amount of attacks targeting the firewall.


The NIDS: Snort

Well, because snort's installation, preparation and configuration need too much space, I would discuss it even briefly, instead I would point you to This email address is being protected from spambots. You need JavaScript enabled to view it.'s HOWTO Build a Snort/ACID Console on Red Hat Linux which is a great paper that covers this topic in great detail.

I would just like to name a simple addition to Richard's paper, in case of honeynets, we do not setup snort to detect attacks only. Instead, because it is going to be installed on the gateway (i.e. all traffic will pass through it), I would prefer to have it log all connections first then detect attacks. The Honeynet Project have provided a sample configuration file for this.

I prefer this way for two reasons. It eliminates the need for another sniffer (too much load) and in case an attack is not detected by Snort, we could go thru the traffic logs briefly and find such attacks. Just remember to setup logging to your MySQL database in real time, and to syslogd (ssylogd in our case) on daily basis (this should match the Honeynet Definitions, Requirements, and Standards).

So far, our systems is setup as a gateway and a packet sniffer+IDS (i.e. everything is ready to move on to the last stage) except that we want to allow logging into the system in a secure fashion. So, lets set that up first.


Secure Remote Logins: OpenSSH

Most Unix users have started using ssh as a replacement for the insecure "r" commands including rsh, rcp, rlogin and telnet. Originally SSHG was free software, but after version 1.2.12 it had some strict limitations (porting to some Operating Systems and exporting issues related to encryption) which made it an undesirable solution. So, the good guys from the OpenBSD Project have decided to create a free sshd.

OpenSSH depends on two other packages to install (which may or may not be installed on your system). These packages are OpenSSL and zlib.

Because I'm on a Red Hat box at the moment, I will just install from RPM. Don't worry if your system is not RPM compatible (whether Debian or Slackware), installing from source is pretty similar to installing any other package. Installation the RPMs is simple. Just change dir to wherever you downloaded the RPMs (/usr/local/downloads in our case) and install the packages in the following order (if you try to change the order, your system will complain from unavailable dependencies).

# rpm -Uvh zlib.rpm openssl-0.9.6c.rpm openssh-3.0.2p1.rpm

The version numbers might differ, just make sure you get the correct RPMs for your distribution. If OpenSSH was installed correctly a ssh -V should show output similar to this:

OpenSSH 3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f

As I said before, version numbers may differ, but this is the general formula.

Configuring OpenSSH

As you know, the real (physical) system should only use sshv2. So, open /etc/ssh/sshd config in your preferred editor and change "#Protocol 2,1" to "Protocol 2" then restart sshd. Also, only DSA keys are allowed and not RSA keys, so, change "RSAAuthentication yes" to "RSAAuthentication no" in /etc/ssh/sshd config. That should do it for configuring OpenSSH, to test your configuration issue the command "ssh -l user localhost", this should present you with a remote login requesting the user's password. If so, then everything went pretty ok, and you are ready to go start creating your virtual honeynet.


Configuring the Virtual Honeynet

Virtual honeynets usually run on a piece of software called emulators that simplify the process of running multiple Operating Systems in real-time on one system (examples of such emulators are VMWare, Bochs and Plex86). All of those have the ability to run other Operating Systems under your real Operating System, but after experiencing with them for a while, I found them to be more problematic than expected (i.e. resource hogs, expensive, hard to use, etc..), So, I started looking for a simple solution that would do only one job, run linux-on-linux. I just wanted to run a virtual Linux network on my real system, and after spending some time searching for something that would do the job, I found User-Mode-Linux which is a port of the Linux kernel to itself. Well after reading its documentation I thought "wow! that's exactly what I want". Plus using UML isn't hard at all, all you need is a kernel executable and a filesystem to boot. So, I'll walk you thru the basic steps of starting up linux-on-linux.


Building the Kernel Executable

Just because you could get your hands on a pre-built kernel executable isn't a good excuse for not building from source. Building from source gives you the chance to add whatever patches you want or change whatever settings to what suits your needs.

Download the latest kernel to /usr/local/downloads/linux (which will be our UML setup directory) untar the image (as the time of writing the latest kernel was 2.4.15), then download and patch the kernel source tree with the latest UML patch. Assuming the patch is called uml-patch-2.4.16-2.bz2 the following set of commands should do the job.


# cd /usr/local/downloads/linux
# tar -zxvf linux-2.4.15.tar.gz
# cd linux-2.4.15
# wget https://sourceforge.net/projects/user-mode-linux/files/kernel%20patch/0.53-2.4.16/uml-patch-2.4.16-2.bz2/download
# cat uml-patch-2.4.16.bz2 | bunzip2 - | patch -p1

You might also be interested in referring to the Kernel HOWTO for further instructions.

Now we should have the kernel source patched with the UML patch (include any patches that you want using "cat /path/to/patch | patch -p1"), So, build the kernel with your favorite configuration, but remember to include "ARCH=um" on the make line. This tells the make process that we want a kernel executable and not a normal kernel (i.e. "make xconfig" becomes "make xconfig ARCH=um").

After you are done choosing the configuration that best suits you (just remember to enable multicast networking support when asked), save and exit, then execute "make dep ARCH=um" and "make linux ARCH=um", you should now have an executable called "linux" in the top of your kernel source tree directory. Linux is the kernel executable that will be used to boot UML, but before we move on to the next step, there is one simple point that should be explained.

If two systems are booted from the same HDD, the HDD filesystem will be corrupted. This is the same case in UML, you cannot boot two UMLs from the same filesystem. So, while you're at the UML download page get a number of filesystems (or download one and create multiple copies of it).

Before we boot "linux" we should understand the syntax/arguments used, the most important arguments are discussed below.


UML Arguments

  • "ubdx=file" means that the virtual device /dev/ubx (where x is a number) is present in the file called "file". This file must be a Linux native filesystem, another option that could be used instead of "file" is "swap" which creates a swap partition on the specified device (although swap is not a linux native filesystem, it is required by linux to run in a correct manner) and always remember the bigger the better.


  • "eth0=mcast" tells the real (physical) system to use the first Ethernet adaptor as a multicast device, this will be needed for virtual networking (unless you want to assign an Ethernet device per system).

Other parameters are available. For more on those consult the User Mode Linux HOWTO.

To have a properly functioning network, you need to have uml switch and uml net running before booting "linux." Obtain uml switch and uml net from the UserMode Linux download page then build and install them with "make all && make install DESTDIR=/").


Booting the Virtual System

You would probably endup booting "linux" with a command like


# linux ubd0=root fs.rh72.pristine ubd1=swap eth0=mcast

I used "umn=" for this example (although we did not assign to any system) just to show you an example, instead, you will probably be booting each system with its own IP address to configure its services and traps.

If everything went ok, you should be represented with a login screen, log in as 'root' with no password. Starting here you will feel at home.

You will need to have several services running, including Apache, BIND, Sendmail or Roxen. I can only recommend you read their installation documentation, which will really help in case you feel everything is Greek to you. Also, I would recommend you setup their logging to the highest possible level.

Now that you have your servers/honeypots up and running do some testing for the configuration before moving on.

There has been quite a number of issues related to virtual networking, some people complain of mis-configured routes, packet drops, etc., but I have not encountered any of that. If you pass by such a situation, please report it. I would like to recommend that you visit Setting up the network part of the UML documentation.


The blackhat trap

Next comes some ideas that I found to be the best when it comes to monitoring activity.

  • Ssyslog -- I previously mentioned setting up and installing Syslog and configuring it to send logs to your MySQL database, just re-do those steps (this time, inside your virtual systems) and set them to log to your real (physical) system's MySQL database.


  • Snare -- One of the biggest problems faced by honeynet admins is not knowing what exactly to log, huge logs can't be examined easily, and small ones usually do not provide enough info, and even if they had the correct amount of info, it is not stored in a user-friendly format, and this is where Snare's role comes. Snare is a HIDS made specially for auditing purposes It could log most important system calls on your system, and by keeping compatibility with the Department of Defense’s C2 standards. Snare represents an all-in-one auditing solution which will make life easier when its time for the real analysis.


Installing Snare

At the time of writing, Snare version 0.8.1 was the current release. Assuming your system is a RPM compatible system, use the following to install:

# rpm --install snare-core-0.8-1.i386.rpm snare-0.8-1.i386.rpm

Installing from source is also possible for non-RPM systems. Check out Snare's documentation for mor

Configuring Snare

I am not an XFree86 fan (having it on a honeypot is useless) plus, it is not worth the trouble to get it up and running under UML. So, I prefer editing the Snare configuration file manually by hand. The file is located at /etc/audit/audit.conf, usually the files defaults are more than enough, just take a peak and change anything you don't like (a full explanation of the file's contents could be found here).

You could also configure Snare to log to a remote logging server. In our case, the real system, or to make sure the systems logs couldn't be tampered get an ACL program and set the log files to append only. The grsecurity tool has a nice patch that contains a really powerful ACL admin. Note that this patch must be applied during creating the kernel executable. Last thing we have to do now is tell the system to start Snare's auditd on bootup, this could be done with:

# ln -s /etc/init.d/auditd /etc/rc.d/rc3/S90audit

One big drawback of Snare is that it doesn't log LKM loading into the kernels. LKMs could change a lot when it comes to security (you will understand how in Appendix A), so, I provided a kernel patch in the Appendix that should be built applied while creating the kernel executable. This patch will detect any LKM loading and log it to ssyslogd.

The previous configuration should be applied to all honeypots, starting here you are on your own to change and modify anything inside the honeypots. I have intended to keep the section about UML as small as possible because, in my honest opinion, virtual honeynets are pretty flexible and could be customized to suit any environment, so writing about this section would probably need more space than this paper has.

At last you are done with your virtual honeynet, nothing else is left, but before ending this paper I would like to show you what I learned from other honeynets (this is like presenting you with a starter) just in case a honeypot was compromised.

I just hope this paper has represented a good resource and a real How-To on the subject of creating virtual honeynets.



  • Loadable Kernel Modules -- This section represents some issues that started to arise lately like using LKMs for covering tracks, DDoS, etc..


  • Kernel patch for detecting and logging LKM loading. -- This patch does not block LKM loading attempts, it just detects them and drops a line in ssyslogd.


  • Modified rc.firewall to block outgoing DDoS attacks. -- This script needs to be modified manually to suit your needs. By default the script does not block DDoS attacks as this is yet experimental.


  • Port-Scand --Port-Scand is a port of This email address is being protected from spambots. You need JavaScript enabled to view it.'s alert.sh to iptables. Despite the huge differences between CheckPointFireWall-1 and iptables the script maintains full functionality of the original alert.sh


  • Know Your Enemy: Honeynets -- The Honeynet Project is an effort to learn the tools, tactics, and motives of the blackhat community and share these lessons learned.


  • Honeynet Project Forensic Challenge Results -- Dave Dittrich of the Honeynet Project announced the results of the "Honeynet Fornesic Challenge". The results of all submitted reports are available on the page. Dave also talks about how the Honeynet Project is going to continue using this example to "develop examples and best practices that fit the needs of local, state and federal law enforcement agencies in understanding and assessing computer crime cases and pursuing suspects."


  • Honeynet Research Alliance Announced -- The Honeynet Resea community of organizations dedicated to researching, developing and deploying Honeynets and sharing the lessons learned. Its goal is to bring together people and organizations actively involved in Honeynet research. Its primary means of communication is a closed maillist.



There are other sections that will be added to this paper later on (one of them will be reverse engineering, i.e. using the attackers tools including rootkits, backdoors, etc., to learn their own tactics. This paper is not the end release. Check back soon!!

If you find any mistakes or any point that you would like to discuss, please contact me by mail at This email address is being protected from spambots. You need JavaScript enabled to view it..