Tweet

What Secure Shell? Implementing and Optimizing SSH.  Secure Shell (SSH) is a program used to secure communication between two entities. SSH uses a client/server architecture, where SSH clients, available on all versions of Windows, different flavors of Unix, and various Macintosh operating systems, connect to SSH servers, which can be operating systems such as Sun Solaris or Microsoft Windows or devices such as a Cisco router. In its simplest sense, SSH is used to execute remote commands securely on another entity, often used as a replacement for Telnet and the Berkeley “R” protocols such as remote shell (RSH) and remote login (Rlogin), discussed further in Chapter 8. In addition to executing remote commands, SSH is used as a secure remote copy utility, replacing traditional protocols such as the File Transfer Protocol (FTP) and Remote Copy Protocol (RCP).  Despite the name  Secure Shell, SSH is not a shell at all. Unlike other traditional shells found in different flavors of Unix, such as BASH, KORN, and C, SSH provides encryption between entities, not a shell interface between entities. The encryption methods and algorithms used for SSH are all based on industry standards such as 3DES, Blowfish, Twofish, and  AES. The paragraphs that follow discuss the basics of SSH: how it works, what it can be used for, and why it is tremendously flexible. This chapter is useful for readers who do not have experience with SSH or who have never been introduced to it aside from a casual reference.  Advanced users may want to skip to the next chapter. Specifically, this chapter discusses the following topics. Differences between SSH1 and SSH2 SSH version 1 (SSH1) was the first iteration of SSH; however, SSH1 had several limitations, including the use of port forwarding, which led to the second iteration of SSH: SSH version 2 (SSH2). In addition to its limitations, SSH1 had several security issues associated with its cryptography, which also led to the establishment of SSH2. The differences between SSH1 and SSH2 may seem minor to most endusers; however, the differences are quite significant. SSH1 and SSH2 are two different protocols. SSH2 was completely rewritten from scratch, giving it more security, performance, and flexibility than SSH1.  Also, SSH1 and SSH2 encrypt communication differently, which mitigated several of the documented issues with SSH1’s encryption methods. SSH1 is not being developed now, whereas SSH2 is becoming the standard when referring to SSH. There are still many implementations of SSH1, but the implementations are becoming fewer and more in favor of SSH2. For the purposes of this book, I do not refer to, use, or demonstrate the use of SSH1. I concentrate solely on the usage and optimization of SSH2.                 Various Uses of SSH. SSH can be used in a variety of ways, depending on your network environment and business requirements. The flexibility that SSH provides in any type of dynamic or static environment gives it a significant advantage over other utilities in the industry, both security-focused utilities, such as IPSEC, and nonsecurity-focused utilities, such as FTP. SSH can be used for multiple users with just a single process (daemon) or service running on the server, with most of the configuration required on the client side.  1.Security  2.Remote command execution   3.Remote file transfer  4. Remote network access   5.Secure management  6.Proxy services                              Security The implementation of SSH in a trusted or nontrusted environment can protect against many of the security issues with Internet Protocol version 4 (IPv4). IPv4 has been plagued with security issues ranging from poor initial sequence numbers (ISN) in TCP header packets, which leads to session hijacking, to unauthenticated address resolution packets (ARPs) being distributed to the network. The use of SSH not only protects against the common LAN attacks described previously; it guards against the following types of attacks as well. Spoofing of IP addresses. Aremote device, usually an operating system, can change its IP address and pretend to be a different source, usually a trusted source.  Data modification. As data is passed through corporate networks and the Internet, any intermediary can modify the data while it is in transit.  ARP pollution. This occurs when incorrect  ARP packets to redirect and capture sensitive data are distributed.  Session hijacking. This occurs when individuals guess or predict the ISN in TCP headers, gaining control of Telnet and RSH sessions.  Clear-text data. This occurs when critical or sensitive clear-text data, such as usernames, passwords, and commands, is intercepted. The preceding list is not exhaustive, as SSH can protect against many other attacks, which may be direct or indirect.  Another reason SSH is so popular is its ability to protect against network sniffing on both Local  Area Networks (LANs) and Wide  Area Networks (WANs). That feature allows network administrators and server administrators to manage and connect to remote systems without the risk of losing sensitive information to unauthorized users. Remote Command Line Execution SSH offers the ability to execute commands on a remote entity, which can be an operating system or a network device. In the Unix world, SSH gives the remote user the shell listed in the passwd file of the /etc directory; however, the communication is still encrypted over the wire. For example, based on the following Unix passwd file:account is nologin, despite making a valid SSH connection. The SSH daemon running on the Unix server would query the information from the passwd file in order to process usernames for authentication. SSH does not use its own username and passwords for authentication; it uses the operating system’s username and password information, which makes the process a lot easier to use. The result would be that valid accounts with an appropriate shell in the passwd file would be authenticated and given the correct shell, while being encrypted with SSH. The process works a bit differently in the Windows world, but the result is still the same. Since Windows does not have different shell options, all SSH users would be given a command prompt (cmd.exe) or some form of the command prompt itself. Similar to the Unix world, SSH services in Windows use the existing password database (the SAM or ntds.dit files) for authentication.  Remote File Transfer Remote file transfer is similar to remote command line execution. SSH offers the ability to retrieve and send files to and from a remote entity. Remote file transfer actually comes in two forms in the Unix world. SSH offers Secure Copy Protocol (SCP) in some installations of SSH1 and SSH2, or Secure File Transfer Protocol (SFTP), in most installations of SSH2. In the Windows world, only SFTPexists. Both SCP and SFTP provide similar, if not the same, function, which is to put and get files from a remote entity in a secure fashion. SFTP uses the existing SSH daemon on Unix and the existing SSH service on Windows. There is no extra step required to enable secure file transfer; it is automatically enabled on most versions of SSH2. Many SSH clients also come packaged with SCP or SFTP clients; therefore, the use and execution of the additional functionality is very straightforward.  Remote Network Access  In addition to providing remote command line and remote file transfer utilities, SSH can provide access to remote networks, creating something similar to a virtual private network (VPN). SSH can not only provide VPN functionally in the typical sense of the word (PPP over SSH), but can also provide services that many VPN users require, such as e-mail, file transfer, and Intranet services with port forwarding.  Also, using SSH as a VPN solution is far less expensive than using a typical VPN solution. When considering any SOHO VPN appliance, a VPN card in a current network device, or any full-scale VPN server/ device, the cost of any such device is not any different from the cost of most other network devices, but far exceeds the cost of SSH server implementations. SSH as a VPN solution not only provides access to services such as e-mail, internal file servers, and Intranet services, but with the use of advanced tunneling, it provides access to X11 services, remote applications, and remote tunneling.  Secure Management Many networks today adhere to poor management practices, leaving their critical systems and devices vulnerable to management attacks. Many environments secure network devices and operating systems and create a properly segmented network perimeter, but then they connect to sensitive systems/ devices with poor management protocols over wide-open or nonexistent management networks. The clear-text protocols mentioned earlier, such as Telnet, FTP, and SNMP, are not the only poor management protocols in question, but many management applications have not secured their communication appropriately or have known issues identified with them. Older versions of certain management applications such as pcAnywhere, Virtual Network Computer (VNC), and Citrix have either had poor encrypted management protocols, which were reversed through engineering, or do not require any type ofencrypted management for the sensitive communication. Furthermore, any attacker can download the client version of these applications and attempt to connect to the application’s agent with a captured or guessed username and password. This assumes that there is no separate management network that the attacker cannot access, which prevents him or her from connecting to any agents. While separate management networks are ideal for safe and secure management, implementation of out-of-band management networks is not only very costly but adds a significant amount of complexity to a network. SSH can be used as a secure management alternative by providing encrypted communication for any type of system or device management. Not only does SSH provide secure communication for remote command line management, which is the most popular management method on most Unix systems; it provides secure communication of graphic user interfaces (GUIs) with less secure applications such as VNC. In addition, SSH can provide two-factor authentication for all management methods by requiring a public key and password for management access.  As best practice, two-factor authentication should be used for all management methods, as it reduces the number of brute-force attacks, password-guessing attacks, and dependencies on passwords for security. SSH can enforce two-factor authentication quite easily, which supports a critical best practice in management security. Lastly, SSH can eliminate the need for an out-of-band management network, removing a significant amount of cost and adding administrative simplicity in managing the systems and devices.

 What Secure Shell? Implementing and Optimizing SSH. 

