Honeypots and Resource-Integrity Tools

When attackers pound on your network's door, you can use a variety of tools to detect and protect against the intrusion threat. Such tools include firewalls, intrusion-detection systems, authentication techniques, ACLs, access privileges, and smart cards.

However, two useful tools that administrators often overlook are honeypots and resource-integrity tools. Honeypots can lure attackers so that you can study their methods of operation, and resource-integrity tools can tell you whether a user, or possibly an intruder, has altered files or other system resources.

Honeypots
A honeypot is a system that you design specifically to look vulnerable so that attackers think it's easy prey. Attackers who probe the machine find a system that's easy to attack and that they believe might contain sensitive information. On the back end, the system logs all the intruders' probes and attacks.

Honeypots can act as decoys and can keep intruders away from your other systems. However, intruders can use a poorly protected honeypot that connects to your main system as a springboard to enter your main system. When you set up a honeypot, don't attach it to your organization's network. You can also use honeypots to gather information for future prosecution of intruders and to learn how attackers operate.

Before you set up a honeypot, you need to decide whether to place it inside or outside your firewall. Establish the honeypot on the same side of the firewall that your decoy files would reside if they were real. For example, if you want your honeypot to catch unscrupulous employees by mimicking an inhouse payroll server, place the honeypot behind your firewall. If your honeypot mimics a home computer connected to an ISP over a Digital Subscriber Line (DSL), place the honeypot in front of your firewall.

A Simple Honeypot
I've found that honeypots can be complex to set up; therefore, few systems administrators use them regularly. However, you can create a simple honeypot from a machine's default OS and application installation. Populate the system with nonsensitive files and records that might interest attackers.

To set up a simple honeypot, install a default OS, such as Windows 2000, and the latest service pack on the computer that you've decided to use as the honeypot. Don't upgrade from a previous OS. Then add services, such as Microsoft SQL Server, to the honeypot system. Finally, add appropriate content to the honeypot, such as SQL Server databases and tables.

You need to audit the system as often as practical, taking care to protect the audit logs well. You might consider backing up the log files daily on a remote computer that you connect to the same network as the honeypot. This backup can protect log files in case the intruder erases or modifies the originals on the honeypot. However, keep the honeypot network and your actual network separate so that an intruder can't use the honeypot to access your real data and files. Be sure to audit for critical system events, such as logon and logoff attempts, account-management attempts, policy-change attempts, and privilege uses. For more information about auditing for these events, see "Related Articles."

Logon and logoff attempts can signal that someone is trying to log on to the computer or is using a dictionary attack, in which a cracking program uses a word list to guess passwords. Account-management attempts show that someone is trying to add, remove, or update accounts on the honeypot machine. A policy-change attempt shows that someone is trying to change security policy. Privilege uses can signal that someone is trying to use debugging or backup privileges. The security log entries will show the account name that the attacker is using to make these security-sensitive requests. You can use Event Viewer to see this information. To find Event Viewer, go to Start, Programs, Administrative Tools, then click Event Viewer.

If you use Microsoft IIS on your honeypot, perform World Wide Web Consortium (W3C) extended logging (for information about the W3C extended logging format, see "Extended Log File Format: W3C Working Draft WD-logfile-960323" at http://www.w3.org/tr/wd-logfile.html) and log all the default settings, as well as the Win32 error status code. The Win32 error status code will help you determine why a request failed. All Win32 error status codes reside in the winerror.h file that most Microsoft C or C++ compilers contain. For descriptions of Win32 error codes, see "Win32 Error Codes" (http://msdn.microsoft.com/library/default.asp?url=/library/psdk/adsi/ds2_error_8sol.htm). You can determine an error number's meaning by typing the command

net helpmsg nnn

at a command line, where nnn is the error number. You can also monitor Win2K file and object audit access in the \%systemroot%\logfiles\W3SVC1 directory in case an attacker attempts to change the IIS logs directly.

If you use SQL Server, you can record all failed and successful logons and use standard security. This arrangement lets you see when users access the computer under the systems administrator (sa) account. Attackers usually use known accounts to try to access SQL Server systems, and the most common account in SQL Server is the sa account.

Opening Ports
As you add applications to the honeypot system, you're also opening more TCP and UDP ports. An attacker who scans the system for open ports will detect those ports, which give the attacker more ways to try to enter your system.

You can use a programming language (e.g, Perl, C++) to open ports without adding applications to your system and to log usage attempts on the ports that you've opened. For example, the Perl script that Listing 1 shows opens ports 25 (SMTP), 1433 (SQL Server), and 23 (Telnet) and logs all attempts to use these ports. The script mimics a highly vulnerable server, but you don't need to load server software on the machine. The script also warns you if ports 25, 1433, or 23 are already open. (You can download an excellent Windows implementation of Perl from ActiveState Tool—http://www.activestate.com. By default, the ActivePerl setup program will add the Perl interpreter to C:\perl. You can copy the port file to any directory and type

perl socksrv.pl

at the command line.)

Opening and monitoring ports is useful because it lets you know when someone scans the computer. Open ports also make the computer appear as if it's hosting services that it isn't. However, when you use a programming language to open and listen to ports, attackers who probe your system will quickly realize that the machine contains nothing of interest to them.