The security implications for the server are somewhat worse in Windows NT than they are in Unix. The basic problem is the same; the server is relying on the client's information about the user. Most clients are not in the least trustworthy (there are a number of ways for somebody with control over a client to take on any identity they please). In addition, since the client is identified only by checking the source IP address, the server is vulnerable to IP address spoofing even if it only trusts carefully chosen clients.

Worse yet, there is a mismatch between rsh and Windows NT's security model. Under NT, a program cannot just assume a user's identity without a password. rsh, however, is incapable of providing a password. The rsh server has to find some way to bridge this gap. Some servers take the straightforward and completely insecure approach of not even trying to assume the user's identity, and running everything with the server's permissions. Others store a mapping between rsh users and Windows NT users, including the Windows NT password. This provides better security when the server is in use, but an attacker who gets access to the mapping data has user and password information.

Because of these problems, running these servers is not advisable.

[82]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

• Don't allow any of the "r" commands across your firewall except outbound by proxy; they're unsafe. Use SSH or alternative protocols such as Telnet, FTP, and so on that can be made more secure.

• There is no way to safely provide outgoing rsh service using packet filters, because to do so you would have to allow incoming TCP connections to random ports below 1024 for the error channels.

• Because of the mismatch in security models, the rsh server is particularly dangerous on Windows NT; although Windows NT-based rsh clients are reasonably safe, Windows NT-based rsh servers are much more dangerous than Unix-based rsh servers.

• If you absolutely have to allow "r" commands, make sure that the trusted host mechanisms are strictly controlled (preferably by disabling that code in the server, which may require command-line options or modifying the source code).

• Beware disclosure of reusable passwords when using rlogin, just as when using Telnet.

[83]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

• Don't allow Remote Console, RCMD, or other SMB-based services, across your firewall.

• Don't run REMOTE at all.

Both version 1 and 2 of SSH meet the characteristics of a secure private communication session because:

• The client and server negotiate encryption algorithms (in the case of SSH version 2, negotiation also determines which key exchange mechanism and integrity checksums are used).

• The identity of the server to which a client is connecting is always verified, and this identity check is performed before any client user authentication information is sent. This mechanism is discussed in the next section on server authentication.

• The key exchange algorithms that are used prevent man-in-the-middle attacks.

• At the end of the key exchange, a checksum exchange will detect any tampering with algorithm negotiation.

• The server checks the client identity in a number of ways; these mechanisms are discussed later in the section on client authentication.

• All data packets exchanged include message integrity checks. An integrity check failure causes a connection to be closed.

• An SSH server uses temporary authentication parameters that are discarded after a configurable time period (normally one hour) to prevent recorded sessions from being decrypted at a later time.

In both versions of SSH, public key cryptography is used to prove the identity of a server. The first part of checking the identity is to verify that you have a valid public key for the server that you wish to connect to. At the time SSH version 1 was developed, this was a very difficult problem because there was no standard interoperable global infrastructure for the purpose of distributing and verifying public keys. This situation is slowly improving, and SSH version 2 can use a certificate authority to verify a public key (this is one of the features provided by using TLS, which is discussed in Chapter 14, "Intermediary Protocols"). SSH version 2 also supports the mechanism developed for SSH version 1.

The solution SSH version 1 uses is novel; the client retrieves the public key from the server itself, checks to see if it already knows a key for a server having this name, and compares the keys. A mismatch in keys causes a warning to be printed. When the client doesn't already have a key, it also prints a warning and optionally stores the public key for the next time you connect to the server. This system makes the client vulnerable to a hostile server on the first connection, but it does provide significantly more security than having the client vulnerable to a hostile server on every connection.

It is also possible to provide a local system database of keys for servers that users might want to connect to. This protects clients against a hostile server but at the expense of maintaining the local database. Having a local database is effective only if it is possible to know in advance which servers clients are going to connect to.

After checking the validity of a key, SSH then checks the identity of the server by sending a message encrypted using the public key.[84] When the server proves that it successfully decrypted the message, and therefore knows the private part of the public key, the client believes it is talking to the correct server.

[84]SSH version 2 does not always use public key algorithms for this. See the description of TLS in Chapter 14, "Intermediary Protocols", for how server identity is determined.

rhosts

