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.
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 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).
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 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, Mike Clark 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
There 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:
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 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 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.
|
Name |
Type |
IP or Group
items |
Description |
|
Firewall |
Workstation |
10.10.10.1 |
honeynet
administrator |
|
Roxen |
Workstation |
10.10.10.80 |
This system is running the
Roxen
webserver instead of running an
IIS |
|
DNS |
Workstation |
10.10.10.53 |
This is our DNS
server |
|
Sendmail |
Workstation |
10.10.10.110 |
This is our
mailserver |
|
Apache |
Workstation |
10.10.10.81 |
This is another webserver
running beside Roxen, it would be nice to find vulnerabilities in
it |
|
honeynet |
Group |
Roxen+DNS+Sendmail+Apache |
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.
|
Num |
Source |
Destination |
Service |
Action |
Log |
|
00 |
any |
Firewall |
ssh or MySQL |
Accept |
Log |
|
01 |
any |
honeynet |
any |
accept |
log |
|
02 |
honeynet |
any |
any |
accept |
log |
|
03 |
any |
any |
any |
drop |
log |
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.
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 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, 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 http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.4.16-2.bz2
# 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=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.
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.
References
- 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 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
- 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.
Conclusion
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
etsh_cucu@yahoo.com.
Only registered users can write comments.
Please login or register. Powered by AkoComment! |
