Remote Access Tools

Remote access is the hallmark of modern multiple- user operating systems like Solaris and its antecedents , such as VAX/VMS. Unlike the single-user Windows NT system, users can concurrently log into and interactively execute commands on Solaris server systems from any client that supports Transmission Control Protocol/Internet Protocol (TCP/IP), such as Solaris, NT, and Macintosh. Single-user remote access has now been made possible on Windows NT Server also, using TCP/IP through products like Symantec s pcAnywhere; however, remote logins prevent concurrent console logins on NT. This is not the case with Solaris, which can support hundreds and thousands of interactive user shells at any one time, constrained only by memory and CPU availability.

In this section, we will examine several popular methods of remote access, such as telnet, which have been popular historically. We will also outline the much-publicized security holes and bugs that have led to the innovation of secure remote access systems, such as Secure Shell (SSH). These safer systems facilitate the encryption of the contents of user sessions and/or authentication sequences and provide an important level of protection for sensitive data. Although remote access is useful, the administrative overhead in securing a Solaris system can be significant, reflecting the increased functionality that remote access services provide.

Remote Access Risks

One of the unfortunate drawbacks of the telnet system is that usernames, and especially unencrypted passwords, are transmitted in cleartext around the network. Thus, if you were using a telnet client to connect from a cyber caf in Paris to a server in New York, your traffic might pass through 20 or 30 routers and computers, all of which can be programmed to sniff the contents of network packets. A sample traceroute of the path taken by packets from AT&T to Sun s web page looks like this:

 $ traceroute www.sun.com Tracing route to wwwwseast.usec.sun.com [192.9.49.30] over a maximum of 30 hops:  1   184 ms   142 ms   138 ms  202.10.4.131   2   147 ms   144 ms   138 ms  202.10.4.129   3   150 ms   142 ms   144 ms  202.10.1.73   4   150 ms   144 ms   141 ms  ia4.optus.net.au [202.139.32.17]   5   148 ms   143 ms   139 ms  202.139.1.197   6   490 ms   489 ms   474 ms  sf1.optus.net.au [192.65.89.246]   7   526 ms   480 ms   485 ms  gn.cwix.net [207.124.109.57]   8   494 ms   482 ms   485 ms  core7.SanFrancisco.cw.net [204.70.10.9]   9   483 ms   489 ms   484 ms  core2.SanFrancisco.cw.net [204.70.9.132]  10   557 ms   552 ms   561 ms  xcore3.Boston.cw.net [204.70.150.81]  11   566 ms   572 ms   554 ms  sun.Boston.cw.net [204.70.179.102]  12   577 ms   574 ms   558 ms  wwwwseast.usec.sun.com [192.9.49.30] Trace complete. 

That s a lot of intermediate hosts , any of which could potentially be sniffing passwords and other sensitive data. If the network packet that contains the username and password is sniffed in this way, a rogue user could easily log into the target account using a telnet client. This risk has led to the development of Secure Shell (SSH) and similar products that encrypt the exchange of username and password information between client and server, making it difficult for sniffers to extract useful information from network packets.

Tip  

OpenSSH is now supplied with Solaris for the first time with the release of Solaris 9.

Although rlogin is the fastest kind of remote login possible, it can be easily exploited on systems that are not trusted and secure. Systems that are directly connected to the Internet, or those that form part of a subnet that is not firewalled, should never be considered secure. These kinds of configurations can be dangerous in some circumstances, even if they are convenient for remotely administering many different machines.

Caution  

The most dangerous use of /etc/hosts.equiv occurs, for example, when the file contains the single line: +. This allows any users from any host that has equivalent usernames to remotely log in.

The . rhosts file is also considered dangerous in some situations. For example, it is common practice in some organizations to allow the root and privileged users to permit automatic logins by root users from other machines by creating an /.rhosts file. A more insidious problem can occur when users define their own . rhosts files, however, in their own home directories. These files are not directly controlled by the system administrator and may be exploited by malicious remote users. One way to remove this threat is to enforce a policy of disallowing user . rhosts files and activating a nightly cron job to search for and remove any files named . rhosts in the user directories. If cron entry for a root like this

 0 2 * * * find /staff -name .rhosts -print -exec rm{} \; 