Secure Shell (SSH) is a program used to secure communication between two entities. SSH uses a client/server architecture, where SSH clients, available on all versions of Windows, different flavors of Unix, and various Macintosh operating systems, connect to SSH servers, which can be operating systems such as Sun Solaris or Microsoft Windows or devices such as a Cisco router. In its simplest sense, SSH is used to execute remote commands securely on another entity, often used as a replacement for Telnet and the Berkeley “R” protocols such as remote shell (RSH) and remote login (Rlogin), discussed further in Chapter 8. In addition to executing remote commands, SSH is used as a secure remote copy utility, replacing traditional protocols such as the File Transfer Protocol (FTP) and Remote Copy Protocol (RCP). 

Despite the name  Secure Shell, SSH is not a shell at all. Unlike other traditional shells found in different flavors of Unix, such as BASH, KORN, and C, SSH provides encryption between entities, not a shell interface between entities. The encryption methods and algorithms used for SSH are all based on industry standards such as 3DES, Blowfish, Twofish, and  AES. The paragraphs that follow discuss the basics of SSH: how it works, what it can be used for, and why it is tremendously flexible. This chapter is useful for readers who do not have experience with SSH or who have never been introduced to it aside from a casual reference.  Advanced users may want to skip to the next chapter. Specifically, this chapter discusses the following topics.

