Who's Watching Who?: Honeypots and Honeynets-Snooping the Snoops
Articles and Tips: article
01 Jul 2004
"All warfare is based on deception." -Sun Tzu
It's friday afternoon and i find myself mesmerized by the flurry of activity taking place on one of my computers connected to the Internet; it must be a slow evening in Russia. Someone has decided to play with a seemingly innocent Linux box. I've configured this host to appear as if it offers FTP and telnet services, although it actually offers no services at all--it's a Windows XP system that pretends to be a Linux host. Right now, someone from Russia is scanning this sweet host looking for open ports; they are even trying to log in to the fake FTP services. Unbeknownst to them, that sweet host is performing a reverse reconnaissance process on them--from port scanning to reverse DNS querying to trace routing. This host is one of our "honeypots."
While they poke around and try to access services on that host, our honeypot software logs their activities providing us with a clear view of their intentions--what fun!
A honeypot is a system that is set up as a target--often configured to track all access and pretend to offer services so it appears more enticing. If someone performs a reconnaissance scan or attack on the network and they hit the honeypot along the way, the honeypot may be configured to log this information, send you an alert that a scan is underway, and even perform a reverse reconnaissance operation to learn more about the scanning system.
Honeypots can be quite deceptive, appearing to offer a variety of services that may interest the scanner. Typically, honeypot software should be installed on a system that will be dedicated to being a honeypot. After installation comes the most important step in setting up a honeypot: defining the configuration.
The Face of a Honeypot
What services will your honeypot appear to offer? Should there be active user accounts on the system? Will your honeypot allow an attacker to get the password file? All fun questions to design a sticky, irresistible treat.
Your honeypot should blend in with the network, not stick out like a sore thumb. If you are placing your honeypot in the middle of your server farm, ensure the honeypot has a name that matches your server naming process. For example, if your servers are named SVR1BLG1, SVR2BLG1 and SVR3BLG1, consider naming your honeypot SVR4BLG1.
If your other servers are HTTP servers, then consider setting up your honeypot to offer HTTP services as well. With some honeypots you can even serve up a Web page that makes the honeypot appear to be a true Web server.
Figure 1 shows the main window of Specter, one of my favorite honeypot software packages. As you can see, Specter offers numerous configuration options to build a customized honeypot that fits right in with your network.
Figure 1: The main Specter window offers numerous configuration options.
In this example, my honeypot's system name is "SVR4BLG1"--it sits in a server farm where most of the servers are named by server and building number. This honeypot offers FTP, SMTP and HTTP services and appears to be a Linux system when OS fingerprinting is run against it.
This configuration performs a series of reconnaissance probes against a scanner/attacker as seen in the Intelligence section. Many honeypots can be configured to scan back against the intruder and log their findings. When started, this honeypot will also trap any traffic sent to the SUN RPC, SSH, SUB-7, Back Orifice 2000 and Blaster ports. All hits will be saved in an event log.
Deception ToolKit (DTK) is a honeypot solution that runs with a GUI interface on top of White Glove (available at www.all.net), a bootable version of Linux (also available at www.all.net). DTK offers numerous configuration options and can even pretend to use multiple IP addresses. For more information, see Honeypots and Honeynets.
Figure 2 shows the DTK honeypot interface. Simply click buttons to configure the honeypot to match its network surroundings.
Figure 2: Deception ToolKit offers a GUI interface only if it is running over White Glove.
As you compare Figures 1 and 2, you may notice some similarities between Specter and DTK. Most honeypots offer the option to select an operating system to spoof, the services that should be visible, the system name and the logging method.
Let's take a quick look at some of the standard elements of a honeypot configuration. I'll give you some suggestions on how to configure a honeypot on your network.
For more information about the Honeynet Project http://project.honeynet.org
Operating System
The Operating System, or OS, characteristic defines how the honeypot responds to OS fingerprinting processes based on port scans, ICMP scans or even banner information from the honeypot. If your honeypot sits in the middle of a group of Linux-based servers, it would make sense to configure your honeypot to emulate a Linux host.
I've been disappointed with this feature in most honeypots. For example, I may configure a Specter honeypot to pretend to be a Linux host even though I'm running Specter on a Windows 2000 host. The true OS of the box can be revealed using one of the better vulnerability scanners, such as LANguard Network Security Scanner (www.gfi.com). If someone scans my honeypot and gets an FTP banner that clearly indicates the honeypot is a Linux box, but a vulnerability scanner reveals the system to be a Windows box, then the deception is faulty and the honeypot is exposed as a fake.
To test this on your network, set up your honeypot on one operating system and configure it to emulate a different operating system. Scan your honeypot with NMap (www.insecure.org), LANguard Network Security Scanner, NetScanTools Pro (www.netscantools.com) or Retina (www.eeye.com). See if your honeypot fools these vulnerability scanners.
Note: I stay away from configurations that cause the honeypot to constantly change its "face." For example, on Specter you can configure the operating system as Random. It may seem quite obvious you've hit a honeypot if your OS fingerprinting results indicate the OS of a target is changing.
Character
Specter offers a character setting that defines how the honeypot responds to a more intrusive type of scan. For example, if someone simply scans port 80 (HTTP) on the honeypot configuration shown in Figure 1, the honeypot responds with an indication that port 80 is open. Because this honeypot is configured with an open character, it will serve up a real Web page if the attacker attempts to Web browse. Other characters, such as Secure and Aggressive, will serve up a warning page indicating that the attacker has been detected by a Specter honeypot.
My favorite Specter character is Aggressive. In this mode, the Specter honeypot will perform a reverse reconnaissance on the attacker in order to gather as much information as possible.
Figure 3: The log file tracks the attacker's commands to the honeypot and the honeypot's response.
Services
Again, remember that it's important to configure honeypot services so your honeypot blends right in to your company landscape. If your honeypot sits in the middle of the Web server farm, turn on FTP and HTTP. If you place the honeypot in the middle of your e-mail server area, turn on POP and SMTP.
When a TCP connection is attempted to these services, the honeypot responds with the appropriate packet to allow the connection.
Some honeypots allow you to customize services as well. For example, your honeypot could display a Web page when someone connects to it on port 80. If someone breaks into the POP service, your honeypot could allow access to a decoy e-mail. These added deceptions may provide more information on the attacker or possibly reveal the honeypot to the attacker.
Intelligence
In this section, you define what the honeypot does to the attacker. This traceback function is particularly useful when you are trying to characterize the folks who are attacking your network. In some honeypots (including Specter), the commands used by the attacker are also tracked. Figure 3 shows the steps the client used in an attempt to connect to the honeypot using FTP. The honeypot allowed an anonymous FTP login and prompted the attacker to enter their e-mail address as their password.
Traps
Traps allow you to watch for connection attempts on specific ports. For example, if you turn on the SUN-RPC (SUN Remote Procedure Call) trap, any connection attempts on port 111 are recorded in the event log. In Specter, you can add a custom trap to watch for suspicious traffic based on its port number. In Figure 1, notice that I turned on a trap for port 4444 (Blaster's default port).
Password Type
In the password section, you can define how complex the words in the password files should be. Typically, we set our password complexity to Mean--these would require years to crack using brute force password-cracking programs. If the password is set to Warning, the honeypot will create a password file out of the custom warning message. If you have one person who continues to come after the firewall, consider changing the custom warning message and thereby the password file to include their name if you know it.
Notification
Honeypots can be configured to track attacks and scans and even alert you by e-mail when such an event occurs. Care must be taken when configuring a honeypot to notify you when each alert occurs. You don't want the honeypot to saturate you with messages. A good honeypot should include a silencing feature to ensure you are not overrun with alerts.
Other Configuration Options
Honeypot software capabilities and configurations vary. Some of the interesting configuration options you may find are listed below:
MARKERS: Specter offers a questionable feature called "markers" that provides an executable file to the attacker. When the executable file is launched, it performs an examination of the attacker's drive and maintains the results on the local drive. Specter's marking ability was designed to enable law enforcement officers to create a correlation between an attacker's hard drive and a Specter log file. I recommend that you consult a legal representative before enabling Specter markers.
USERS: In order to make the honeypot appear more realistic as a network host, consider creating accounts on the honeypot. These users may appear to be logged in to the honeypot for a more convincing deception. Figure 4 shows a Specter user configuration window that lists seven custom user accounts.
REMOTE MANAGEMENT: Some honeypots can be managed remotely. This is particularly helpful when you have several honeypots scattered around your network. Now that we have covered the general characteristics and features of honeypots, it is time to determine the best place to put the honeypot.
Figure 4: Add user accounts for a more effective deception
Placing the Bait
Now that you know the basic functionality of the honeypot, where do you place it? There are several options. You could place a honeypot on the outside of the firewall to see the types of scans that are being sent toward the network. You could also place a honeypot on the DMZ to track scans and attacks that are run against the DMZ servers.
Hint: Be certain that no communication is allowed inside the network from the honeypot in the DMZ. You don't want someone to "bounce" off the honeypot to access the inside network.
Consider these other honeypot placement options:
PROXIMITY DECOY: Place the honeypot near existing servers and configure the server to look similar to the other servers surrounding it.
STANDALONE: Place the honeypot all alone on a network segment to locate anyone trying to run discovery throughout the network.
MINE FIELD: Load up a network segment with only honeypots; no other servers should reside on this segment.
Sometimes just one honeypot isn't enough. You may want to create a deception that includes several systems. In that case, you need a honeynet.
Honeypots and Honeynets
Honeynets are collections of honeypots that may exist on one or many computers. These honeynets may be made up of multiple physical machines, each loaded with honeypot software. For example, you could have six Linux systems hosting Deception ToolKit and five Windows systems hosting Specter for a total of 11 honeypots. The problem with this configuration is the hardware cost--11 systems!
The answer to this problem is a virtual honeynet, consisting of multiple virtual honeypots loaded on a single computer. Virtual honeynets have the advantage of requiring less hardware. If you want to build a honeynet with 50 computers in it, you could do this all on a single computer.
So how do you create a virtual honeynet? There are many options. You could load a honeypot software that advertises multiple "personalities" on the network. One example of this type of software is Symantec's Decoy Server (www.symantec.com). Decoy Server (formerly called ManTrap) emulates multiple systems on a single physical machine.
Another option uses VMWare (www.vmware.com) to load multiple virtual hosts on a single physical machine. By loading different honeypot software on separate operating systems, you can create a virtual honeynet on the one physical machine.
You can mix and match physical honeypots and virtual honeynets as well.
If attackers begin scanning around on this network, they are likely to hit one or more of the honeypots within this honeynet. The log files should provide some indication of the scanning method used.
Legalities of Honeypot Use
What if someone spoofs your IP address and they port scan a honeypot? That honeypot may perform a reverse reconnaissance on your IP address. If this has a negative affect on your system, to whom are you going to complain? Probably the owner of the honeypot.
We seem to be such a litigious society--it seems obvious that it's only a matter of time before we have a honeypot-related case in the courts. I always recommend that you talk with legal counsel before deploying a honeypot. The primary contact to keep up on the legal issues of honeypot use within the U.S. is Richard Salgado. His presentation on honeypot legalities is online at http://project.honeynet.org.
For More Information...
One of the best resources on honeypot/honeynet technology and hacker profiling is The Honeynet Project, which boasts of an impressive Board of Directors. Currently, the Board includes George Kurtz, CEO of Foundstone; Bruce Schneier, CTO of Counterpane; Alfred Huger, CTO of SecurityFocus.com; Martin Roesch, CTO of SourceFire; and Jennifer Granick of the Stanford Law School and Lance Spitzner, the founder of the Honeynet Project. Check out The Honeynet Project online at http://project.honeynet.org.
Well, it is now creeping into Friday night. Time to head out of the office and join the real world. By Monday morning we should have some really nice log files from all those folks who came to play over the weekend.
LAura is a Sr. Protocol/Security Analyst at the Protocol Analysis Institute, LLC. (www.packet-level.com; www.podbooks.com)
hon.ey.pot*
An Internet-attached server that acts as a decoy, luring in potential hackers in order to study their activities and monitor how they are able to break into a system. Honeypots are designed to mimic systems that an intruder would like to break into but limit the intruder from having access to an entire network. If a honeypot is successful, the intruder will have no idea that s/he is being tricked and monitored. Most honeypots are installed inside firewalls so that they can better be controlled, though it is possible to install them outside of firewalls. A firewall in a honeypot works in the opposite way that a normal firewall works: instead of restricting what comes into a system from the Internet, the honeypot firewall allows all traffic to come in from the Internet and restricts what the system sends back out.
By luring a hacker into a system, a honeypot serves several purposes:
The administrator can watch the hacker exploit the vulnerabilities of the system, thereby learning where the system has weaknesses that need to be redesigned.
The hacker can be caught and stopped while trying to obtain root access to the system.
By studying the activities of hackers, designers can better create more secure systems that are potentially invulnerable to future hackers.
* as defined by www.webopedia.com/TERM/h/honeypot.html
Sticky Sweet Treats
Test drive these honeypot packages to see which one fits best on your network.
Specter Honeypot
PLATFORM Windows 2000 SP2 or Windows XP SP1
PROS Clean interface, easy to install/configure
CONS Log analyzer gets slow when really full
Deception ToolKit
PLATFORM White Glove (bootable Linux) recommended
PROS Free; clean interface when run over White Glove
CONS Requires White Glove for GUI
Decoy Server
PLATFORM SUN Ultra 5 or later; Solaris 7 SPARC
(patch level 106541-04 or higher)
PROS Emulates multiple hosts in separate "cages"
CONS Complex configuration, expensive
The Honeypot Buzz
Decoy-Based A honeypot that pretends to be another type of system; it does not release its true configuration information.
OS-Based A honeypot that is tied to an OS. For example, you could build a honeypot on top of a Linux box, and this honeypot cannot spoof its operating system. It shows up as a Linux box when OS fingerprinted.
Virtual Host A honeypot host that is not tied to a physical device. Virtual hosts are used in virtual honeynets.
Aggressive A honeypot mode that performs reconnaissance on the attacker
Target of Opportunity A term used to define the "low-hanging fruit" on a network by scanning all systems and looking for easy prey.
Zero-day Attack A vulnerability exploited in the wild before it is reported to security groups.
Session Playback A honeypot function that allows you to record and replay the attack session to witness the attack process.
Host-based Attacks Attacks that are focused on specific hosts. Host-based attacks should be evident in system logs.
Network-based Attacks Attacks visible in a datastream on the network. If configured properly, network analyzers can detect and capture these attack sequences.
Sacrificial Lamb A honeypot that is designed to be attacked. This sacrificial lamb should have no link to the internal network.
Proximity Decoys A honeypot that is set up near production systems. The production systems won't report attacks or scans, but the honeypot will.
Redirection Shield An upstream redirection process to transparently send certain traffic to the honeypot instead of the production system.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.