Firewalling a Secure Shell Service

Firewalling a Secure Shell Service Agung Prasetijo1 , Mark Looi2 , Andrew Clark2 , Gary Gaskell2 , Paul Ashley3 , and Joris Claessens4 1

Dept. of Electrical Engineering, Fac. of Engineering, Diponegoro University, Jl. Prof. H Soedarto, S.H. Tembalang, Semarang, Indonesia. Email: [email protected] 2 Information Security Research Centre, School of Data Communications, Queensland University of Technology, GPO BOX 2434, Brisbane, Australia. Email: {mlooi, aclark, gaskell}@isrc.qut.edu.au 3 Tivoli, Security Business Unit, 9020 Capital of Texas Hwy, Great Hills Corporate Center, Building 1, suite 270, Austin, TX 78759, United States of America. Email: [email protected] 4 COmputer Security and Industrial Cryptography (COSIC), Dept. of Electrical Engineering, Katholieke Universiteit Leuven, Kasteelpark Arenberg 10, 3001 Leuven-Heverlee, Belgium. Email: [email protected]

Abstract– The security threats to networked systems have increased. The demand for accessing hosts remotely in a secure manner is therefore also increasing. In order to meet this demand, many users and network administrators use the Secure Shell (SSH) service. However, the SSH system may be configured with insecure defaults. A proxy in-between an SSH server and its clients is one possible way to enforce an organisation’s security policy while allowing such users and network administrators to continue to use the service. The proxy presented here has been developed from the SSH version 1 (SSH-1) source code and it helps network managers to enforce a desirable policy, such as allowing the use of strong authentication methods and avoiding security flaws in the server configuration. Keywords– Authentication, firewall, proxy, security, SSH

I. INTRODUCTION

A

ccessing or managing hosts remotely often involves the use of the Telnet [6] or Rlogin [3] services. By using these services, users may remotely access hosts that have such services enabled. Unfortunately, both Telnet and Rlogin services do not provide confidentiality, authentication or integrity of information, as these tools do not use any cryptography. The secure Shell (SSH) service, instead, has the capability of providing data confidentiality (using encryption), and data authentication (using a Message Authentication Code or MAC), and entity authentication (using cryptographic authentication) to protect all messages as they travel across untrusted networks. The SSH system has been developed by the Helsinki University of Technology [5]. It provides a number of strong authentication methods such as RSA (public key) based authentication. Moreover, its source code is extensible for new authentication methods, such as

Kerberos [4] authentication and the TIS [8] challengeresponse authentication method. The function of secure tunneling in the SSH service is a useful tool as it allows users and network administrators to access hosts in a remote networks using any application protocol in a secure manner. This has led to a significant increase in demand for the SSH service. However, the use of the SSH service may increase security risk if it is poorly configured. Allowing password authentication, for example, instead of using other stronger authentication methods in a highly secure environment will reduce the overall security. Password authentication is protected by encryption, however, an attacker may attempt to slowly guess user passwords. Users are known to use poor passwords [2]. Hence, it may be expected that a password guessing attack might succeed. Likewise, with empty passwords in the SSH server configuration enabled, users may log in to the system without providing any password. This will increase the chance of unauthorised users gaining access. As the threat to information systems is increasing along with the popularity of the SSH service, restricting the SSH service is becoming important to provide the availability of an SSH service without sacrificing the system security. A proxy is a practical way to enhance the security of the SSH service. The SSH proxy may enforce the network security policy. It may require a stronger authentication method to be used, enforce port and X11 tunneling policy, and eliminate weak SSH configuration issues of SSH servers behind the proxy. The outline of this paper is as follows: the next section gives an overview of the SSH protocol. It explains how the SSH is structured and how it provides session-based security services. The paper will then describe how the SSH service is employed in a corporate network and how an SSH proxy can contribute to the security of the SSH service. In the next section, a prototype of an SSH proxy is presented. This is followed by an analysis of outstanding issues learnt from developing that prototype.

