Configuring rlogind

Configuring rlogind

The rlogin program is one of several r-commands. These commands were developed to provide various types of remote access to a UNIX system (hence the name ; rlogin is short for remote login ). When you run the rlogin client, it attempts to connect to a server that's called rlogind or in.rlogind . One of the merits of rlogind is that it's easy to configure; it has few options, so you don't need to deal with complex configuration files. Unfortunately, the protocol is also very primitive by today's security standards. Although it's easy to use, controlling access to a system that uses rlogind can be tricky.

Setting rlogind Startup Options

The rlogind server is usually launched from a super server, as described in Chapter 4, Starting Servers. Most distributions that use inetd include an entry for rlogind in their /etc/inetd.conf files, although that entry is often commented out by default. To run the server, you need only uncomment the line and restart the super server. Distributions that use xinetd generally provide a startup file in /etc/xinetd.d to start the server. This file is often configured to disable the server by default, so you may need to edit it to enable the server, as described in Chapter 4.

The rlogind server accepts a handful of parameters that influence its behavior. These are:

  • -n Normally, rlogind checks back with the client periodically to be sure it's still working, even if no data have been transferred recently. This option disables these "keepalive" messages.

  • -a This option is supposed to enable an increased level of password authentication, but it's broken on many distributions, and has little effect.

  • -h Normally, rlogind doesn't honor the superuser's .rhosts file, if present, as described shortly. This option causes rlogind to honor this file.

  • -l This option disables .rhosts authentication for all users. The superuser is an exception, if -h is also used.

  • -L This option disables authentication based on .rhosts or hosts .equiv files.



Although the -h , -l , and -L options are all officially part of rlogind 's repertoire , they're ineffective on most modern Linux distributions as delivered. This is because these options do not work on systems that use the Pluggable Authentication Module (PAM) security system, which is used on most modern Linux distributions.

Understanding rlogind Security

All of the r-commands use a security model that's generally considered by today's standards to be quaint at best, and hopelessly insecure at worst. In part, this is because the protocol is built on a trusted hosts security model, in which the server trusts the client with much of the authentication task. There are ways to tighten rlogind 's security to a limited extent, though, and using a Kerberos-enabled version of the program can help even more. When a user attempts to connect to an rlogind server, the system takes the following steps to authenticate the user:

  1. The server checks the originating port of the client's connection request. A normal rlogin client uses a port in the range 5121023, so rlogind drops the connection if the origin port isn't in that range. This step is designed to prevent an ordinary user of another system from writing a modified rlogin client to get around the trusted hosts security features, because only root may open ports numbered below 1024. Today it's easy for an individual to set up a Linux computer and so have root privileges, or initiate connections from OSs that allow anybody to open ports numbered below 1024, so this test isn't as effective as it might be.

  2. The server performs a DNS lookup on the connecting IP address to find the client's hostname.

  3. If the DNS lookup produced a hostname in the same domain as the server or if the -a option is used, rlogind looks up the IP address based on the hostname. If the two IP addresses match, and if the -L or -l option is not used, rlogind checks the ~/.rhosts and /etc/ hosts.equiv files to see if the client is trusted. If it is, and if the remote user has an account on the server, rlogind permits a login without further verification.

  4. If the DNS lookups yielded a mismatch on the IP address, if -L or -l was in use, or if the client can't be found in any of the trusted hosts authentication files, rlogind prompts the user for a password. If the user enters the correct password, rlogind allows entry to the system. If not, the server prompts again, then prompts for a username and password. If the user can't produce a correct combination after several tries , rlogind drops the connection.

Several of the preceding steps rely upon rlogind knowing the connecting user's username. This information is passed quietly from one system to another, or you can specify the username with the rlogin client's -l parameter, as in rlogin -l sjones .

Because rlogind uses a trusted hosts security model, and because the hosts it trusts can be configured by individual users via their .rhosts files, the server's security may be circumvented in several different ways. These include compromising the security of the client, spoofing a trusted client's IP address, removing a trusted client from the network and replacing it with one that the attacker controls, and replacing or adding to the .rhosts file in the target user's account. Many of these modes of attack aren't trivially easy, particularly on a network with otherwise strong security, but the combination makes rlogind a poor choice of remote login protocol in most situations. It does have one advantage, though: Under many circumstances, rlogind doesn't require the user to enter either a username or a password, so access to the server system is quick and easy:

 [rodsmith@nessus rodsmith]$  rlogin speaker  Last login: Mon Aug 12 14:48:58 2002 from nessus on 4 [rodsmith@speaker rodsmith]$ 

