Running in a Secure Environment

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

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

Have a security professional 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. These actions depend on the operating system used by the host machine.

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.

Make sure that the file system on each Payara Server host can prevent unauthorized access to protected resources.

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

*Nix 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 the group owner and other users.

The directory structure in which Payara 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 Payara Server.

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

Having two system administrator users provides a backup at all times. The Payara Server user should be a restricted user, not a system administrator user. One of the system administrator users can always create a new Payara Server user if needed.

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 additional security, avoid choosing an obvious name such as "system," "admin," or "administrator" for your system administrator user accounts.

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

Set a policy to expire passwords periodically based on your organisation account management policies.

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.

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.

Payara Server should run only as an unprivileged user, never as the root in *Nix systems or as an Administrator user in Windows systems.

Develop your applications 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 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.

If the operating system on which Payara Server runs supports security auditing of file and directory access, it is recommended using audit logging to track any denied directory or file access violations.

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 that can be used for this purpose.

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

Refer to your official Java runtime version for a list of recommended security-related patches.

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 Payara Server components.

See Managing Administrative Security.

If you create a domain with the --savelogin option, create-domain saves the administration username 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 the domain.

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 prevent sensitive data from being compromised, secure data transfers by using HTTPS.

By default, Payara Server uses self-signed certificates. The self-signed certificates that Payara Server uses will not be trusted by clients by default because a certificate authority does not vouch for their authenticity.

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

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.

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

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.

Consider setting module log levels for the 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, Payara Server logging messages are recorded in the server log, and you can set the file rotation limit, as described in rotate-log

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.

The default admin user is created when you install Payara Server or create a new domain and accept its default username.

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.

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

JSP comments, unlike HTML comment blocks, are deleted when the JSP is compiled and therefore cannot be viewed in a web browser.

Always keep source code off of the production machine. Getting access to your source code allows an intruder to find security holes. Consider pre-compiling 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.

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

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

Of particular concern is code that uses Java native interface (JNI) because Java positions native code outside the scope of the Java security model.

If Java native code behaves in an errant manner, it is only constrained by the operating system. That is, the Java native code can do anything Payara 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.

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 Payara Server and untrusted classes are being run, the Java security manager may be useful. See "Enabling and Disabling the Security Manager" in the Application Development section.

The ability to return user-supplied data can present a security vulnerability called cross-site scripting (XSS), which can be exploited to steal a user’s security authorization.

To remove this 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.