Appeared in Proceedings of the 2001 International Conference on Electrical, Electronics, Communication and Information CECI 2001, Jakarta, Indonesia, March 7-8, 2001, pp IT39–IT43 Indonesian Society on Electrical, Electronics, Communication and Information (IECI) – ISBN : 979-8575-02-4

II. SSH PROTOCOL OVERVIEW Secure Shell is an application protocol, which consists of three layered components [9] (see Figure 1).

Fig. 1. SSH protocol layers in the application layer of the TCP/IP protocol stack.

The bottom layer in the SSH protocol is known as the SSH Transport Layer. This layer is responsible for providing encryption, compression (if necessary), and server authentication. Protocol version exchange and key exchange between a server and its client are also established in this layer. The layer sitting above the SSH Transport Layer is called the SSH Authentication Layer, which is responsible for providing flexible user authentication. Extensibility of authentication methods is provided by this authentication protocol. Some organisations may use their own authentication methods. Two or more authentication methods may also be combined to provide stronger authentication. The uppermost layer, the SSH Connection Layer protocol, is responsible for providing interactive login sessions, remote execution of commands, or tunneling over secure channels. Establishing the SSH Transport Layer Within the TCP/IP implementation, the SSH server conventionally (officially assigned by IANA [1]) listens for connections on port 22. When a client makes a connection to an SSH server, the server provides a child process to handle the client’s requests. The server immediately sends its protocol version identification string. It then waits for the client’s response with the appropriate protocol identification string. Both sides must be able to process these identification strings. From this point onwards, the server switches into a binary packet protocol. The server immediately sends a “public key” packet which contains check bytes, its host key (long term key) and server key (an RSA key regenerated periodically throughout a session), protocol flags, available ciphers and authentication types to the client. The client then processes this information and responds to the server with a “session key” packet which contains the client’s available cipher types, the server’s check bytes, an

encrypted (with both server’s keys) session key, and some protocol flags. Both the server and the client then immediately activate the encryption. Upon success, the server responds with an encrypted “success” packet. Each packet in an SSH communication message is preceded by a defined message code. For example, the “session key” packet code has an integer value of 3, and a “success” packet code has an integer value of 14. The message code available on every packet may be examined in order to have the proxy enforce the security policy. Authenticating Users After both server and client keys have been exchanged, the secure channel of the SSH transport layer is established. Authentication of the user is then required. Firstly, the client sends a username to the server. The server may accept and directly authorise the user if the server is configured to allow no authentication. Conversely, the server may be configured to require authentication. The authentication methods available may be chosen, such as password-based authentication, rhosts authentication or RSA authentication (or even a combination of rhosts and RSA authentication). The server might be configured to allow more than one authentication method, and users may use any one of these authentication methods to log in to the host. The client may connect to the server from an arbitrary port. However, the client must use a privileged port (below 1024) if rhosts authentication is requested. Interactive Session Once a user has been authenticated, some extra functionality may be requested before an interactive session is established. This extra functionality includes packet compression, port and/or X11 forwarding, a pseudoterminal or a shell. If a user requests a shell or a command, the server responds to this request by forking a shell and entering an interactive session. A “success” message is sent when the request is successful. This interactive session is established to enable the user to execute commands through the SSH connection. III. AN SSH PROXY IN A CORPORATE NETWORK It is a common situation that a corporate network has many SSH servers at different locations which are maintained by different persons. For this reason (amongst others), some SSH servers might be poorly configured. The configuration file of the SSH daemon allows the use of weak authentication methods, for example, password and rhosts authentication, and may even allow not to use authentication at all. Allowing root login in an SSH service can also be an issue for a network requiring good security. With respect to network security, the SSH service solves the problem of securely accessing remote host, but opens some potential security vulnerabilities at the same time. In

