About Traps and Deceptive Measures

Traps and deceptive measures are measures that appear to be real systems, services, environments, and so forth, but they're not. Deceptive measures are designed to cause people who attack and misuse systems and networks to obtain false information or to interact with virtual or other nonreal environments in which they can do little, if any, harm. A "trap" is designed to keep an attacker in one place (that is, one system or one application and so forth) so that the behavior and actions of the attacker can be recorded and analyzed , possibly (but not necessarily ) for the purpose of use as evidence in a court of law. Deceptive measures are thus broader in scope; traps are one of several types of deceptive measures. Traps and deceptive measures encompass a wide range of methods and tools, of which honeypots, automated messages, Trojaned commands, and virtual environments are some of the best known.

Honeypots

We will first consider what honeypots are and why they are used.

What Are Honeypots?

In the most fundamental sense, a honeypot is a computer designed to attract attackers . The computer is not a real server; it is not intended for legitimate users. It appears, however, to be a real server or service by blending in with the normal environment. It performs and responds as users expect; if properly designed and implemented, it should not disrupt the computing environment. If the honeypot incorporates a trap element, this element is not obvious. At the same time, a honeypot logs everything that an attacker or potential attacker does.

Goal

The major goal of honeypots is rather simple ‚ to have an adversary find and use a tempting environment that is so credible that the adversary devotes considerable attention to it. All the while,"white hat" personnel are monitoring and recording what the adversary does, but the adversary does not notice the monitoring and recording activity (provided, of course, that the honeypot is designed and implemented correctly). Another possible goal is to gather evidence (possibly legal evidence), as discussed in a later part of this chapter.

Automated Messages

Automated messages are messages ^[1] sent to a user when usage of a system or application is suspicious. As mentioned in Chapter 3,"A Methodology for Incident Response," many attacks occur during nonworking hours. An ingenious system administrator or someone else could configure a system to display an intimidating login message (for example, whenever someone tries to login between midnight and 5 a.m. and possibly also on weekends). Alternatively, a message might appear minutes or hours after a user has logged in. A user might, for instance, attempt to do something suspicious, such as enter the rpcinfo and showmount commands. This might trigger the display of an automated message on the user's screen.

^[1] Chapter 7,"Legal Issues," discusses the importance of having system warning banners, banners that are displayed during logins. Automated messages go beyond logon banners in that they are context dependent and are displayed any time after the login banner appears to the time the user logs out.

The intimidating message might, at a minimum, warn against unauthorized usage. In a more extreme case, this message might ask the person who is attempting to log in to call a certain phone number to provide positive identification. Consider the following possible messages:

"Do not continue to attempt to log in to this system unless you are a legitimate user. Our policy is to prosecute all unauthorized access to this and other systems. Everything you are doing on this system is being monitored ."

"We have traced the origin of your connection and are verifying whether the connection is legitimate."

"You are using an account that has not been used in so long that we consider your access pattern suspicious ‚ please call 415-445-4545 to verify your identity immediately."

Goal

The rationale of automated messages is to capitalize on the desire of most attackers to remain anonymous. Many times, the first thing an attacker who breaks into a UNIX or Linux system will do is enter the who command to determine who is on the compromised system at that time. If it appears that the system administrator is logged in, many attackers will log out immediately. When a message such as one of the preceding is displayed, attackers are likely to think they have been discovered , prompting them to move on to other systems.

Implementing Automated Messages

Implementing automated messages usually is not difficult. The easiest implementation methods include integrating messages into login script execution or the lastlogin message in UNIX and Linux. Scheduling one or more message displays via a cron job in UNIX and Linux or an at/Task Scheduler job in Windows NT or Windows 2000 is another alternative. Some significant hurdles exist, however, the most notable of which is a lack of existing tools that provide suitable automated message-generation support capability. Another is the difficulty of making messages look contextually plausible. An attacker who repeatedly receives the identical message will quickly learn that the message is bogus . It is important, therefore, to ensure that a variety of contextually plausible messages will be displayed.

Trojaned Commands

Still another approach is using Trojaned commands. This section discusses what Trojaned commands are and how they can be used.

What Are Trojaned Commands?

Certain commands are used disproportionately by attackers who are "door knob rattling" (that is, using methods that provide information about potential victim systems).

The following are some possible target commands:

• finger

• rwho

• rpcinfo

• showmount

• nslookup

