Because the Endeca Server application runs in a J2EE container in the WebLogic Server, you should be aware of some of the security features of WebLogic Server.
Oracle recommends that you use SSL in a production environment. WebLogic Server supports SSL on a dedicated listen port which defaults to 7002.
The generate_ssl_keys utility not only creates the SSL certificates but also enables the SSL Listen Port of 7002 in WebLogic Server, and sets 7002 as the port on which Endeca Server is started. Therefore, all you need to do to configure SSL on WebLogic Server is to run this script (described in Key Generation Utility).
Note that the generate_ssl_keys utility leaves the non-SSL (HTTP) 7001 port enabled, so that you can log into the Administration Console without a certificate.
You should protect your network with a firewall. If you must provide outside access to destinations within the firewall, set up a secure VPN (Virtual Private Network). A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines.
WebLogic also supports connection filters for domains. Connection filters allow you to deny access at the network level. They can protect server resources on individual servers, server clusters, or an entire internal network or intranet. For example, you can deny any non-SSL connections originating outside of your corporate network. Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names. For more information on connection filters, see the "Using Network Connection Filters" chapter in the Programming Security for Oracle WebLogic Server document (http://docs.oracle.com/cd/E23943_01/web.1111/e13711/con_filtr.htm#SCPRG377).
When running your Endeca Server application in a WebLogic Server production environment, it is important that you secure the physical machine, the operating system, and all other software that is installed on the host machine. You should also check with the manufacturer of the machine and operating system for recommended security measures.
The following recommendations for securing a WebLogic Server host in a production environment are summarized from the WebLogic document titled Securing a Production Environment, available at the URL listed in the following topic.
Security Action | Description |
---|---|
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 WebLogic Server 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 that hosts WebLogic Server. |
Use a file system that can prevent unauthorized access. | Make sure that the file system on each WebLogic Server host 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, these locations:
For example, Linux 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 WebLogic Server 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
WebLogic Server. Having two system administrator users provides a backup at all
times. The WebLogic Server user should be a restricted user, not a system
administrator user. One of the system administrator users can always create a
new WebLogic Server user if needed.
WebLogic domain and server configuration files should be accessible only by the operating system users who configure or run WebLogic Server. Review active user accounts regularly and when personnel leave. |
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.
Do not deploy a domain that can be accessed with the username weblogic and the password welcome1. These credentials are provided by default for domains containing the WebLogic Server sample applications, which should never be installed on a machine in a production 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 WebLogic Server production machine. Do not install the WebLogic Server sample applications on a production machine. |
Do not run WebLogic Server in development mode in a production environment. | Production mode sets the server to run with settings that are more secure and appropriate for a production environment. |
Enable security auditing. | Both Linux and Windows support 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 operation-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. |
Install the latest maintenance packs, minor releases, and critical patch updates. | If you are responsible for security
related issues at your site, register your WebLogic Server installation with My
Oracle Support. You can create a My Oracle Support account at
http://www.oracle.com/us/support.
You should also visit the Critical Patch Updates and Security Alerts page at http://www.oracle.com/technology/deploy/security/alerts.htm. |
Secure your JNDI root context. | Group "Everyone" must not have access to the JNDI Root Content resource if the WebLogic Server Administration Console is externally visible. By default, JNDI resources have a default security policy of Everyone. |