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