Implementing SSH Strategies for Optimizing the Secure Shell phần 10 pot

Figure 10.7 Port-forwarding filters for VShell. Figure 10.8 Access Control setting on the file server’s VShell service. SSH Case Studies 341 Figure 10.9 SFTP settings on the file server’s VShell service. Next, set the SFTP options for the SFTP subsystem on the file server. The file server’s root-file directory is called Common and is located on a separate 500GB hard drive labeled X, which will be the partition (drive) for the SFTP root directory. Using VShell SFTP will limit all remote-access clients to that directory only and any subdirectories and/or files, as shown in Figure 10.9. The last order of business is to configure the other clients to use the estab- lished SSH connection for communication. While limited space does not allow each step to be described in detail (see Chapter 7 for more detailed steps), the basic idea is to use the loopback interface, 127.0.0.1, for each IP address of the desired server and port, as shown in Table 10.2. Table 10.2 Client Specifications SERVICE IP ADDRESS PORT Mail Relay 127.0.0.1 25 Mail Server 127.0.0.1 110 SFTP 127.0.0.1 22 Web (http://127.0.0.1) 127.0.0.1 80 342 Chapter 10 Results Checklist After the client setup has been completed, the requirements of case study # 1 will have all been met, as described in Table 10.3. Table 10.3 Business Requirements and Results BUSINESS REQUIREMENT RESULTS Must support strong level on The VShell SSH server has been encryption (Triple-DES or above) configured to use 3DES or above. Must be accessible from all types All SSH architecture can always work from of networks, including NAT”d NAT’d networks, including remote offices networks, remote offices, hotel rooms, and hotel rooms. VShell SSH server has behind internal proxy servers, and been configured to listen on port 443, organizations that only allow which makes it accessible to clients TCP port 80 and 443 outbound behind internal proxy servers and organizations that allow only TCP port 443 outbound. Must support two-factor authentication VShell has been configured to require a username/password and a public key for authentication, as shown in Figure 10.2. Must be able to provide easy access SecureCRT and VShell have been to e-mail and intranet servers from configured to allow port forwarding to internal networks, DMZ networks, and access e-mail and intranet servers. The extranets perimeter firewall allows communication from the SSH server to the appropriate server. Must be able to provide secure A separate VShell service has been file-sharing access installed on the file server, limited only for the SFTP subsystem and disabled for other utilities (remote access, port- forwarding, and remote execution). Must require a single action from The application option has been set on novice end-users for e-mail SecureCRT’s port-forwarding option, which automatically executes the mail client after the SSH session has been established. Must provide stable and consistent SSH always provides stable and performance consistent performance after implementation. SSH Case Studies 343 Case Study #2: Secure Wireless Connectivity The following case study examines an organization called Virtucon. Virtucon is a domestic corporation headquartered in Fremont, California. Virtucon is a think-tank organization that generates test questions for the Iowa standard- test program. Any leakage of test questions, whether they are notes, e-mails, chat messages, Web pages, or documents, would undermine the integrity of the Iowa test results. While most Virtucon employees work on the Virtucon campus, employees are often encouraged to work anywhere and anytime on the Virtucon grounds, whether it is in a conference room, a neighbor’s cube, or even outside on a box. The Problem Virtucon needs to provide secure wireless connectivity for all its internal users. All buildings on the Virtucon campus should be equipped with wireless (802.11) connectivity for all employees, including conference rooms, outdoor lunch areas, and internal cubes and offices. Business Requirements The following are the business requirements provided by Virtucon: ■■ Must support strong level on encryption (Triple-DES or above) and should not expose the internal corporate network to malicious activity ■■ Must provide complete access for two core-computing aspects of the organization, which are external Web access and internal e-mail ■■ External visitors, contractors/consultants, and war-drivers should be completely restricted from accessing the wireless network, even for external Web-access purposes ■■ Must require only a single action from novice end-users for e-mail and external Web access ■■ Must provide stable and consistent performance Secure wireless connectivity for internal employees is a must in many orga- nizations. Despite the overwhelming number of security exposures in 802.11 wireless networks, many organizations cannot afford to ignore wireless for much longer. This case study focuses on how to use SSH to secure wireless (802.11) networks. 344 Chapter 10 In order to implement secure wireless connectivity, you need some core requirements from the SSH servers and clients. For this case study, you will be using the flexibility of dynamic port forwarding (local SOCKS proxy), as described in Chapter 9, for the SSH clients. The ability to connect and port for- ward to the SSH servers, while restricting any type of access to the SSH server itself, will be required. With these two requirements for our SSH servers, the following highlights the utilities you will be using in order to satisfy Virtu- con’s business requirements: ■■ SSH Communications’ SSH server ■■ OpenSSH SSH client or SSH Communications’ SSH client ■■ Any SOCKS-enabled e-mail client and Web browser The key requirements from an architecture perspective will be the ability for the SSH server to access the core Internet connection for Virtucon and the abil- ity to access the e-mail servers. Since command-line access to the SSH server is not desired, command-line access will need to be restricted. Furthermore, since dynamic port forwarding will be used on the SSH clients (port forward- ing via SOCKS), you will need to ensure that all Web and e-mail clients have SOCKS support. Figure 10.10 shows the architecture to fulfill the requirements. All devices in Figure 10.10 are part of the existing architecture, except for SSH Communications’ SSH server off the perimeter firewall. Notice that the wireless-access point is not inside the internal network, but segments into another zone. This protects the corporate internal networks by creating a defense in-depth mode. If any compromise were to occur on the wireless net- work or on the SSH server connected to the wireless network, the internal cor- porate network would still be protected. The wireless-access points in this architecture are used as bridges to connect the wireless clients to the SSH server. With only the need for one additional item, the architecture for secure wireless access with SSH is quite simple. In addition to the architecture, the perimeter firewall in Figure 10.10 needs to be slightly modified. The firewall needs to allow the SSH server to access the mail-relay server and the internal e-mail server. The firewall needs to allow the SSH server access to the Internet, since the SSH clients will be using the SSH server to browse the Web. Table 10.4 shows the firewall rules that need to be deployed for the secure wireless solution. SSH Case Studies 345 Figure 10.10 SSH architecture for case study #2. Wireless ClientsWireless Clients E-mail SMTP Server (Relay) 192.168.1.100 E-mail POP3 Server 172.16.1.150 INTERNAL NETWORK Internet Firewall SSH Server 6.12.11.30 Wireless Access Point 346 Chapter 10 Table 10.4 Firewall Rules for Case Study #2 RULE SOURCE DESTINATION PORT ACTION COMMENT 1 SSH Server Internet 80,443 Allow Allow the SSH server to access the Internet, using port 80 and 443. 2 SSH server E-mail SMTP 25 Allow Allow the SSH server (Relay) server to access port 25 on the mail- relay server. 3 SSH server E-mail POP3 110 Allow Allow the SSH server server to access port 110 on the E-mail POP3 server. Rule 1 on the firewall is the most obvious; allow the SSH server to access the Internet. (Depending on which firewall you have deployed, make sure you do not allow the SSH server access to the entire network, specifically to the inter- nal network, but full outbound access to the Internet only). The next two rules are in place for port-forwarding reasons. Since the wireless SSH clients will be using the SSH server and port forwarding to access the e-mail, the SSH server will need to be allowed access to all of the other servers. Configuration Now that the architecture and firewall rules have been set up for SSH, the con- figuration options need to be examined. SSH Client Configuration OpenSSH and SSH Communications’ command-line SSH client can both be used in this situation, since they both support dynamic port forwarding. In order to enable dynamic port forwarding to forward e-mail and Web commu- nication via the SSH server, according to Figure 10.10, complete the following steps: SSH Case Studies 347 1. For OpenSSH, enter the following command: ssh 6.12.11.30 –p 22 –l <username> -D 1080 2. For SSH Communications’ SSH server, enter the following command: ssh2 6.12.11.30 –p 22 –l <username> -L socks/1080 3. On the SSH client, configure any relevant applications to use a SOCKS server for outbound connections. Enter the loopback address (127.0.0.1) for the IP address and port number 1080. Figures 10.11 and 10.12 show a sample SOCKS configuration of Internet Explorer and Netscape Mes- senger, respectively. NOTE Netscape Communicator, Mozilla, Eudora, Outlook, and Outlook Express also support SOCKS. To reach the SOCKS configuration screen on Internet Explorer, shown in Fig- ure 10.11, open Internet Explorer ➪ Tools ➪ Internet Options ➪ Connections ➪ LAN Settings. Make sure that Use Proxy Server is checked. Then select Advanced and enter the SOCKS information. Figure 10.12 shows SOCKS configuration on Netscape Messenger. To reach this SOCKS configuration screen for Netscape Messenger, shown in Figure 10.12, open Netscape Messenger ➪ Edit ➪ Properties ➪ Advanced ➪ Proxies ➪ Manual Proxy Configuration. Select View and enter SOCKS information. Figure 10.11 SOCKS configuration on Internet Explorer. 348 Chapter 10 Figure 10.12 SOCKS configuration on Netscape Messenger. All communication between the wireless SSH client to the SSH server, through the wireless-access point, is encrypted with SSH. This allows the flex- ibility of a local SOCKS server port (dynamic port forwarding) to be used with any applications that support SOCKS, while gaining the benefit of secure com- munications on any applications to and from the SSH server. In addition to setting up SOCKS for Web and e-mail clients, be sure to keep in mind that the basic idea is to use the loopback interface, 127.0.0.1, for the SOCKS address, shown in the preceding example, and to use the server’s real address for the regular client configurations. Table 10.5 shows the configura- tions for SSH clients according to Figure 10.10. Table 10.5 Mail and Web-Client Specifications SERVICE IP ADDRESS SOCKS IP ADDRESS: PORT Mail Relay 192.168.1.100 127.0.0.1:1080 Mail Server 172.16.1.150 127.0.0.1:1080 Web Any 127.0.0.1:1080 SSH Case Studies 349 To support the requirement that novice users have one-step access to e-mail and Web browsing, the two preceding SSH commands can be scripted quite easily into a Windows batch file or a Unix shell script. This will allow novice Windows users to double-click the batch file (.bat) and be prompted for a pass- word only for access. Similarly, novice Unix users will have to single-click or simply execute the shell script from the command line. To create the two scripts, copy and paste the preceding SSH syntax and paste it into a blank file. In Windows, save the file as ssh.bat; in Unix, save the file as ssh.sh. Then you are done. Once novice users execute that script, the SSH command will be exe- cuted, and the end-user will be prompted only for a password. SSH Server Configuration The next and last focus in this case study will be to configure the SSH server itself. Since dynamic port forwarding requires nothing from the SSH server in order to work, the only items to configure on the SSH server are to ensure that strong encryption is used, from the business requirements, and that terminal access to the SSH server is restricted. First, set the encryption settings for the SSH Communications’ SSH server. Under the SSH server’s encryption section, which is under the SSH Server Set- tings, ensure that 3DES or AnyStdCipher (any standard cipher) is selected. This will enforce the level of encryption the meets the business requirement previously stated, as shown in Figure 10.13. Figure 10.13 Encryption section for SSH Communications’ SSH server. 350 Chapter 10 [...]... clients; SSH Communications SecureCRT appearance, 106 , 108 authentication, 105 cipher algorithm, 105 connection configuration, 108 emulation, 108 field options, 105 file transfer, 108 firewalls, 106 107 Global Options, 106 107 host name, specifying, 105 log file, 109 log session, 109 – 110 port forwarding, local, 209–211 port forwarding, remote, 215–216 port, specifying, 105 printing, 107 , 109 protocols,... VShell SSH server, 147–149 SSH client keys with OpenSSH server, 140 SSH Communications’ SSH server, 139 VShell SSH server, 140–141 SSH Communications authentication types, 100 built-in SFTP client, 103 connecting to, 99 global settings, 101 102 log session, 103 104 profile settings, 100 101 SSH Communications client See command-line clients 371 372 Index SSH Communications’ SSH server See also SSH2 configuration... specifying, 105 public-key authentication, 109 Session Options, 108 109 SSH connection mechanism, 105 SSH1 , 107 SSH2 , 107 trace, 109 – 110 username, specifying, 105 Web Browser, 107 security issues, 14 overview, 5–7 Index server certificate configuration, 61–62 Server Compression Level option, 75 server key section option, 34 servers See also OpenSSH; SSH Communications’ SSH server; VShell SSH server... files, 96 SSH agents, 152–153 SSH client key pairs, uploading to OpenSSH server, 145–147 SSH client key pairs, uploading to SSH Communications’ SSH server, 144–145 SSH client key pairs, uploading to VShell SSH server, 147–149 SSH client keys with OpenSSH server, 140 SSH client keys with SSH Communications’ SSH server, 139 SSH client keys with VShell SSH server, 140–141 SSH Communications’ SSH server,... Because SSH can do so much and can do it all very well, the perfect name for it would be All-everything SSH can offer secure remote access; secure SOCKS; secure Telnet; secure RSH/Rlogin; secure backups; secure FTP; secure file transfer (SMB/NFS); secure authentication; secure management; secure wireless; secure e-mail; and secure Web browsing With so much to offer, there is no comparison between SSH and... 5–7 SSH host restrictions, 181–183 SSH PAM client, 47 SSH port forwarding See port forwarding SSH1 compatibility, 97 SSH1 option, 107 SSH2 , 15 See also installing SSH2 ; SSH Communications’ SSH server; sshd2_config file options SSH2 option, 107 Ssh1 Compatibility option, 50, 97 sshd_config file options AFSTokenPassing, 37 authentication, 34–35 AuthorizedKeysFile, 35 Banner, 38 Challengeresponseauthentication,... you aware of all the basics of these products Then the book turns to the details of how to optimize SSH Chapter 4 describes the authentication advances of SSH, such as username/password, public-key authentication, server-side authentication, and host-based authentication Chapter 4 shows how to implement the various authentication features of SSH, while making the process seemly for the end-user Chapter... After the OpenSSH server has been installed from the Windows file server, you will need to mount the D partition for all SSH clients on the Linux workstations To mount the D partition, complete the following steps: 1 Open the passwd file from c:\Program Files\OpenSSH\etc\ 2 Change the default directory for each user in the passwd file on the Windows file server Enter /cgydrive/d, as shown in the following... configuration files, OpenSSH See command-line clients, configuration file; sshd_config file options configuration files, SSH Communications’ SSH server See sshd2_config file options configuration files, VShell SSH server See VShell SSH server, configuration file configuring SSH See installing; optimizing SSH connection filters, 80–81, 179–181 Connection option, 108 customizing SSH See optimizing SSH cygdrive,... OpenSSH, 18 installing SSH2 , 23–24 OpenSSH See also command-line clients definition, 15 file sharing, 278–279 port forwarding, remote, 213 public-key authentication, 150–151 SFTP server, 277 sources for, 15 OpenSSH keys on OpenSSH servers, 135–136 SSH Communications’ SSH server, 136–137 VShell SSH server, 137–139 OpenSSH server configuration file See sshd_config file options port forwarding, 217 OpenSSH . access to the Internet, since the SSH clients will be using the SSH server to browse the Web. Table 10. 4 shows the firewall rules that need to be deployed for the secure wireless solution. SSH Case. connect the wireless clients to the SSH server. With only the need for one additional item, the architecture for secure wireless access with SSH is quite simple. In addition to the architecture, the. Figure 10. 7 Port-forwarding filters for VShell. Figure 10. 8 Access Control setting on the file server’s VShell service. SSH Case Studies 341 Figure 10. 9 SFTP settings on the file server’s VShell