The old saying goes, "It's easier to draw flies with honey than with vinegar." If a hacker is eyeing your network, you might be able to lure him away from actual data by using a honeypot. Here's how honeypots work.
If a hacker was attacking your network right now, would you know about it? If you are reading this, then I'm assuming that you check your event logs regularly and that you probably have a good firewall and intrusion detection system in place, but let's be honest. How long would it take you to detect an attempted security breach?
It probably depends on the technique that the hacker is using. A good intrusion detection system will instantly alert you to many common security breaches. At the same time though, there are some penetration techniques that an intrusion detection system won't even notice. Sure, you might be able to catch the malicious action if you review your audit logs, but I have seen some companies that produce over a gigabyte of log data (total across all servers) every single day. How long would it take you to sort through that much log data? Would you even notice the malicious activity in the log, or would it blend in with all of the other log entries?
An alternative to allowing a hacker to attack your system and then hoping you find out about it later is to get a honeypot. A properly deployed honeypot can make it much easier to spot malicious activity. In this article, I will explain what a honeypot is and what it does.
What is a honeypot?
By now, you are probably wondering what a honeypot is. There are several different varieties of honeypots, but to put it simply, a honeypot is a bait system. The reason why honeypots are so effective is because nobody in the organization would have a legitimate business use to access the systems on it. In fact, most companies that deploy honeypots do not even disclose to users that the honeypots exist.
Because nobody knows about the honeypot system, and nobody is supposed to be using it, any activity detected by the honeypot (other than log checking by the IT staff) can be considered to be unauthorized. This means that while your production servers are compiling huge logs of mostly authorized activity, the honeypot compiles tiny, but very important logs.
Of course, honeypots do have some limitations. The biggest limitation is that they report only on themselves. Suppose for a moment that a hacker decided to break into your network. You've got a good firewall and intrusion detection system in place, but let's assume that the hacker got in by exploiting a hole in your corporate Web site. In a situation like this, the firewall won't issue a warning because the hacker is passing through the already open Port 80. Likewise, unless the hacker does a port scan or something like that, the intrusion detection system may not generate an alert either.
Once the hacker manages to take control of your Web server (or a backend database server), they will start looking for other systems to take control of. Let's assume that the next thing that the hacker goes after is a domain controller. In this particular instance, the hacker has penetrated the Web site, gained control of a backend Web server or database server, and moved on to a domain controller. The hacker never once hit the honeypot system. Because the hacker did not interact directly with the honeypot system, the honeypot logs nothing.
On the other hand, let's assume that the hacker has no prior knowledge of your network infrastructure. After taking control of the Web server or database server, the hacker needs to figure out which system to go after next. Of course before the hacker can decide which system to attack, they must know which systems are on the network. To do so, a hacker might do a ping sweep. If the honeypot is pinged, information regarding the ping is usually logged.
Assuming that the honeypot looks like a tempting target to the hacker, the hacker might then try to log into the honeypot, thinking that it is a legitimate server. If the hacker tries to log in, the honeypot will log information about the log in attempt. As I explained earlier, there are a lot of different types of honeypots. The actual information that is logged depends on the individual honeypot. It is not uncommon however for the honeypot to record the actual keystrokes used by the hacker as they attempt to break into the honeypot.
Recording the hacker's keystrokes has several advantages. For starters, you can see exactly what commands are being entered in an attack against your system. This allows you to see first hand what techniques hackers use. Furthermore, most hack jobs make use of a legitimate user account and password combination. If you log a hacker's keystrokes, you will be able to tell if a hacker is attempting to authenticate into the system using one of your user accounts. This is extremely valuable information because it allows you to know which account has been compromised. You can then disable the account (or change its password) before the account can be used to gain full entry into your system.
Other uses for honeypots
So far I have explained how a honeypot can be used to gather information about an attempted security breach and alert an administrator to a hack attempt. However, there are actually several different ways that organizations use honeypots.
One of the lesser known uses for honeypots is as a deterrent. The idea behind using a honeypot as a deterrent is that the vast majority of security breaches are inside jobs performed by trusted employees. That being the case, some companies make it widely known to employees that there are honeypots or even honeynets in place (more on honeynets later). The catch is that the IT department closely guards the identities of real servers and of honeypot servers. The idea is that if an employee is considering hacking into the system, they know ahead of time that the IT department has laid traps for them. Any of the servers on the network could potentially be a honeypot. This might not stop a seasoned hacker, but it would certainly make a lesser skilled hacker think twice before trying to break into an unauthorized portion of the network.
Another use for honeypots is that they can be used as a research tool. Hacking techniques are constantly evolving, and the only way that you can hope to keep your network secure is to stay a step ahead of the bad guys. Placing a honeypot into a hostile environment allows you to witness first hand the latest hacking techniques so that you can better defend your own network.
Yet another use for honeypots is that they can be used as a forensic tool. For example, imagine that tomorrow you find out that someone had gained full administrative privileges over your Exchange Server. What do you do about it?
This is kind of a trick question because the answer really depends on who you are trying to make happy. According to pretty much every security book that I have ever read, once a server has been hacked, it can never be trusted again because you have no way of knowing exactly what the hacker has done to the system. The hacker could have planted a Trojan that you don't know about. The only way to guarantee the integrity of the server is to completely format the drives, reload the operating system, and restore a backup that was made prior to the security breach.
While I personally agree with this approach, you must remember that in almost every organization, E-mail is one of the most critical applications. I have seen situations in which management refused to allow the IT department to take a mail server offline after a security breach, because the server is too critical to take offline. In these situations, the instructions given to the IT department were usually to clean the server as much as possible, but don't take it offline.
The reason why I am telling you this is to make a point. Often times, the IT staff is not able to perform thorough forensics after a hack because the hack occurred against a production box that can't be taken offline for any reason. Since the administrator can't perform thorough forensics, the hacker goes unpunished.
A honeypot gives the administrator the opportunity to perform detailed forensics that they would never have the chance to perform against a production server. Furthermore, since the honeypot's job is to act as a bait server, the honeypot automatically logs much of the forensic evidence that you will need in order to catch the hacker.
Types of honeypots
Earlier I mentioned that there are several different types of honeypots. Honeypots can mimic just about anything on a network. Most of the time honeypots are configured to look like a server, but a honeypot can also pose as a workstation, or even as a Cisco router for that matter.
Regardless of what a honeypot is posing as, honeypots have two main classifications; real (also called high interaction) and virtual (also called low interaction). To put it simply, a real honeypot is exactly what it appears to be. It is a real server, running a real operating system. A virtual honeypot is an emulator that's configured to act like a server. Both types of honeypots have their advantages and disadvantages.
A virtual honeypot is basically 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.
To see why this is the case, let's go back to my earlier example of a honeypot appliance that's emulating an FTP server. One of the first things that a hacker would probably try to do when attacking an FTP server is to figure out the underlying operating system. It's fairly common for a honeypot to emulate the characteristics of a Windows, UNIX, or Linux operating system.
However, every operating system interacts with the TCP/IP protocol stack in a unique way. A skilled hacker can tell what operating system is running by examining the protocol stack. Only a couple of virtual honeypots are intelligent enough to mimic an operating system's use of the protocol stack. Keep in mind though that this is just one example of a technique that a hacker might use to determine what operating system is actually running. There are many other techniques. The point is that a virtual honeypot is not going to fool a skilled hacker for long.
The other problem with virtual honeypots is the way that they gather information. For example, if a honeypot is emulating an FTP server, then the honeypot is probably only programmed to gather information related to known attack patterns against FTP servers. If a hacker tries something new or encrypts the attack packets with IPv6, then there is a good chance that the honeypot may not know how to react to the exploit.
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.
One last type of honeypot that I want to talk about is a honeynet. A honeynet is a collection of real honeypots. Some companies deploy honeypot networks that closely resemble their production networks. Such honeynets might have domain controllers, application servers, and even DNS servers. The idea is to trick an attacker into thinking that the honeynet is your organization's production network.
By appearing to be an entire network, the honeynet is more deceptive and much more likely to draw the attention of a hacker than a simple honeypot. The practical effect is still the same. A fake setup allows you to track what hackers do and how they do it, thereby allowing you to build a defense or even report them to authorities.