Performance of a webapp.secure Environment

Transcription

1 Performance of a webapp.secure Environment

2 ii Performance of a webapp.secure Environment

3 Contents Performance of a webapp.secure Environment Objectives for the webapp.secure performance tests 1 Summary for the webapp.secure performance tests. 1 Hardware equipment and software environment for the webapp.secure performance tests Test environment Setting up the DMZ - firewall rules webapp.secure overview Test case setup for the webapp.secure performance tests Results for the webapp.secure performance tests.. 7 Scaling virtual CPUs on the webapp.secure guests 7 Varying physical CPUs on z/vm Detailed set up examples for the webapp.secure performance tests Firewall iptables rules Glossary for the webapp.secure performance tests 20 Other sources of information for the webapp.secure performance tests Notices for the webapp.secure performance tests.. 21 iii

4 iv Performance of a webapp.secure Environment

5 Performance of a webapp.secure Environment WebScurity s webapp.secure protects Web application servers from Internet attacks. This utility of the IBM System z Linux Utility Services is a strategic direction, protecting Web applications from attacks in addition to traditional firewall and perimeter security. Published November 2007 This paper determines the performance of a webapp.secure environment. It shows that the implementation of a DMZ with all its services and servers is a very good case for server consolidation on z/vm. To view or download the PDF version of this document, click on the following link: Performance of a webapp.secure Environment (about 456 KB) Objectives for the webapp.secure performance tests The objective of this project was to determine the performance and CPU scaling measurements for the webapp.secure environment. 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 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 for the webapp.secure performance tests After performing performance tests on our webapp.secure test environment, we compiled a summary of our results and recommendations. 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 for the webapp.secure performance tests on page 7. One virtual CPU on the webapp.secure server v When increasing the workload on the webapp.secure server the throughput increased quickly and reached a saturation point. At this point the CPU 1

6 v v 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. Multiple virtual CPUs on webapp.secure server and multiple physical CPUs on z/vm v v v v v v 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 for the webapp.secure performance tests To perform our webapp.secure tests, we created a customer-like environment. We configured the hardware and software, network, storage server, and the DMZ. Hardware and Software The following section lists the hardware, software, network, configurations, and test environment we used for our webapp.secure test runs. Host hardware Two LPARs on a 16-way IBM System z9, type 2094-S18: v 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) v One LPAR for z/os equipped with: 2 CPs, dedicated 4 GB memory 2 Performance of a webapp.secure Environment

7 HiperSockets connection (LPAR to LPAR) Network setup v v v 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) v IBM 3390 disk model 3 v 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 Version/Level Apache HTTP Server Red Hat Enterprise Linux SUSE Linux Enterprise Server RHEL 4 ES (client) SLES9 SP3 webapp.secure WebSphere Application Server for z/os WebSphere Studio Workload Simulator iwl l (client) z/os 1.07 z/vm 5.2 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 The test environment consisted of an IBM System z server and an IBM System x server. Figure 1 on page 4 shows the setup of the webapp.secure environment. Performance of a webapp.secure Environment 3

8 Figure 1. webapp.secure test environment 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: v 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. v 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 on page 5 for the firewall rules we used. v 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 on page 5 for the firewall rules we used. v The z/os LPAR was connected to the z/vm LPAR through a HiperSockets connection and contained the WebSphere Application Server. v The guest network zones on z/vm were configured as HiperSockets guest LANs. Setting up the DMZ - firewall rules The firewall rules we used for our webapp.secure environment are detailed here. The firewall rules were structured in the following three areas: v Incoming traffic v Forwarding v 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 on page Performance of a webapp.secure Environment

9 Firewall 2 The rules we used for firewall 2 were: 1. Incoming traffic a. Stop all incoming traffic 2. Allow SSH session to firewall 2 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 (client) port 80 (HTTP) and port 443 (HTTPS) to go to (webapp.secure) 7. Allow forwarding of ICMP traffic 8. Allow forwarding of all related and established traffic 9. Outgoing traffic a. Allow output traffic for ICMP Note: Rules 2, 3, 7, and 9a are for maintenance only and would probably not be implemented in a production environment. Firewall 1 The rules we used for firewall 1 were: 1. Incoming traffic a. Stop all incoming traffic 2. Allow SSH session to firewall 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 (guest LAN) to go to (HiperSockets to z/os) 7. Allow forwarding of ICMP traffic 8. Allow forwarding of all related and established traffic 9. Outgoing traffic a. Allow output traffic for ICMP Note: Rules 2, 3, 7, and 9a are for maintenance only and would probably not be implemented in a production environment. webapp.secure overview The webapp.secure environment we used is summarized in this section. webapp.secure was positioned between the application server on z/os and the Internet-facing network firewall (Firewall 2 in Figure 1 on page 4). It accepted all client connections and validated their requests before allowing them to be processed by the application server through a separate connection. Performance of a webapp.secure Environment 5

