InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.4: Firewalls and demilitarized zone (DMZ) configurations
7.1.4: Firewalls and demilitarized zone (DMZ) configurations
Firewalls are often used in multimachine systems to protect back-end resources such as
databases. They can also be used to protect application servers and even Web servers from
unauthorized outside access.
A demilitarized zone (DMZ) configuration involves multiple firewalls that add
layers of security between the Internet and a company's critical data and business logic.
A wide variety of topologies are appropriate for a DMZ environment. WebSphere Application
Server provides great flexiblity in configuring DMZ topologies, but the basic locations of
elements are as follows:

Comparison of DMZ configurations
Somehow, requests for applications being managed by WebSphere Application Server must
get from the Web server to the application servers, passing through firewalls. WebSphere
Application Server offers many configuration choices for accomplishing this goal. The
following table summarizes the benefits of each DMZ configuration option supported by the
product. The criteria for each topology are described after the table.
A checkmark ( ) represents an
advantage. Remote OSE and reverse proxy are the recommended configurations, but you will
still need to evaluate whether one of them suits your particular environment better than
the other options.
Benefit ( ) or statistic |
Remote OSE |
Thick servlet redirector |
Thin servlet redirector |
Administrative
agent |
Reverse proxy |
Compatible with product security |
 |
 |
|
 |
 |
Avoids data access from DMZ |
 |
|
 |
 |
 |
Supports NAT |
 |
|
|
|
 |
Avoids DMZ protocol switch |
|
|
|
|
 |
Allows encrypted link between Web server and application server |
|
 |
 |
 |
Depends on Web server |
Avoids single point of failure |
 |
 |
|
|
|
Minimum firewall holes |
1 per application server, plus 1 if WebSphere security is used on the Web server
machine, plus 1 if the OSERemoteConfig script is used to configure remote OSE on the Web
server machine |
3,
plus 1 per application server |
3,
plus 1 per application server |
3,
plus 1 per application server |
1 |
- Compatible with product security. IBM WebSphere Application Server
security protects applications and their components by enforcing authorization and
authentication policies. Configuration options compatible with product security are
desirable because they do not necessitate alternative security solutions.
- Avoids data access from DMZ. A DMZ configuration protects application
logic and data by creating a demilitarized zone between the public Web site and the
servers and databases where this valuable information is stored. Desirable DMZ topologies
do not have databases or servers that directly access databases in the DMZ. Because a
WebSphere administrative server needs access to a database for its configuration
information, it is often not a viable solution to run an administrative server in the DMZ.
- Supports Network Address Translation (NAT). A firewall product that
runs NAT receives packets for one IP address, and translates the headers of the packet to
send the packet to a second IP address. In environments with firewalls employing NAT,
avoid configurations involving complex protocols in which IP addresses are embedded in the
body of the IP packet, such as Java Remote Method Invocation (RMI) or Internet Inter-Orb
Protocol (IIOP). These IP addresses are not translated, making the packet useless.
- Avoids DMZ protocol switch. The Web server sends HTTP requests to
application servers behind firewalls. It is simplest to open an HTTP port in the firewall
to let the requests through. Configurations that require switching to another protocol
(such as IIOP), and opening firewall ports corresponding to the protocol, are less
desirable. They are often more complex to set up, and the protocol switching overhead can
impact performance.
- Allows encrypted link between Web server and application server. Configurations
that support encryption of communication between the Web server and application server
reduce the risk that attackers will be able to obtain secure information by
"sniffing" packets sent between the Web server and application server. A
performance penalty usually accompanies such encryption.
- Avoids single point of failure. A point of failure exists when one
process or machine depends on another process or machine. A single point of failure is
especially undesirable because if the point fails, the whole system will become
unavailable. When comparing DMZ solutions, a single point of failure refers to a single
point of failure between the Web server and application server. Various failover
configurations can minimize downtime and possibly even prevent a failure. However, these
configurations usually require additional hardware and administrative resources.
- Minimum required number of firewall holes. Configurations that minimize
the number of firewall ports are desirable because each additional firewall port leaves
the firewall more vulnerable to attackers.
- Relative performance. Some solutions are faster than others, in terms
of the number of client requests they can process per unit of time.
- Relative administrative maintenance. Some solutions require little or
no maintenance after you establish them, while others require periodic administrative
steps, such as stopping a server and starting it again after modifying resources that
affect the configuration. To learn about the necessary maintenance for a topology, review
the instructions for setting up and maintaining that topology. Of course, if you can
automate the necessary administrative steps, this might not concern you. See article 6.6.0.2 for information about the available command-line
clients and scripting possibilities.
|
|