The "white hat" community often counters the threat that such commands pose by disabling these commands altogether. Instead of disabling dangerous commands, however, it might in some circumstances be prudent to modify them to provide misinformation . For example, someone who uses finger on a potential victim machine might obtain output that shows that root is using the system, something that normally intimidates potential attackers. Similarly, the output might show a list of users on the system, all of which represent bogus accounts set up to provide an alarm if an attacker logs in to any of them. Most importantly, however, all command usage (including the time of command entry, the source address, and so forth) can be logged.

Goal

The major goal of using Trojaned commands is making systems and networks harder to attack by deceiving actual and potential attackers. By providing attackers with bogus user names , bogus IP addresses, and so forth, use of this deception method can considerably elevate the work factor necessary to successfully attack systems.

Evaluation

One of the major advantages of using Trojaned commands is the simplicity of this approach. All a person has to do is modify existing commands. (This, of course, depends on the availability of source code.) Furthermore, no special machines are necessary; Trojaned commands can be used on any non-honeypot server!

One of the major disadvantages, however, is that only a limited subset of commands is suitable. It makes sense to use the Trojan commands approach with commands such as finger and rpcinfo , but most commands that a normal user would use are not suitable. Consider, for example, what would have to be done to cause bogus output to be displayed when the mount or net use commands are entered. Additionally, there is a real risk of disruption when legitimate users enter one or more trojaned commands. Legitimate users can enter any of the commands that are more suitable for use with this approach; the output they receive is likely to cause a flood of help desk calls and waste the users' time ( causing frustration and possibly hostility ). Finally, it takes considerable time and ingenuity to set up Trojaned commands that are credible to attackers. If a potential attacker uses finger on a system once and then again two hours later, finding exactly the same list of users and session characteristics, the attacker will quickly realize that something is wrong. The attacker then might post a message warning other would-be attackers, thus rendering the use of Trojaned commands useless.

Virtual Environments

The next alternative we will consider is the use of virtual environments.

What Are Virtual Environments?

Virtual environments are special, safe environments (usually in the form of special shell environments) that are set up after users log in. These environments are normally created by execution of shell scripts for a special account, often one that has already been compromised and to which an attacker is likely to return. The normal authentication program is used when anyone tries to gain access to a system, but to create a virtual environment, one replaces the normal login shell with a special one.

One of the most fascinating tales in the entire computer and information security arena is the story of "Berferd ^[2] ," a Dutch attacker who regularly broke into a system at AT&T Bell Laboratories several years ago. Bill Cheswick, then a researcher at AT&T Bell Laboratories, noticed these attacks and set up a "jail (virtual) environment" for him. Thinking that he had gained a root shell, Berferd logged in to the victim system time after time. In reality, however, he was in a virtual environment in which his access was severely limited. All the while, Berferd's actions were being recorded; Cheswick traced the source of the attacks to the Netherlands.

^[2] Cheswick,William, and Steven Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker . Addison Wesley, 1994.

Goal

The main goal of virtual environments is to create a safe environment for logins so that the actions of attackers can be recorded and analyzed. Receiving prompt notification that an attacker is once again active on a system is yet another possible goal.

How to Implement Virtual Environments

Implementing virtual environments does not need to be complicated. Cheswick originally used a small set of programs and alterations to the MIPS operating system. A normal UNIX or Linux system, however, is likely to be easier to use and certainly as functional in setting up a jail environment. You need to add at least one line such as the following to the /etc/passwd file, such as:

 admin:*:111:111:ADMIN:/home/admin:/home/admin/root_sh 

An unpassworded entry (or, in some cases, an easy-to-guess password) for each account must then be added to the shadow password file.

The key to successful jail environments is the shell environment created after a login. The root_sh shell must make the attackers believe they are in a real environment. Entering cd .., for example, must ostensibly move the attackers to the parent directory of what appears to be the current working directory. The content of all files within directories such as / , /bin , /sbin , /dev/ , /etc/ , /usr , /var , /tmp , and others must be credible. All output from the user interaction in the jail environment can be sent to /var/log/hacker.log or another path , depending on the particular version of UNIX or Linux used.

Evaluation

Jail environments are particularly useful when attackers have been repeatedly breaking into systems but the decision to keep the systems running and connected to the network has been made. Jail environments can allow people dealing with the break-ins to record the actions of the perpetrators without additional appreciable risk to systems and networks. One of the downsides is that building credible jail environments can be difficult. With two major exceptions ‚ both of which are commercial firewalls that place apparent attackers in a special, artificial environment rather than simply dropping packets ‚ jail environment shells are not available in the public domain. Creating a custom shell for this purpose that will fool most attackers generally requires a great amount of effort and expertise. Additionally, whoever creates a jail environment shell must be careful to avoid security flaws that could allow attackers to break out of this shell, escalate privileges, initiate a core dump, and other undesirable outcomes .