The generally accepted definition of a honeypot is such: a system designed to be probed, attacked, or compromised; i.e., hacker bait. The idea is to cut all non-hostile traffic to zero, and wait for traffic—any traffic = unauthorized access or suspicious scanning. There are a few main reasons for honeypots: to see how many unauthorized people are able to break into a secure network, to find and capture new worms, to find and document new attacks/exploits, or to record the every move of an attacking hacker—from a script kiddie to an advanced hacker. No one honeypot is designed specifically to do all of these things.

     A honeypot can be as simple as a single computer running a program to listen on any number of ports; when a connection is made, the program logs the source IP and alerts the owner with an e-mail. Conversely, a honeypot can be as complex as a whole network of fully functional computers running different operating systems and various services. When a computer on the honeynet is scanned, the owner might be e-mailed; when a system is compromised the owner might get a call on their cell phone, a page, and an e-mail. Some honeypots are ready-made, while the more advanced honeypots or nets are often hand built with every detail carefully worked into place.

An Example of a Honeypot Deployed to Alert

     One critical requirement for a honeypot is that no traffic is purposely directed towards the system. Such a honeypot might reside in the middle of a cluster of computers that are used for accounting in a huge business firm. If an attacker has penetrated the security perimeter, chances are that they might scan the entire LAN of accounting computers, thus kicking off an alarm when the honeypot is scanned. The firm is now aware of a break-in. A worm would be a likely candidate in this case, but the attacker could be human. Now the company knows of a breach, and can research and plug the security gap.

Honeypots Designed to Capture In-depth Information

     A Honeypot that can farm a lot of information needs to give an attacker a wide range of options; once an attacker has compromised such a honeypot, they need to be able to reach out of the system and gather toolkits, contact other hackers, and any other preliminary actions that might be of interest to the security community (or any interested party). However, with a fully functional system, the interloper will be able to launch attacks and could leave the designer of the honeypot in some legal trouble—thus the builder of the honeypot would be wise to have a safeguard system set up to keep the damage of an outgoing attack, from the honeypot, to a minimum (I will get to this more below).

How does a Honeypot Gather Information

     Obviously a honeypot must capture data in an area that is not accessible to an attacker. Data capture happens on a number of levels; I will begin by describing the outermost level of data capture, and work my way into the innermost levels of data capture.

Firewall Logs—Simple, yet effective.

     A Packet Sniffer (or similar IDS sensor)—The IDS should be configured to passively monitor network traffic (for an added level of invisibility, one might set the system up to have no IP address or, in some instances, the sniffer could be configured to completely lack an IP stack). This will capture all cleartext communication, and can read keystrokes.

     Local and Remote Logs—These should be set up just as you would on any other system, and will possibly be disabled, deleted, or modified by an experienced hacker, but plenty of useful information will still be available from all the previous capture methods. Remotely Forwarded Logs—Will capture data on a remote log and then instantly forward the data to a system even further out of the range of the attacker.

How does a Honeypot Limit Outbound Attacks

     To protect oneself from any sort of third party liabilities, an individual deploying a honeypot will likely want some kind of safeguard. Firewalls can be configured to let an unlimited number of inbound connections, while limiting outbound connections to a specific number (be it 10 outbound connections, or 50). This method lacks flexibility, and could shut an attacker out at a critical point (in the middle of an IRC session, or before they have retrieved all of their tools). A more flexible option is as follows: a system configured as a layer 2 bridge (which will lack all TCP activity, thus being harder to detect). The system can be configured to monitor all activity and can utilize a signature database to distinguish a known attack from any non-aggressive activity (and instead of blocking the attack, it can simply add some data to the packet to render it ineffectual). It can also throttle bandwidth (to quench a DDoS attack). This is a very effective way to protect other systems; however, it will not block unknown or new attacks.

Putting the Honey into the Pot

     An advanced honeypot is a fully functional OS, and therefore can be filled with financial information, e-mails with passwords for other honeypots, databases of fake customers—anything that might motivate an attacker to compromise the system. An individual could set up a web server that explains that the law services of so and so and so and so from San Francisco are currently setting up their systems to do online consultation for big banks and other big businesses. A whole network of honeypots sits in a secure environment behind a firewall that an attacker would need to break through. The network might have loads of fake data and e-mail; a large playing field for an advanced hacker to wander through.

Identifying a System as a Honeypot

     I won’t go into much detail here, but anyone who is out breaking into systems should keep an eye open for honeypots. Simple systems might easily be identifiable (a stated OS with an IP signature that doesn’t match i.e. Nmap), while a honeynet might be very difficult to detect (a remote Syslog that is trojaned—sending data to a computer on an entirely different and more secure LAN).