Physically secure the hardware.

Keep your hardware in a secured area to prevent unauthorized operating system users from tampering with the deployment machine or its network connections.

Log out of the Administration Console before navigating to a non-secure site.

If you are logged on to the Administration Console, be sure to log out completely before browsing to an unknown or non-secure Web site.

Secure networking services that the operating system provides.

Have an expert review network services such as e-mail programs or directory services to ensure that a malicious attacker cannot access the operating system or system-level commands. The way you do this depends on the operating system you use.

Sharing a file system with other machines in the enterprise network imposes risks of a remote attack on the file system. Be certain that the remote machines and the network are secure before sharing the file systems from the machine.

Use a file system that can prevent unauthorized access.

Make sure that the file system on each GlassFish Serverhost can prevent unauthorized access to protected resources. For example, on a Windows computer, use only NTFS.

Set file access permissions for data stored on disk.

Set operating system file access permissions to restrict access to data stored on disk. This data includes, but is not limited to, the following:

The database files. GlassFish Server includes an implementation of Java DB (formerly known as Derby), however, you can use any JDBC-compliant database.

The directory and filename location of a private keystore, such as keystore.jks

The directory and filename location of a Root Certificate Authority (CA) keystore, such as cacerts.jks.

For example, operating systems provide utilities such as umask and chmod to set the file access permissions. At a minimum, consider using "umask 066", which denies read and write permission to Group and Others.

Limit the number of user accounts on the host machine.

Avoid creating more user accounts than you need on host machines, and limit the file access privileges granted to each account. On operating systems that allow more than one system administrator user, the host machine should have two user accounts with system administrator privileges and one user with sufficient privileges to run GlassFish Server. Having two system administrator users provides a back up at all times. The GlassFish Server user should be a restricted user, not a system administrator user. One of the system administrator users can always create a new GlassFish Server user if needed.

Important: Domain and server configuration files should be accessible only by the operating system users who configure or execute GlassFish Server.

Review active user accounts regularly and when personnel leave.

Background Information: Configuration data and some URL (Web) resources, including Java Server Pages (JSPs) and HTML pages, are stored in clear text on the file system. A sophisticated user or intruder with read access to files and directories might be able to defeat any security mechanisms you establish with authentication and authorization schemes.

For your system administrator user accounts, choose names that are not obvious.

For additional security, avoid choosing an obvious name such as "system," "admin," or "administrator" for your system administrator user accounts.

Safeguard passwords.

The passwords for user accounts on production machines should be difficult to guess and should be guarded carefully.

Set a policy to expire passwords periodically.

Never code passwords in client applications.

Do not deploy an application that can be accessed with the default username admin and no password.

Safeguard password files

The -passwordfile option of the asadmin command specifies the name of a file that contains password entries in a specific format. These password entries are stored in clear text in the password file, and rely on file system mechanisms for protection.

To provide additional security, create a password alias.

Use a password alias

A password alias stores a password in encrypted form in the domain keystore, providing a clear-text alias name to use instead of the password.

To provide additional security, use the create-password-alias subcommand to create an alias for the password. The password for which the alias is created is stored in an encrypted form.

Then, specify the alias in the entry for the password in the password file as follows:

In password files and the domain configuration file, use the form ${alias=alias-name} to refer to the encrypted password.

Do not run GlassFish Server as root

GlassFish Servershould run only as an unprivileged user, never as root.

The directory structure in which GlassFish Server is located, including all files, should be protected from access by unprivileged users.

Taking these steps helps ensure that unprivileged users cannot insert code that can potentially be executed by GlassFish Server server.

Consider use PAM Realm

The use of a PAM Realm requires GlassFish Server to run as an account that has read-access to a shadow password file or the equivalent, and therefore may not be suitable in your environment.

Do not develop on a production machine.

Develop first on a development machine and then move code to the production machine when it is completed and tested. This process prevents bugs in the development environment from affecting the security of the production environment.

Do not install development or sample software on a production machine.

Do not install development tools on production machines. Keeping development tools off the production machine reduces the leverage intruders have should they get partial access to a production machine.

Enable security auditing.

If the operating system on which GlassFish Server runs supports security auditing of file and directory access, Oracle recommends using audit logging to track any denied directory or file access violations. Administrators should ensure that sufficient disk space is available for the audit log.

Consider using additional software to secure your operating system.

Most operating systems can run additional software to secure a production environment. For example, an Intrusion Detection System (IDS) can detect attempts to modify the production environment. Refer to the vendor of your operating system for information about available software.

Apply operating system patch sets and security patches.

Refer to the vendor of your operating system for a list of recommended patch sets and security-related patches.

Apply the latest maintenance packs and critical patch updates.

Refer to the vendor of your operating system for a list of maintenance packs and critical patch updates.