WebSphere® Application Server V5 introduces a number of run time configuration changes that impact not only the processes that are running, but also the transports that are used for interprocess communication. As a result, customers migrating from prior versions of WebSphere Application Server will likely need to adjust their firewall configurations for Version 5. This article will outline the port assignments for each process, as well as the transports utilized by Version 5. The specifics of configuring firewalls will not be covered here, since firewall configuration is specific to the each firewall vendor.
In brief, major changes to the run time components of WebSphere Application Server V5 from prior versions include:
- Replacement of the Adminserver process with a Deployment Manager (DMgr) and a Node Agent (NA):
- The DMgr provides a single administration point for management of WebSphere Application Server processes, as well as the configuration for a cell. The DMgr can either reside on a machine (node) running WebSphere Application Server processes or on a standalone server dedicated to this task. For high availability purposes, the latter is recommended. (See the availability articles in the Resources section for more information.)
- The NA is a local process for each node (physical server) in a WebSphere Application Server cell that provides for process management of the application server(s) and JMS Server running on each node.
- WebSphere Application Servers also run a name service and a security service; this is different from prior versions where the Adminserver provided these functions.
- Version 5 also provides a JMS server capability. In WebSphere Application Server Base, the JMS server runs in process with the application server process. In WebSphere Application Server Network Deployment (ND), the JMS server is a standalone process on each node.
- The WebSphere Congtrol Program (WSCP) and XMLConfig command line tools have been replaced by wsadmin.
In addition to the changes to the WebSphere Application Server V5 process model outlined above, there are corresponding changes to the transports used from prior versions. Prior to Version 5, all interprocess communication was via RMI/IIOP (or RMI/IIOP/SSL when security was enabled), with the exception of the communication between the Web (HTTP) server plug-in and the application server Web container, which was HTTP (or HTTPS with security enabled) or OSE (in Version 3.x). In Version 5, internal administrative communication between servers, and from administrative clients, is via SOAP by default, which runs over HTTP(S). However, RMI/IIOP, which is used for EJB communication, can optionally be used for clients or inter-server communication.
Figure 1, below, shows the processes in a "typical" WebSphere Application Server cell, as well as the transports between each of these processes. The legend for the transports is outlined in following table. A listing of the port assignments is also available in the WebSphere InfoCenter (see References).
|H||HTTP||Browser to Web server, Web server to application server, and admin Web client|
|W||WebSphere Application Server Internal||WebSphere Application Server clients and internal server admin traffic
|I||RMI/IIOP||EJB clients (standalone and Web container)|
|M||WebSphere MQ Protocol||WebSphere MQ clients (true clients and application servers)|
|L||LDAP||WebSphere Application Server verification of user information in registry|
|J||JDBC||Application JDBC access and WebSphere Application Server session DB access|
Figure 1. Processes in a WebSphere Application Server cell
Figure 2 expands this "typical" WebSphere Application Server cell by placing firewalls in the picture for a more representative data center configuration.
Figure 2. WebSphere Application Server cell with firewalls
Three firewalls have been added to the topology:
- Firewall 1 (FW1) is used in conjunction with Firewall 2 (FW2) to create a "demilitarized zone", where only Web servers are running. This provides protection from threats external to the enterprise, and limits access in case of an intrusion through the outer firewall (FW1).
- Firewall 3 (FW3) is used to secure the production data center from internal threats, such as from non-production networks.
While it's possible to add additional firewalls, such as one between the application servers and the database servers, or even between application servers, these additional firewalls provide little in the way of additional protection, but will certainly increase complexity of the topology. Much of the value provided by additional firewalls can be achieved with less complexity by using virtual private networks or placing all the components on the same subnet.
The memory-to-memory transport must be secured separately by using administrative functions to specify DES encryption.
Web and SOAP clients
Now that we've outlined the various components and transports involved in a typical topology, let's address the firewall port assignments for each component on a layer-by-layer basis, starting with the client requests going to the Web (HTTP) server, as shown in Figure 3.
Figure 3. Client to Web server
Since we're only dealing with HTTP and HTTPS traffic, this layer is likely the easiest to configure, since the browser clients and the Web services client requests all typically run over HTTP(S). As a result, the firewall will require two ports opened: 80 and 443 (unless you're using different ports other than the defaults for your Web servers).
Web server to application server
The next layer that needs to be configured is the link between Web servers and the application servers, as shown in Figure 4.
Figure 4. Web server and application server
This layer is also relatively easy to configure since, again, we're only dealing with a single protocol: HTTP(S). By default, WebSphere Application Server starts port assignments for the Web container component in each application server at 9080 (for HTTP) and 9043 (for HTTPS). WebSphere Application Server automatically increments the port assignments as additional application servers are added to a node, although it is also possible not to do so when creating an application server. Therefore, assuming you're allowing the run time to take care of port assignments for you, the second application server on a node would use ports 9081 (HTTP) and 9044 (HTTPS), the third would use 9082 and 9045, and so on. If you wish to see the current settings, or use different ports, navigate to the Web container transports dialog by selecting Application Servers => servername => Web Container => HTTP Transports in the administration browser, as shown in Figure 5.
Figure 5. HTTP Transports dialog
EJB clients to application servers
The next layer has not only the most connections, but also has multiple options for transports on some of those connections, as shown in Figure 6.
Figure 6. EJB clients to application servers
EJB clients communicate with application servers over several ports:
- BOOTSTRAP_ADDRESS: Bootstrap port for finding name service, fixed.
- ORB_LISTENER_ADDRESS: TCP/IP port, dynamic by default.
When security (SSL) is enabled, there are three additional ports:
- SAS_SSL_SERVERAUTH_LISTENER_ADDRESS: SAS SSL port for backward compatibility with prior versions of WebSphere Application Server, dynamic by default.
- CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS: CSIv2 client authentication SSL port, dynamic by default.
- CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS: CSIv2 SSL port (without client authentication), dynamic by default.
An EJB client will also need access to the ORB listener port for the Node Agent:
- ORB_LISTENER_ADDRESS: TCP/IP port, fixed.
Though not depicted in Figure 6, this last port is used for an EJB client initial request to the Location Service Daemon (LSD) running in the Node Agent. This is required because the WebSphere WorkLoad Management (WLM) implementation relies on âlocation forwardingâ, as it is called by the CORBA standard. The WLM portion of the WebSphere Application Server run time returns an indirect IOR (interoperable object reference) to the EJB client as a result of the lookup() call. This indirect IOR points to the ORB Listener port in the Node Agent. In response to the indirect IOR request, the Node Agent returns a direct IOR to an application server that is running the EJB.
Minimally, in an unsecured environment, you will need to allow for firewall traffic over the application server BOOTSTRAP_ADDRESS (a, above) and ORB_LISTENER_ADDRESS (b) as well as the Node Agent ORB_LISTENER_ADDRESS (f). In an environment with WebSphere security enabled, you will also need to make provisions for the CSIV2 and SAS addresses (c,d,e), depending on your application and system requirements.
The application server BOOTSTRAP_ADDRESS (a) is incremented automatically for you as you create application servers, with a starting value for the first application server on a node of port 9810. Unless you require backward compatibility with WebSphere Application Server V4.x systems, there is no need to worry about SAS. If you do require interoperability with WebSphere Application Server V4.x clients or application servers, then you will need to configure the noted SAS port (c) to be static by assigning it a value.
View or change the ports for each application server by selecting Application Servers => servername => End Points in the administration browser client, as shown in Figure 7.
Figure 7. End Points dialog
Some of the ports, particularly the ORB_LISTENER_ADDRESS (b, above), are not listed in the End Points dialog (Figure 7) by default. In the case of the ORB_LISTENER_ADDRESS, this means that the port number is dynamically assigned. To specify a fixed port assignment for a port that is not listed, simply create a new port using the New button in the End Points dialog with the appropriate name and the WebSphere Application Server run time will then use it. (See the transport articles in the Resources section for more information.)
The key to configuring a firewall is twofold:
- Fix these ports by specifying End Points, and
- For IIOP connections, use a firewall that does not perform Network Address Translation. (most firewalls do not "understand" IIOP).
When you navigate to these End Points in the admin browser, a value of "0" (zero) will have been assigned, indicating a dynamic port assignment. Simply fix the value for the port by specifying a number in place of zero. When the End Points have been changed to static values, you can configure your firewall to accept traffic on these ports.
There are two types of administration clients in WebSphere Application Server V5: a browser-based administration console, and high function clients (e.g. wsadmin, Tivoli® Performance Viewer, etc.). Each has different port requirements.
The default port assignments for the browser-based console are 9090 and 9443. These can be viewed by looking at the admin_host virtual host (Figure 8) and the HTTP Transports for the DMgr (Figure 9), which is exposed beginning with WebSphere Application Server V5.0.1.
Figure 8. Viewing port assignments using Host Aliases
Figure 9. Viewing port assignments using HTTP Transports dialog
Should you choose to modify these ports, you will need to make the changes in both places; once in the Host Alias dialog, and once in the HTTP Transports for the DMgr dialog. The navigation paths to these dialogs are depicted in Figures 8 and 9. You will then need to configure your firewall to allow communication on the ports you have chosen.
Next, here is one specific example of a high function client: wsadmin. The default connection type for this client is SOAP on port 8879. Changing this port is also a two-step process:
- Modify the SOAP_CONNECTOR_ADDRESS End Point for the Deployment Manager.
- Modify the
com.ibm.ws.scripting.portproperty in the
wsadmin.propertiesfile, or specify the port number when invoking wsadmin from the command line. For example:
wsadmin -conntype SOAP -port <new port>
Alternatively, you can use RMI to connect wsadmin to the Deployment Manager. In this case, the default port is 9809, which is the BOOTSTRAP_PORT for this process. The RMI command to start wsadmin is:
wsadmin -conntype RMI -port 9809
One advantage of forcing wsadmin to use RMI is that the RMI run time will prompt for the administrative user ID and password, rather than requiring they be specified on the command line or in a properties file.
Whatever connection method you choose, you'll need to open the appropriate port on your firewall to allow access to the Deployment Manager. By the way, not only does restricting the ports for the wsadmin connection help to restrict access to the Deployment Manager, but it can also be used to help enforce that configuration changes are only made via the Deployment Manager; any changes made "locally" at the Node Agent are overwritten at the next repository synchronization. Restricting firewall access in this manner precludes wsadmin from connecting to the MBean server running in the Node Agent where an AdminConfig MBean is running.
If you have trouble with one of more nodes connecting to the Dmgr after restarting the Dmgr and Node Agent(s), stop the Node Agent(s) and run the
syncNode.bat/shcommand line script before restating the Node Agent(s). Don't forget to specify the port number when running syncNode.
The connector type chosen for the administration client is independent of the connection type chosen for internal server-to-server administrative communication (ie., management servers to application servers). You can use SOAP for internal server administrative communication and RMI for your administration clients, or vice versa, or make them both the same. The connector type used for internal administrative communication is specified via the Preferred Connector property, which is specified on the "Administration Services" tab for each server process.
Additional firewall considerations
Some customers may choose to separate the WebSphere application servers from their database and LDAP servers with a firewall. If you do this, you'll need to make provisions for the database connections from the application servers to the database servers. The ports utilized will vary by database, so consult your database documentation for the actual ports that should be used. Some example default ports are:
- DB2: 50000 and 50001
- Oracle: 1521
- SQL Server: 1433
- LDAP: 389 is the default, but if you choose to separate your LDAP server from your WebSphere servers with a firewall, this port will also need to be configured.
We have not discussed the protocol traffic between WebSphere Application Servers in the same cell because there are several additional ports that would require configuration: memory replication (DRS ports), the DMgr file transport, and others. Such a configuration is not recommended, since it adds great complexity with little, if any, additional protection. However, should you decide to do so, the specifics will vary depending upon your deployment topology. One possible topology is the separation of application servers running the Web container from application servers running the EJB container. In this case, the Web container application servers are EJB clients, so the steps described above for EJB clients will apply. Assuming that both the Web application servers and the EJB application servers are in the same cell, provisions will need to be made for the Node Agent NODE_MULTICAST_DISCOVERY_ADDRESS (a UDP protocol on port 5000) between each of the nodes in the cell, including the Deployment Manager node. You will also need to allow traffic for the Deployment Manager CELL_DISCOVERY_ADDRESS, CELL_MULTICAST_DISCOVERY_ADDRESS, and BOOTSTRAP_ADDRESS as well as the SOAP_CONNECTOR_ADDRESS for both the DMgr and Node Agent. Additionally, if you're using the WebSphere JMS Server you'll need to allow for both administration and application communication to this process. See Resources for a complete list of ports.
When configuring WebSphere Application Server V5 and your firewalls against unwanted intrusions, it's important to be patient and methodical. Correctly identifying the ports required for your environment, and opening only those ports, is critical for your success and your security. Using the information in this article as a guide, along with the reference material listed below, your firewall documentation, and a network tool such as netstat to assist in validating your port usage, you should be able to successfully and effectively secure your environment.
Special thanks to Keys Botzum for his assistance in reviewing this article, as well as for use of two slides from his WebSphere 50 Security Hardening presentation, which were the basis for many of the illustrations in this article. Thanks also to Pete Van Sickel for his assistance in independently validating the information listed by walking through the configuration and monitoring network traffic.
- WebSphere InfoCenter
- Implementing a Highly Available Infrastructure for WebSphere Application Server Network Deployment Version 5.0 without Clustering
- Server Clusters For High Availability in WebSphere Application Server Network Deployment Edition 5.0