Securing the .rhosts and hosts.equiv Files
Linux — and all the flavors of UNIX — are file-based operating systems. Practically everything that’s done on the system involves the manipulation of files. This is why so many attacks against Linux are at the file level.
Hacks using the hosts.equiv and .rhosts files
If hackers can capture a user ID and password by using a network analyzer or can crash an application and gain root access via a buffer overflow, one thing they look for is what users are trusted by the local system. That’s why it’s critical to assess these files yourself. The /etc/hosts.equiv and .rhosts files list this information.
hosts.equiv
The /etc/hosts.equiv file won’t give away root access information, but it does specify which accounts on the system can access services on the local host. For example, if tribe were listed in this file, all users on the tribe system would be allowed access. As with the .rhosts file, external hackers can read this file and then spoof their IP address and hostname to gain unauthorized access to the local system. Attackers can also use the names located in the .rhosts and hosts.equiv files to look for names of other computers to exploit.
.rhosts
The highly-important $home/.rhosts files in Linux specify which remote users can access the Berkeley Software Distribution (BSD) r-commands (such as rsh, rcp, and rlogin) on the local system without a password. This file is in a specific user’s (including root) home directory, such as /home/jsmith. A .rhosts file may look like this:
tribe scott
tribe eddie
This file allows users Scott and Eddie on the remote-system tribe to log in to the local host with the same privileges as the local user. If a plus sign (+) is entered in the remote-host and user fields, any user from any host could log in to the local system. The hacker can add entries into this file by using either of these tricks:
- Manually manipulating the file
- Running a script that exploits an unsecured Common Gateway Interface (CGI) script on a web-server application that’s running on the system
This configuration file is a prime target for a malicious attack. On most Linux systems I’ve tested, these files aren’t enabled by default. However, a user can create one in his or her home directory on the system — intentionally or accidentally — which can create a major security hole on the system.