Once a host becomes trusted, there is the possibility that a trusted host or a trusted user may be impersonated. In the case of trusted user impersonation, there really is not much that can be done. The superuser on a trusted host is capable of impersonating any user. Note that it is usually not prudent to give trusted user access to the superuser. Probably the best way to minimize the risk of trusted user impersonation is to be aware of the quality of the administration on the trusted host.
Impersonating a trusted host is not so easily accomplished. Having two systems with the same IP address active on the same IP subnet usually results in strange behavior on the part of any systems communicating with the systems having the same IP address. If two systems on different IP subnets have the same IP address, then routing packets belonging to the system attempting the impersonation usually fails in the absence of the source routing option.
When the ``r'' command client uses the source routing option, it is possible that all of the routers along the way, the server network system software, and the ``r'' command server application software may make use of the source route supplied by the client. It is best to ensure that all of the following conditions are true in order to defeat a trusted host impersonation based on the use of source routing: the router to the subnet on which the server is located does not route packets with the source routing option enabled; the server network system software does not accept a source routed packet; and ``r'' command server application software checks incoming packets for the source route option and refuses service to such requests.
When a trusted host is not functioning, impersonating that trusted host on the same IP subnet is easily accomplished. It is common for personal computers to be turned off at night. This provides a perfect opportunity to impersonate a personal computer. Workstations are usually left on all the time. If the trusted host is turned off or disconnected from the network, then another system on the same subnet can easily assume the IP address of the trusted host. This situation is not easily detectable.
An ``r'' command server can employ some measure of protection against impersonation of a trusted host. A daemon, possibly consisting of just a shell script, can be created on the server to periodically monitor the ``health'' of the server's trusted hosts. Such monitoring could be no more complicated than simply using ping to insure that each trusted host is alive. Should a trusted host not respond properly to the monitoring, then entries for that trusted host in the hosts.equiv and all .rhosts file are removed. When a trusted host comes on line again, it would be required to identify and authenticate itself with the server. This identification and authentication could be done by the trusted host administrator logging into the server or by some automated communication between the trusted host and the server. The entries for the trusted host in the hosts.equiv and/or .rhosts files would then be replaced.