should execute this simple find and remove command every morning at 2:00 A.M. for all user accounts whose home directories lie within the /staff partition.

Using Remote Access Tools

With the increased use of the Internet for business-to-business and consumer-to-business transactions, securing remote access has become a major issue in the provision of Solaris services. Fortunately, solutions based around the encryption of sessions and authentication of clients have improved the reliability of remote access facilities in a security-conscious operating environment.

Secure Shell (SSH)

Open Secure Shell, OpenSSH, or just plain SSH is a secure client and server solution that facilitates the symmetric and asymmetric encryption of identification and authentication sequences for remote access. It is designed to replace the telnet and rlogin applications on the client side, with clients available for Solaris, Windows, and many other operating systems. On the server side, it improves upon the nonsecure services supported by inetd, such as the r-commands. Figure 7-1 shows a typical SSH client session for vpn.cassowary.net from a Windows client.

Figure 7-1: Typical SSH client session

SSH makes use of a generic transport layer encryption mechanism over TCP/IP, which uses the popular Blowfish or government-endorsed triple-DES (Data Encryption Standard) algorithms for the encryption engine. This is used to transmit encrypted packets, whose contents can still be sniffed like all traffic on the network, but by using public-key cryptography, implementing the Diffie-Hellman algorithm for key exchange, the contents of encrypted packets appear to be random without the appropriate key to decrypt them.

The use of encryption technology makes it extremely unlikely that the contents of the interactive session will ever be known to anyone except the client and the server. In addition to the encryption of session data, identification and authentication sequences are also encrypted using RSA encryption technology. This means that username and password combinations also cannot be sniffed by a third party. SSH also provides automatic forwarding for graphics applications, based around the X11 windowing system, which is a substantial improvement over the text-only telnet client.

The sequence of events for establishing an SSH client connection to a server is demonstrated in Figure 7-2, and proceeds as follows :

1. The client connects to a server port requesting a connection (usually port 22, but this can be adapted to suit local conditions).

2. The server replies with its standard public RSA host key (1024 bits), as well as another RSA server key (768 bits) that changes hourly. Since the server key changes hourly, even if the keys for the traffic of one session was cracked, historic data would still remain encrypted, limiting the utility of any such attack.

3. The server can be configured to reject connections from hosts that it doesn t know about, but by default it will accept connections from any client.

4. If the connection is accepted, the client generates a session key composed of a 256-bit random number and chooses an encryption algorithm that the server supports (triple-DES or Blowfish).

5. The client then encrypts the session key using RSA, using both the host and server key, and returns the encrypted key to the server.

6. The server decrypts the session key and encryption is enabled between the client and server.

7. If the default authentication mechanism is selected, the client passes the username and password for the server across the secure channel.

   
   Figure 7-2: Authenticating a Secure Shell (SSH) connection

It is possible to disable the username/password authentication sequence by permitting logins to clients that have an appropriate private RSA key, as long as the server has a list of accepted public keys. However, if a client computer is stolen and the private key is retrieved by a rogue user, access to the server can be obtained without a valid username and password combination.

On the client side, a knownhsts.txt file is created and server keys are recorded there. Entries look like this:

 server 1024 35 0744831885522065092886345918214809000874876031312 6632026365561406995692291726767198155252016701986067549820423736 3937365939987293508473066069722639711474295242507691974151195842 9560631766264598422692206187855359804332680624600001698251375726 2927556592987704211810142126175715452796748871506131894685401576 4183 

In addition, a private key for the client is stored in Identity , and a public key for the client is stored in Identity.pub . Entries in this file are similar to the server key file:

 1024 37 25909842022319975817366569029015041390873694788964256567 2146422966722622743739836581653452906032808793901880289422764252 4259614636549518998450524923811481002360439473852363542223359868 1146192539619481853094466819335629797741580708609505877707742473 7311773531850692230437799694611176912728474735224921771041151 Paul Watters 

Tip  

It is sensible in a commercial context to enforce a policy of SSH-only remote access for interactive logins. This can easily be enforced by enabling the SSH daemon on the server side and removing entries for the telnet and rlogin services in /etc/services and /etc/inetd.conf . Now that OpenSSH is supplied with Solaris, there is no excuse for not deploying SSH across all hosts in your local network.