Another characteristic of rlogind is that it uses unencrypted data transfers. These are discussed in more detail in the upcoming section, "Understanding Telnet Security." The bottom line is that your data may be intercepted, so you should use rlogind only on small private networks that you're confident have not been compromised.

In sum, if a scripted login or otherwise quick access is required, rlogind may be worth considering, but its weak security model means you should be wary of it in most circumstances. The Telnet protocol requires use of passwords in most situations, and SSH is even more secure.

Controlling rlogind Access

If you do choose to use rlogind , the server prompts for a password when a login is attempted from an untrusted host. Chances are, though, that you want to use rlogind because it doesn't require the use of a username or password, so you want to configure it to trust certain hosts. This may be done in two ways:

  • /etc/hosts.equiv This is a system-wide configuration file to set r-command access. If a system is listed in this file, any user of that system may access r-command services on the server, provided the same username exists on the server or the username is remapped as described shortly. In the event of a name mismatch (for instance, if the user julia tries to use rlogin to access the account fred ), the user must provide a password.

  • ~/.rhosts This file, which is stored in a user's home directory, specifies clients that are to be trusted for an individual user. A remote user with the same username as the user on the server can access the server's resources as that user. (It's possible to remap this username, as described shortly.) Users are responsible for maintaining this file in their own accounts, if it's to be used at all.



The availability of ~/.rhosts files means that you as a system administrator delegate some of the authority for security on your system to your users when r-command servers such as rlogind are installed. This thought makes some administrators quite nervous, and it's one of the reasons you are well advised to not use rlogind , or to carefully restrict its use via TCP Wrappers or other means, as described shortly.

Both these files control access to all r-command serversprincipally rlogin , rcp , and rsh . When the computer uses the BSD LPD printing system (described in Chapter 9, Printer Sharing via LPD), these files also control access to that system. (As described in Chapter 9, a printer-specific configuration file may be used instead of these general-purpose r-command control files.)

Both these files have the same format, although the interpretation of some elements differs slightly from one file to the other. The file consists of a series of lines that describe individual hosts or groups of hosts. Each line's format is specified as follows :

 [+-][  hostname  ] [  username  ] 

The leading plus ( + ) or minus ( - ) sign explicitly allows or denies access from the specified client. The default is to allow the host, so the plus sign may be omitted in most cases. The minus sign, by contrast, may be used to explicitly deny a client access when it would otherwise be allowed by a preceding line that specifies several hosts, as described shortly.



Be very careful if you use a plus sign. A line that consists only of a plus sign (without a hostname) means to grant access indiscriminately to all clients. This makes for an extremely poor security policy. If you mistakenly include a space between a plus sign and a hostname, the system will interpret the hostname as a username, giving full access to anybody who cares to try to access your system.

You may specify the hostname as either an IP address (such as ) or as a hostname (such as ). In the latter case, the hostname may be either a fully qualified domain name (FQDN), such as the full , or a machine name alone if the two computers are in the same domain, such as gingko if the server is in the same domain as gingko . If you precede a name with an at-sign ( @ ), it refers to an NIS domain (your system must be configured to use NIS for this form to work). The safest form in which to specify hosts is as IP addresses, followed by FQDNs, followed by machine names only.

If you include a username in the list, this gives the listed user full access to the system. In the case of the .rhosts file, this means that the listed user is equivalent to the user in whose directory the .rhosts file resides. For instance, suppose julia includes the following line in her .rhosts file: jbrown 

This configuration grants the user jbrown on access to julia 's account on the server using rlogin , and similar privileges using rsh and rcp . (From the jbrown account on the client, the user will have to use the -l julia option to rlogin to log in to julia 's account on the server.)

The phrase "full access to the system" has a stronger meaning in the case of /etc/hosts.equiv . When a username appears in this file, the effect is that the named user of the remote system has unfettered access to all accounts on the server, with the exception of root . Thus, if the preceding example line was added to /etc/hosts.equiv , jbrown on could use rlogin to gain access not just to the julia account, but to any other ordinary user's account. In this context, "ordinary user" includes system accounts like daemon , which can often be abused to acquire root privileges. Thus, specifying a username isn't safe in /etc/hosts.equiv , except possibly in explicit denial situations (when the line begins with a minus sign).

In addition to the access controls provided by ~/.rhosts , /etc/ hosts.equiv , and passwords in case these files don't give automatic access to a client, you can use other control mechanisms to restrict access to an rlogind server. Because this server is usually run from inetd or xinetd , you can use TCP Wrappers or xinetd 's access control features to limit access to specific IP addresses or by other means. I strongly recommend you do so. A packet filter firewall rule can also block access to the rlogin port (TCP port 513), as described in Chapter 25, Configuring iptables.

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: