Configuring the System for Security

By default, Nokia takes a secure approach to network access by disabling most services. However, a couple insecure services such as Telnet and HTTP are enabled for functional purposes to help you get started. This section walks you through the configuration of Secure Shell (SSH) and disabling Telnet as well as changing from clear-text HTTP to SSL-encrypted Voyager access.

SSH is an encrypted Telnet provided in IPSO 3.4 and later as part of the operating system, so you aren't required to install any additional packages to use it, as in earlier versions. Nokia's implementation of SSH is OpenSSH version 2.1.1. All you need to do in order to get started with SSH is enable the server daemon, and then you are on your way to a more secure system. You need an SSH client to establish a connection to the Nokia to use it; several such clients are freely available for download. Some of the most common clients are Putty, TTSSH, OpenSSH, SecureCRT, and F-Secure. For a comprehensive list of both free and commercial clients for various operating systems, visit www.freessh.org.

Enabling SSH Access

Configuring SSH is a quick and easy three-step process:

1. To configure SSH access, go to the main Configuration page and click Secure Shell (SSH) under the Security and Access Configuration heading.

2. Click Yes to enable the SSH daemon.

3. Finally, click Apply | Save.

As shown in Figure 19.20, the default options on this screen are safe to accept. If you want to tighten access further, it is recommended that you do it in stages. Perhaps after you know that the default configuration works, you might want to disable admin login and set up a new user who can log in and su to the admin account.

Figure 19.20: The Main SSH Configuration Screen

SSH Versions 1 and 2

You have the option of allowing SSH versions 1, 2, or both in the configuration settings. SSHv2 is generally believed to be more secure than v1 and should be your first choice. See Figure 19.21 for additional options.

Figure 19.21: Additional SSH Options

Be aware that if you check 1 only under Configure Server Protocol Details, you will enable version 1 clients to connect to your firewall, but not version 2 clients, which are newer and becoming more common. The default setting is to allow both versions 1 and 2 SSH clients to connect so that you don't have to worry about which client you are using. A useful trick with newer (version 2-capable) clients is to specify -1 on the SSH command line when connecting to an unknown host that seems to be rejecting your connection attempts. This forces the client to downgrade itself to version 1, perhaps allowing the connection. Similarly, -2 forces the client to use protocol version 2. For the cautious, choose to allow only version 2, because it is considered to be more secure and the common free SSH clients now support protocol version 2.

Host Keys

A public/private host key pair is generated the first time you set up SSH and is displayed on this screen after you enable the SSH daemon. The host key is used to identify the host to the client during the connection. On the first connection attempt, the client receives the host's key and is asked whether to accept the key and save it or to reject it. SSH clients maintain a list of all known hosts in a file on the local system. If on a subsequent connection attempt the host key does not match the key obtained originally, the client will be warned that a possible man-in-the-middle attack could be occurring, giving them the option to terminate the connection and verify the new key. By default, the host key on IPSO is set to 1,024 bits.

Authorized Keys

You can configure SSH to be more or less secure by choosing from a few different types of authentication schemes. Probably the most secure method is the use of RSA and/or DSA (SSHv2 only) authentication. This method uses the public key infrastructure (PKI) to verify the user's authenticity. In order for this system to work, you must generate a unique public/private key pair and configure the client with this information. Then, you publish the public key to the Nokia by entering it into the SSH Configuration page within Voyager. This information is stored in the $HOME/.ssh/authorized_keys file on the system. Only the user with the associated private key (and the passphrase to unlock that private key) will be able to log in. Using authorized keys provides the ultimate security between client and server.

In order to configure authorized keys in Voyager, first log in to Voyager and click Config, then follow this procedure:

1. Click SSH (Secure Shell) under the Security and Access Configuration heading on the main Configuration screen.

2. Ensure that the SSH daemon is already enabled, and then scroll down to the bottom of the page, and click the link to Go to the authorized keys page.

3. From here, you can enter the client's RSA public key for version 1, which would be obtained from the SSH client, typically in a file called identity.pub. You can also enter the DSA key in OpenSSH format (typically in a file called id_dsa.pub on the ssh client) or in SSHv2 format (the key file could look something like id_KEYTYPE_KEYLEN_X.pub.

Starting the Daemon

Once you enable SSH in the Voyager configuration, the daemon is started automatically. You can verify whether the daemon is running or not by logging into the system locally and typing ps –auxw | grep ssh. If the daemon is running, you will see output similar to the following:

gatekeeper[admin]# ps -auxw | grep ssh root       669  0.0  1.1   276  652  d0  S+    6:09PM    0:00.02 grep ssh root       650  0.0  2.5   404 1476  ??  Is    6:06PM    0:00.62 /usr/sbin/     sshd-x –D