Appeared in Proceedings of the 2001 International Conference on Electrical, Electronics, Communication and Information CECI 2001, Jakarta, Indonesia, March 7-8, 2001, pp IT39–IT43 Indonesian Society on Electrical, Electronics, Communication and Information (IECI) – ISBN : 979-8575-02-4

particular, the port and X11 forwarding feature allows users to forward ports in the internal network which are normally blocked by a firewall. An SSH proxy is able to enforce an organisation’s desirable policy. Figure 2 shows the situation where the SSH proxy eliminates potential security dangers due to poorly configured SSH servers and due to potentially dangerous port and X11 forwarding.

Fig. 2. An SSH proxy may eliminate potential security dangers due to multiple poorly configured SSH servers.

IV. SSH PROXY The SSH proxy is described in detail in the following subsections. Establishing Two SSH Connections Two different secure connections are firstly established (see Figure 3). When the proxy receives a connection request from a client, the proxy establishes an SSH Transport Layer connecting the client with the proxy. The proxy, in turn, requests a connection to an associated SSH server and also the server and the proxy establish an SSH Transport Layer. To let the proxy know which server the user ask for, modification to user procedures is necessary to pass the server address to the proxy. These two SSH Transport Layers have different secret keys and different session identifiers as shown in Figure 3.

Fig. 3. Establishment of two connections (SSH Transport Layers) one after another.

Note that a client cannot authenticate to the proxy if the two connections have not been established, for example, when the proxy fails to connect to the server. The client must then initiate another connection to the proxy. Proxying Authentication Methods Immediately after the two SSH Transport Layers have been established, the client sends its username to the proxy in order to begin the authentication phase. The proxy may enforce a policy which disallows root login in an SSH service. If the proxy allows the username to log in, it forwards the username to the server. The response from the server (“success” or “failure”) is then forwarded to the client through the proxy. Note that a superuser on Unix servers does not always have the username ‘root’, as any account with a user ID (UID) of 0 is a superuser. However, it still improves the security options available to a security manager. The client then requests authentication. The server might provide several known available authentication methods. Some authentication methods are strong, such as RSA authentication and Kerberos authentication. Some of the other authentication methods, for example rhosts authentication, may be very risky to use in a network requiring good security. The proxy can be used to enforce certain authentication methods. E.g., the proxy can be configured to only allow strong authentication methods and to reject connections which request a weak authentication method. In that case, the proxy would refuse a password authentication request and will not forward this request to the server. The proxy may either wait for other authentication attempts or immediately disconnect. Port and X11 Forwarding Requests Once a user is authenticated to the SSH server, the user may ask for a pseudo terminal, a shell, or a command. It is also possible for the user to request port and X11 forwarding. This port forwarding is also known as tunneling. The port forwarding capability allows the user to forward any connections from a remote machine to a local machine or vice versa. A preferred port is allocated to listen for connections on a remote machine and such connections are forwarded to the local machine. Hence, the user can receive forwarded connections from the remote machine to the local machine. This may be a security issue if a user is attempting to use the tunnel to pass an application protocol through a firewall, where that protocol is normally blocked. A proxy can be used to enforce a policy which disallows the use of port and X11 forwarding. Handling Interactive Sessions An interactive session can be requested by asking for a shell or a command. The command mode will process a client command line soon after the interactive session is established, while a shell mode will wait until a command is

Appeared in Proceedings of the 2001 International Conference on Electrical, Electronics, Communication and Information CECI 2001, Jakarta, Indonesia, March 7-8, 2001, pp IT39–IT43 Indonesian Society on Electrical, Electronics, Communication and Information (IECI) – ISBN : 979-8575-02-4