10 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 un-trusted 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: the HTTP specification, and user-defined policies. HTTP specifications and user-defined policies are specified in the webapp.secure WAProperties.xml file (see WAProperties.xml on page 11). Test case setup for the webapp.secure performance tests To perform the webapp.secure performance tests we needed to configure webapp.secure and the workload software. 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: v The IP address of the Apache HTTP Server was set to: <web-server-name>webserver</web-server-name> v 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> <entry-point>/ PlantsByWebSphere/*</entry-point> v In the <ssl> stanza the following changes were made: All SSL statements were set to: <enable values= True,False default= False >True</enable> 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-toweb-server> For all other webapp.secure configuration properties we used the default settings. See Detailed set up examples for the webapp.secure performance tests on page 11 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: 6 Performance of a webapp.secure Environment

11 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 for the webapp.secure performance tests After performing our webapp.secure performance tests, we charted our test results, interpreted the results, and created recommendations. The following tests were performed: v Scaling the number of virtual CPUs on the webapp.secure z/vm guest machine from one to two to four v Vary the number of physical CPUs on the z/vm LPAR for the same number of virtual CPUs on the webapp.secure guests 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 Memory CPUs z/vm 5120 MB 3(4)(5) z/os 4096 MB 2 webapp.secure 512 MB 1(2)(4) Apache HTTP Server 512 MB 1 Firewall1 512 MB 1 Firewall2 512 MB 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. Performance of a webapp.secure Environment 7

12 Table 3. Scaling virtual CPUs on webapp.secure server and physical CPUs on System z # of Virtual CPUs - # of Physical CPUs - z/vm # of Clients webapp.secure Throughput Figure 2 shows the throughput scaling for one, two, and four virtual CPUs on the webapp.secure server. 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 on page 9 and Figure 4 on page 9) 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 on page 9 for two virtual CPUs and Figure 4 on page 9 for four virtual CPUs. 8 Performance of a webapp.secure Environment

13 Figure 3. CPU scaling, CPU Utilization (HTTP) - 2 virtual CPUs on webapp.secure server Figure 4. CPU scaling, CPU Utilization (HTTP) - 4 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. 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. Performance of a webapp.secure Environment 9

14 Related information webapp.secure performance tests - hardware equipment and software environment To perform our webapp.secure tests, we created a customer-like environment. We configured the hardware and software, network, storage server, and the DMZ. webapp.secure performance tests - test case setup To perform the webapp.secure performance tests we needed to configure webapp.secure and the workload software. webapp.secure performance tests - detailed set up examples The detailed examples of configuration and sample scripts we used in our test runs are shown here. webapp.secure performance tests - glossary Terms we used in our webapp.secure performance tests paper are defined here. webapp.secure performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. 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 on page 11. Table 4. Varying physical CPUs on z/vm test cases # of Virtual CPUs - webapp.secure # of Physical CPUs - z/vm Throughput Figure 5 on page 11 compares the throughput of the original results with the result having z/vm with one less physical CPU. 10 Performance of a webapp.secure Environment

15 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 implemented a secure server environment, including a DMZ, which uses seven virtual CPUs on four physical CPUs without any physical network cable. Related information webapp.secure performance tests - hardware equipment and software environment To perform our webapp.secure tests, we created a customer-like environment. We configured the hardware and software, network, storage server, and the DMZ. webapp.secure performance tests - test case setup To perform the webapp.secure performance tests we needed to configure webapp.secure and the workload software. webapp.secure performance tests - detailed set up examples The detailed examples of configuration and sample scripts we used in our test runs are shown here. webapp.secure performance tests - glossary Terms we used in our webapp.secure performance tests paper are defined here. webapp.secure performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Detailed set up examples for the webapp.secure performance tests The detailed examples of configuration and sample scripts we used in our test runs are shown here. 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 Performance of a webapp.secure Environment 11

16 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. " "www1.webscurity.com") 3. an IP address (i.e. " ") Example: <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-server-port> <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> </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> </host-names> <host-names> <host-name></host-name> </host-names> <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</hide-server-identity> <hide-server-identity values="true,false" default="true">true 12 Performance of a webapp.secure Environment

17 </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 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> <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> <entry-point>/webseal_pages/*</entry-point> <entry-point>/wbtree/*</entry-point> <entry-point>/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. Performance of a webapp.secure Environment 13

18 **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 https-only over an unencrypted link (http), will automatically be blocked. Example: <unprotected-dirs> <unprotected-dir>/unsecure/*.jpg</unprotected-dir> <unprotected-di protocol="https">/secure/*.gif</unprotected-dir> </unprotected-dirs> <unprotected-dirs> <unprotected-dir></unprotected-dir> </unprotected-dirs> <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> </recipients> <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> </server> <port>8080</server> <action>/cgi-bin/alert.cgi</action> <from>primary Web Server</from> </http-alert> 14 Performance of a webapp.secure Environment

19 <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. <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</listen-port> <cert-file>/usr/local/wa/cert/watest.crt</cert-file> <cert-key-file>/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</max-listen-queue> <keep-alive-timeout> Number of seconds to wait for a subsequent request before webapp.secure closes the connection. Performance of a webapp.secure Environment 15

20 <keep-alive-timeout default="15">15</keep-alive-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:</log-request-header> </log-request-headers> <log-request-headers> <log-request-header></log-request-header> </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-response-header>connection:</log-response-header> <log-response-header>set-cookie:</log-response-header> </log-response-headers> <log-response-headers> <log-response-header></log-response-header> </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. <special-character-filters> 16 Performance of a webapp.secure Environment

21 <char-set field-type="text"><>"';()</char-set> <char-set field-type="textarea"><>"';()</char-set> <char-set field-type="password"><>"';()</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. <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-file-directory> 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> <Daily>False</Daily> <Weekly>False</Weekly> <Monthly>False</Monthly> </rollover-period> Performance of a webapp.secure Environment 17

22 18 Performance of a webapp.secure Environment 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 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</process-javascript> <process-javascript values="true,false" default="true">true</process-javascript> <strict-https>

23 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-ip-header> <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 Details on the firewall iptables rules that we used for our webapp.secure tests are shown here. Firewall 2 The rules we used for firewall 2 were: v 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 v Stop all forwarding by using the following command: iptables -P FORWARD DROP Allow forwarding of TCP traffic on IP interface (client) port 80 (HTTP) and port 443 (HTTPS) to go to (webapp.secure) by using the following commands: iptables -A FORWARD -p tcp --dport 80 -s /24 -d j ACCEPT iptables -A FORWARD -p tcp --dport 443 -s /24 -d 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 v Allow output traffic for ICMP by using the following command: iptables -A OUTPUT -p icmp -j ACCEPT Performance of a webapp.secure Environment 19

24 Firewall 1 The rules we used for firewall 1 were: v 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 v Stop all forwarding by using the following command: iptables -P FORWARD DROP Allow forwarding of TCP traffic on interface (guest LAN) to go to (HiperSockets to z/os) by using the following command: iptables -A FORWARD -p tcp -i hsi1 -o hsi2 -d 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 v Allow output traffic for ICMP by using the following command: iptables -A OUTPUT -p icmp -j ACCEPT Glossary for the webapp.secure performance tests Terms we used in our webapp.secure performance tests paper are defined here. 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. Other sources of information for the webapp.secure performance tests Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. For information on WebSphere Application Server see the following v The WebSphere software page at: 20 Performance of a webapp.secure Environment

25 v v apptransaction z/os Getting Started: WebSphere Process Server and WebSphere Enterprise Service Bus, V6 at: WebSphere Application Server Version 6.0.x information center at: com.ibm.websphere.base.doc/info/aes/ae/rtrb_securitycomp.html For information on Linux on IBM eserver zseries see: For information on z/vm see: For information in Apache HTTP Server see: For information on IBM open source projects see: Detailed information on webapp.secure can be found at the webscurity, Inc. Web site at: v Information available at the webscurity Web site includes: Quick Start Guide Setup Guide Brochure Whitepaper Notices for the webapp.secure performance tests Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and various Web sites. IBM, IBM eserver, IBM logo, DB2, DB2 Universal Database, DS8000, ECKD, FICON, HiperSockets, Performance Toolkit for z/vm, System Storage, System z, System z9, WebSphere, xseries, 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 and Xeon are trademarks of Intel Corporation in the United States, other countries or both. Performance of a webapp.secure Environment 21

26 Linux is a registered trademark of Linus Torvalds in the United States and other countries. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries, or both. 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. All statements regarding IBM s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here. 22 Performance of a webapp.secure Environment