Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Administrator's Guide to Security

> ## Chapter 2
> General Security Measures

> In 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 Java System Application Server more secure.

> This section contains the following topics:

> - About General Security
> - Limiting Physical Access
> - Using Firewalls
> - Limiting Administration Access
> - Managing Passwords
> - Limiting Other Applications on the Server
> - Securing Against an Unprotected Server

> ##

> About General Security

> Networks 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 Java System 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 Access

> The 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 Java System 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.

> By default all the configuration files in the /config directory as well as the /application directory are only readable by the instance owner. To protect the password data, it is important to maintain these directories with these default restricted-access permissions.

> - Backup tapes—You must protect your backup tapes as vigilantly as you protect data on the server.

> Note | Because some of configuration files may contain cleartext passwords, when the Sun Java System Application Server file systems are backed up these passwords will, if present, be contained in these backups, and can be retrieved and potentially abused by anyone who has access to the backup media.

> - 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.

> Operating system hardening is very platform-specific and cannot be covered in any detail in this documentation. Please consult your platform vendor. See, for example, the JASS Toolkit for Solaris

> http://wwws.sun.com/software/security/jass/

> The Sun Java System 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 Firewalls

> This section examines some common firewall configurations and the parameters to be configured for correct functioning. This is general information that pertains to the Sun Java System Application Server. For details, refer to the documentation from your particular firewall vendor.

> The following topics are addressed in this section:

> - Single Firewall
> - Double Firewall - DMZ Configuration
> - Triple Firewall - DMZ With Database Protection

> ### Single Firewall

> The simplest and most common firewall configuration places a single firewall between the Sun Java System 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.

> Note | If direct RMI/IIOP access to EJBs is allowed from the Internet, the IIOP/RMI listener port (default 3700) must be opened as well. However, this practice is strongly discouraged as it creates potential security risks.

> 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 Java System 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 Java System Application Server
> - A proxy plugin that forwards requests to the Sun Java System 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 Java System 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.

> Table 2-2 Single Firewall Protocols and Ports

> Protocol | Wall | Default Port | Reason
> --- | --- | --- | ---
> TCP/IP | Outer | 80 | HTTP requests to routing server
> TCP/IP | Outer | 443 | HTTPS requests to routing server
> TCP/IP | Inner | 80 | HTTP requests to Sun Java System Application Server
> TCP/IP | Inner | 443 | HTTPS requests to Sun Java System Application Server

> For information on these ports, refer to the Sun Java System 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 Access

> If 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 Passwords

> There 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
> - Managing the Superuser Password
> - Changing Passwords or PINs
> - Using the password.conf File

> ### 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:
> - Uppercase letters
> - Lowercase letters
> - Numbers
> - Symbols

> ### 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.

> Caution | Because you can edit the admpw file, it is very important that you keep the server machine in a secure place and restrict access to its file system: On UNIX/Linux systems, consider changing the file ownership so that it is writable only by root or whatever system user runs the Admin Server daemon. By default, the /config directory is readable only by the instance owner which protects the directory and other sensitive files. Be sure these permissions are not altered. On Windows systems, restrict the file ownership to the user account the Admin Server uses.

> To set up superuser access for the Admin Server, perform the following steps in the Administration interface:

> 1. Access Admin Server and select Security.
> 2. Select Access Control.

> The Superuser Access Control page is displayed.

> 3. Enter the host names that are allowed superuser access to the Admin Server.
> 4. Enter the IP addresses that are allowed superuser access to the Admin Server.
> 5. Enter the authentication user name.
> 6. Enter the authentication password.

> For a list of guidelines to consider when changing a password, see .

> 7. Re-enter the authentication password.
> 8. Click OK.
> 9. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
> 10. 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 Java System Application Server prompts you for the SSL key database password at startup. If you want to be able to restart an unattended Sun Java System 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.

> Note | Leaving the SSL-enabled server's password in the password.conf file is a large security risk. Anyone who can access the file has access to the SSL-enabled server’s password. Consider the security risks before keeping the SSL-enabled server’s password in the password.conf file.

> - 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 Java System Application Server user. Protecting the directory prevents others from creating a false password.conf file.

> Note | On Windows, you cannot protect directories or files on File Allocation Table (FAT) file systems by restricting access to them.

> If security risks are not a concern for you, follow these steps to start your SSL-enabled server automatically:

> 1. Make sure SSL is on.
> 2. 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

> 3. Stop and start your server for the new setting to take effect.

> ##

> Limiting Other Applications on the Server

> It is possible to circumvent Sun Java System 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.

> - UNIX—Carefully choose the processes that are started from the inittab script and the rc script.
> - Don’t run telnet or rlogin from the server machine.
> - Don’t have rdist on the server machine. While the purpose of rdist is to distribute files, it can also be used by an attacker to update files on the server machine illegally.
> - Windows—Be selective about which drives and directories you share with other machines. Also, carefully choose which users have accounts or Guest privileges.

> 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 Server

> If 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:

> - Different port numbers—Make sure that the protected server and the unprotected server are assigned different port numbers. The registered default port numbers are:
> - 443 for the protected server
> - 80 for the unprotected server
> - For UNIX—Redirect the document root directory using the chroot tool.

> The UNIX chroot command allows you to create a second root directory to limit the server to specific directories. Refer to the man page for guidelines on using this command.

> In the Administration interface, you can specify the chroot directory for a specific virtual server by performing the following steps:

> 1. Access App Server Instances and select the server instance from the left pane.
> 2. Select HTTP Server and Virtual Servers.
> 3. Select the virtual server you want to specify the chroot directory for.

> The page for the General tab is displayed.

> 4. Scroll down the page until you find the Chroot field.
> 5. Enter the full pathname in the Chroot directory.
> 6. Click Save.
> 7. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
> 8. Stop and start the server for changes to take effect.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.