Differences between SSH1 and SSH2

SSH version 1 (SSH1) was the first iteration of SSH; however, SSH1 had several limitations, including the use of port forwarding, which led to the second iteration of SSH: SSH version 2 (SSH2). In addition to its limitations, SSH1 had several security issues associated with its cryptography, which also led to the establishment of SSH2. The differences between SSH1 and SSH2 may seem minor to most endusers; however, the differences are quite significant. SSH1 and SSH2 are two different protocols. SSH2 was completely rewritten from scratch, giving it more security, performance, and flexibility than SSH1.  Also, SSH1 and SSH2 encrypt communication differently, which mitigated several of the documented issues with SSH1’s encryption methods. SSH1 is not being developed now, whereas SSH2 is becoming the standard when referring to SSH. There are still many implementations of SSH1, but the implementations are becoming fewer and more in favor of SSH2. For the purposes of this book, I do not refer to, use, or demonstrate the use of SSH1. I concentrate solely on the usage and optimization of SSH2. 

               Various Uses of SSH.

SSH can be used in a variety of ways, depending on your network environment and business requirements. The flexibility that SSH provides in any type of dynamic or static environment gives it a significant advantage over other utilities in the industry, both security-focused utilities, such as IPSEC, and nonsecurity-focused utilities, such as FTP. SSH can be used for multiple users with just a single process (daemon) or service running on the server, with most of the configuration required on the client side. 

1.Security 

2.Remote command execution 

 3.Remote file transfer

 4. Remote network access 

 5.Secure management

 6.Proxy services

                             Security

The implementation of SSH in a trusted or nontrusted environment can protect against many of the security issues with Internet Protocol version 4 (IPv4). IPv4 has been plagued with security issues ranging from poor initial sequence numbers (ISN) in TCP header packets, which leads to session hijacking, to unauthenticated address resolution packets (ARPs) being distributed to the network. The use of SSH not only protects against the common LAN attacks described previously; it guards against the following types of attacks as well.

Spoofing of IP addresses. Aremote device, usually an operating system, can change its IP address and pretend to be a different source, usually a trusted source. 

Data modification. As data is passed through corporate networks and the Internet, any intermediary can modify the data while it is in transit. 

ARP pollution. This occurs when incorrect  ARP packets to redirect and capture sensitive data are distributed.

 Session hijacking. This occurs when individuals guess or predict the ISN in TCP headers, gaining control of Telnet and RSH sessions. 

Clear-text data. This occurs when critical or sensitive clear-text data, such as usernames, passwords, and commands, is intercepted.

The preceding list is not exhaustive, as SSH can protect against many other attacks, which may be direct or indirect.  Another reason SSH is so popular is its ability to protect against network sniffing on both Local  Area Networks (LANs) and Wide  Area Networks (WANs). That feature allows network administrators and server administrators to manage and connect to remote systems without the risk of losing sensitive information to unauthorized users.

