World War II saw some impressive acts of deception, some to hide secrets, and some to mislead the other side. The Germans developed the Enigma machine, an early electronic encryption device. The Allies broke the Enigma code, and so learned a great deal about German military actions. And in an effort to mask the D-Day invasion, the Allies launched a project known as "Fortitude." Under Fortitude, the Allies created fake armies, composed largely of inflatable rubber tanks and other "vehicles," carefully placed to convince the Germans that the main Allied invasion would take place at Pas-de-Calais rather than Normandy. Fortitude was a great success: it lured German forces away from the Normandy beaches, helping the Allies establish a presence on the European mainland.
World War II saw some impressive acts of deception, some to hide secrets, and some to mislead the other side. The Germans developed the Enigma machine, an early electronic encryption device. The Allies broke the Enigma code, and so learned a great deal about German military actions. And in an effort to mask the D-Day invasion, the Allies launched a project known as “Fortitude.” Under Fortitude, the Allies created fake armies, composed largely of inflatable rubber tanks and other “vehicles,” carefully placed to convince the Germans that the main Allied invasion would take place at Pas-de-Calais rather than Normandy. Fortitude was a great success: it lured German forces away from the Normandy beaches, helping the Allies establish a presence on the European mainland.
Today’s confrontation between computer crackers and system administrators bears some resemblance to the information and misinformation campaigns of World War II. The skirmishes between security measures and security exploits rage on. Most Linux system administrators know how to use encryption tools such as the Secure Shell (ssh) to hide keystrokes and network traffic from crackers, and we all hope that these tools are substantially safer than Enigma. But a less well-known security tactic is the computer equivalent of Fortitude: the honeypot. A honeypot is a computer system that’s intentionally configured to appear (or to actually be) vulnerable to outside attack. Seemingly weak, the honeypot entices a would-be intruder to attack it. But the honeypot is not just a simple decoy — it’s closely monitored to detect attacks and analyze intrusion techniques. Given the nature of an attack and critical information such as the originating IP address, measures can be developed to improve security on other, real production systems, and perhaps to even pursue the cracker through the legal system.
Before reading any further, you should realize that honeypots do not protect your systems in the way that a firewall protects your systems. Unlike World War II’s Fortitude, a honeypot isn’t likely to lure a cracker into expending so many resources on attacking the decoy that your other systems become safer. Rather, honeypots are information-gathering, forensic tools. To improve your network’s overall security, you must configure the honeypot properly, and then take the time to analyze data collected from attacks.
In general, because honeypots require significant resources to configure and deploy, and require an ongoing commitment to proactive monitoring, honeypots are typically only deployed in larger enterprises. However, if you’re willing to make the investment, honeypots can fine-tune your defenses.
The Benefits and Risks of Running a Honeypot
A typical honeypot lures a cracker into attacking it. The honeypot or associated software can then track the cracker’s activity, frequently capturing incriminating information. The honeypot then fakes a network problem or system crash, and makes the system unavailable.
Typically, organizations with many systems or a strong interest in computer security run honeypots. Honeypots can help gather information about cracker exploits in general, and sometimes even collect information about individual crackers.
For instance, a honeypot would (you hope) appear to be more vulnerable or more appealing to crackers than your legitimate systems. So, finding a weak system, the crackers attack your honeypot first, giving you information on how they perform their attacks. You could then use this information to help secure your real systems.
At present, though, honeypots don’t spit out complete suggestions for such improvements. Once you’ve acquired some data on cracker attack patterns, you must know how to analyze that data. You may need to perform web searches on keywords such as the names of files the crackers attempted to upload to your system or the commands they attempted to run. Ideally, such an investigation teaches you about vulnerabilities that might exist on your real computers, enabling you to fix them before a cracker can exploit them.
Beyond collecting forensic evidence, honeypots can also be useful research tools. Used in this way, honeypots are one step removed from immediate network security needs. For example, you might be an academic researcher who’s studying network attack patterns. In that case, the capability of a honeypot to be easily reconfigured to simulate any one of several potential target systems can be invaluable, because you can learn what systems are being attacked and in what ways.
You can also use honeypots to track individual crackers. Suppose your network has been compromised in the past, but the attacker destroyed log files that would have helped you trace the attack back to its origin. To avoid that mistake again, you can set up a honeypot. If the cracker attacks the honeypot, its logs may be more complete than those on a regular system, particularly if the cracker deletes non-honeypot log files.
Unfortunately, running a honeypot isn’t without its risks. One risk is technical: a honeypot can backfire, creating more security problems than it solves. For instance, suppose you set up a regular computer as a honeypot, intending to isolate the cracker and monitor the cracker’s activities on a system that’s been truly compromised. You might place this system behind a firewall, intending to keep the compromised system from being a risk to others. However, if you misconfigure the firewall, or if the cracker manages to break into the firewall, the cracker can then use your honeypot as a platform for attacking other computers. This risk is very real, and you should take it very seriously. In a worst-case scenario, you could be sued by the cracker’s next victim.
What’s worse, the legality of some honeypot techniques is uncertain, particularly in certain states. Under United States federal jurisdiction, honeypots might qualify as tools for “interception of communications.” In other words, they may be illegal under federal wiretapping laws. In theory, you could find yourself charged with a felony that carries a 5-year prison term. This theory has yet to be tested in the courts, though; so far, nobody has been charged under wiretapping laws for running a honeypot.
On the other hand, federal law contains some provisions that may make at least some honeypots legal. For instance, if the services on the honeypot contain a banner clearly stating that the services may be monitored, and if a cracker continues using the services, then you can make a strong argument that the cracker consented to the monitoring. Check http://alpinista.dyndns.org/files/thp for further discussion of this topic.
Another problem is the so-called Super DMCA laws that have been passed in Delaware, Illinois, Maryland, Michigan, Pennsylvania, and Virginia. Similar legislation is pending in Arkansas, Florida, Georgia, Massachusetts, New York, Oregon, South Carolina, Tennessee, and Texas. Among other things, this legislation includes provisions making it illegal to conceal the source of a communication. Many honeypots, and particularly standalone programs, work in part by responding to IP addresses that are not assigned — perhaps qualifying as concealing the source of the communication. Thus, Super DMCA legislation may outlaw at least certain types of honeypots. Indeed, some of the honeypot programs described in this article are now hard to obtain because of these laws. For more information, consult the Electronic Frontier Foundation’s informational site at http://www.eff.org/IP/DMCA/states.
The bottom line is this: You should not deploy a honeypot without first consulting with your attorney. Be sure your lawyer is familiar with computer, wiretapping, and Super DMCA laws. If you’re deploying a honeypot as part of your job, be sure that you have permission from whoever is responsible for authorizing additions to the network, and from the organization’s lawyer. Get this authorization in writing. The risks — and the steps you can take to protect yourself — are similar to those involved in cracking a password file to locate poor passwords.
A Honeypot Rundown
After you’ve taken the necessary legal steps to protect yourself, you can get on with the task of deploying a honeypot. Just a couple of years ago, running a honeypot required designing it yourself. A typical honeypot was a computer that ran custom-tweaked versions of servers.
For instance, if “MegaServer 2.3.7″ had a known security bug, a system administrator might take the fixed MegaServer 2.3.8, modify it to announce itself as MegaServer 2.3.7, run the server on an out-of-the-way computer without legitimate users, and monitor the traffic to the server using a packet sniffer such as Snort. (The May 2003 “Guru Guidance” column describes Snort. You can find it online at http://www.linux-mag.com/2003-05/guru_01.html.)
An approach that takes even more effort is to create a custom server. For instance, an administrator might write a server from scratch that pretends to be a telnet server. This server might mimic a known vulnerability, present a convincing shell, and log data. In reality, though, this honeypot would not give intruders real access to the system.
Today, honeypots have become popular enough that some specialized honeypot programs are now available. Typically, these programs emulate one or more flawed servers, sometimes seeming to run on operating systems that you aren’t even running. Some of these programs can even respond to IP addresses that the host computer doesn’t normally use, effectively creating “phantom” computers.
Some existing prepackaged honeypot programs include:
* Honeyd, headquartered at http://www.citi.umich.edu/u/provos/honeyd, emulates one or more machines running on IP addresses other than the one officially used by the host computer. You can tell it what types of systems to emulate and what servers to pretend to run. Each of these emulated servers is implemented via a shell script. Honeyd ships with scripts to emulate WU-FPTD, a POP3 server, a telnet server, sendmail, and Microsoft’s IIS Web server.
* The Deception Toolkit (DTK), located at http://www.all.net/dtk/dtk.html, is similar in concept to Honeyd. DTK supports both a generic response generator and specialized sub-programs. However, many of them crash or behave strangely, so you may need to debug the software.
* LaBrea, named after the famous La Brea tar pit in Los Angeles, California, takes the honeypot concept one step further. Rather than merely setting up a system with fake services, LaBrea uses TCP/IP tricks to keep the attacker’s system occupied for inordinate periods of time. The goal is to keep a miscreant busy, preventing attacks against other systems. For legal reasons, LaBrea is no longer available from its nominal homepage at http://www.hackbusters.net/LaBrea, although a web search turns up other sources, such as http://www.stearns.org/labrea.
* The Tiny Honey Pot (THP) is just that — a very simple honeypot program. This package, available from http://alpinista.dyndns.org/files/thp, is a series of Perl scripts that emulate various servers. The system runs a handful of honeypots on peculiar ports and relies upon iptables rules to redirect input from other ports to the honeypot ports. Unlike some honeypots, THP doesn’t listen on IP addresses that aren’t assigned to the computer on which it runs.
In addition to these packages, you can use other tools to implement honeypots, or use other programs in conjunction with honeypots. Intrusion detection systems (IDSs) such as Snort are particularly helpful adjuncts to honeypots.
Another honeypot tool is remarkably simple: honeypot e-mail addresses. You can create e-mail addresses that don’t receive actual e-mail, then use them in Usenet newsgroup posts. The idea is to get the honeypot e-mail address on spammers’ lists. You can then track the spam (say, if you’re a spam researcher), or configure your system’s mail filters to dump any message that’s sent to the bogus address and to legitimate addresses. Such messages are almost certainly spam.
Although specialized honeypot programs are gaining in popularity, using an intentionally misconfigured computer as a honeypot remains a possibility. You can set up a system with defective versions of popular servers, but configure it to log data to a properly secured computer. The secure computer’s logs will then show evidence of the intrusion. Once the honeypot has been compromised, shut it down and restore its software from a backup to lure another cracker. This approach is riskier than using specialized honeypot software, though. An intruder who breaks into such a system is more likely to abuse it to do real damage to other systems — something that’s not so likely if you were running a specialized honeypot program. If the cracker uses the system as a stepping-stone to attack others’ computers and you monitor that attack, you may also run afoul of the wiretapping laws mentioned earlier.
In general, today’s honeypot software tends to be very delicate. A minor mismatch of installed system components or a small deviation from the provided instructions can be enough to prevent the software from working. On the whole, honeypot packages don’t seem to be easy to configure or use. However, THP appears to be the most stable and least difficult to configure, so let’s use it to create a honeypot. One disclaimer: these steps require root privileges, so proceed carefully.
Download THP from its Web site, http://alpinista.dyndns.org/files/thp. The version used here is 0.4.6. Extract the THP files by changing to the /usr/local directory and typing tar xvzf ~/thp-0.4.6.tar.gz. (Substitute an appropriate path and filename, if necessary.) Various THP tools assume they’ll be installed in /usr/ local/thp, so this is the simplest way to install the package.
From /usr/local, type ln -s thp-0.4.6 thp to create the necessary symbolic link. Type mkdir /var/log/hpot. THP stores its log files in this directory.
Type chown nobody.nobody /var/log/hpot, followed by chmod 700 /var/log/hpot. These commands restrict access to the log directory. You may want (or even need) to change the user in this step, but if you do so, you must also modify the super server configuration used to launch the honeypot servers.
Copy the files from the xinetd.d subdirectory in the THP directory to your real /etc/xinetd.d directory. Change the disable = no lines in these files to read disable = yes. If your system uses inetd rather than xinetd, you must create /etc/inetd.conf entries that are equivalent to the xinetd configuration files.
In the /usr/local/thp directory, type ./iptables.rules. This action starts the iptables script that redirects ports in the way THP expects. If it’s not already running, start portmap. On Red Hat and similar systems, typing /etc/rc.d/init.d/ portmap start does the job. On other distributions, you may need to adjust this path. Use pmap_set to adjust the portmapper configuration. Type pmap_set < ./fakerpc from the THP directory to do the job.
Finally, start or restart your super server. On Red Hat, type /etc/rc.d/init.d/xinetd restart to restart it.
At this point, THP should respond to just about any access attempt on any unused port by presenting what appears to be a root prompt. Gullible crackers will believe they’ve encountered the world’s most poorly secured computer, but in fact, THP is logging everything they type. These logs appear in /var/log/hpot, one file per session. You’ll have to correlate these logs with data from your super server in /var/log/ messages to determine the caller’s IP address. You can combine THP with an IDS tool such as Snort to obtain still more data. An IDS may be able to log attempts to access UDP ports, for instance, which THP alone can’t do.
Unfortunately, THP doesn’t present the sort of notices (that warn communications are being monitored) that might help keep a THP system from running afoul of wiretapping laws. You might want to modify THP to do so before deploying it — but again, you should consult a qualified, attorney before deploying THP or any other honeypot.
Roderick W. Smith is the author or co-author of eleven books, including
Advanced Linux Networking and
Linux Power Tools. He can be reached at firstname.lastname@example.org.