The rhosts authentication mechanism is exactly the same as for the BSD "r" commands. If the client is using a privileged port and the .rhosts file permits the login, then it is allowed. This mechanism is not enabled by default, and it is not recommended because it is not secure. This mechanism requires that SSH be installed so that it can use a privileged port.

rhosts with RSA authentication of the client host

This approach combines .rhosts with public key cryptography. The server first checks the identity of the client host. If the RSA public key for the client host is known to the server and the client can prove it knows the host private key, then .rhosts authentication is performed. Allowing this mechanism is the simplest way to replace the BSD "r" commands without forcing users to set up any new files. This mechanism also requires that SSH be installed so that it can use a privileged port and be able to read the client host private key.

RSA authentication of the user

This approach uses only public key cryptography. The client first sends the user's public key to the server. If the server is willing to accept the key, it responds with a challenge so that the client can prove that it knows the user's private key. This mechanism reads only user files and does not require SSH to use a privileged port. SSH can also use an "agent" to hold user private keys. SSH clients, when they need to use a private key, contact the SSH agent to perform cryptographic operations on their behalf. By default SSH clients will automatically set up forwarding to your SSH agent if you have one running. This means that you can chain together multiple SSH connections through several systems without having to copy your private key to multiple systems.

Kerberos v5 authentication and TIS authentication server

These modes work the same way as other applications that use these systems, which are described in Chapter 21, "Authentication and Auditing Services".

Passwords

The final, and fallback authentication mode for SSH is to prompt for the user's normal login password. This is the same authentication used by programs like Telnet; the advantage is that at the point where SSH asks for the password, it has already established an encrypted connection, so the password is not passed in cleartext the way it is with Telnet or rlogin.

• The source IP address of the connection

• The name of the host from which the connection is coming

• The groups of which the user is a member

Figure 18-2. SSH port forwarding

Port forwarding does require some knowledge of how the protocols work and the port numbers that are used. It is therefore not useful to most users. If you receive requests to use port forwarding features, you may wish to consider implementing a real virtual private network. See Chapter 5, "Firewall Technologies", for information on virtual private networking.

Both the client and the server provide ways to permanently turn off port forwarding; you can compile them without the port forwarding feature, or use a system configuration file to disable it. However, this will not prevent users from using their own clients (which may ignore the system configuration file).

Inbound port forwarding is configured at the start of an SSH session. SSH can set up forwarding for several different ports at the same time. However, an attacker can only exploit the ports that were set up at the start of a session; additional ports can only be attacked when new SSH sessions are started. For instance, if you set up port forwarding to an IMAP server, that may expose the IMAP server to attackers, but it doesn't allow access to any other services. It is possible to place default forwarding information into the per-user configuration file. This will cause ports to be forwarded automatically whenever an SSH session is started. You may want to disable inbound port forwarding on your SSH server to keep users from opening internal ports to attackers with this feature.

However, if an attacker can do port forwarding to a proxy server, and the proxy server can talk to the internal network, a single port forward can turn into extremely general access. For instance, if a port is forwarded from the outside to a web proxy, the attacker then has access to anything that the web proxy can reach. For various reasons, ranging from laziness to a desire to accommodate bad browser configurations, administrators often set up their external proxy systems so that they can reach internal servers. In this configuration, one single port forward can provide an attacker straightforward access to the entire internal web, and all the information and vulnerable servers that are on it. A SOCKS proxy server can give even more direct and widespread access.

If you allow incoming SSH connections and port forwarding, you should make sure that any firewall proxy services refuse and log connection attempts from those systems. In general, if you are using firewall proxy services, you should configure them to not allow connections to internal systems. This protects you from users using port forwarding on an incoming SSH server and using your proxy servers to access internal or external resources.

[85]SSH clients use a port below 1024 when using .rhost-based authentication methods, and a port above 1023 otherwise.

[86]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

• If you have to allow inbound connections, SSH is one of the safest ways.

• Avoid using the .rhosts-based authentication methods.

• Only allow inbound SSH connections to servers that you control.

• Consider turning off port forwarding.

• Only enable remote X11 support when you need it.

• Consider disallowing outbound SSH connections, because they can be used to tunnel inbound connections, and it is difficult to enforce port forwarding restrictions on them.