If you try to kill the sshd process, the process monitor (pm) restarts sshd automatically. Available sshd options are listed in Table 19.1.

Table 19.1: SSHD Server Options

Switch	Option	Description
-f	Filename	Define the server configuration file. The default file is /var/etc/sshd_config.
-d	N/A	Turn on debugging.
-i	N/A	Run the server from inetd.
-q	N/A	Run in quiet mode, no logging.
-p	Port #	TCP port the server will listen on. The default port is 22.
-k	Number of seconds	How often to regenerate the server key. The default time interval is 3,600 seconds.
-g	Number of seconds	Authentication grace period. The default is 300 seconds.
-b	Bits	RSA key size. The default RSA server key is 768 bits.
-h	Filename	The file where the SSH host key is stored. The default file is /var/etc/ssh_host_key.
-4	N/A	Use IPv4 only.
-6	N/A	Use IPv6 only.
-D	N/A	Don't fork and detach on startup.

Disabling Telnet Access

If you followed the procedure to enable SSH access, and you have an SSH client installed and tested on your workstation, you should go back into Voyager and disable Telnet access. You will no longer need Telnet as long as you have SSH to access the system. Since you won't be using it, it is not wise to leave it open on the system as one more method for an attacker to attempt to gain access to the box. Figure 19.22 illustrates the default values of the network access services in IPSO 3.6.

Figure 19.22: Default Network Access Settings

To disable Telnet through Voyager, click the Network Access and Services link on the main Configuration screen under the heading Security and Access Configuration. From there, click the radio button for No in the table directly across from "Allow TELNET access." Finally, click Apply | Save to disable Telnet and commit the changes.

An Alternative to FTP

By default, FTP is disabled in your Nokia, as you saw in Figure 19.22, and the majority of boxes out there will not need this service running. Therefore, it would be prudent to leave FTP disabled within Voyager, and you can enable it only when necessary. FTP has been known to have several security vulnerabilities and transfers all data, including usernames and passwords in the clear. If you need to transfer files to or from your system, use Secure Copy (SCP) instead. This tool allows you to perform encrypted file transfers to or from your NSP (if you have SSH enabled), which is much more secure than the standard FTP protocol.

The only time that you might need to enable FTP on a Nokia is when you are performing remote file transfers of packages or IPSO images during system maintenance and you happen to have those packages on a local Nokia system already. You can use FTP on your local Nokia to retrieve the packages or images from all the other systems on your network when you use the automated tools within Voyager. Through the Voyager GUI, FTP and HTTP are your only options. This might be fine if your box is local and protected by a firewall, but you might want to simply SCP the files to each Nokia manually before you begin maintenance on them. For example, if you want to get the ipso.tgz file onto your Nokia using SCP, you could use a command like the one that follows:

gatekeeper[admin]# scp admin@192.168.200.8:ipso.tgz . admin@192.168.200.8's password:  ipso.tgz        100% |*****************************|    

Securing FTP

If you still want to use FTP on your Nokia, we can give you a couple of recommendations for making the use of this protocol more secure. First, you can require S/Key one-time passwords in IPSO 3.5 or later for Telnet and FTP authentication. You can also restrict FTP to local networks only by use of access lists or via your firewall policy. By implementing both of these actions together, you can use FTP in a secure fashion.

To configure the S/Key passwords, you first need to obtain a one-time password (OTP) generator. Most UNIX systems come with a generator on the command line called key, this is also available on IPSO. If this tool is not available to you, you need to find one to download. A Windows client called winkey32.exe, is available from Nokia Support in Resolution #1255. S/Key did not function properly in IPSO versions prior to 3.5, so if you want to use S/Key authentication, you first need to update IPSO to 3.5 or later. Select S/Key passwords as follows:

1. Log in to Voyager and click Config.

2. Select the link Users under the Security and Access Configuration heading.

3. Scroll down to the bottom. There you will see a section on configuring S/Key for each user. Select either Allowed or Required for each user. The default setting here is for S/Key to be disabled.

4. Click Apply.

5. Three new boxes will appear. Enter the current user password in the first box, and enter an S/Key secret password in the next two boxes that is between four and eight alphanumeric characters long (see Figure 19.23).

   
   Figure 19.23: S/Key Configuration

6. Click Apply. The sequence number (starting at 99 and decreasing each time S/Key is used) and the seed will be displayed. This information will also be displayed when you attempt to log in to the system. You will use this information as input to the S/Key OTP generator along with the original password you supplied to the system in order to begin using the S/Key authentication method.

