6 Running in a Secure Environment

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.

Set file access permission for the GlassFish Server installation.

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

Taking this step helps ensure that unprivileged users cannot insert code that can potentially be executed by GlassFish Server.

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. Therefore, any password file created for use with the -passwordfile option should be protected with file system permissions. Additionally, any password file being used for a transient purpose, such as setting up SSH among nodes, should be deleted after it has served its purpose.

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 Server should run only as an unprivileged user, never as root.

Taking this step helps ensure that code from other users cannot be executed by GlassFish 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.

Enable Secure Admin.

The secure administration feature allows an administrator to secure all administrative communication between the domain administration server (DAS), any remote instances, and administration clients such as the asadmin utility, the administration console, and REST clients.

In addition, secure administration helps to prevent DAS-to-DAS and instance-to-instance traffic, and carefully restricts administration-client-to-instance traffic.

The secure administration feature provides a secure environment, in which you can be confident that rogue users or processes cannot intercept or corrupt administration traffic or impersonate legitimate GlassFish Server components.

See Managing Administrative Security.

Protect the .asadminpass file

If you create a domain with the --savelogin option, create-domain saves the administration user name and password in the .asadminpass file in the user's home directory.

Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage this domain.

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. Therefore, any password file created for use with the -passwordfile option should be protected with file system permissions. Additionally, any password file being used for a transient purpose, such as setting up SSH among nodes, should be deleted after it has served its purpose.

To provide additional security, create a password alias.

Deploy production-ready security providers to the security realm.

Java Authorization Contract for Containers (JACC) is the part of the Java EE specification that defines an interface for pluggable authorization providers. This enables you to set up third-party plug-in modules to perform authorization.

By default, the GlassFish Server provides a simple, file-based authorization engine that complies with the JACC specification. You can also specify additional third-party JACC providers.

If you have purchased or written your own security providers, make sure that you have deployed and configured them properly.

Use SSL, but do not use the self-signed certificates in a production environment.

To prevent sensitive data from being compromised, secure data transfers by using HTTPS.

By default, GlassFish Server uses self-signed certificates. The self-signed certificates that GlassFish Server uses might not be trusted by clients by default because a certificate authority does not vouch for the authenticity of the certificate.

You can instead use your own certificates, as described in Using Your Own Certificates.

Restrict the size and the time limit of requests on external channels to prevent Denial of Service attacks.

To prevent some Denial of Service (DoS) attacks, restrict the size of a message as well as the maximum time it takes a message to arrive.

The default setting for maximum post size is 2097152 bytes and 900 seconds for the request timeout.

Enable authentication and authorization auditing.

Auditing is the process of recording key security events in your GlassFish Server environment. You use audit modules to develop an audit trail of all authentication and authorization decisions. To enable audit logging, two steps are required:

1. On the Security page, select the Audit Logging Enabled checkbox to enable audit logging.

2. Set the auditOn property for the active audit module to true.

Review the auditing records periodically to detect security breaches and attempted breaches. Noting repeated failed logon attempts or a surprising pattern of security events can prevent serious problems.

Set logging for security and SSL messages.

Consider setting module log levels for table.javax.enterprise.system.ssl.security and javax.enterprise.system.core.security. You can set a level from Severe to Finest (the default is Info), but be aware that the finer logging levels may produce a large log file.

By default, GlassFish Server logging messages are recorded in the server log, and you can set the file rotation limit, as described in rotate-log(1)

Ensure that you have correctly assigned users to the correct groups.

Make sure you have assigned the desired set of users to the right groups. In particular, make sure that users assigned to the asadmin group need to be members of that group.

Create no fewer than two user accounts in the asadmin group.

The user admin is created when you install GlassFish Server. For production environments, create at least one other account in the asadmin group in case one account password is compromised. When creating asadmin users give them unique names that cannot be easily guessed.

Assign a password to the admin account.

By default, GlassFish Server includes a single account for user "admin" and an empty password. For production environments this default is inherently unsecure, and you should set a password for admin.

Use JSP comment tags instead of HTML comment tags.

Comments in JSP files that might contain sensitive data and or other comments that are not intended for the end user should use the JSP syntax of <%/* xxx */%> instead of the HTML syntax <!-- xxx -->. The JSP comments, unlike the HTML comments, are deleted when the JSP is compiled and therefore cannot be viewed in the browser.

Do not install uncompiled JSPs and other source code on the production machine.

Always keep source code off of the production machine. Getting access to your source code allows an intruder to find security holes.

Consider precompiling JSPs and installing only the compiled JSPs on the production machine. To do this, set the deploy subcommand -precompilejsp option to true for the component.

When set to true, the deploy and redeploy subcommands -precompilejsp option compiles JSPs during deploy time. If set to false (the default), JSPs are compiled during runtime.

Configure your applications to use SSL.

Set the transport-guarantee to CONFIDENTIAL in the user-data-constraint element of the web.xml file whenever appropriate.

Examine applications for security.

There are instances where an application can lead to a security vulnerability.

Of particular concern is code that uses Java native interface (JNI) because Java positions native code outside of the scope of Java security. If Java native code behaves errantly, it is only constrained by the operating system. That is, the Java native code can do anything GlassFish Server itself can do. This potential vulnerability is further complicated by the fact that buffer overflow errors are common in native code and can be used to run arbitrary code.

If your applications contain untrusted code, enable the Java security manager.

The Java security manager defines and enforces permissions for classes that run within a JVM. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. However, when third parties use GlassFish Server and untrusted classes are being run, the Java security manager may be useful. See "Enabling and Disabling the Security Manager" in Oracle GlassFish Server Application Development Guide.

Replace HTML special characters when servlets or JSPs return user-supplied data.

The ability to return user-supplied data can present a security vulnerability called cross-site scripting, which can be exploited to steal a user's security authorization. For a detailed description of cross-site scripting, refer to "Understanding Malicious Content Mitigation for Web Developers" (a CERT security advisory) at http://www.cert.org/tech_tips/malicious_code_mitigation.html.

To remove the security vulnerability, before you return data that a user has supplied, scan the data for HTML special characters. If you find any such characters, replace them with their HTML entity or character reference. Replacing the characters prevents the browser from executing the user-supplied data as HTML.