Chapter 1: An Introduction to Honeypots

		Chapter 1 - An Introduction to Honeypots Honeypots for Windows by Roger A. Grimes Apress 2005

It’s an exciting time to be involved with honeypots. If you’ve ever wanted to participate in something grand just as it’s taking off big, honeypots are it.

This chapter gets you started by defining just what honeypots and honeynets are, and why you would want to use them. It also provides an overview of honeypot components and types, as well as a history of their evolution. Finally, we’ll talk about the risks and trade-offs involved in operating honeypots.

What Is a Honeypot?

“A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource.” This definition was developed by Lance Spitzner (founder of The Honeynet Project) and the unofficial leader of the honeypot community. This definition includes two overall guiding principles of honeypots:

• The phrase information system resource is broadly defined intentionally, so that the honeypot can be any type of computer resource. It can be a workstation, file server, mail server, printer, router, any network device, or even an entire network. While honeypots most often mimic servers and workstations, I’ve seen many router honeypots, and even a honeypot mimicking a Hewlett-Packard JetDirect print server card.

• A honeypot is intentionally put in harm’s way to be compromised and has no legitimate production value beyond the honeypot goals. If your web server is frequently exploited and you analyze the information, that doesn’t make it a honeypot; that just makes it a poorly configured web server.

Note 

The Honeynet Project (http://www.honeynet.org) is a nonprofit organization founded in October 1999 dedicated to information security and honeypot research. Its goal is to learn the tools, tactics, and motives of the blackhat community and share these lessons learned. All of its work is open source and shared with the security community.

A honeypot can be whatever you want it to be. If you’re interested in honeypots as a new user, you must first decide on your goals, which will determine what type of honeypot you will deploy. Ask yourself what you are interested in protecting and what you are interested in learning.

THE HONEYPOT AS A TOOL

Every honeypot administrator has a favorite honeypot story, so it seems appropriate to start this book with one of mine. The client had called me because the company’s network was under constant attack. When they connected their corporate network to the Internet, network utilization immediately maxed out. When the Internet was disconnected, network utilization dropped to its normal 2% to 5%. It was visually stunning to see all the network device activity lights staying lit constantly, all at once. It reminded me of a network broadcast storm, but that wasn’t the problem. Whatever the malicious hackers were doing, it required a lot of bandwidth.

The client’s technicians had run antivirus scanners, had an actively functioning (though misconfigured) firewall, and had looked at all their servers and workstations for signs of foul play. They couldn’t find any. They even changed all the passwords in a futile attempt to lock out the hackers. This did prevent the attack for about 15 minutes, but then the hackers were back in. The technicians had placed a network sniffer on their network to capture and analyze packets for malicious content. They had been successful, but so successful that they had captured millions of packets—far too many to manually investigate how the hackers were getting in and discover what they were doing.

We disconnected the network from the Internet, and I set up a honeypot using Honeyd (an open-source honeypot solution). We configured it to accept connections to any UDP or TCP port number. I hooked up Snort (an intrusion detection system, or IDS) to capture all inbound packet traffic to the honeypot. We changed all of the user passwords again, turned on Honeyd, enabled the Internet connection, and then waited. We had connection attempts in seconds. Analyzing the data in real time, the honeypot captured many attempts to connect to a Microsoft SQL Server using the administrator account, called SA, and a blank password. A blank SA password is a common vulnerability in poorly configured SQL Server systems.

I asked the technicians if they had any SQL Server servers with blank SA passwords. They said they did not. We went to the computer room to investigate. They showed me their two production SQL Server computers. Neither had blank SA passwords. Then a technician remembered that one of the dusty boxes sitting in the corner of the room ran SQL Server, too. It was a development box installed by an outside programming company hired to upgrade one of the client’s primary applications. The programming job became a debacle, the vendor never delivered the promised application, and the box had remained unused for almost a year, or so they had thought. It did indeed have a blank SA password, and in quick order, we found out it had been exploited.

Using a packet sniffer, I then found heavy traffic between the development SQL Server box and an older Novell NetWare 3.11 server that ran Lotus cc:Mail (an e-mail application) for one user on the network. The NetWare server was being used by the hackers as an Instant Relay Chat (IRC) server and as a storage site for pirated software, pornography, and games. The SQL Server box was simply the hackers’ initial backdoor entry to gain access to my client’s network. The hackers then connected to the NetWare server using the never-changed SUPERVISOR account and began serving up files. The file storage area on the NetWare file server and traffic between the two compromised boxes were encrypted. We could see that a lot of disk space was used up (using the Novell syscon and ndir commands), but not what it contained.

We pulled the compromised computers off the network, and the hacking traffic disappeared, except for the hundreds of new attempts knocking against the now properly configured firewall. We knew the hacking was automated, because the time between when we replugged the network back into the Internet and the SQL Server attacks beginning again was seconds. We set up another SQL Server computer as a honeypot, but this time with all the appropriate monitoring tools. We were able to capture the hackers’ communications (mostly in a foreign language), learned the encryption method (SSH), and learned that the attacks were coming from different IP addresses in Korea.

Because we could not be certain of the extent of the damage, we spent the rest of the week rebuilding network servers, cleaning workstations, and tightening default security. A company policy was written to ensure that future vendors had to follow a certain set of recommended security steps, including changing all default passwords and not leaving blank ones. The client now runs a honeypot and IDS full time. They continue to get daily visits from the Korean hackers, even though they have complained through the appropriate administrative channels.

There are many ways this particular type of malicious hacking event could have been discovered. If the firewall were appropriately configured, the attack would not have been successful in the first place. The client could have used a network sniffer, auditing log files, or computer security utilities to track down the origination of the high-traffic levels. But in this case, a honeypot used in conjunction with an IDS proved an effective combination. That’s because any traffic going to the honeypot is malicious in nature, so it’s quick and easy to separate the malicious activity from the legitimate traffic.