Enterprise Software

SolutionBase: Configuring a Honeypot for your network using KF Sensor

Deploying a honeypot can be a good way to catch hackers in the process of trying to attack your network. Brien Posey shows how to set up a honeypot quickly using KF Sensor.

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 database.

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 192.168.1.100. 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 NICs.

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 effect.

Editor's Picks

Free Newsletters, In your Inbox