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
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
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).
a while of monitoring the activity of your honeynet, a more accurate
security policy could be created.
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.
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
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
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.
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.
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:
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).
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).
honeynet should follow the Honeynet
Definitions, Requirements, and Standards stated by the honeynet
Preparing for the honeynet
There are a number of tools that will help us in creating
our virtual honeynet, these tools are :
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)
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,
tar -zxvf fwbuilder-0.9.7.tar.gz
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.
IP or Group items
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
Now that we have all our systems defined, we should create
our rulebase, but first we need to outline our security policy.
host may connect to "Firewall" using ssh or MySQL.
host could connect to our honeynet.
honeynet is allowed to access any host.
else should be dropped.
that passes our firewall should be logged.
Now comes 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 we have to deal with :
mysql-3.23.28-gamma-pc-linux-gnu-i686.tar.gz is in /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
Start MySQL with
now setup a password for user root (the word password mypass will be our
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@*;
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
tar -zxvf msyslog-pre_1.08f.tar.gz
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.
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
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
Setting up EoE
Installing EoE is the basic and usual :
tar -zxvf eoe-2.51.tar.gz
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)
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
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.
OpenSSH depends on two other packages to install (which may or may not be installed
on your system), these packages are OpenSSL
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
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
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.
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.
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.
tar -zxvf linux-2.4.15.tar.gz
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 :
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.
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.
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
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
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
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,
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
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
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.
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
documentation for more help).
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
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.
A: Situations - Loadable Kernel Modules (LKMs).
This section represents some issues that started to arise lately like using
LKMs for covering tracks, DDoS, etc..
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).
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.
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>
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 firstname.lastname@example.org.