Remote Command Line Execution

SSH offers the ability to execute commands on a remote entity, which can be an operating system or a network device. In the Unix world, SSH gives the remote user the shell listed in the passwd file of the /etc directory; however, the communication is still encrypted over the wire. For example, based on the following Unix passwd file:account is nologin, despite making a valid SSH connection. The SSH daemon running on the Unix server would query the information from the passwd file in order to process usernames for authentication. SSH does not use its own username and passwords for authentication; it uses the operating system’s username and password information, which makes the process a lot easier to use. The result would be that valid accounts with an appropriate shell in the passwd file would be authenticated and given the correct shell, while being encrypted with SSH. The process works a bit differently in the Windows world, but the result is still the same. Since Windows does not have different shell options, all SSH users would be given a command prompt (cmd.exe) or some form of the command prompt itself. Similar to the Unix world, SSH services in Windows use the existing password database (the SAM or ntds.dit files) for authentication. 

Remote File Transfer

Remote file transfer is similar to remote command line execution. SSH offers the ability to retrieve and send files to and from a remote entity. Remote file transfer actually comes in two forms in the Unix world. SSH offers Secure Copy Protocol (SCP) in some installations of SSH1 and SSH2, or Secure File Transfer Protocol (SFTP), in most installations of SSH2. In the Windows world, only SFTPexists. Both SCP and SFTP provide similar, if not the same, function, which is to put and get files from a remote entity in a secure fashion. SFTP uses the existing SSH daemon on Unix and the existing SSH service on Windows. There is no extra step required to enable secure file transfer; it is automatically enabled on most versions of SSH2. Many SSH clients also come packaged with SCP or SFTP clients; therefore, the use and execution of the additional functionality is very straightforward. 

Remote Network Access 

In addition to providing remote command line and remote file transfer utilities, SSH can provide access to remote networks, creating something similar to a virtual private network (VPN). SSH can not only provide VPN functionally in the typical sense of the word (PPP over SSH), but can also provide services that many VPN users require, such as e-mail, file transfer, and Intranet services with port forwarding.  Also, using SSH as a VPN solution is far less expensive than using a typical VPN solution. When considering any SOHO VPN appliance, a VPN card in a current network device, or any full-scale VPN server/ device, the cost of any such device is not any different from the cost of most other network devices, but far exceeds the cost of SSH server implementations. SSH as a VPN solution not only provides access to services such as e-mail, internal file servers, and Intranet services, but with the use of advanced tunneling, it provides access to X11 services, remote applications, and remote tunneling. 

Secure Management

Many networks today adhere to poor management practices, leaving their critical systems and devices vulnerable to management attacks. Many environments secure network devices and operating systems and create a properly segmented network perimeter, but then they connect to sensitive systems/ devices with poor management protocols over wide-open or nonexistent management networks. The clear-text protocols mentioned earlier, such as Telnet, FTP, and SNMP, are not the only poor management protocols in question, but many management applications have not secured their communication appropriately or have known issues identified with them. Older versions of certain management applications such as pcAnywhere, Virtual Network Computer (VNC), and Citrix have either had poor encrypted management protocols, which were reversed through engineering, or do not require any type ofencrypted management for the sensitive communication. Furthermore, any attacker can download the client version of these applications and attempt to connect to the application’s agent with a captured or guessed username and password. This assumes that there is no separate management network that the attacker cannot access, which prevents him or her from connecting to any agents. While separate management networks are ideal for safe and secure management, implementation of out-of-band management networks is not only very costly but adds a significant amount of complexity to a network. SSH can be used as a secure management alternative by providing encrypted communication for any type of system or device management. Not only does SSH provide secure communication for remote command line management, which is the most popular management method on most Unix systems; it provides secure communication of graphic user interfaces (GUIs) with less secure applications such as VNC. In addition, SSH can provide two-factor authentication for all management methods by requiring a public key and password for management access.  As best practice, two-factor authentication should be used for all management methods, as it reduces the number of brute-force attacks, password-guessing attacks, and dependencies on passwords for security. SSH can enforce two-factor authentication quite easily, which supports a critical best practice in management security. Lastly, SSH can eliminate the need for an out-of-band management network, removing a significant amount of cost and adding administrative simplicity in managing the systems and devices.