| Sun ONE Application Server 7 Administrator's Guide to Security |
Chapter 2
General Security MeasuresIn addition to using security mechanisms such as authentication, encryption, and ACL files, as well as taking advantage of the J2EE authentication and authorization mechanisms, there are a number of manual steps you can take to make your Sun ONE Application Server more secure.
This section contains the following topics:
About General SecurityNetworks face risks from external and internal attackers, who use a variety of tactics to gain access to your server and the information on it. The Sun ONE Application Server offers secure connections between the server and the client. However, it can’t control the security of information once the client has the information, nor can it control access to the server machine 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 machine? What happens to those numbers after the SSL connection is terminated? You are responsible for securing any information clients send to you through SSL.
Limiting Physical AccessThe simple security measure of physically protecting your server from access is often overlooked. Keep the server machine in a locked room that only authorized people can enter. This prevents anyone from attacking the server machine itself.
- Root password—It is crucial to protect your machine’s administrative (root) password. As with all passwords, but particularly the root password, be sure to select passwords that are difficult to guess.
- Application server configuration—Some of the Sun ONE Application Server configuration files (such as server.xml, various J2EE application descriptor XML files, password.conf) may contain cleartext passwords for a number of external resources (such as JDBC database passwords and SSL databases) that the application server needs to authenticate to during its operation. All such configuration files must be carefully protected.
- Backup tapes—You must protect your backup tapes as vigilantly as you protect data on the server.
- Ports—Disable any ports not used on the machine. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. This means that the only way to get a shell is to physically use the server’s machine, which should already be in a restricted area.
- Security hardening of the operating system—This is recommended and should be considered a requirement on any production system that is accessible through the Internet.
The Sun ONE Application Server assumes that those who have access to the physical server will not abuse the server channel. It is very important that you take whatever precautions you can to restrict server access only to authorized, well intentioned users.
Using FirewallsThis section examines some common firewall configurations and the parameters to be configured for correct functioning. This is general information that pertains to the Sun ONE Application Server. For details, refer to the documentation from your particular firewall vendor.
The following topics are addressed in this section:
Single Firewall
The simplest and most common firewall configuration places a single firewall between the Sun ONE Application Server server and the Internet browser. The firewall needs to be configured to allow HTTP connections to the HTTP port (default 80) and/or the HTTPS port (default 443) as appropriate for web container access.
The advantage of the single firewall configuration is simplicity. The biggest disadvantage is that there is a single line of defense. If the firewall is breached, the only defense is the security of each of the individual machines within the private network.
The following table summarizes the protocols and ports which need to be configured to the firewall to permit correct functioning. The left column indicates the protocol used, the center column indicates the port, and the right column indicates the type of communication.
Table 2-1 Double Firewall Protocols and Ports
Protocol
Wall
Port
Reason
TCP/IP
Outer
80 (default)
HTTP requests
TCP/IP
Outer
443
HTTPS requests
For information on these ports, refer to the Sun ONE Application Server Administrator’s Guide and the Administration interface online help.
Double Firewall - DMZ Configuration
The double firewall, also known as the demilitarized zone (DMZ) configuration, is becoming more common as many organizations allow limited access to their private networks to partners and customers. The double layer of protection combined with active monitoring of activity at each firewall and within the DMZ will detect most attempts to penetrate the internal network. The security provided is much better than the single firewall configuration.
The double firewall configuration provides:
- An outer firewall between the Internet browser and a routing web server/application server located in the DMZ
- An inner firewall between the routing server in the DMZ and the protected Sun ONE Application Server
- A proxy plugin that forwards requests to the Sun ONE Application Server behind the second firewall
In the double firewall configuration, the outer firewall must be configured to allow for HTTP and HTTPS transactions. The inner firewall must be configured to allow the HTTP server plug in to communicate with the Sun ONE Application Server server(s) behind the firewall.
The following table summarizes the protocols and ports which need to be configured to the firewall to permit correct functioning. The left column indicates the protocol used, the second column indicates which firewall the protocol/port applies to, the third column indicates the port, and the right column indicates the type of communication.
For information on these ports, refer to the Sun ONE Application Server Administrator’s Guide and the Administration interface online help.
Triple Firewall - DMZ With Database Protection
In some corporate settings, databases reside on their own networks, protected by firewalls. The triple firewall configuration provides maximum security for what may be the most important corporate asset: the data contained within the corporate database. The firewall between the LAN and the database systems provides protection against internal as well as external threats.
The connections to the database use standard access mechanisms such as Open DataBase Connectivity (ODBC), Java DataBase Connectivity (JDBC), and database vendor-supplied connector libraries. The connections to the database are not different from any other application, so the firewall configuration for the database protection layer will conform to the standard settings required for access to the specific database in use.
Limiting Administration AccessIf you use remote configuration, be sure to set access control to allow administration access by only a few users and computers.
You should always turn on encryption for the master Admin Server. If you don’t use an SSL connection for administration, you must be very cautious when performing remote server administration over the unsecure network. Anyone can intercept your administrative password and reconfigure your servers.
If you want your Admin Server to provide end-user access to the LDAP server or local directory information, consider maintaining two Admin Servers and using cluster management, so that the SSL-enabled Admin Server acts as the master server, and the other Admin Server is available for end-user access. Refer to "Enabling SSL Communication with LDAP" for further information.
Instructions for implementing cluster management can be found in the Sun clustering documentation collection.
Managing PasswordsThere are 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 of all, since anyone with that password can configure any and all servers on your computer. Your private key password is next most important. If someone gets your private key and your private key password, they 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’ll remember but others won’t guess. For example, you might remember MCi12!mo as “My Child is 12 months old!” A bad password is your child’s name or birth date.
The following topics address additional information on passwords:
Creating Hard-to-Crack Passwords
There are some simple guidelines that will help you create a stronger password.
It is not necessary to incorporate all the following guidelines in one password, but the more of these guidelines you use, the harder your password will be to crack:
- Passwords should be 6-14 characters long (observing whatever length limitation your system has).
- Do not use the illegal characters: *, ", or spaces
- Do not use dictionary words (any language)
- Do not make common letter substitutions, like replacing E with 3, or L with 1
- Do include characters from as many of these classes as possible:
Managing the Superuser Password
You can configure superuser access for your Admin Server. In this case, the superuser is the person who has access to change any or all parts of the server configuration (not to be confused with the system’s superuser/root). These settings affect only the superuser account. That is, if your Admin Server uses distributed administration, you need to set up additional access controls for the administrators you enable.
The superuser's user name and password are kept in a file called intsall_dir/domains/domain_dir/admin-server/config/admpw. If you forget the user name, you can view this file to obtain the actual name; however, the password is encrypted and unreadable. The file has the format username:password.
If you forget the password, you can edit the admpw file and simply delete the encrypted password.
To set up superuser access for the Admin Server, perform the following steps in the Administration interface:
- Access Admin Server and select Security. The following screen is displayed:
Figure 2-1 Superuser Access Control Page
- Select Access Control.
The Superuser Access Control page is displayed.
- Enter the host names that are allowed superuser access to the Admin Server.
- Enter the IP addresses that are allowed superuser access to the Admin Server.
- Enter the authentication user name.
- Enter the authentication password.
For a list of guidelines to consider when changing a password, see .
- Re-enter the authentication password.
- Click OK.
- Access App Server Instances and your server instance in the left pane, then click Apply Changes.
- Stop and start the server for changes to take effect.
Changing Passwords or PINs
It’s good practice to change your trust database/key pair file password or PIN periodically. If your Admin Server is SSL-enabled, this password is required when starting the server. You should only change this password on your local machine. Refer to "Changing a Trust Database Password" for instructions.
It is important to make sure your key-pair file is protected. The Admin Server stores key-pair files in the /config directory of the instance. By default, the /config directory files are set to be readable only by the instance owner. It is important to monitor these permissions to ensure that the file permissions aren’t inadvertently changed later by backup scripts or other events.
It’s also important to know if the file is stored on backup tapes or is otherwise available for someone to intercept. If so, you must protect your backup tapes as carefully as your protect your server data.
Using the password.conf File
By default, the Sun ONE Application Server prompts you for the SSL key database password at startup. If you want to be able to restart an unattended Sun ONE Application Server, you must save the password in a password.conf file.
Note
Only use the password.conf file if your system is adequately protected so that this file and the key databases cannot be compromised.
- For UNIX—Normally, you cannot start a UNIX SSL-enabled server with the /etc/rc.local or the /etc/inittab files because the server requires a password before starting. Although you can start an SSL-enabled server automatically if you keep the password in plain text in a file, this is not recommended. The server’s password.conf file should be owned by root or the user who installed the server, with only the owner having read and write access.
- For Windows—If you have a New Technology File System (NTFS) file system, you should protect the directory that contains the password.conf file by restricting its access, even if you do not use the file. The directory should have read/write permissions for the Admin Server user and the Sun ONE Application Server user. Protecting the directory prevents others from creating a false password.conf file.
If security risks are not a concern for you, follow these steps to start your SSL-enabled server automatically:
- Make sure SSL is on.
- Create a new password.conf file in the config subdirectory of the server instance.
- If you are using the internal PKCS11 software encryption module that comes with the server, enter the following information:
internal:your_password
- If you are using a different PKCS11 module (for hardware encryption or hardware accelerators), specify the name of the PKCS11 module, followed with the password. For example:
nFast:your_password
- Stop and start your server for the new setting to take effect.
Limiting Other Applications on the ServerIt is possible to circumvent Sun ONE Application Server security by exploiting weaknesses in other programs running on your server. An obvious prevention step is to disable any unnecessary programs and services running on your server.
Be careful about what programs you or other people install on your server. Other people’s programs might have security holes that they may or may not be aware of. Worst of all, someone might install a malicious program designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.
Securing Against an Unprotected ServerIf you want to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one.
If your resources are limited and you must run an unprotected server on the same machine as your protected server, do the following:
In the Administration interface, you can specify the chroot directory for a specific virtual server by performing the following steps:
- Access App Server Instances and select the server instance from the left pane.
- Select HTTP Server and Virtual Servers.
- Select the virtual server you want to specify the chroot directory for.
The page for the General tab is displayed.
- Scroll down the page until you find the Chroot field.
- Enter the full pathname in the Chroot directory.
- Click Save.
- Access App Server Instances and your server instance in the left pane, then click Apply Changes.
- Stop and start the server for changes to take effect.
