Introduction

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 generic 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 admin, plus thru this paper I'll be trying to put in as much of my experience as possible to make it easier for you, but before we start there are a few points we have to understand.

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

What does DCAP and DCON mean and what are their uses? 
DCAP (Data CAPture) 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.
DCON (Data CONtrol) tools are devices or systems built for the purpose of controlling the activity of a 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 all together.
Mr. Danny Rozenblum's goes pretty deep into the subject of intrusion detection thru his paper Understanding Intrusion Detection Systems.

What is a honeynet and how does it differ from a honeypot?
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). Lance Spitzner 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 version of the SSH protocol suite of network connectivity tools that increasing numbers of people on the Internet are coming to rely on. 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.

What is User-Mode-Linux? 
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?

Advantages

• If your honeynet was connected to your production network, most attackers would trip over your honeynet before reaching you 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 horn 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.

Disadvantages

• 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 their 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 two reasons : 1- price, 2- hard to administrate, 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 (ran by emulators) networked together to create a virtual production environment, this type of honeynet overcomes the disadvantages of classic honeynets without loosing any of its power or flexibility, Mike Clark of the honeynet project has written a nice paper that covers this topic on Security Focus, the paper could be found here.

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 for the honeynet

There are a number of tools that will help us in creating our virtual honeynet, these tools are :

• MySQL
• Snort
• Eyes On Exec
• FireWall Builder
• OpenSSH
• Modular Syslog
• SNARE

Just download those tools to /usr/local/download (create the dir if you don't have it).

Figure A is a diagram that represents how our honeynet and rulebase should look like.

Now we are completely ready for creating the honeynet, so lets start!!

Creating the Host OS 
Because all our honeynet is going to run off one system, we should prepare that system to act as a gateway, firewall, router for our virtual honeynet.

Setting up the firewall (our first level of DCON)

Configuring FireWallBuilder 

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 -zxvf fwbuilder-0.9.7.tar.gz
cd fwbuilder-0.9.7
./configure
make
make install

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 10.10.10.0/24 routable addresses and I will also consider the firewall, snort management and syslog server to be on the same machine.

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

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 comes the rulebase.

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 we have to deal with :

• MySQL
• ssyslogd

assuming mysql-3.23.28-gamma-pc-linux-gnu-i686.tar.gz is in /usr/local/download,

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

cd /usr/local/downloads
tar -zxvf msyslog-pre_1.08f.tar.gz
cd msyslog-pre_1.08f
./configure
make
make install

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 suites your environment.

So far, so good, And 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 go for? 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 HISD 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 stop 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 :

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 Richard La Bella'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, incase 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 thru it), I would prefer to have it log all connections first then detect attacks. The Honeynet Project have provided a sample configuration file (snort.conf) for this.
I prefer this way for two reasons, 1- eliminates the need for another sniffer (too much load), 2- incase 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 fase of creating the virtual honeynet) 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 -rsh, rcp, rlogin and telnet which doesn't start with an "r" but is insecure nonetheless-. 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 to run on the OpenBSD platform, later on, due to the need for a free SSH demon, their work was ported a multitude of Operating Systems like Linux, AIX, HP/UX and Solaris.

Setting up OpenSSH 
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 RedHat 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 ("./configure && make && make install" in the directory which contains the un-archived packages).

Installing the RPMs
Installation 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
rpm -Uvh openssl-0.9.6c.rpm
rpm -Uvh 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 represent you with a remote login requesting the user "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 suites 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 http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.4.16-2.bz2
cat uml-patch-2.4.16.bz2 | bunzip2 - |patch -p1

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, just remember to include "ARCH=um" on the "make" line, "Arch-um" 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 with choosing the configuration that best suites 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.
• "umn=address" means that the IP address "address" will be assigned to the virtual system, if not specified, UML will default to 192.168.0.253 with a subnet mask of 255.255.255.0, although you enter an IP address while booting UML, you still need to configure the systems networking using the "ifconfig" command after your boot it up.
• "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) but these are the ones needed for our honeynet.

Note : 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 User Mode Linux download page, build and install them with "make all && make install DESTDIR=/").

Booting up the virtual system 
You would probably endup booting "linux" with a command like

linux ubd0=root_fs.rh72.pristine.bz2 ubd1=swap eth0=mcast umn=10.10.10.50

I used "umn=10.10.10.50" for this example (although we did not assign 10.10.10.50 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.

Unfortunately, I cannot walk you thru installing Apache, BIND, Sendmail or Roxen (That's outside the scope of this paper). I could only recommend you read their installation documentation -which will really help incase 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 quit 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 (i.e. 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
As the time of writing, Snare version 0.8.1 was the current release. Assuming your system is a RPM compatible system
rpm --install snare-core-0.8-1.i386.rpm snare-0.8-1.i386.rpm
will install Snare, installing from source is also possible for non-RPM systems (checkout Snare's documentation for more help).

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 -grsecurity 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 Appendix B) -that should be built applied while creating the kernel executable-, this patch will detect any LKM loading and log it to syslogd (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 suite 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 learnt from other honeynets (this is like presenting you with a starter) just incase 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.

Appendices

Appendix A: Situations - Loadable Kernel Modules (LKMs).

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

Appendix B: Kernel patch for detecting and logging LKM loading.

Note: This patch does not block LKM loading attempts, it just detects them and drops a line in syslogd (ssyslogd in our case).

Appendix C: Modified rc.firewall to block outgoing DDoS attacks.

Note : This script needs to be modified manually to suite your needs. By default the script does not block DDoS attacks as this is yet experimental.

Appendix D: Port-Scand.

Port-Scand is a port of Lance Spitzner's alert.sh to iptables. Despite the huge differences between CheckPointFireWall-1 and iptables the script maintains full functionality of the original alert.sh>

End Note

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 -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 etsh_cucu@yahoo.com.