When it comes to computer security, honeypots are all the
rage. Honeypots can detect unauthorized activities that might never be picked
up by a traditional intrusion detection system. Furthermore, since almost all
access to a honeypot is unauthorized, nearly everything in a honeypot’s logs is
worth paying attention to. Honeypots can act as a decoy to keep hackers away
from your production servers. At the same time though, a honeypot can be a
little tricky to deploy. In this article, I will walk you through the process
of deploying a honeypot.

Before we begin

Before I get started, I want to take a moment and point out
that there are many different types of honeypot systems. Honeypots can be
hardware appliances or they can be software based. Software based firewalls can
reside on top of a variety of operating systems. For the most part though,
honeypots fall into two basic categories; real and virtual.

A virtual honeypot is essentially an emulated server. There
are both hardware and software implementations of virtual honeypots. For
example, if a network administrator was concerned that someone might try to
exploit an FTP server, the administrator might deploy a honeypot appliance that
emulates an FTP server.

Virtual honeypots have both their good and bad points. The
primary advantages to virtual honeypots are that they are cheaper, easier to
deploy and more secure than real honeypots. The down side is that virtual
honeypots will not fool a skilled hacker for long, and they have limited
information gathering capabilities.

A real honeypot uses a real server running a real operating
system. The main advantage to using a real honeypot is that because a real
operating system is involved, the honeypot will react to a hack attempt in
exactly the same way that a production server would. Because a real honeypot is
not limited to the constraints of an emulator, it can log any type of attempt
to breach security, even if the attack uses a previously unknown technique.

There are several negative issues associated with real
honeypots though. First, they are expensive. Remember that a real honeypot runs
a real operating system. This means that in addition to purchasing the honeypot
software, you will also have to purchase server hardware and an operating
system license.

Real honeypots are also more difficult to deploy than
virtual honeypots are. This is because you must make every effort to secure the
honeypot’s operating system. That leads me to the most serious negative aspect
to real honeypots. If a hacker does manage to take control of a honeypot
machine, the honeypot can be used as a staging area from which to attack the
rest of the network. In case you are wondering, virtual honeypots can not be
used in such an attack.

For the purposes of this article, I will be demonstrating
how to set up a virtual honeypot. As I mentioned earlier, honeypots come in all
shapes and sizes. For this article, I will be using a Windows based honeypot
known as KF Sensor. The Key Focus Web
site offers a 14 day trial that you can try out for yourself.

Downloading and installing KFSensor

KFSensor has some modest hardware requirements. At a
minimum, it requires a 1 GHz processor, 30 MB of hard disk space, and 128 MB of
RAM. The manufacturer recommends a 1.5 GHz processor, 500 MB of hard disk
space, 512 MB of RAM, and a SQL database.

The KFSensor download consists of a 1.7 MB self extracting
executable file. Download the file and copy it into an empty folder on your
computer. When you double click on the file, it will launch a very basic Setup
program. The only thing special that you need to know about the Setup process
is that it will require a reboot.

After the initial installation completes and the computer
has had a chance to reboot, the Setup wizard restarts and walks you through the
configuration process. Click Next to bypass the wizard’s Welcome screen and you
will be prompted to enter a domain name for the honeypot network. You can use
your network’s real domain name, or you can make something up. The installer
cautions you not to use a domain name that someone else already owns though.

The next screen that you will see gives you the chance to
transmit alerts through E-mail. If you want to use this feature then enter a To
and From address. Click Next to continue. You will now see a screen that asks
what components you want to install. KFSensor is designed to detect a lot of
different types of intrusions. You can configure KFSensor to emulate a lot of
different services, based on the components that you select. For the purposes
of this article, select all of the available components and click Next.

The next screen that you encounter asks you if you want to
install KFSensor as a system service. The advantage to installing KFSensor as a
system service is that the software runs independently of whether or not you
are logged into the system. Even if another user were to login, KFSensor will
continue to run in the background.

There are a couple of downsides to installing KFSensor to
run as a system service though. First, you can only install the software as a
system service if you are logged in as a local administrator. The other
disadvantage is that if a hacker were to somehow find a hole in the KFSensor
software (unlikely, but not impossible), then they could theoretically gain
system level permissions over the computer. In my opinion though, you should
install the software as a system service. I believe that the benefits outweigh
the risks.

Click Next and you will see a screen indicating that Setup
is complete. Click Finish to complete the installation process.

Using KFSensor

Now that installation has completed, it’s time to start
using KFSensor. When the Setup wizard closes, you will see the main KFSensor
screen shown in Figure A.

Figure A

This is the main KFSensor screen.

As you can see, the column on the left contains a list of
port numbers and what the port is typically used for. If the icon to the left
of a port listing is green, it means that KFSensor is actively monitoring that
port for attacks. If the icon is blue, it means that there has been an error
and KFSensor is not watching for exploits aimed at that particular port.

