I found a great article written by Asim Saddal outlining a list of general best practices to apply to any WebSphere Application Server V7 and V8 environment. It is copied exactly below. If you need the original article source, you can find it here.
However, some of the recommendations only apply to specific conditions and scenarios. These recommendations could be used to set up any WebSphere environment.
General Best Practices for WebSphere Application Environments
1. All WebSphere Application processes should be running as non-admin/root user.
It’s not a good practice to run a process as an admin/root user. For obvious reasons, you don’t want more folks to know about the admin/root password and generally the WebSphere admins are not the system admins. Create a services user account on the box and use it for the WebSphere Application’s start and stop purposes.
2. Enabled Global Security.
By default, the WebSphere Application Server enables administrative security. Thus, for the most part, the infrastructure provides for reasonable authentication, authorization, and encryption of administrative traffic by default. When administrative security is enabled, the WebSphere Application Server’s internal links between the deployment manager and the application servers and traffic from the administrative clients (Web and command line) to the deployment manager are encrypted and authenticated. Among other things, this means that administrators will be required to authenticate when running the administrative tools.
3. Enabled Application Security.
In addition to leveraging the application server’s security for administration, it’s strongly recommend that you leverage it for application security. Doing so gives your applications access to a strong and robust standards-based security infrastructure. Applications that didn’t leverage application server security were typically found to have serious security holes. Designing and implementing a secure distributed infrastructure is not easy.
To enable application security, go to the global security panel and select Enable application security.
4. Configure WebSphere Security with proper LDAP repository.
WebSphere security supports different configurations, including LDAP servers, local users and local operating system levels users. However, it’s recommended that you use a proper LDAP server for this purpose.
5. Leverage Administrative roles.
WebSphere Application Server allows for a variety of administrative roles depending on the version: Administrator, Operator, Monitor, Configurator, AdminSecurityManager, iscadmins, Deployer, or Auditor. These roles make it possible to give individuals (and automated systems) access that’s appropriate to their level of need. It’s strongly recommended that you take advantage of roles whenever possible.
By using the less powerful roles of monitor and operator, you can restrict the actions an administrator can take. For example, you can give the less senior administrators just the ability to start and stop servers and the night operators just the ability the watch the system (monitor). These actions greatly limit the risk of damage by trusting people with only the permissions they need.
6. Use HTTP Server as an interface for the Applications.
Use HTTP servers in front of an application layer, i.e., WebSphere Application. Don’t allow communications directly with WebSphere’s http web container port from either a load balance or from browsers.
7. HTTP and WebSphere on the Same box.
At least in higher environments, install and configure the http server on a different box than the WebSphere box. In the lower environments the same box can be used for both layers.
8. Logs on External Drive.
At least in higher environments, write the WebSphere and application log files to an external drive, so it won’t fill up the server’s file space.
9. Logs Archive.
Depending on the application, rotate and clean up the logs in a timely manner.
10. Read-only Logs Access for Developer.
If it’s okay with the security team, grant developers read-only access for WebSphere and the applications logs on the external drive.
11. Alternate Log Access for Developers.
To enable developers to view the production application and WebSphere logs, host those shared folders from the web server instead of giving them access to those boxes. Once the logs are hosted from the web server, developers need only a web browser to view those files from their computers.
12. Log Level.
Configure log level to error in high environments. Logs in the higher environments don’t need to produce unnecessary information. In the lower environments it can be set to info or debug level.
13. Leverage WebSphere Application Servers’ high availability and failover capabilities.
Out-of-the-box WebSphere support high availability and failover functionality. There is no need to use any external component or product for this. One of the key benefits is that user http session can be shared within the cluster members and, in the case of failover, the other active cluster members can resume the activity using same session.
14. Minimum Cluster Members in Cluster.
In the WebSphere clustered environment, define and create at least three cluster members. In the case of failover with two cluster members, not only the entire load will shift to one node but it also becomes a single point of failure. With three nodes, at least the load will still be distributed to two nodes and there is no single point of failure.
15. Database and WebSphere on Same box.
At least in higher environments, separate the application layer from the data layer and install them on different boxes. In the lower environments the same box can be used for both layers.
16. Use Type-4 JDBC Drivers.
Type-4 JDBC drivers don’t require any component to be installed on the application layer. For the type-2 and type-3, the database’s client needs to install on the WebSphere box.
17. Protect application server to database link.
As with any other network link, confidential information can be written to or read from the database. Most databases support some form of network encryption and you should leverage it.
18. Script based WebSphere Administration.
In general, it’s good practice to use scripts to avoid human errors during the deployment and configuration, especially in higher environments. However, it requires an investment in time and resources to develop these scripts, especially if it is first time and / or script-based administration is not part of the current culture. Once the scripts are created, they can be used in all environments and maybe automate some of the tasks.
19. Monitoring.
Use proper application and infrastructure runtime monitoring tools that can monitor environments and application thresholds and potentially alert you to problems before they cause service interruptions.
20. EAR vs WAR Files.
According to J2EE specs, EAR file should be deployed in WebSphere. However, WebSphere does support deploying WARs and upgrade class functionality. Developers should produce EAR files from their development tool or generate EAR should it be created from the deployment scripts before deploying the application in WebSphere.
21. Don’t run samples in production.
WebSphere Application Server ships with several excellent examples to demonstrate various parts of the WebSphere Application Server. These samples are not intended for use in a production environment. Don’t run them there, as they create significant security risks. In particular, the showCfg and snoop servlets can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you don’t want to give a potential intruder. This is easily addressed by not installing the samples during the profile creation.
22. Environments.
Generally, it’s good to have more environments. Typically four would be a sufficient enough: development, QA, staging and production. Development and QA environments don’t need a lot of hardware resources. It’s recommended that the staging environment be a replica of production in terms of application data and hardware resources. The staging environment can also be used for stress testing and / or for production support.
23. Performance Tuning.
Tune WebSphere application servers properly for each application. Performance tuning includes optimization of a number of web container threads, JVM heap sizes, JDBC connections, OS tuning, etc. After configuring these parameters to optimize values, boost the application performance. Stress / staging environment should be used for load testing.
24. Separate your production network from your intranet.
Most organizations today understand the value of a DMZ that separates the outsiders on the Internet from the intranet. However, far too many organizations fail to realize that many intruders are on the inside. You need to protect against internal as well as external threats. Just as you protect yourself against the large untrusted Internet, you should also protect your production systems from the large and untrustworthy intranet.
25. Separate your production networks from your internal network using firewalls.
These firewalls, while likely more permissive than the Internet-facing firewalls, can still block numerous forms of attack.
Keep up-to-date with patches and fixes. As with any complex product, IBM occasionally finds and fixes security bugs in WebSphere Application Server, Virtual Enterprise, Datapower and other products. It’s crucial that you keep up-to-date on these fixes. It’s advisable that you subscribe to support bulletins for the products you use and, in the case of WebSphere Application Server and WebSphere Virtual Enterprise, monitor the security bulletin site for your version. Those bulletins often contain notices of recently discovered security bugs and the fixes. You can be certain that potential intruders learn of those security holes quickly. The sooner you act the better.
More information on WebSphere Application Server security, including recommendations on hardening the WebSphere Application Server infrastructure, is available on the WebSphere Application Server security page.
© 2008 SYS-CON Media Inc.