7. Click Save.

Configuring Secure Socket Layer

Secure Socket Layer (SSL) allows you to view the Voyager Web interface through an encrypted tunnel. You can then use HTTPS instead of plain-text HTTP in the location window of your Web browser. Just as with ssh/scp, utilizing encryption for your connections to Voyager adds an extra layer of security to your session.

Creating the Self-Signed Certificate

The first step in configuring SSL is to create an SSL certificate for the Web server to use for authenticity. You can choose to generate a certificate request to send to a trusted third-party certificate authority (CA) for them to sign, which will cost you some money, or you can sign your own certificate, assuming that you trust yourself, and forgo the extra fee. We recommend generating a self-signed certificate through the Voyager interface. It is just as secure to use a self-signed certificate. The only difference is that your Web browser will ask you to verify that you want to accept the certificate that is not signed by a known CA. There is no difference in the quality of the encrypted connection, and you can begin using your certificate right away if you do it yourself.

To set up SSL in Voyager, follow this procedure:

1. Log in to Voyager and select Config.

2. Under the Security and Access Configuration heading, click SSL Certificate Tool.

3. The SSL Certificate Tool (Request) screen will be displayed (Figure 19.24). Select the private key size you want to use (the default of 1024 bits is recommended), and enter the passphrase that you will use to protect your private key. You need to enter this same passphrase on a later screen, so don't forget it.

   
   Figure 19.24: The SSL Certificate Tool

4. Next you need to configure the distinguished name (DN) that identifies this certificate as unique and belonging to this machine. The values that are required are in bold, and they are Country Name (2-letter code), State or Providence Name, Organization Name, and Common Name (FQDN). Finally, you must specify whether you want to create a self-signed X.509 certificate or generate a signing request. Select A self-signed X.509 certificate (see Figure 19.25).

   
   Figure 19.25: The SSL Certificate Tool, Continued

5. Click Apply, and the new X.509 certificate, private key, and fingerprint will be displayed.

6. Next, scroll down and click the Voyager SSL Certificate link at the bottom of the result page. This choice brings you to a new window where you need to cut and paste the certificate and private key from the result page. You might want to open this page in a separate window to complete the next step.

7. Copy the new X.509 certificate into the Voyager SSL Certificate screen, including the entire BEGIN and END line. This information should go in the first big text input area labeled New Server Certificate.

8. Now copy the new private key, including the entire BEGIN and END line, into the next text area labeled Associated private key.

9. Enter the passphrase that you used in Step 3.

10. Click Apply | Save.

11. Click Up. This displays the Voyager Web Access screen, which is discussed next (see Figure 19.26).

    
    Figure 19.26: Enabling HTTPS

Enabling HTTPS for Voyager

Now that you have generated a self-signed certificate, as discussed in the previous section, you can enable encryption for secure Voyager access and configuration. If you are following along from the SSL configuration, you should already be at the screen displayed in Figure 19.26. If you are starting here, you can also get to this screen by clicking the Voyager Web Access link under the Security and Access Configuration heading on the main Configuration screen.

Note

When you enable SSL/HTTPS in the configuration for Voyager Web Access, you disable the unencrypted HTTP access that you had up to that point. If you cannot connect via HTTPS for some reason and you need to get remote Voyager access, you have these options to reset Voyager from the console or remote command line:

1. Restart Voyager with no encryption listening on port 80 with the voyager -e 0 80 command.

2. Run clish and set the encryption level back to 0 on Voyager with the following options: Nokia> set voyager ssl-level 0

3. Run lynx to configure the system with a text-based Voyager interface locally, set the encryption level to none, and Apply the change.

To set up secure Voyager Access via SSL, enable it as follows:

1. Change the SSL port number to a value greater than 1024. The default port is 443, but since this is a well-known port for HTTPS connections, it would be wise to pick another port that is not as common.2. Next, select the minimum grade of encryption that you want to allow. By default, SSL is disabled and no encryption is required. Select Require Triple-DES, which gives you up to a 168-bit key if you have a Web browser that can support a key that size.

3. Click Apply.

4. If you try to click Save now, your connection will be refused. You must reconnect to Voyager using HTTPS and the port you choose for the connection—for example: https://192.168.168.100:8443/cgi-bin/httpd.tcl.

5. You will now be prompted to accept the self-signed certificate, which you generated previously. Choose to remember the certificate permanently and click Continue(see Figure 19.27).

   
   Figure 19.27: Accepting the Certificate

6. If you receive a domain name mismatch error next because you are connecting to an IP address but the certificate was generated with an FQDN, click OK to continue.

7. Enter your authentication information again to access Voyager.

8. Click Save.