...

Performance of a webApp.secure Environment Performance of a webApp.secure Environment

by user

on
Category: Documents
2

views

Report

Comments

Transcript

Performance of a webApp.secure Environment Performance of a webApp.secure Environment
Performance of a webApp.secure Environment
November 2007
Performance of a webApp.secure
Environment
1
Performance of a webApp.secure Environment
Table of Contents
Preface.................................................................................................................................... 3
Level of Understanding ....................................................................................................... 3
Objectives ............................................................................................................................... 3
Summary................................................................................................................................. 3
One virtual CPU on the webApp.secure server................................................................... 3
Multiple virtual CPUs on webApp.secure server and multiple physical CPUs on z/VM....... 4
Hardware equipment and software environment..................................................................... 4
Hardware and Software ...................................................................................................... 4
Host hardware................................................................................................................. 5
Network setup ................................................................................................................. 5
Storage server setup....................................................................................................... 5
Client hardware............................................................................................................... 5
Software.......................................................................................................................... 5
z/VM guest configuration ................................................................................................ 6
Test environment ............................................................................................................ 6
Setting up the DMZ - firewall rules ...................................................................................... 7
Firewall 2 ........................................................................................................................ 7
Firewall 1 ........................................................................................................................ 7
webApp.secure overview .................................................................................................... 8
Test case setup....................................................................................................................... 8
webApp.secure setup ......................................................................................................... 8
Workload............................................................................................................................. 9
Results .................................................................................................................................... 9
Scaling virtual CPUs on the webApp.secure guests ......................................................... 10
Varying physical CPUs on z/VM ....................................................................................... 13
Appendix A. Detailed set up examples.................................................................................. 14
WAProperties.xml ............................................................................................................. 14
Firewall iptables rules ....................................................................................................... 28
Firewall 2 ...................................................................................................................... 28
Firewall 1 ...................................................................................................................... 29
Appendix B. Glossary............................................................................................................ 30
Appendix C. Other Sources of Information............................................................................ 30
2
Performance of a webApp.secure Environment
Preface
Level of Understanding
Knowledge and understanding of enterprise-level computer environments and
WebSphere® Application Server will help you understand the results detailed in
this paper.
Objectives
webScurity Inc.'s webApp.secure protects Web application servers from Internet
attacks. Providing webApp.secure in the IBM System z™ environment ensures
that once the application stream is validated, all future communications are
physically secure. This utility of the IBM System z Linux® Utility Services is a
strategic direction, protecting Web applications from attack, in addition to
traditional firewall and perimeter security. It is inserted before the Web server in
the DMZ to protect end-to-end Web solutions from application attacks or
vulnerabilities.
The objective of this project was to determine the performance and CPU scaling
measurements for the webApp.secure environment.
The information obtained in these tests is to be used for IBM internal sizing
teams and should not be used to develop capacity sizing rules-of-thumb for
customer environments. For sizing and capacity planning, contact our educated
specialists from the IBM System z sizing team using the appropriate capacity
planning tools.
Summary
This section provides a short summary of our test results. Our test results and
recommendations are specific to our environment. Findings useful in our
environment might not apply in other environments with other workloads. When
reviewing our results, please keep in mind that the workload used for our testing
is a very heavy workload and was intended to drive the system to its limits.
Typical customer workloads might be much lighter. For our detailed test results
information, see Results.
One virtual CPU on the webApp.secure server
ƒ When increasing the workload on the webApp.secure server the
throughput increased quickly and reached a saturation point. At this
point the CPU utilization on the webApp.secure goes to about 90% and
limits the total throughput of the entire application system.
ƒ The other z/VM® guests were only lightly utilized, making the DMZ an
ideal environment that could be efficiently hosted under z/VM.
ƒ The z/OS® system with the WebSphere Application Server was also
lightly utilized.
3
Performance of a webApp.secure Environment
Multiple virtual CPUs on webApp.secure server and multiple physical CPUs on
z/VM
ƒ When we increased the number of virtual CPUs on the webApp.secure
server we also increased the number of physical CPUs on z/VM to cover
the additional load.
ƒ When the workload exceeded the saturation point, the stable behavior
was the same for one, two and four virtual CPUs.
ƒ At throughout saturation, the firewall and Web server in the DMZ were
only lightly utilized. This can indicate that hosting these systems under
z/VM, on a z/VM guest LAN, is advantageous over platforms requiring
separate hardware boxes, where these boxes would never be fully
utilized and network latency is incurred.
ƒ With a z/VM guest LAN and HiperSockets™ connection, response times
are good even in the case of transaction overload. This would be more
difficult and costly to achieve in a hardware-implemented network.
ƒ At webApp.secure throughput saturation, the z/OS LPAR CPU utilization
was also light with two CPUs being only half utilized.
ƒ In all multiple physical CPU cases, z/VM had more than one CPU free.
Reducing the number of physical CPUs on z/VM by one results in a
moderate degradation of throughout, 5%–10%, which is expected
because of queuing effects. The cost of having one less CPU may make
this an acceptable tradeoff.
Hardware equipment and software environment
This section provides details on the hardware and software used in our testing.
Topics include:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Host and client hardware used
Host and client software used
Network setup
Storage server setup
z/VM guest configuration
The test environment
Firewall rules
webApp.secure overview
Hardware and Software
The following section lists the hardware, software, network, configurations, and
test environment we used for our webApp.secure test runs.0.58ns (1.7 GHz)
4
Performance of a webApp.secure Environment
Host hardware
Two LPARs on a 16-way IBM System z9™, type 2094-S18:
ƒ One LPAR for z/VM equipped with:
ƒ 3, 4 or 5 CPs, dedicated
ƒ 5 GB memory, 0.5 GB expanded memory
ƒ OSA Express 2 gigabit Ethernet card (OSA code level 0805)
ƒ HiperSockets connection (LPAR to LPAR)
ƒ One LPAR for z/OS equipped with:
ƒ 2 CPs, dedicated
ƒ 4 GB memory
ƒ HiperSockets connection (LPAR to LPAR)
Network setup
ƒ The z/VM LPAR was connected to the client using a Fiber Gigabit
Ethernet Interface
ƒ The z/VM guests used virtual guest LAN(s) configured as type
HiperSockets with a maximum frame size (MFS) of 24 KB
ƒ The z/VM LPAR and the z/OS LPAR were connected via a HiperSockets
connection
Storage server setup
Enterprise Storage Server® (ESS) 2105 800
ƒ IBM 3390 disk model 3
ƒ Physical DDMs with 15,000 RPMs
Client hardware
One x330 PC with two processors, 1.26 GHz
Software
Table 1. Host and client software used
Product
Apache HTTP Server
Red Hat Enterprise Linux
SUSE Linux Enterprise Server
webApp.secure
WebSphere Application Server for z/OS
WebSphere Studio Workload Simulator
z/OS
z/VM
5
Version/Level
2.0.49
RHEL 4 ES (client)
SLES9 SP3
3.0-1
6.0.2
iwl-0-03309L (client)
1.07
5.2
Performance of a webApp.secure Environment
z/VM guest configuration
Each unit of the DMZ (firewall, Web server, webApp.secure server) was
implemented in a separate Linux guest. The z/VM guests were interconnected by
a z/VM guest LAN configured as type HiperSockets. All guests ran SLES9 SP3.
Test environment
Figure 1 shows the setup of the webApp.secure environment.
Figure 1. webApp.secure test environment
The test environment consisted of an IBM System z server and an IBM System
x™ server. The System z contained a z/VM LPAR with four guests and a z/OS
LPAR. Each functional component, like the firewalls, the webApp.secure server,
and the Apache Web server, were implemented as separate Linux systems
running as z/VM guests.
The network was split into three parts:
ƒ The System x and the System z servers were connected in the
ƒ
ƒ
ƒ
ƒ
unsecured external zone. The System x server contained the
webApp.secure workload generator, which drove the clients and
generated the workload.
The DMZ contained one guest with the webApp.secure Proxy Server
protected from the external zone with a firewall (Firewall 2) and the
Apache Web server. See Firewall 2 for the firewall rules we used.
The trusted internal zone was protected with another guest with a more
restrictive firewall (Firewall 1) and contained the z/OS WebSphere
Application Server. See Firewall 1 for the firewall rules we used.
The z/OS LPAR was connected to the z/VM LPAR through a
HiperSockets connection and contained the WebSphere Application
Server.
The guest network zones on z/VM were configured as HiperSockets
guest LANs.
6
Performance of a webApp.secure Environment
Setting up the DMZ – firewall rules
The firewall rules were structured in the following three areas:
ƒ Incoming traffic
ƒ Forwarding
ƒ Outgoing traffic
The strategy was to deny most everything at first and then allow some dedicated
connections. We setup the iptables rules to allow ping and SSH. In a production
environment, ping (ICMP) and SSH (TCP port 22) would probably be denied.
The detailed iptables commands used to implement the setup are shown in
Firewall iptables rules.
Firewall 2
The rules we used for firewall 2 were:
1. Incoming traffic
a.Stop all incoming traffic
1
2. Allow SSH session to firewall 2
1
3. Allow ICMP traffic to firewall 2
4. Allow all related and established traffic for firewall 2
5. Forwarding traffic
a.Stop all forwarding traffic
6. Allow forwarding of TCP traffic on IP interface 10.10.60.0 (client) port 80
(HTTP) and port 443 (HTTPS) to go to 192.168.40.95 (webApp.secure)
1
7. Allow forwarding of ICMP traffic
8. Allow forwarding of all related and established traffic
9. Outgoing traffic
a.Allow output traffic for ICMP
1
Firewall 1
The rules we used for firewall 1 were:
1. Incoming traffic
a. Stop all incoming traffic
1
2. Allow SSH session to firewall 1
1
3. Allow ICMP traffic to firewall 1
4. Allow all related and established traffic for firewall 1
5. Forwarding traffic
a. Stop all forwarding traffic
6. Allow forwarding of TCP traffic on interface 192.168.40.0 (guest LAN) to
go to 10.10.50.110 (HiperSockets to z/OS)
1
7. Allow forwarding of ICMP traffic
7
Performance of a webApp.secure Environment
8. Allow forwarding of all related and established traffic
9. Outgoing traffic
a. Allow output traffic for ICMP
1
webApp.secure overview
webApp.secure was positioned between the application server on z/OS and the
Internet-facing network firewall (Firewall 2 in Figure 1). It accepted all client
connections and validated their requests before allowing them to be processed by
the application server through a separate connection.
Request validation along with the isolation provided by a separate connection
meant the application server communicated with a single, trusted client –
webApp.secure. It never accepted connections or processed requests from an untrusted source.
The Internet-facing network firewall limited incoming traffic to standard HTTP
TCP port(s). webApp.secure accepted client connections that passed through the
network firewall on the standard HTTP TCP port(s). Requests from the client
were evaluated by webApp.secure to ensure they conformed to the Intended Use
Guidelines (IUG) (see the guidelines at webScurity, Inc.'s Web site:
http://www.webscurity.com/products.htm), the HTTP specification, and userdefined policies.
HTTP specifications and user-defined policies are specified in the
webApp.secure WAProperties.xml file (see WAProperties.xml).
Test case setup
webApp.secure setup
webApp.secure is distributed as an RPM file and installed with the "rpm -i"
command.
webApp.secure installs in /usr/local/wa and all required customization is
accomplished by the WAProperties.xml file located in /usr/local/wa/etc.
We made the following modifications to the WAProperties.xml file:
ƒ The IP address of the Apache HTTP Server was set to:
<web-server-name>webserver</web-server-name>
ƒ A list of "entry point" URLs for the Web site was stated. These are the
URL's that will be permitted access.
<entry-point>/WebSeal_pages/*</entry-point> <entrypoint>/PlantsByWebSphere/*</entry-point>
ƒ In the <ssl> stanza the following changes were made:
ƒ All SSL statements were set to:
<enable values="True,False" default="False">True</enable>
8
Performance of a webApp.secure Environment
ƒ To have no encryption between webApp.secure and Apache
HTTP Server we set the following:
<encrypt-to-web-server values="True,False"
default="True">False</encrypt-to-web-server>
For all other webApp.secure configuration properties we used the default settings.
See Appendix A, Detailed set up examples for the complete WAProperties.xml
file we used.
Additional information on the installing and setting up of webApp.secure is
available in the Welcome to webApp.secure and webApp.secure Installation and
Setup Guide documents available from webScurity, Inc. at:
http://www.webscurity.com.
Workload
The workload used in these tests was WebBench's static page content files. There
are approximately 6000 static pages in the WebBench webserver benchmark.
These files were placed on the WebSphere Application Server in the
PlantsByWebSphere directory.
An IBM internal version of the WebSphere Studio Workload Simulator was used
to drive the HTTP/HTTPS requests to the system under test. The WebSphere
Studio Workload Simulator engine (iwlengine) runs on the client machine and
generates requests continuously until the run time length is reached. WebSphere
Studio Workload Simulator allows the specification of the number of client tasks
that will be generating requests and is driven by a script.
In addition to valid file name requests, there are requests for invalid file names.
The WebSphere Studio Workload Simulator script contained 6001 get or get ssl
statements.
Results
This section provides our detailed test results and conclusions. Results from our
benchmark test runs are shown.
The following tests were performed:
ƒ Scaling the number of virtual CPUs on the webApp.secure z/VM guest
machine from one to two to four
ƒ Vary the number of physical CPUs on the z/VM LPAR for the same
number of virtual CPUs on the webApp.secure guests
9
Performance of a webApp.secure Environment
The following table shows the configuration of the LPARs and the z/VM guests
used for the tests.
Table 2. webApp.secure CPU scaling configuration
System/Guest
z/VM
z/OS
webApp.secure
Apache HTTP Server
Firewall1
Firewall2
Memory
5120 MB
4096 MB
512 MB
512 MB
512 MB
512 MB
CPUs
3(4)(5)
2
1(2)(4)
1
1
1
Scaling virtual CPUs on the webApp.secure guests
In these tests, virtual CPUs on the webApp.secure guest machine were increased
from one to two to four. We also increased the number of physical CPUs on the
z/VM LPAR to keep the environment around the webApp.secure server constant.
However, we did not test with six CPUs because of the significant amount of
unused CPU capacity with five CPUs.
The following table shows how the virtual CPUs from the webApp.secure guest
and the physical CPUs on the z/VM LPAR are scaled and also shows the number
of clients used in this configuration.
Table 3. Scaling virtual CPUs on webApp.secure server and physical CPUs on
System z
# of Virtual CPUs –
webApp.secure
1
2
4
# of Physical CPUs –
z/VM
3
4
5
# of Clients
1 - 20
1 - 50
1 - 90
Throughput
Figure 2 shows the throughput scaling for one, two, and four virtual CPUs on the
webApp.secure server.
10
Performance of a webApp.secure Environment
Figure 2. CPU scaling – throughput (HTTP)
Observations: With each number of virtual CPUs, throughput reaches a
saturation point and stays stable even as the client requests are increased. The
point of saturation scales with the number of CPUs.
CPU utilization
In this paper, the CPU utilization values are always normalized in a way that
100% means one CPU is fully utilized. The CPU utilization charts below (Figure
3 and Figure 4) show the utilization for each LPAR (z/VM or z/OS) by a line
with triangle symbols. The details of how the z/VM guests use the CPU is shown
with stacked bars, which should sum up to the z/VM utilization without the
operating system CP related CPU part, so it is always a little bit lower than the
z/VM LPAR load. If the CPU load from a guest in the legend is not visible, that
means it is too low to display.
The following figures show the CPU utilization in our environment, Figure 3 for
two virtual CPUs and Figure 4 for four virtual CPUs.
11
Performance of a webApp.secure Environment
Figure 3. CPU scaling, CPU Utilization (HTTP) – Two virtual CPUs on
webApp.secure server
Figure 4. CPU scaling, CPU Utilization (HTTP) – Four virtual CPUs on
webApp.secure server
Observations: When throughput saturation is reached, the CPU utilization on the
webApp.secure server flattens. This happens even though the system is not fully
utilized. The effort of the other systems in the DMZ (firewall, Web server) is less
than a half CPU in all cases, which is very low. The two z/OS CPUs are utilized
around a half and z/VM also has more than one CPU free.
Due to the short latency of the guest LAN and HiperSockets connection, the
response times remained good, under 50 ms, even during the overloaded cases.
12
Performance of a webApp.secure Environment
Conclusion: The systems in the DMZ are very well placed in the z/VM guest
LAN because the alternative on other platforms require separate hardware boxes,
which are never fully utilized, and a full network infrastructure with cables and a
switch. You can achieve good response times using a HiperSockets connection
and a z/VM guest LAN.
Varying physical CPUs on z/VM
Because z/VM has a capacity of more than one CPU free in each case, we did
additional CPU scaling tests with z/VM with one physical CPU less, but all
virtual CPUs unchanged, which led to an increase of the CPU over commitment.
Table 4 shows the test cases used to produce Figure 5.
Table 4. Varying physical CPUs on z/VM test cases
# of Virtual CPUs – webApp.secure
2
2
4
4
# of Physical CPUs – z/VM
3
4
4
5
Throughput
Figure 5 compares the throughput of the original results with the result having
z/VM with one less physical CPU.
Figure 5. CPU scaling - throughput (HTTP)
Observations: Reducing the number of CPUs for z/VM by one reduces the
throughput between 5% and 10%.
Conclusion: The reduction of throughput is expected to be caused by queuing
effects. This means that three parallel units for the same work have higher
latencies compared with four units. However, saving one CPU might be an
advantage, which is worth a slight reduction in throughput. Be aware that we
13
Performance of a webApp.secure Environment
implemented a secure server environment, including a DMZ, which uses seven
virtual CPUs on four physical CPUs without any physical network cable.
Appendix A. Detailed set up examples
This appendix contains detailed examples of configuration and sample scripts we
used in our test runs.
WAProperties.xml
<?xml version="1.0"?>
<webApp.secure-properties version="3.0">
<!-*******************************************************
*****************
<web-server-name>
Name of the server running the Web/application
server webApp.secure
is protecting.
This can be in the form of:
1. an internal machine name (i.e. "jupiter",
"server")
2. a fully-qualified host name (i.e.
"www.webscurity.com",
"www1.webscurity.com")
3. an IP address (i.e. "192.168.0.1")
Example: <web-servername>www.webscurity.com</web-server-name>
*******************************************************
*****************
-->
<web-server-name>webserver</web-server-name>
<!-*******************************************************
*****************
<web-server-port>
TCP port number of the Web/application server
webApp.secure is
protecting.
**Note: In production, this would normally be a
non-standard TCP port
number that is CLOSED in the network
firewall. In test mode,
this would normally be 80.
Example: <web-server-port>8080</web-serverport>
*******************************************************
*****************
-->
14
Performance of a webApp.secure Environment
<web-server-port>80</web-server-port>
<!-*******************************************************
*****************
<listen-ip>
IP address webApp.secure should listen on.
Normally this will be left blank indicating it
will be listening on all
available IP addresses.
Example: <listen-ip>192.168.100.23</listen-ip>
*******************************************************
*****************
-->
<listen-ip></listen-ip>
<!-*******************************************************
*****************
<listen-port>
TCP port number webApp.secure should listen on.
Normally this will be the standard TCP port 80
for HTTP traffic.
Example: <listen-port>80</listen-port>
*******************************************************
*****************
-->
<listen-port>80</listen-port>
<!-*******************************************************
*****************
<host-names>
Fully-qualified "Internet" host name(s) of the
Web/application server
webApp.secure is protecting.
Example: <host-names>
<host-name>www.webscurity.com</hostname>
</host-names>
*******************************************************
*****************
-->
<host-names>
<host-name></host-name>
</host-names>
<!-*******************************************************
*****************
15
Performance of a webApp.secure Environment
<hide-server-identity>
Flag to hide server identification information
from the client to
prevent banner-grabbing.
**Note: Defaults to "True" and must be
explicitly set to "False"
in order to disable hiding the server
information.
**Note: Case-sensitive. Will internally set to
"True" unless this
field reads "False" (Upper-case 'F',
lower case "alse").
Example: <hide-server-identity>True</hideserver-identity>
*******************************************************
*****************
-->
<hide-server-identity values="True,False"
default="True">True
</hide-server-identity>
<!-*******************************************************
*****************
<site-test>
Flag to indicate webApp.secure is performing a
test with a Web site.
When set to True, webApp.secure will replace
the client Host: HTTP
header with the value of the <host-name>
property (it uses the first
entry if ther are multiple entries).
For example, this allows you to use
http://localhost:1111/ in the
browser's address bar to connect to your Web
server through
webApp.secure (assuming webApp.secure is
running on the localhost and
listening on TCP port 1111).
It is preferred to leave the <site-test>
property to False (even while
testing) and modify your local "hosts" file to
direct traffic through
webApp.secure.
Example: <site-test>True</site-test>
*******************************************************
*****************
-->
<site-test values="True,False"
default="False">False</site-test>
<!--
16
Performance of a webApp.secure Environment
*******************************************************
*****************
<http-methods>
List of valid HTTP request methods
webApp.secure should honor.
**Note: Defaults to GET, HEAD, and POST only,
others must be explicitly
added.
*******************************************************
*****************
-->
<http-methods>
<http-method>GET</http-method>
<http-method>HEAD</http-method>
<http-method>POST</http-method>
</http-methods>
<!-*******************************************************
*****************
<entry-points>
List of "entry point" URL's for the Web site.
The default is "/", but
one might also define "/index.html" (for
example) as well.
While there is no limit to how many entry
points can be defined,
generally speaking, the fewer there are, the
more secure the site will
be.
An optional "protocol" attribute can be used
with the entry-point
element. Setting protocol="https" indicates the
entry point should be
accessible over an encrypted link (https).
Requests for entry points
identified as https-only over an unencrypted
link (http), will
automatically be blocked.
Example:
<entry-points>
<entry-point>/unsecure.php</entry-point>
<entry-point
protocol="https">/secure.php</entry-point>
</entry-points>
*******************************************************
*****************
-->
<entry-points>
<entry-point>/</entry-point>
17
Performance of a webApp.secure Environment
<entry-point>/WebSeal_pages/*</entrypoint>
<entry-point>/wbtree/*</entry-point>
<entrypoint>/PlantsByWebSphere/*</entry-point>
</entry-points>
<!-*******************************************************
*****************
<unprotected-dirs>
List of unrestricted directory paths which are
useful to accommodate
URI's dynamically generated by client-side
script (JavaScript, VBScript,
etc.). Please refer to the User Guide for
complete details and
explanation.
Client requests for resources in these
directories are NOT restricted i.e. always allowed.
**Note: unprotected-dirs should be used VERY
sparingly to maintain
maximum security.
**Note: <unprotected-dir>/</unprotected-dir>
should NEVER be defined.
Doing so would give unrestricted access
to ALL resources in ALL
directories relative to "/".
An optional "protocol" attribute can be used
with the unprotected-dir
element. Setting protocol="https" indicates the
unprotected directory
should be accessible over an encrypted link
(https). Requests for
unprotected directories identified as httpsonly over an unencrypted
link (http), will automatically be blocked.
Example:
<unprotected-dirs>
<unprotecteddir>/unsecure/*.jpg</unprotected-dir>
<unprotected-di
protocol="https">/secure/*.gif</unprotected-dir>
</unprotected-dirs>
*******************************************************
*****************
-->
<unprotected-dirs>
<unprotected-dir></unprotected-dir>
</unprotected-dirs>
<!--
18
Performance of a webApp.secure Environment
*******************************************************
*****************
<smtp-alert>
Setup for SMTP alerts. Please refer to the User
Guide for complete
details and explanation.
Example:
<smtp-alert>
<enable>True</enable>
<server>mail.mycompany.com</server>
<port>25</server>
<subject>webApp.secure alert
message</subject>
<from>Primary Web Server</from>
<recipients>
<recipient>[email protected]</recipient>
</recipients>
<user-id>[email protected]</user-id>
<password>myPassword123</password>
</smtp-alert>
*******************************************************
*****************
-->
<smtp-alert>
<enable values="True,False"
default="False">False</enable>
<server></server>
<port default="25">25</port>
<subject>webApp.secure alert
message</subject>
<from></from>
<recipients>
<recipient></recipient>
</recipients>
<user-id></user-id>
<password></password>
</smtp-alert>
<!-*******************************************************
*****************
<http-alert>
Setup for HTTP alerts. Please refer to the User
Guide for complete
details and explanation.
Example:
<http-alert>
<enable>True</enable>
<server>192.168.0.2</server>
<port>8080</server>
19
Performance of a webApp.secure Environment
<action>/cgi-bin/alert.cgi</action>
<from>Primary Web Server</from>
</http-alert>
*******************************************************
*****************
-->
<http-alert>
<enable>False</enable>
<server></server>
<port>80</port>
<action></action>
<from></from>
</http-alert>
<!-*******************************************************
*****************
<net-alert>
Setup parameters for network alerts. Please
refer to the User Guide for
complete details and explanations.
Example:
<net-alert>
<enable>True</enable>
<recipients>
<recipient>Admin</recipient>
</recipients>
</net-alert>
*******************************************************
*****************
-->
<net-alert>
<enable values="True,False"
default="True">True</enable>
<recipients>
<recipient></recipient>
</recipients>
</net-alert>
<!-*******************************************************
*****************
<ssl>
Setup parameters for secure sockets layer
(SSL). Please refer to the
User Guide for complete details and
explanations.
*******************************************************
*****************
-->
20
Performance of a webApp.secure Environment
<ssl>
<enable values="True,False"
default="False">True</enable>
<prompt-passphrase values="True,False"
default="False">False</prompt-passphrase>
<listen-ip></listen-ip>
<listen-port default="443">443</listenport>
<certfile>/usr/local/wa/cert/watest.crt</cert-file>
<cert-keyfile>/usr/local/wa/cert/watest.key</cert-key-file>
<ca-cert-file></ca-cert-file>
<random-file></random-file>
<encrypt-to-web-server
values="True,False" default="True">False
</encrypt-to-web-server>
<web-server-port
default="443">443</web-server-port>
<allow-SSLv2 values="True,False"
default="False">False</allow-SSLv2>
</ssl>
<!-*******************************************************
*****************
<max-connections>
Maximum number of simultaneous requests
webApp.secure will serve.
*******************************************************
*****************
-->
<max-connections values="0 to max-integer"
default="5000">5000</max-connections>
<!-*******************************************************
*****************
<max-listen-queue>
Maximum number of pending connections
webApp.secure will queue.
*******************************************************
*****************
-->
<max-listen-queue default="511">511</maxlisten-queue>
<!-*******************************************************
*****************
<keep-alive-timeout>
21
Performance of a webApp.secure Environment
Number of seconds to wait for a subsequent
request before webApp.secure
closes the connection.
*******************************************************
*****************
-->
<keep-alive-timeout default="15">15</keepalive-timeout>
<!-*******************************************************
*****************
<log-request-headers>
List of HTTP request headers webApp.secure will
log - regardless of
log_level (see the User Guide for details
regarding the log_level
setting).
Example:
<log-request-headers>
<log-request-header>Referer:</logrequest-header>
</log-request-headers>
*******************************************************
*****************
-->
<log-request-headers>
<log-request-header></log-requestheader>
</log-request-headers>
<!-*******************************************************
*****************
<log-response-headers>
List of HTTP response headers webApp.secure
will log - regardless of
log_level (see the User Guide for details
regarding the log_level
setting).
Example:
<log-response-headers>
<log-responseheader>Connection:</log-response-header>
<log-response-header>Setcookie:</log-response-header>
</log-response-headers>
*******************************************************
*****************
-->
22
Performance of a webApp.secure Environment
<log-response-headers>
<log-response-header></log-responseheader>
</log-response-headers>
<!-*******************************************************
*****************
<form-validation>
Setup parameters for HTML form validation.
Please refer to the User
Guide for complete details and explanations.
*******************************************************
*****************
-->
<form-validation>
<enable values="True,False"
default="True">True</enable>
<release-on-submit values="True,False"
default="False">False</release-on-submit>
<action-required values="True,False"
default="True">True</action-required>
</form-validation>
<!-*******************************************************
*****************
<cookie-validation>
Setup parameters for HTTP cookie validation.
Please refer to the User
Guide for complete details and explanations.
*******************************************************
*****************
-->
<cookie-validation>
<enable values="True,False"
default="True">True</enable>
<strict values="True,False"
default="False">False</strict>
</cookie-validation>
<!-*******************************************************
*****************
<special-character-filters>
List of special characters for webApp.secure to
filter for given input
field types.
**Note: Default character set includes <>"';()
for ALL HTML form
text data entry field types.
23
Performance of a webApp.secure Environment
*******************************************************
*****************
-->
<special-character-filters>
<char-set fieldtype="TEXT">&lt;&gt;"';()</char-set>
<char-set fieldtype="TEXTAREA">&lt;&gt;"';()</char-set>
<char-set fieldtype="PASSWORD">&lt;&gt;"';()</char-set>
</special-character-filters>
<!-*******************************************************
*****************
<activity-flush-count>
Number of lines to write to the activity log
file before flushing. To
maintain the integrity of the activity log
file, it will be flushed
(actually closed and re-opened) every
<activity-flush-count> OR 30
seconds (whichever comes first). Setting this
value too low has a
significant negative impact on performance.
Setting it too high may
compromise the integrity of the log file in the
event of a system
failure.
*******************************************************
*****************
-->
<activity-flush-count values="0 to max-integer"
default="1000">1000
</activity-flush-count>
<!-*******************************************************
*****************
<form-cleanup>
Setup parameters for form IUG cleanup. Over
time, there will be form
IUG's stored in memory that will likely never
be needed - i.e. a
particular form will never be submitted by a
user and therefore never
need validation.
*******************************************************
*****************
-->
24
Performance of a webApp.secure Environment
<form-cleanup>
<enable values="True,False"
default="False">True</enable>
<seconds></seconds>
<minutes></minutes>
<hours></hours>
<days>15</days>
</form-cleanup>
<!-*******************************************************
*****************
<cookie-cleanup>
Setup parameters for cookie IUG cleanup.
*******************************************************
*****************
-->
<cookie-cleanup>
<enable values="True,False"
default="False">True</enable>
<seconds></seconds>
<minutes></minutes>
<hours></hours>
<days>15</days>
</cookie-cleanup>
<!-*******************************************************
*****************
<w3c-extended-log-file>
Definition block for W3C extended form logging.
Please see the User
Guide for complete details.
*******************************************************
*****************
-->
<w3c-extended-log-file>
<enable values="True,False"
default="False">False</enable>
<truncate values="True,False"
default="False">False</truncate>
<!-- Directory path for log files
(directory-only - not file name) -->
<log-file-directory></log-filedirectory>
<!-- The amount of time that should
pass before a new log file is started. -->
<!-- To disable rollover, set all
intervals to False. -->
<rollover-period>
<Hourly>True</Hourly>
25
Performance of a webApp.secure Environment
<Daily>False</Daily>
<Weekly>False</Weekly>
<Monthly>False</Monthly>
</rollover-period>
<!-- W3C extended fields to include in
each line of the log file. -->
<fields>
<field>date</field>
<field>time</field>
<field>c-ip</field>
<field>cs-method</field>
<field>cs-uri</field>
<field>cs-uri-stem</field>
<field>cs-uri-query</field>
<field>s-status</field>
<field>sc-bytes</field>
</fields>
</w3c-extended-log-file>
<!-*******************************************************
*****************
<syslog>
Definition block for system logging (UNIX
syslog/Windows EventLog).
When <enable> is "True", all error and select
informational messages
will be logged to the UNIX syslog (if
available) or Windows EventLog.
Setting the value of <enable> to "False" will
disable all logging to
the syslog or EventLog, with the exception of
startup errors.
*******************************************************
*****************
-->
<syslog>
<enable values="True,False"
default="True">True</enable>
</syslog>
<!-*******************************************************
*****************
<passive-mode>
Flag to indicate webApp.secure is running in
"passive mode". When
<passive-mode> is "True", all malicious
activity will be identified,
logged, and alerted, but allowed to pass
through. When <passive-mode> is
"False", all malicious activity identified will
26
Performance of a webApp.secure Environment
be logged, alerted, and
blocked.
Example: <passive-mode>True</passive-mode>
*******************************************************
*****************
-->
<passive-mode values="True,False"
default="False">False</passive-mode>
<!-*******************************************************
*****************
<remote-admin>
Definition block for remote administration
setup. These settings define
how (if) remote administration will be done via
a standard Web browser.
Please refer to the User Guide for complete
details.
*******************************************************
*****************
-->
<remote-admin>
<enable values="True,False"
default="True">True</enable>
<listen-ip></listen-ip>
<listen-port>8020</listen-port>
<password>21232f297a57a5a743894a0e4a801fc3</password>
<client-ips>
<client-ip></client-ip>
</client-ips>
<allow-SSLv2 values="True,False"
default="False">False</allow-SSLv2>
</remote-admin>
<!-*******************************************************
*****************
<process-javascript>
Flag to indicate webApp.secure should process
JavaScript.
Example: <process-javascript>True</processjavascript>
*******************************************************
*****************
-->
<process-javascript values="True,False"
default="True">True</process-javascript>
<!--
27
Performance of a webApp.secure Environment
*******************************************************
*****************
<strict-https>
Flag to indicate webApp.secure should strictly
enforce https URL's.
Example: <strict-https>True</strict-https>
*******************************************************
*****************
-->
<strict-https values="True,False"
default="True">True</strict-https>
<!-*******************************************************
*****************
<client-ip-header>
Flag to indicate webApp.secure should send the
client IP address in the
WA-Client-IP: custom HTTP header.
Example: <client-ip-header>True</client-ipheader>
*******************************************************
*****************
-->
<client-ip-header values="True,False"
default="True">True</client-ip-header>
</webApp.secure-properties>
<!-- Copyright (C) 2002 webScurity Inc. - All Rights
Reserved -->
Firewall iptables rules
Firewall 2
The rules we used for firewall 2 were:
Stop all incoming traffic using the following command:
iptables -P INPUT DROP
Allow SSH session to firewall 2 by using the following command:
iptables -A INPUT -p tcp --dport 22 -s 0/0 -j ACCEPT
Allow ICMP traffic to firewall 2 by using the following command:
iptables -A INPUT -p icmp -j ACCEPT
Allow all related and established traffic for firewall 2 by using the following
command:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT
28
Performance of a webApp.secure Environment
Stop all forwarding by using the following command:
iptables -P FORWARD DROP
Allow forwarding of TCP traffic on IP interface 10.10.60.0 (client) port 80
(HTTP) and port 443 (HTTPS) to go to 192.168.40.95 (webApp.secure) by
using the following commands:
iptables -A FORWARD -p tcp --dport 80 -s 10.10.60.0/24 -d
192.168.40.95 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -s 10.10.60.0/24 -d
192.168.40.95 -j ACCEPT
Allow forwarding of ICMP traffic by using the following command:
iptables -A FORWARD -p icmp -j ACCEPT
Allow forwarding of all related and established traffic by using the following
command:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j
ACCEPT
Allow output traffic for ICMP by using the following command:
iptables -A OUTPUT -p icmp -j ACCEPT
Firewall 1
The rules we used for firewall 1 were:
Stop all incoming traffic by using the following command:
iptables -P INPUT DROP
Allow SSH session to firewall 1 by using the following command:
iptables -A INPUT -p tcp --dport 22 -s 0/0 -j ACCEPT
Allow ICMP traffic to firewall 1 by using the following command:
iptables -A INPUT -p icmp -j ACCEPT
Allow all related and established traffic for firewall 1 by using the following
command:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT
Stop all forwarding by using the following command:
iptables -P FORWARD DROP
Allow forwarding of TCP traffic on interface 192.168.40.0 (guest LAN) to go
to 10.10.50.110 (HiperSockets to z/OS) by using the following command:
iptables -A FORWARD -p tcp -i hsi1 -o hsi2 -d 10.10.50.110 -j
ACCEPT
Allow forwarding of ICMP traffic by using the following command:
iptables -A FORWARD -p icmp -j ACCEPT
29
Performance of a webApp.secure Environment
Allow forwarding of all related and established traffic by using the following
command:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j
ACCEPT
Allow output traffic for ICMP by using the following command:
iptables -A OUTPUT -p icmp -j ACCEPT
Appendix B. Glossary
ƒ DMZ
Demilitarized zone. A DMZ is a network area that sits between an
organization's internal network and an external network, usually the
Internet. Access from the DMZ to the internal zone is as restricted as
possible. In our tests, only the proxy was able to access well-defined
targets in the internal zone from the DMZ.
ƒ HTTP
Hyper Text Transfer Protocol. The communications protocol that
enables Web browsing.
ƒ HTTPS
A Web protocol for secure transactions that encrypts and decrypts user
page requests and pages returned by the Web server.
Appendix C. Other Sources of Information
For information on WebSphere Application Server see the following
ƒ The WebSphere software page at:
http://www.ibm.com/software/info1/websphere/index.jsp?tab=products/
apptransaction
ƒ z/OS Getting Started: WebSphere Process Server and WebSphere
Enterprise Service Bus, V6 at:
http://www.redbooks.ibm.com/redpieces/abstracts/sg247378.html?Open
ƒ WebSphere Application Server Version 6.0.x information center at:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/
com.ibm.websphere.base.doc/info/aes/ae/rtrb_securitycomp.html
For information on Linux on IBM eServer™ zSeries® see:
www.ibm.com/servers/eserver/zseries/os/linux/
For information on z/VM see:
www.vm.ibm.com
For information in Apache HTTP Server see:
http://httpd.apache.org/docs/
For information on IBM open source projects see:
www.ibm.com/developerworks/opensource/index.html
30
Performance of a webApp.secure Environment
Detailed information on webApp.secure can be found at the webScurity, Inc.
Web site at:
http://www.webscurity.com/products.htm
Information available at the webScurity Web site includes:
ƒ
ƒ
ƒ
ƒ
Quick Start Guide
Setup Guide
Brochure
Whitepaper
31
Performance of a webApp.secure Environment
© Copyright IBM Corporation 2007
IBM Corporation
New Orchard Rd.
Armonk, NY 10504
U.S.A.
Produced in the United States of America
11/07
All Rights Reserved
IBM, IBM logo, Enterprise Storage Server, eServer, HiperSockets, System x, System z, System z9,
WebSphere, zSeries, z/OS, and z/VM are trademarks or registered trademarks of International Business
Machines Corporation of the United States, other countries or both.
The following are trademarks or registered trademarks of other companies
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United
States, other countries or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Intel is a trademark of Intel Corporation in the United States, other countries or both.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
SUSE is a registered trademark of Novell, Inc., in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
Information concerning non-IBM products was obtained from the suppliers of their products or their
published announcements. Questions on the capabilities of the non-IBM products should be
addressed with the suppliers.
IBM hardware products are manufactured from new parts, or new and serviceable used parts.
Regardless, our warranty terms apply.
IBM may not offer the products, services or features discussed in this document in other countries, and
the information may be subject to change without notice. Consult your local IBM business contact for
information on the product or services available in your area.
THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS PROVIDED FOR INFORMATIONAL
PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY
OF THE INFORMATION CONTAINED IN THIS DOCUMENTATION, IT IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON
(R)
IBM'S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM
WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE
USE OF, OR OTHERWISE RELATED TO, THIS DOCUMENTATION OR ANY OTHER DOCUMENTATION.
NOTHING CONTAINED IN THIS DOCUMENTATION IS INTENDED TO, NOR SHALL HAVE THE
EFFECT OF, CREATING ANY WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS
OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE
AGREEMENT GOVERNING THE USE OF IBM SOFTWARE
1. This rule is for maintenance only and would probably not be
implemented in a production environment.
ZSW03026-USEN-00
32
Fly UP