Few would deny that security has become a huge priority for network administrators over the last few years. Administrators dedicate lots of time to making sure their networks have all of the latest security patches, firewalls, and intruder detection systems designed to log suspicious activity. Unfortunately, firewall and intrusion detection system reports aren’t as effective as they used to be because both produce tremendously large log files. It’s not uncommon to accumulate a gigabyte’s worth of log data each day. In today’s “do more with less” world, companies lack the manpower to sift through such massive logs on a daily basis.
I’m not saying that firewall logs and intruder detection reports are worthless. They do have their place. However, when you consider the massive volume of information that they produce and the fact that intruder detection systems are notorious for generating false positives, you can’t help but to wonder if there isn’t a better way.
Honeypot solves information overload problem
For some, that better way might be a honeypot. There are two main varieties of honeypots, real and virtual, and both serve as a decoy. The concept for a honeypot came about a couple of years ago when network administrators needed a way to find out if anyone was sniffing their network. Conventional wisdom said that if someone is sniffing the network, they aren’t sending out any packets and the sniff is therefore undetectable. Someone had the idea, however, to set up a bait system that would occasionally send out packets related to the Windows networking service. Anyone sniffing the network would have to do a DNS query to find out the identity of this unknown system. When the DNS query was performed, the IP address and computer name of the machine making the query would be logged, along with the date and time of the query.
Since this technique was first introduced, bait systems or honeypots have evolved quite a bit. There are now about a dozen companies offering various honeypot solutions. If you’re concerned about security, there’s little question that you could benefit from having a honeypot system in place. The main decision you need to make is whether your company would see the greatest benefit from a real or virtual honeypot.
Real vs. virtual
When deciding whether to use a real or virtual honeypot, you need to think in terms of risk and reward. Virtual honeypots pose very little, if any, security risks, but they don’t do nearly as good of a job catching hackers as a real honeypot. A real honeypot, on the other hand, has infinitely better detection capabilities than a virtual honeypot, but there’s a chance that a top-notch hacker could use the honeypot to take over the rest of your network.
A virtual honeypot is basically an emulator. For example, virtual honeypots often emulate FTP servers, monitoring all TCP and UDP ports and logging all activity on all ports. A hacker who discovers the fake FTP server will most likely try to initiate an FTP session. If that happens, the virtual FTP server logs everything the hacker attempts to do. For example, the honeypot might log what ports were used, which authentication credentials were used, etc. The server would even respond to a hacker’s requests in the same way that a real FTP server would. Best of all, because this is a virtual FTP server, there’s no operating system and therefore no way that a hacker could use the honeypot to compromise the rest of your network.
In theory, this method sounds really good. After all, a virtual honeypot is very safe to use and captures lots of useful information. For example, if the honeypot captured the hacker’s logon credentials, you might be able to find out which accounts have been compromised so that you can do something about it. The benefits end there, though.
There are two main drawbacks to virtual honeypot systems. First, they’ll fool only the less sophisticated hackers. Remember that virtual honeypots don’t have an underlying operating system (aside from perhaps a very limited embedded version of Windows or Linux). Because of this, many of the commands that a more experienced hacker might issue simply won’t work. This instant tip-off tells hackers that they’re accessing a honeypot rather than an actual server.
The other limitation to virtual honeypots is in the type of information the honeypot is capable of logging. For example, if a virtual honeypot is posing as an FTP server, it will obviously capture FTP-related information. It will probably also capture port probes and other common types of attacks. What happens, though, when an attacker tries to send encrypted traffic through an obscure IPv6 port? Chances are that a virtual honeypot will not have anticipated such a move from the hacker and will not know how to log it. To put it simply, virtual honeypots are good at detecting known types of attacks, but they do not fare very well in catching newly devised attacks.
Real honeypot advantages
A real honeypot, on the other hand, is one or more real systems that have been set up as bait systems. Because a real honeypot is a real system with a real operating system, it will respond to hacker requests in the same way a production network would. This has its good and bad points. On the upside, it’s almost impossible for hackers to realize that they’re accessing a honeypot and not a production network. In fact, about the only thing that could give it away would be if the honeypot network were not updated on a regular basis.
Where a real honeypot really shines is in detection. Remember that any traffic destined for the honeypot is assumed to be malicious. Therefore, it doesn’t matter at all what type of attack a hacker might be using; a real honeypot should be able to detect it.
Real honeypot disadvantages
The downside to a real honeypot is that a hacker could potentially take control of a honeypot server and use it as a place from which to attack your production servers. To block this attack, you’ll want to set up a firewall between your honeypot network and your production network that blocks all traffic between the two. Some of the more sophisticated Linux honeypots have mechanisms in place to prevent hackers from accessing production machines, but Windows honeypots don’t have such a feature at this time.
The winner is typically real
In many environments, a real honeypot is far superior to a virtual honeypot. However, before you go out and invest in a real honeypot, you need to consider the costs. You’ll need a machine to run it on and software licenses for the operating system and any applications that might be running on the honeypot. Finally, you must decide if you’re willing to accept the potential risks that a real honeypot poses to overall security.