given by a client. In this interactive session, the server allocates the standard input to data sent by a client. The server’s standard output and server’s standard error are directed to the client. The client processes these two outputs as the client’s standard output and client’s standard error. The SSH proxy just forwards any packets from the client, as it does not control every command entered by a user (this should however be possible in theory). V. PROXY IMPLEMENTATION ISSUES One possible way to create an SSH proxy is modifying a distribution of SSH for which the source code is freely available. The SSH-1.2.27 [7] was chosen for building such a proxy on a FreeBSD platform. A minimum amount of changes to the server and the client source code have been made. Macros have been used to add necessary lines to the source tree and to delete the unneeded lines. The proxy has been designed to have two different SSH Transport layers (as shown in Figure 3), as the proxy must have the ability to receive, interpret, and forward on packets. In contrast to the original server, which only has one connection, the proxy must listen to both directions. The source code has thus been modified in such a way that different buffers and contexts needed for the server part and the client part are provided. Practically, when the proxy relays from one side to the other side, all the descriptors, buffers, and contexts are interchanged. The ones for the working connections are being used and the other ones are stored in temporary variables. In the interactive mode, the proxy uses the same approach as for the synchronous connections used for the authentication request and port or X11 forwarding request. Two different sets of variables are used for storing data for the server side and the client side. Hence, the proxy maintains an individual state for the two sides. In this prototype, the proxy waits for packets from the client and the server. Once a packet is received from one side, the proxy then forwards the packet to the other side without examining its content. In an interactive session, user commands are thus passed to the server without any additional control. Regarding the SSH Authentication Layer, the proxy only accepts one authentication attempt in every connection. Once this attempt is unsuccessful, the proxy will immediately drop the connection. The Authors propose that the proxy examines the policy setting for root logins. If root logins are prohibited, any user authentication requests with the username of root will be denied. Other username authentication request will be forwarded to the server. As stated above, if the non-root username has a UID of 0 on the destination server, the proxy cannot detect this and a “privileged” login will slip past the proxy, despite the policy setting. A standard SSH daemon operates by accepting a user authentication request from a client and performing a lookup for that username in

the local user database (/etc/passwd). The proxy does not have a database of all usernames of all servers that it is proxying. Hence, where a normal SSH daemon could examine that user account database and verify the UID, the proxy can not. Furthermore, the use of a default deny policy in the SSH proxy will lead to a better security practice rather than using a default permit policy. With this default deny policy, users must register first to the network administrator in order that they are allowed to use the SSH service. Hence, the proxy must have the capability of storing a list of acceptable accounts. Due to an undetermined problem, compression is not working correctly at the proxy in the current prototype. As the Authors do not consider compression to be a security feature, this issue has not been fully investigated at this time. A more serious and conceptual problem has been identified with RSA authentication which is now discussed in detail. VI. A PROBLEM WITH PROXYING RSA AUTHENTICATION AND A PROPOSED SOLUTION It is not possible to proxy the RSA authentication method. If the proxy would just forward the authentication messages, the server’s verification fails as the client response to the server’s challenge would fail. This verification fails as the client uses the client-proxy session ID when preparing the response, whereas the server is expecting the response to be based on the session that it shares with the proxy. The client does not know the session ID of the proxy-server connection (See Figure 4).

Fig. 4. The two different session identifiers cause the response of the challenge to be considered false by the server.

When the client asks for RSA authentication, the proxy forwards this request to the server. The server in turn generates a challenge for the client. The client then decrypts the challenge using its private key, concatenates it with a session ID shared between the proxy and the client. The response is the MD5 hash of the resulting concatenation which is sent to the server through the proxy. The server will therefore consider that the client’s response is false

Appeared in Proceedings of the 2001 International Conference on Electrical, Electronics, Communication and Information CECI 2001, Jakarta, Indonesia, March 7-8, 2001, pp IT39–IT43 Indonesian Society on Electrical, Electronics, Communication and Information (IECI) – ISBN : 979-8575-02-4

because the server uses a different session ID than the client. The issue of RSA authentication is important as the RSA authentication method is the strongest user authentication method in the default SSH distribution. To alleviate the problem of proxying RSA authentication, the way the system authenticates the user must be changed. The Authors suggest that both the server and the proxy might be able to process RSA authentication. Firstly, the user authenticates to the proxy, and after that, the proxy authenticates to the server (see Figure 5).

