test

Sun Java System Web Server 6.1 SP12 Administrator's Guide

Considering Additional Security Issues

There are other security risks in addition to someone trying to break your encryption. Networks face risks from external and internal hackers, using a various tactics to gain access to your server and the information on it.

In addition to enabling encryption on your server, take extra security precautions. For example, put the server machine into a secure room, and do not allow unauthorized individuals to upload programs to your server.

The following sections describe some important tasks you can perform to make your server more secure:

Limit Physical Access

Keep the server machine in a locked room that only authorized people can access. This step prevents the possibility of hacking the server machine.

Protect your machine’s administrative (root) password.

Limit Administration Access

If you use remote configuration, set access control to allow administration from trusted 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, so that the SSL-enabled Administration Server acts as the master server, and the other Administration Server is available for end-users’ access.

For more information regarding clusters, see About Clusters.

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

Choosing Solid Passwords

You use many passwords with your servers the administrative password, the private key password and database passwords. Your administrative password is the most important passwords since anyone with that password can configure the servers on your computer. Your private key password is also important. If someone obtains your private key and your private key password, they can create a unauthorized server that appears to be yours, or intercept and change communications to and from your server.

A good password is one you can remember but others cannot guess. For example, you could remember MCi12!mo as “My Child is 12 months old!” A bad password is your child’s name or birthdate.

Creating Hard-to-Crack Passwords

You can follow guidelines to create a secure password.

It is not necessary to incorporate all of the following rules in one password the more rules you use, the better your chances are of making your password more secure:

Changing Passwords or PINs

It’s a good practice to change your trust database and key pair file password or PIN periodically. If your Administration Server is SSL enabled, the password is required when starting the server. Changing your password periodically adds an extra level of server protection.

Change this password only from your local machine. For a list of guidelines follow when changing a password, see Creating Hard-to-Crack Passwords.

ProcedureTo change passwords

To change your trust database/key-pair file password for the Administration Server or an server instance, perform the following steps:

  1. Access either the Administration Server or the Server Manager.

    From the Server Manager you must first select the server instance from the drop-down list.

  2. Select the Change Password link.

  3. Select the security token for which you want to change the password from the drop-down list.

    By default this is 'internal’ for the internal key database. If you have PKCS#11 modules installed, you see all the tokens listed. Click the Change Password link.

  4. Enter the current password.

  5. Enter the new password.

  6. Renter the new password.

  7. Click OK.

  8. From the Server Manager, click Apply, and then Restart for changes to take effect

    Make sure your key-pair file is protected. The Administration Server stores key-pair files in the directory server_root/alias. Consider making the files and directory readable only to Sun Java System servers installed on your computer.

    It is also important find out if the file is stored on backup tapes or is otherwise available for someone to intercept. If as, 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 machine as the server. It is possible to circumvent your server’s security by exploiting holes in other programs running on your server. Disable unnecessary programs and services. For example, the UNIX sendmail daemon is difficult to configure securely and it can be programmed to run other possibly detrimental programs on the server machine.

UNIX and Linux

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

Windows

Carefully consider the drives and directories that are share with other machines. Also, consider the users who have Guest privileges.

Be careful about programs you upload on your server, or those that other people install on your server. Other people’s programs might have security gaps. Someone could 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 in the <HEAD> section of a file in HTML:

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

Limiting Ports

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

Knowing Your Server’s Limits

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

For example, you might acquire credit card numbers over an SSL connection, but are those numbers stored in a secure file on the server machine? What happens to those numbers after the SSL connection is terminated? You should be responsible for securing any information clients send to you through SSL.

Making Additional Changes to Protect Servers

If you need to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one. If resources are limited and you must run an unprotected server on the same machine as your protected server, do the following.

The chroot allows you to create a second root directory to limit the server to specific directories. You use this feature to safeguard an unprotected server. For example, assume that the root directory is /d1/ms. Then any time the web server tries to access the root directory, it is connected /d1/ms. If the Web Server tries to access /dev, it gets /d1/ms/dev. This process allows you to run the web server on your UNIX/Linux system, without giving it access to all the files under the actual root directory.

However, if you use the chroot, you need to set up the full directory structure required by the Sun Java System Web Server under the alternative root directory, as shown in the following illustration:

Figure 6–2 Example of chroot Directory Structure

Example of chroot Directory Structure

ProcedureTo specify the chroot for a Virtual Server Class

You can specify the chroot directory for a virtual server class by performing the following steps:

  1. Access the Server Manager and select the server instance from the drop-down list.

  2. Select the Virtual Server Class tab.

  3. Click the Edit Classes link.

  4. Make sure the Option is set to Edit for the class in which you wish to specify chroot.

  5. Click the Advanced button for that class.

    The Virtual Servers CGI Settings page appears.

  6. Enter the full pathname in the Chroot field.

  7. Click OK.

  8. Click Apply.

  9. Choose Load Configuration Files to dynamically apply.

Specifying the chroot for a Virtual Server

You can specify the chroot directory for a specific virtual server by performing the following steps:

ProcedureTo specify the chroot directory for a specific virtual server

  1. Access the Server Manager and select the server instance from the drop-down list.

  2. Select the Virtual Server Class tab.

  3. Click on the link for the virtual server you wish to specify the chroot directory for from the Tree View of the Server.

  4. Select the Settings tab.

    The Settings page appears.

  5. Enter the full pathname in the Set to field next to Chroot Directory.

  6. Click OK.

  7. Click Apply.

  8. Choose Load Configuration Files to dynamically apply.

    You can also specify the chroot directory for a virtual server using the Class Manager Virtual Servers tab and the CGI Settings link.

    For more information about how to specify a chroot directory for a virtual server, see the Sun Java System Web Server 6.1 SP12 Programmer’s Guide.