There are two recurring themes in Internet security:

- Trust

- Authentication

Trust is the relationship between machines that are authorized to connect to one another. Authentication is the process those machines use to identify each other.

Trust and authentication generally have an inverse relationship. Thus, if a high level of trust exists between machines, stringent authentication is not required to make a connection. On the other hand, if little or no trust exists between machines, more rigorous authentication is required.

If you think about it, humans exercise similar rules. For example, if your best friend came to your front door, you'd let him right in. Why not? You trust him. However, if a total stranger came knocking, you would demand that he identify himself.

Methods of Authentication

Although you might not realize it, you are constantly being authenticated. For example, you might have to provide a username and password to use any of the following services:

- Your Internet connection

- FTP sites

- Telnet services and shell accounts

In fact, today, most subscription-based Web sites require a username and password. You're subjected to high levels of authentication every day. Do you know what that means? The Internet simply doesn't trust you!

Authenticating humans, therefore, involves a password scheme. (Some models employ a simple username/password scheme, whereas others can be more complex, such as challenge-response systems based on one-time passwords. The end result is the same, though—the user either has the correct password or she does not.)

Machines can be authenticated in other ways, depending on their trust relationship. For example, a machine can be authenticated by its host name or an IP source address. Using RHOSTS entries is a common procedure for setting this up.

RHOSTS

The RHOSTS system can be used to establish a relationship of trust between machines. It's described in the Solaris Manual Page:

The / etc / hosts . equiv and .rhosts files provide the "remote authentication" database for rlogin(1), rsh(1), rcp(1), and rcmd(3N). The files specify remote hosts and users that are considered "trusted." Trusted users are allowed to access the local system without supplying a password.

hosts.equiv files are essentially .rhosts configuration files for the entire system. These are set by root and apply hostwide. In contrast, .rhosts files are user-based and apply only to particular users and directories. (This is why users should be restricted from making their own .rhosts files. These open smaller holes all over the system.)

This file specifies that the four machines named (and the users hickory, dickory, doc, and mouse) are now trusted. These can access the local machine through the r services without being subjected to password authentication.

To complete the process (and create a two-way trust relationship), all four of the machines must also maintain rhost entries.

The r services consist of the following applications:

rlogin—Remote login. This works in very similar fashion to Telnet and offers a remote login session.

rsh—Remote shell. This enables users to run shell commands on the remote box.

rcp—Remote file copy. This enables users to copy files from local to remote machines, and vice versa.

rcmd—Remote command. This enables privileged users to execute commands on remote hosts.

All four r services use the / etc / hosts . equiv or . rhosts allow / deny scheme for trust purposes. No trust exists if these files are empty or don't exist, and therefore a spoofing attack (of this variety) cannot occur.

The authentication that occurs at connection time, then, is based solely on the IP source address. This is known to be a flawed model, as Steve M. Bellovin explains in his paper Security Problems in the TCP/IP Protocol Suite:

If available, the easiest mechanism to abuse is IP source routing. Assume that the target host uses the reverse of the source route provided in a TCP open request for return traffic. Such behavior is utterly reasonable; if the originator of the connection wishes to specify a particular path for some reason—say, because the automatic route is dead—replies may not reach the originator if a different path is followed.

The attacker can then pick any IP source address desired, including that of a trusted machine on the target's local network. Any facilities available to such machines become available to the attacker.

The following points have been established for now:

1. Trust and authentication have an inverse relationship; more trust results in less stringent authentication.

2. Initial authentication is based on the source address in trust relationships.

3. IP source address authentication is unreliable because IP addresses (and most fields of an IP header) can be forged.

4. A trust relationship of some kind must exist for a spoofing attack to work.

From this, you can surmise one of the reasons why IP spoofing has achieved cult status in the cracker community. Most cracking attacks have historically relied on password schemes; crackers would steal the / etc / passwd file and crack it. They would do their dirty work after having obtained the root password (and at least one user login/password). In spoofing, however, neither a username nor a password is passed during the attack. The security breach occurs at a very discrete level.

Another reason IP spoofing has gained much notoriety is that it can be used as a key element in other forms of attack. One example of this is known as "session hijacking," which is described in the next section.