Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide

Other Security Considerations

Other security risks exist beyond someone trying to break your encryption. Networks face risks from external and internal hackers, using a variety of tactics to gain access to your server and the information on it. In addition to enabling encryption on your server, you should take extra security precautions. For example, put the server computer in a secure room, and do not allow individuals you do not trust to upload programs to your server. This section describes some of the key things you can do to make your server more secure.

This section contains the following topics:

Limiting Physical Access

This simple security measure is often forgotten. Keep the server computer in a locked room that only authorized people can enter. This policy prevents anyone from hacking the server computer itself. Also, protect your computer’s administrative (root) password, if you have one.

Limiting Administration Access

If you use remote configuration, be sure to set access control to allow administration from only a few users and computers. If you want your Administration Server to provide end-user access to the LDAP server or local directory information, consider maintaining two Administration Servers and using cluster management. The SSL-enabled Administration Server then acts as the master server, and the other Administration Server is available for end-users’ access. For more information about clusters, see Chapter 6, Managing Server Clusters.

You should also turn encryption on for the Administration Server. If you do not use an SSL connection for administration, be cautious when performing remote server administration over an unsecure network. Anyone could intercept your administrative password and reconfigure your servers.

Choosing Strong Passwords

You use a number of passwords with your server: the administrative password, the private key password, database passwords, and so on. Your administrative password is the most important password, because anyone with that password can configure any and all servers on your computer. Your private key password is the next most important. Anyone who has your private key and your private key password, can create a fake server that appears to be yours, or intercept and change communications to and from your server.

A good password is one you will remember but others will not guess. For example, you could remember MCi12!mo as “My Child is 12 months old!” An example of a bad password is your child’s name or birthday.

Creating Hard-to-Crack Passwords

Use these guidelines to create a stronger password. You do not have to incorporate all of the following rules in one password, but the more rules you use, the better your chances of making your password hard to guess. Some tips:

Changing Passwords or PINs

Change your trust database/key-pair file password or PIN periodically. If your Administration Server is SSL-enabled, this password is required when starting the server. Changing your password periodically adds an extra level of server protection.

You should only change this password on your local computer. For a list of guidelines to consider when changing a password, see Creating Hard-to-Crack Passwords.

ProcedureTo Change the Trust Database/Key-Pair File Password

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Change Key Pair File Password link.

  3. From the Cryptographic Module drop-down list, select the security token on which you want to change the password.

    By default, this token is Internal for the internal key database. If PKCS #11 modules are installed, all of the security tokens will be listed.

  4. Type your current password.

  5. Type your new password.

  6. Type the new password again and click OK.

    Make sure your key-pair file is protected. The Administration Server stores key-pair files in the directory server-root/alias.

    Know whether the file is stored on backup tapes or otherwise available for someone to intercept. If so, you must protect your backups as completely as your server.

Limiting Other Applications on the Server

Carefully consider all applications that run on the same computer as the server. Someone could circumvent your server’s security by exploiting holes in other programs running on your server. Disable all unnecessary programs and services. For example, the UNIX sendmail daemon is difficult to configure securely and can be programmed to run other, possibly detrimental, programs on the server computer.

UNIX and Linux

Carefully choose the processes started from inittab and rc scripts. Do not run telnet or rlogin from the server computer. You also should not have rdist on the server computer. This can distribute files but can also be used to update files on the server computer.

Windows

Carefully consider which drives and directories you share with other computers. Also, consider which users have accounts or guest privileges. Be careful about what programs you put on your server, or allow others to install. Other people’s programs might have security holes. Even worse, someone might upload a malicious program designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.

Preventing Clients From Caching SSL Files

You can prevent pre-encrypted files from being cached by a client by adding the following line inside the <HEAD> section of an HTML file:

<meta http-equiv="pragma" content="no-cache">

Limiting Ports

Disable any ports not used on the computer. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. This protection means that the only way to get a shell on the computer is to physically use the server’s computer, which should already be in a restricted area.

Knowing Your Server’s Limits

The server offers secure connections between the server and the client. It cannot control the security of information once the client has it, nor can it control access to the server computer itself and its directories and files.

Being aware of these limitations helps you understand what situations to avoid. For example, you might acquire credit card numbers over an SSL connection, but are those numbers stored in a secure file on the server computer? What happens to those numbers after the SSL connection is terminated? Be sure to secure any information clients send to you through SSL.