Administration

Digg This!

The demands of security have gone far beyond simply managing user accounts and restricting access between internal and external networks. Emerging business practices challenge the enterprise to create flexible and robust security architectures that meet rapidly changing business demands. This article provides best practices tips that an administrator can implement to secure an enterprise. The land mines are highlighted so you know what to avoid.

The open, flexible, easy-to-configure security architecture of BEA WebLogic Server delivers advantages at multiple levels and introduces an advanced security design for application servers. Systems have to be protected from both insiders and outsiders. Misuse of a system or improper administration can leave it open for intrusion or attack.

Using development mode for domains running in production mode is not recommended. Never use development mode for production servers; it relaxes the security constraints for all servers in a domain. If you are using compatible security (using 6.x security configuration in 8.x), disable guest logins in production so that they cannot be used to access WebLogic resources in a WebLogic Server domain.

SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of a boot.properties file, you cannot restart your servers. Later, I will explain how to recover the administrative password if you lose it.

While creating scripts to automate WebLogic administration tasks, the option ?Dweblogic.system.BootIdentityFile lets you avoid hard-coding a username and password in your text script. Also, more than anything else file system security of the WebLogic installation directories is most important. Allow access only to the user account that will be used to run or administer the WebLogic domain.

Tips

• Install JRE instead of the complete SDK.
• Remove or delete the development tools provided by BEA, such as the Configuration Wizard, WebLogic Builder, and jCOM tools.
• The Pointbase database provided with WebLogic installation is for evaluation purposes and not supported in a production environment. Delete it.
• Do not install the sample domains while installing in production or delete the sample domains if already installed.
• Instead of hard-coding user identity in the start scripts, store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.
• BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; assign users to groups, then create role statements.
• Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use postbind UID or postbind GID in the WebLogic machine configuration.
• Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.

J2EE Application Security

Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Create application policies using the WebLogic Administration Console. When you create a security policy using the administration console, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them.

Always keep source code off the production machine. Do not install uncompiled JSPs and other source code on the production machine. Configure your applications to use SSL. Set the transport- guarantee to CONFIDENTIAL in the user-data-constraint element of the web.xml file to secure specific resources of the web application using SSL.

Recovering Administrator Password

WebLogic provides four default administrative roles. The administrative user created during domain creation will be a part of the "Admin" role. Configure additional administrative users to roles such as Admin, Deployer, Monitor, or Operator. When using the default authenticator, if you have not modified the global Admin role (which by default is granted to the Administrator's group), you can recover the administrator password in a WebLogic domain.

To recover the administrator password in a WebLogic domain:

• At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.
• Create a new DefaultAuthenticatorInit.ldift: run java weblogic.security.utils.AdminAccount <tempadmin> <temppassword>.
• Remove the initialized status file, DefaultAuthenticatormyrealmInit.initialized from the <Domain>/<Server>/ldap subdirectory.
• Restart the server, using the new user identity.
• To change the old admin user identity, log into the admin console (Optional).

SSL

When using SSL with WebLogic Server, use keystores; storing identity (private keys and certs) and trust (CA) in files is deprecated. Migrating from an earlier version might require you to create keystores from private keys, certs, or trust files.

If the network that connects WebLogic Servers in a domain is not trusted, enable SSL on each server in the domain so that LDAP replication between the admin server and managed servers uses SSL connections. Enabling the administration port of the domain enforces all the servers in the WebLogic domain to use SSL.

The default WebLogic installation represents exportable-strength SSL implementation (the maximum SSL strength is 512-bit keys with 40-bit bulk encryption). Key lengths longer than 512 bits require a domestic-strength SSL license key from BEA. If you use SSL in your production environment, use high-strength SSL. Key lengths of less than 1024 bits are generally considered weak.

SSL hardware accelerators: Running SSL on the WebLogic Servers is a tremendous drain on server resources. By offloading SSL processing, the resources can be applied to WebLogic functions. SSL processing can be handled by Web servers, load balancers, firewalls, or switches.

Incoming connections in WebLogic Server can be controlled by filtering them. WebLogic Server provides a default implementation of connection filter that you can configure in the admin console.

Tips

• To avoid compromising application security, install and configure server-specific SSL certificates and enable hostname verification on production servers.
• In production, do not use the sample SSL certificates that are provided with WebLogic.
• Use a load balancer with built-in secure sockets layer (SSL) support, or run WebLogic Server on a machine that has SSL hardware, with Java Cryptography Extension (JCE).
• Use SSL with WebLogic Server only if it is necessary. SSL degrades performance.
• To control the types of connections accepted by WebLogic Server instances, use Connection Filters.

Securing the Admin Console

Applications should be installed on the managed server rather than installing them on the administration server. But if you use the admin server to serve applications (or in a single-server domain), do the following for better security:

• Change the default admin user and password to custom.
• Change the admin console context root path.
• Enable domain-wide administration port.
• Consider disabling the admin console.

Authentication Providers

If you use an external LDAP provider, store the server boot identity in the embedded LDAP server, and set timeouts on the external LDAP authentication provider. This way, if the external LDAP server is unavailable you can continue to restart and to serve unprotected data with WebLogic Server. Also before you apply any changes, set the control flag for all authentication providers to OPTIONAL; this prevents a configuration error from causing a production server not to restart.

WebLogic Server provides a custom realm, the NTRealm, based on older security realm API that supports native Windows domain authentication. NTRealm is useful with Windows domains that are not set up to use Active Directory.

Tips

• Store the server boot identity in the embedded LDAP server.
• For finer control of a production environment, use Active Directory authentication, rather than native Windows domain (NTRealm) authentication.
• To prevent denial-of-service attacks, modify the timeout and maximum-size values for the incoming protocol ports (T3, COM, IIOP, HTTP Post time out) on the server.
• Have a security audit performed by an internal or external auditing group.

Backup and Recovery

To migrate or recover WebLogic domains in case of failures, periodically back up the entire domain directory tree from the administration server machine. This way you can recover from a hardware or system failure by merely restoring the domain directory and restarting the admin server. Some important files to be watched/backed up periodically from the administration server machine in a WebLogic production domain are:

• config.xml: Domain configuration repository.
• config.xml.booted: Good backup of domain configuration repository from a successful boot.
• boot.properties: Encrypted username and password for booting administration server.
• running-managed-servers.xml: List of dependent managed servers currently running. This file is used for discovering managed servers if administration server gets restarted while the managed servers are running.
• domain/configArchive/: Contains the copies of the Domain Configuration Repository files. When updated using administration tools, the administration server copies the old config.xml to this directory.
• domain\adminserver\ldap\ldapfiles: Embedded LDAP data files currently being used by the domain's administration server.
• *.ldift files: Can be used to initialize the WebLogic Domain Embedded LDAP server back to when the Domain was created.
• domain/adminserver/ldap/backup/EmbeddedLDAPBackup.zip: Backup of the WebLogic Domain embedded LDAP server. Embedded LDAP is used to store users, groups, roles, policies by the default security realm, myrealm's security providers.
• SerializedSystemIni.dat: Contains encrypted security data that must be present to boot the server.
• Security Certificates: Security certificates and keys being used by the servers of a domain should also be backed up. The location of these files is user configurable.
• Batch/Shell Scripts: setEnv.cmd/sh, startWebLogic.cmd/sh, startManagedWebLogic.cmd/sh.

The WebLogic administrator can check for BEA security advisories to download security-related patches and register to receive notifications of newly available security advisories. Refer to the BEA Advisories & Notifications page on the dev2dev Web site at http://dev2dev.bea.com/advisories.