In case you are wondering why there are blue, error state
icons on my box, it’s because I loaded KFSensor onto a Windows 2003 Server that
has a copy of Exchange Server 2003 installed on it. The ports that are shown as
errors are already in use by Exchange. I’m not recommending that you run
KFSensor on an Exchange Server though. The machine that I am running KFSensor
on is a lab machine, not a production server.

Once you’ve got the software up and running, one of the best
things that you can do is to test the software by launching a port scan against
the machine that’s running KFSensor. For the port scan, I am using a shareware
utility that I got from download.com called HostScan. It simply scans a block
of IP addresses, looking for open ports. Figure B shows how the KFSensor reacts
to a partial port scan.

Figure B

This is how the KFSensor console looks after a partial port scan.

If you look at Figure B, you will notice that the icons next
to ports that were scanned turn red to indicate recent activity. You will
notice that there is a summary of all of the detected activity in the column to
the right. The icon next to each entry is color coded either red or yellow
according to the severity of the event. You can also click on any of the
individual ports, and the column on the right will display only events related
to that specific port. You can then double click on an event to gain more
detailed information about it. For example, you can determine the event’s start
and end time, the IP address of the machine that the activity is coming from,
and even the domain that the attacking machine belongs to.

Building an activity log

OK, so we’ve proven that the honeypot can detect activity,
and we’ve even logged some activity. That’s great for short term testing, but
in a real life situation, you would probably want to log activity to a
database. That way you have a more permanent record of the activity. Having
such a record is important in case you need to do some in depth forensics or in
case you need to get law enforcement involved after a security breach.

Don’t get me wrong. KFSensor does log activity by default,
but it uses a text file rather than a database. The reason why it’s important
to use a database is because a database generally has a higher capacity and
makes it easier to search for what you need than a text file does. Furthermore,
if a hacker were to figure out that you were running KFSensor, and they were
able to gain control over the system, then they could easily erase the log file
to cover their tracks.

The database of choice for KFSensor is SQL. Simply create a
SQL database in the usual manner. After doing so, select the Log Database
command from the KFSensor console’s Settings menu. When you do, you will see
the dialog box shown in Figure C. Simply fill in the blanks to connect KFSensor
to the database that you have created.

Figure C

The Database Log dialog box allows you to connect KFSensor to a SQL

Modifying the honeypot’s behavior

So far I have shown you how to deploy a KFSensor based
honeypot and how to log the data that is collected. The last thing that I want
to show you is how to change the honeypot’s behavior. Like most honeypots,
KFSensor is rules based. All of the data that was produced in Figure B was the
result of KFSensor detecting certain types of activity and then using a rule to
determine what type of action should be taken. The nice thing about KFSensor is
that you can easily modify the existing rules or add your own.

To create or modify rules, select the Edit Active Scenario
command from the Scenario menu. When you do, you will see a dialog box which
contains a summary of all of the existing rules. You can either select a rule
and click the Edit button to edit a rule, or you can click the Add button to
create a new rule. Both procedures work similarly.

Click the Add button and you will see the Add Listen dialog
box, shown in Figure D. The first thing that this dialog box asks for is a
name. This is just a name for the rule. Pick something descriptive though,
because the name that you enter is what will show up in the logs whenever the
rule is triggered.

Figure D

The Add Listen dialog box allows you to create your own rules.

The next few fields are protocol, port, and Bind Address.
These fields allow you to choose what the rule is listening for. For example,
you could configure the rule to listen to TCP port 1023 on IP address The bind address portion of the rule is optional though. If you
leave the bind address blank, the rule will listen across all of the machine’s

Now that you have defined the listener, it’s time to
configure the action that the rule takes when traffic is detected on the
specified port. Your options are close, read and close, Sim Banner, and Sim Std
Server. The close option tells the rule to just terminate the connection. Read
and close logs the information and then terminates the connection. The Sim Std
Server and Sim Banner options pertain to server emulation. The Sim Banner
option allows you to perform a very simple server emulation, such as what you
might use to emulate an FTP server. The Sim STD Server option allows you to
emulate a more complex server, such as an IIS server. If you choose to use one
of the sim options, you will have to fill in the simulator’s name just below
the Time Out field.

The other part of the Action section that’s worth mentioning
is the severity section. You saw in Figure B that KFSensor treated some events
as severe and other events as a more moderate threat. The dialog box’s Severity
drop down list allows you to determine what level of severity should be associated
with the event that you are logging.

The final portion of the Add Listen dialog box is the
Visitor DOS Attack Limits section. This section allows you to prevent denial of
service attacks against KFSensor. You can determine the maximum number of
connections to the machine per IP address (remember that this applies on a per
rule basis). If your threshold is exceeded, you can choose to either ignore the
excessive connections or you can lock out the offending IP address.

Now that you have configured the new rule, select the Active
check box to enable the rule and click OK. The new rule should now be in