لطفا منتظر باشید ...
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
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
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.
WARNING
align=left border=0> 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:
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, "
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.
WARNING
align=left border=0> 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
files also control access to that system. (As described in
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.
WARNING
align=left border=0> 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 192.168.34.56 ) or as a hostname (such as gingko.threeroomco.com ). In the latter case, the hostname may be either a fully qualified
domain name (FQDN), such as the full gingko.threeroomco.com , 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:
172.21.13.14 jbrown
This configuration grants the user jbrown on
172.21.13.14 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 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:
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, "
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.
WARNING
align=left border=0> 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
files also control access to that system. (As described in
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.
WARNING
align=left border=0> 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 192.168.34.56 ) or as a hostname (such as gingko.threeroomco.com ). In the latter case, the hostname may be either a fully qualified
domain name (FQDN), such as the full gingko.threeroomco.com , 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:
172.21.13.14 jbrown
This configuration grants the user jbrown on
172.21.13.14 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 172.21.13.14 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.