Fig. 5. Double RSA authentication. The proxy authenticates the user, and soon after that the server authenticates the proxy.

When a client requests an RSA authentication, the proxy sends a challenge to the client. If the response of the challenge is correct, the proxy should not immediately send a “success” packet to the client. Instead, the proxy asks for RSA authentication with the server. If the proxy is authenticated by the server, the proxy immediately sends a “success” packet to the client. If the server rejects the authentication, even though the response from the client is correct, the proxy must send a “failure” packet to the client. The latter should also be done if the server does not provide RSA authentication. Unfortunately, the cost must be paid for using the method above. The end-to-end security, of course, decreases. The SSH server must always trust the proxy, and the proxy plays an important role in the RSA authentication in this situation. In addition, in order that the proxy recognises every user, the proxy must store every username and the associated public key as well as the encrypted private key. This will also reduce the scalability of the SSH service and will lead to problems in system maintenance. The source code for the prototype is available by contacting the Authors.

forwarding, prohibit the use of empty passwords, and stop root logins. The SSH proxy may reduce the danger of improper SSH server configurations. In this prototype, the proxy has no idea of the users who log in if the database of users similar to the SSH server behind the proxy is not maintained. As a result, granting a UID of “nobody” to every username which is not a root is necessary in order to be able to proxy the username. Likewise, modifying user procedures is important to let the proxy know where a client’s request should be forwarded to. This research has identified that it is not possible for a proxy to forward an RSA authentication challenge-response due to the inclusion of session IDs. in the RSA authentication protocol. Meanwhile, a proposed solution to the RSA authentication problem indeed decreases the security in the authentication phase. By the advent of the SSH proxy, a scalability issue may also lead to a problem when the system in a corporate network expands. End-to-end security is preferred by users, but it prevents an organisation to enforce its overall security policy at the firewall. This paper presented a proxy-based solution for this problem. Besides some remaining technical issues, there is also an important trust aspect. In practice, a balanced solution might therefore constitute of a mixed situation with end-to-end security through the firewall for some parts of the organisation and proxy-based security at the firewall for other parts of the organisation. Further investigation is needed in order to ensure that the SSH proxy does not limit the original SSH server functionality. The current version of this proxy does not handle compression properly. Correcting this problem remains works for the future. REFERENCES [1] The

Internet

Assigned

Numbers

Authority,

URL:

http://www.iana.org. [2] Li Gong, Mark A. Lomas, Roger M. Needham, and Jerome H. Saltzer, “Protecting Poorly Chosen Secrets from Guessing Attacks”, IEEE journal on Selected Areas in Communications, 11(5):648-656, June 1993. [3] B. Kantor, “BSD Rlogin”, RFC 1282, University of California San Diego, December 1991. [4] J. Kohl and C. Neuman, “The Kerberos Network Authentication Service (V5)”, RFC 1510, Digital Equipment Corporation/ISI, September 1993.

[5]Helsinki University http://www.hut.fi.

of

Technology,

URL:

VII. CONCLUSIONS

[6] J. Postel and J. Reynolds, “Telnet Protocol Specification”, RFC 854, ISI, May 1983. [7] SSH Communications Security, “SSH Secure Shell”, URL:

The SSH service often has poor security defaults which may decrease the overall system security. An SSH proxy can be employed to enforce an organisation’s desirable security policy. The proxy will, for example, enforce the use of strong authentication methods, disallow port and X11

[8] Trusted Information Systems, URL: http://www.tis.com. [9] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, “SSH Protocol Architecture”, Internet Draft, Helsinki University of Technology, 9 January 2001.

http://www.ssh.org, 23 July 2000.

Appeared in Proceedings of the 2001 International Conference on Electrical, Electronics, Communication and Information CECI 2001, Jakarta, Indonesia, March 7-8, 2001, pp IT39–IT43 Indonesian Society on Electrical, Electronics, Communication and Information (IECI) – ISBN : 979-8575-02-4