Honeypots and Resource-Integrity Tools

Downloads
19930.zip

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.

Sweetening Your Honeypot
Your honeypot needs to entice attackers without compromising your network's security. The following tips can help you attract more attackers to your honeypot and still protect your network:

• Your honeypot's content must relate to your organization's business so that your trap isn't apparent to attackers. For example, if the honeypot computer belongs to a toy retailer, don't litter the machine with top-secret military plans. If your honeypot mimics a corporation's computer network, consider using .xls and .doc files with names such as stockplan.xls and budget01.doc to generate interest among attackers.
• Consider the type of material that would keep an attacker interested. Your goal is to make the attacker stick around. If you're using SQL Server to set up a database application, set an easy-to-guess sa password and create tables that contain interesting data. Better yet, set up some Active Server Pages (ASP) that connect to a SQL Server database, and set a user account in the connection string. Attackers who access the source code to the ASP page probably will try to access the SQL Server database next.
• Install a high-quality network monitor in front of the honeypot so that you can reconstruct any event. I use Win2K's Network Monitor because it has excellent packet-parsing support, but any sniffer will work. Also, consider adding a good intrusion-detection tool to the honeypot. The tool will help you correlate data from the network monitor, applications, and the OS.
• Compile as much logging data as possible. You'll find it easier to reconstruct an attacker's movements if you have adequate logging information.

Resource-Integrity Tools
Resource-integrity tools are useful security devices because they can tell you whether files, configuration data, user-account information, or other system data (i.e., resources) have changed. For example, an IIS server includes files that make up the Web content, as well as registry data and metabase data that determine how the Web server operates. If any of these resources change, the Web server operation changes. A resource-integrity tool can tell you which resources have changed.

Attackers who modify a Web site's appearance can achieve that goal in several ways. The most-obvious way is to change the Web site's default.htm, default.asp, or index.html file on an IIS server. However, a less-obvious way to change the site's appearance is to upload a new file and set the Web server to point to the new file. In this case, attackers change metabase data and add a new page, but the default Web page file doesn't change. A resource-integrity tool can tell you which system resources have changed or are new, and you can use that information to track down and repair the damage.

Most resource-integrity tools gather file data such as filename, file directory, and the date the file was last modified. The tools also collect one or more hashes—either an MD5 or Secure Hash Algorithm-1 (SHA-1) hash, or both—of the file contents. A hash function produces a small digest, usually 128 or 160 bits in length, of a large body of data. Each digest is a unique representation of the data that it's based on. A small change in the originating data creates a massive change in the resulting digest, and you can't realistically create data that exactly matches a specific digest. You also can't determine the original data by looking only at the digest. A good analogy for a digest is your thumbprint. A thumbprint uniquely identifies you but tells nothing about you or what you know. Also, no other thumbprints are identical to yours.

Resource-integrity tools create a baseline file and perform all verifications by comparing changes with the baseline. Therefore, you need to protect the baseline file. After I create a baseline file, I store the file on a CompactFlash card, which I securely store off site. CompactFlash cards are small, convenient, and high capacity, and they can function like a disk drive, which makes them easy to use with a resource-integrity tool.

A Do-It-Yourself Integrity Tool
I've created a simple resource-integrity tool named FileAlarm, which you can see an excerpt of in Listing 2 (you can download the entre listing from the Code Library on the Security Administrator Web site, at http://www.secadministrator.com). FileAlarm.pl checks a file system for changes and outputs a report. FileAlarm can evaluate and create a snapshot of any file and directory in the file system, and by default the tool writes the baseline log file to the directory in which FileAlarm resides. To store the baseline log file in a location that you select, change the source code's $LOGFILE variable (which you can see at callout A in Listing 2) to a path and filename of your choice (e.g., C:\\MyLog\\Alarm.log). A sample run of FileAlarm on an intranet site yielded the output that Figure 1 shows.

These results show a new file (i.e., index.html) and an updated file (i.e., default.asp). The default.asp file had changes in the update time and the SHA-1 hash of the file, but the file size remained the same at 3654 bytes. The results show that the file content changed, but not the file size. Using these results, you can investigate whether an authorized user or an attacker changed the file. I've used this tool to detect file changes on several Web sites and security-sensitive installations, and in almost every instance, the changes were valid updates that authorized users performed. FileAlarm doesn't check registry or metabase contents, but it tells you whether the metabase file changed.

ActiveState Tool offers several Perl packages that can help you create resource-integrity tools. For example, the SHA package lets you create SHA-1 hashes, the File::Find package performs depth-first searches of a file system, and the Win32::FileSecurity package lets you read ACLs.

Useful Tools
Honeypots and resource-integrity tools can help you see when your network is under attack. Honeypots are useful not only for tracking how intruders move about within a system but for studying the methods that attackers use in trying to probe your system. Resource-integrity tools let you determine whether an attacker might have altered a file or other resource in your system.

Administrators often overlook the value of honeypots and resource-integrity tools. However, the tools can be useful additions to the tools and technologies that you use to ensure your network's security.

Related Articles

You can obtain the following articles from Windows 2000 Magazine's Web site, at http://www.win2000mag.com. RANDY FRANKLIN SMITH "Top 10 Security Tools in the Win2K Server Resource Kit," December 2000, InstantDoc ID 15969 "Monitoring Privileges and Administrators in the NT Security Log," June 2000, InstantDoc ID 8696 "Interpreting the NT Security Log," April 2000, InstantDoc ID 8288 "Introducing the NT Security Log," March 2000, InstantDoc ID 8056