Hardening

Mercury Business Availability Center
Hardening the Platform

Version 5.1 Service Pack 1
Mercury Business Availability Center, Version 5.1 Service Pack 1 Hardening the Platform This manual, and the accompanying software and other documentation, is protected by U.S. and international copyright laws, and may be used only in accordance with the accompanying license agreement. Features of the software, and of other products and services of Mercury Interactive Corporation, may be covered by one or more of the following patents: United States: 5,511,185; 5,657,438; 5,701,139; 5,870,559; 5,958,008; 5,974,572; 6,137,782; 6,138,157; 6,144,962; 6,205,122; 6,237,006; 6,341,310; 6,360,332, 6,449,739; 6,470,383; 6,477,483; 6,549,944; 6,560,564; 6,564,342; 6,587,969; 6,631,408; 6,631,411; 6,633,912; 6,694,288; 6,738,813; 6,738,933; 6,754,701; 6,792,460 and 6,810,494. Australia: 763468 and 762554. Other patents pending. All rights reserved. Mercury, Mercury Interactive, the Mercury logo, the Mercury Interactive logo, LoadRunner, WinRunner, SiteScope and TestDirector are trademarks of Mercury Interactive Corporation and may be registered in certain jurisdictions. The absence of a trademark from this list does not constitute a waiver of Mercury's intellectual property rights concerning that trademark. All other company, brand and product names may be trademarks or registered trademarks of their respective holders. Mercury disclaims any responsibility for specifying which marks are owned by which companies or which organizations. Mercury Interactive Corporation 379 North Whisman Road Mountain View, CA 94043 Tel: (650) 603-5200 Toll Free: (800) TEST-911 Customer Support: (877) TEST-HLP Fax: (650) 603-5300 2005 Mercury Interactive Corporation, All rights reserved If you have any comments or suggestions regarding this document, please send them via e-mail to documentation@mercury.com.
AMLIB_SECUR5.1.1/01
Table of Contents
Welcome to Hardening the Platform ...................................................v Using this Guide....................................................................................v Getting More Information ...................................................................vi Chapter 1: Introduction to Hardening the Mercury Business Availability Center Platform ................................................1 Introduction to Hardening for Mercury Business Availability Center .................................................................................................2 Using a Reverse Proxy Secure Architecture ...........................................4 Using the Hardening Guidelines...........................................................5 Chapter 2: Using a Reverse Proxy in Mercury Business Availability Center ..............................................................................7 Overview of Reverse Proxies..................................................................8 Security Aspects of Using Reverse Proxies.............................................8 Mercury Business Availability Center and Reverse Proxies...................9 Specific and Generic Reverse Proxy Mode Support for Mercury Business Availability Center .............................................................11 Using a Reverse Proxy with a Single Machine Installation.................13 Using a Reverse Proxy with a Distributed Server Installation.............20 Chapter 3: Using SSL in Mercury Business Availability Center...........29 Introducing SSL Deployment in Mercury Business Availability Center ...............................................................................................29 Mercury Business Availability Center Components Supporting SSL..................................................................................32 SSL-Supported Topologies in Mercury Business Availability Center ...............................................................................................33 Configuring SSL Between the Centers Server and Application Users .................................................................................................37 Configuring SSL Between the Core Services Server and the Data Collectors ...........................................................................43 Configuring the Web Guard to Support SSL.......................................52 Remote Auto Upgrading of Data Collectors when Using SSL.............55
iii
Table of Contents
Chapter 4: Using Basic Authentication in Mercury Business Availability Center .............................................................63 Introducing Basic Authentication Deployment in Mercury Business Availability Center .............................................................64 Mercury Business Availability Center Components Supporting Basic Authentication ........................................................................66 Configuring Basic Authentication Between the Centers Server and Application Users ......................................................................68 Configuring Basic Authentication Between the Core Services Server and the Data Collectors.........................................................71 Auto Upgrading Data Collectors Remotely when Using Basic Authentication .................................................................................78 Chapter 5: Hardening Mercury Business Availability Center Components .........................................................................79 Hardening the HTTP Tomcat Coyote Connector ...............................80 Hardening the Web Servers Used by Mercury Business Availability Center............................................................................81 Hardening File Permissions on Mercury Business Availability Center Directories and Files .............................................................91 Chapter 6: Advanced Hardening Information....................................97 Using NAT Devices with Mercury Business Availability Center .........97 Using the LDAP Server for Authentication in Mercury Business Availability Center ...........................................................101 Index..................................................................................................103
iv
Welcome to Hardening the Platform

This guide provides you with detailed instructions on hardening the Mercury Business Availability Center platform.
Note: This guide is not relevant to Mercury Managed Services customers.
Using this Guide

The guide contains the following chapters:
Chapter 1
Introduction to Hardening the Mercury Business Availability Center Platform

Describes the concept of a secure Mercury Business Availability Center platform and discusses the planning and architecture required to implement a secure platform.
Chapter 2
Using a Reverse Proxy in Mercury Business Availability Center

Describes how to use a reverse proxy with Mercury Business Availability Center in order to help secure Mercury Business Availability Center architecture.
Chapter 3
Using SSL in Mercury Business Availability Center

Describes how to configure the Mercury Business Availability Center platform to support Secure Sockets Layer (SSL) communication.
Welcome
Chapter 4
Using Basic Authentication in Mercury Business Availability Center

Describes how to configure the Mercury Business Availability Center platform to support communication using basic authentication.
Chapter 5
Hardening Mercury Business Availability Center Components

Describes the hardening procedures for the Web servers, HTTP connector on Tomcat, and file permissions on Mercury Business Availability Center files and directories.
Chapter 6
Advanced Hardening Information

Describes the use of NAT devices with Mercury Business Availability Center as well as the use of the LDAP server for authentication in Mercury Business Availability Center.
Getting More Information

For information on using and updating the Mercury Business Availability Center Documentation Library, reference information on additional documentation resources, typographical conventions used in the Documentation Library, and quick reference information on deploying, administering, and using Mercury Business Availability Center, refer to Getting Started with Mercury Business Availability Center.
vi
1
Introduction to Hardening the Mercury Business Availability Center Platform
This chapter introduces the concept of a secure Mercury Business Availability Center platform and discusses the planning and architecture required to implement a secure platform. It is strongly recommended that you read this chapter before proceeding to the following chapters, which describe the actual hardening procedures.
This chapter describes: Introduction to Hardening for Mercury Business Availability Center Using a Reverse Proxy Secure Architecture Using the Hardening Guidelines On page: 2 4 5
Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform
Introduction to Hardening for Mercury Business Availability Center

The Mercury Business Availability Center platform is technologically complex and involves a wide distribution of components. This evokes the need for a secure architecture that can meet the challenge of dealing with the security threats to which the Mercury Business Availability Center platform is vulnerable. The hardening guidelines deal with the configuration required to implement a more secure (hardened) Mercury Business Availability Center platform. The hardening guidelines relate to both single machine (where the Core Services and Centers Servers are installed on the same machine) and distributed (where the Core Services and Centers Servers are installed on separate machines) deployments of Mercury Business Availability Center. The hardening information provided is intended primarily for Mercury Business Availability Center administrators, and for the technical operator of each component that is involved in the implementation of a secure Mercury Business Availability Center platform (for example, the Web server). These people should familiarize themselves with the hardening settings and recommendations prior to beginning the hardening procedures.
Before You Start

In order to best use the hardening guidelines given here for your particular organization, you should do the following before starting the hardening procedures:
Evaluate the security risk/security state for your general network, and use the conclusions when deciding how to best integrate the Mercury Business Availability Center platform into your network. Review all the hardening guidelines. A good understanding of the Mercury Business Availability Center technical framework and Mercury Business Availability Center security capabilities will facilitate designing a solid plan for implementing a secure Mercury Business Availability Center platform.
Note: The hardening information provided in this section is not intended as a guide to making a security risk assessment for your computerized systems.
You should also note the following points when using the hardening guidelines:
Verify that the Mercury Business Availability Center platform is fully functioning before starting the hardening procedures. Follow the hardening procedure steps chronologically in each chapter. For example, if you decide to configure the Mercury Business Availability Center servers to support SSL, read Chapter 3, Using SSL in Mercury Business Availability Center and then follow all the instructions chronologically. The Mercury Business Availability Center components do not support basic authentication with blank passwords. Do not use a blank password when setting basic authentication connection parameters. The hardening procedures are based on the assumption that you are implementing only the instructions provided in these chapters, and not performing other hardening steps not documented here. Where the hardening procedures focus on a particular distributed architecture, this does not imply that this is the best architecture to fit your organizations needs. It is assumed that the procedures included in the following chapters will be performed on machines dedicated to the Mercury Business Availability Center platform. Using the machines for other purposes in addition to Mercury Business Availability Center, may yield problematic results.
Tip: You can print out the hardening procedures and check them off as you implement them.
Using a Reverse Proxy Secure Architecture

Mercury Business Availability Center 5.1 Service Pack 1 fully supports the reverse proxy secure architecture. This architecture has a significant number of security advantages. The following security objectives can be achieved by using a reverse proxy in DMZ proxy HTTP/HTTPS communication with Mercury Business Availability Center:

No Mercury Business Availability Center logic or data resides on the DMZ. No direct communication between Mercury Business Availability Center clients and servers is permitted. No direct connection from the DMZ to the Mercury Business Availability Center database is required. No protocol translation occurs. The incoming protocol to the reverse proxy and the outgoing protocol to the Mercury Business Availability Center servers are identical. Only HTTP access to the reverse proxy is allowed, which means that stateful packet inspection firewalls can better protect the communication. A static, restricted set of redirect requests can be defined on the reverse proxy. Most of the Web server security features are available on the reverse proxy (authentication methods, encryption, and others). The reverse proxy screens the IP addresses of the real Mercury Business Availability Center servers as well as the architecture of the internal network. The only accessible client of the Web server is the reverse proxy. This configuration supports NAT firewalls. The reverse proxy requires a minimal number of open ports in the firewall. The reverse proxy provides good performance compared to other bastion host solutions.
It is strongly recommended that you use a reverse proxy with Mercury Business Availability Center to achieve a secure architecture. For details on configuring a reverse proxy for use with Mercury Business Availability Center, see Chapter 2, Using a Reverse Proxy in Mercury Business Availability Center. If you must use another type of secure architecture with your Mercury Business Availability Center platform, contact Mercury Customer Support to determine which architecture is the best one for you to use.
Using the Hardening Guidelines

The chapters in this guide discuss the following hardening topics:
Using a reverse proxy in Mercury Business Availability Center This chapter contains information on using a reverse proxy with Mercury Business Availability Center in order to help secure Mercury Business Availability Center architecture. For details, see Chapter 2, Using a Reverse Proxy in Mercury Business Availability Center. Configuring the Mercury Business Availability Center platform to use SSL communication This chapter contains information on configuring each Mercury Business Availability Center component to support Secure Sockets Layer (SSL) communication. For details, see Chapter 3, Using SSL in Mercury Business Availability Center. Configuring the Mercury Business Availability Center platform to use basic authentication This chapter contains information on configuring each Mercury Business Availability Center component to support communication using the basic authentication protocol. For details, see Chapter 4, Using Basic Authentication in Mercury Business Availability Center. Hardening the Mercury Business Availability Center components This chapter describes the hardening procedures for a number of Mercury Business Availability Center components whose hardening is not built-in, including the Web servers, HTTP connector on Tomcat, and file permissions on Mercury Business Availability Center files and directories. For details, see Chapter 5, Hardening Mercury Business Availability Center Components.
Advanced hardening information This chapter contains additional information for hardening your Mercury Business Availability Center platform, such as using NAT devices and using an LDAP for authentication. For details, see Chapter 6, Advanced Hardening Information.
Note: For information on the ports used by each Mercury Business Availability Center component, as well as procedures for modifying certain ports, see Appendix A, Port Management in Deploying Servers.
At various points in the hardening guidelines, you are instructed to configure the Web server on a Mercury Business Availability Center server machine to support required security settingsfor example, when setting up SSL or basic authentication support. Instructions for configuring these settings can be found in the appropriate Web server documentation, available at the following sites:

for IIS 5.0/6.0 the Microsoft Web site (http://www.microsoft.com) for Apache the Apache Jakarta Web site (http://jakarta.apache.org) for Sun Java System Web Server the Sun Web site (http://docs.sun.com)
2
Using a Reverse Proxy in Mercury Business Availability Center
This chapter describes the security ramifications of reverse proxies and contains instructions for using a reverse proxy with Mercury Business Availability Center.
This chapter describes: Overview of Reverse Proxies Security Aspects of Using Reverse Proxies Mercury Business Availability Center and Reverse Proxies Specific and Generic Reverse Proxy Mode Support for Mercury Business Availability Center Using a Reverse Proxy with a Single Machine Installation Using a Reverse Proxy with a Distributed Server Installation On page: 8 8 9 11 13 20
Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center
Overview of Reverse Proxies

A reverse proxy is an intermediate server that is positioned between the client machine and the Web server(s). To the client machine, the reverse proxy seems like a standard Web server that serves the client machines HTTP protocol requests with no dedicated client configuration required. The client machine sends ordinary Web content requests for content, using the name of the reverse proxy instead of the name of a Web server. The reverse proxy then sends the request to one of the servers. Although the response is sent back to the client machine by the reverse proxy, it appears to the client machine as if it is being sent by the Web server.
Note: This chapter discusses only the security aspects of a reverse proxy. It does not discuss other aspects of reverse proxies, such as caching and load balancing.
Security Aspects of Using Reverse Proxies

A reverse proxy functions as a bastion host. It is configured as the only machine to be addressed directly by external clients, and thus obscures the rest of the internal network. Use of a reverse proxy enables the application server to be placed on a separate machine in the internal network, which is a significant security objective. This chapter discusses the use of a reverse proxy in DMZ architecture, the more common security architecture available today. DMZ is a network architecture in which an additional network is implemented, enabling you to isolate the internal network from the external one. Although there are a few common implementations of DMZs, this chapter discusses the use of a DMZ and reverse proxy in a back-to-back topology environment.
The following are the main security advantages of using a reverse proxy in such an environment: No DMZ protocol translation occurs. The incoming protocol and outgoing protocol are identical (only a header change occurs). Only HTTP access to the reverse proxy is allowed, which means that stateful packet inspection firewalls can better protect the communication. A static, restricted set of redirect requests can be defined on the reverse proxy. Most of the Web server security features are available on the reverse proxy (authentication methods, encryption, and more). The reverse proxy screens the IP addresses of the real servers as well as the architecture of the internal network. The only accessible client of the Web server is the reverse proxy. This configuration supports NAT firewalls (as opposed to other solutions). The reverse proxy requires a minimal number of open ports in the firewall. The reverse proxy provides good performance compared to other bastion solutions.
Mercury Business Availability Center and Reverse Proxies

Mercury Business Availability Center supports a reverse proxy in DMZ architecture. The reverse proxy is an HTTP mediator between the Mercury Business Availability Center data collectors/application users and the Mercury Business Availability Center server(s). If a reverse proxy is being used for application users, Mercury Business Availability Center must be configured to recognize its use. If not, the Mercury Business Availability Center URL optimization mechanism will not be able to properly calculate absolute paths. If a reverse proxy is being used for data collectors, only the data collectors and reverse proxy must be configured to recognize its use.
Mercury Business Availability Center servers can be installed using the following two architectures: Single machine installation The Core Services and Centers Servers reside on the same machine. To configure a reverse proxy for this architecture, see Using a Reverse Proxy with a Single Machine Installation on page 13. Distributed server installation The Core Services and Centers Servers reside on separate machines. To configure a reverse proxy for this architecture, see Using a Reverse Proxy with a Distributed Server Installation on page 20. You can connect the following to Mercury Business Availability Center via a reverse proxy: Mercury Business Availability Center data collectors Mercury Business Availability Center application users The following table describes the component(s) that can be connected via a reverse proxy to each type of Mercury Business Availability Center server:
Mercury Business Availability Center Server Single machine installation (both servers installed on the same machine) Core Services Server Centers Server
Mercury Business Availability Center Components Connecting Via Reverse Proxy to Server Data collectors Application users
Data collectors Application users
10
Specific and Generic Reverse Proxy Mode Support for Mercury Business Availability Center
Mercury Business Availability Center servers reply to application users by sending a base URL that is used to calculate the correct references in the HTML requested by the user. When a reverse proxy is used, Mercury Business Availability Center must be configured to return the reverse proxy base URL, instead of the Mercury Business Availability Center base URL, in the HTML with which it responds to the user. Note that if the reverse proxy is being used for data collectors only, configuration is required only on the data collectors and reverse proxy, and not on the Mercury Business Availability Center server(s). You use the following three parameters to configure Mercury Business Availability Center support of a reverse proxy. These parameters are located on the Infrastructure Settings Manager page, accessible from Platform Administrations Setup and Maintenance tab, in the Foundations > Platform Administration context.
Parameter Name Enable Reverse Proxy HTTP Reverse Proxy IPs Description Controls whether the reverse proxy machine is enabled or disabled. Defines the IP addresses of the reverse proxy or proxies used to communicate with the Centers Server(s). Note that if you define IP addresses for this parameter, Mercury Business Availability Center works in Specific Mode. If no IP addresses are defined for this parameter (the default option), Mercury Business Availability Center works in Generic Mode. Defines the base URL of the machine (reverse proxy, load balancer, or another type of machine) to which the application user initially sends its request. Note that if the Local Virtual Centers Server URL parameter is defined for a specific machine, this URL will be used instead of the Default Virtual Centers Server URL for the specifically defined machine.
Default Virtual Centers Server URL
11
Note: Once you change the Mercury Business Availability Center base URL, it is assumed that the client is initiating HTTP sessions using the new base URL. You must therefore ensure that the HTTP channel from the client to the new URL is enabled.
Specific Mode
If you are working in this mode, each time an application user HTTP request causes Mercury Business Availability Center to calculate a base URL, the base URL is replaced with the value defined for either the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined), if the HTTP request came through one of the IP addresses defined for the HTTP Reverse Proxy IPs parameter. If the HTTP request did not come through one of these IP addresses, the base URL that Mercury Business Availability Center receives in the HTTP request is the base URL that is returned to the client.
Generic Mode
If you are working in this mode, each time an HTTP request causes the Mercury Business Availability Center application to calculate a base URL, the base URL is replaced with the value defined for either the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined). Note that when using this mode, you must ensure that all Mercury Business Availability Center clients are accessing the Mercury Business Availability Center servers via the URL defined for the Default Virtual Centers Server URL or the Local Virtual Centers Server URL parameters.
12
Using a Reverse Proxy with a Single Machine Installation

This section contains the following information regarding the use of a reverse proxy when both Mercury Business Availability Center servers are installed on the same machine (as illustrated in the diagram below): Reverse Proxy Configuration see page 14 Mercury Business Availability Center-Specific Configuration see page 17 Limitations see page 18 Apache 2.0.x Example Configuration see page 18
Application Users
Data Collection
Reverse Proxy Reverse Proxy Server
Corporate Backbone
Single M achine
HTTP/HTTPS port (external, 80/443)
13
Reverse Proxy Configuration

In this topology, all contexts must point to the same machine, on which both Mercury Business Availability Center servers are installed. Reverse proxy Mercury Business Availability Center support should be configured differently in each of the following cases:
Mercury Business Availability Center Components Behind the Reverse Proxy Data collectors (Business Process Monitor, Client Monitor, Real User Monitor, SiteScope) Application users Data collectors and application users
Scenario # 1 2 3
Note: Different types of reverse proxies require different configuration syntaxes. For an example of an Apache 2.0.x reverse proxy configuration, see Apache 2.0.x Example Configuration on page 18.
Support for Mercury Business Availability Center Data Collectors The following configuration is required if only data collectors are connected via a reverse proxy to your single machine Mercury Business Availability Center installation:
Requests for... on the Reverse Proxy Server /topaz/topaz_api/* /ext/* Proxy Request to be Served by:
http://[Mercury Business Availability Center server]/topaz/* http://[Mercury Business Availability Center server]/ext/*
14
Support for Mercury Business Availability Center Application Users The following configuration is required if only application users are connected via a reverse proxy to your single machine Mercury Business Availability Center installation:
Requests for... on the Reverse Proxy Server /MercuryAM/* /mercuryam/* /topaz/* /webinfra/* /freshwater_skin/* /freshwater/* /filters/* /SampleBrowser/* /TopazSettings/* Proxy Request to be Served by:
http://[Mercury Business Availability Center server] /MercuryAM/* http://[Mercury Business Availability Center server] /mercuryam/* http://[Mercury Business Availability Center server] /topaz/* http://[Mercury Business Availability Center server] /webinfra/* http://[Mercury Business Availability Center server] /freshwater_skin/* http://[Mercury Business Availability Center server] /freshwater/* http://[Mercury Business Availability Center server] /filters/* http://[Mercury Business Availability Center server] /SampleBbrowser/* http://[Mercury Business Availability Center server] /TopazSettings/*
15
Support for Both Mercury Business Availability Center Data Collectors and Application Users The following configuration is required if both data collectors and application users are connected via a reverse proxy to your single machine Mercury Business Availability Center installation:
Requests for... on the Reverse Proxy Server /MercuryAM/* /mercuryam/* /topaz/* /ext/* /webinfra/* /freshwater_skin/* /freshwater/* /filters/* /SampleBrowser/* /TopazSettings/* Proxy Request to be Served by:
http://[Mercury Business Availability Center server] /MercuryAM/* http://[Mercury Business Availability Center server] /mercuryam/* http://[Mercury Business Availability Center server] /topaz/* http://[Mercury Business Availability Center server] /ext/* http://[Mercury Business Availability Center server] /webinfra/* http://[Mercury Business Availability Center server] /freshwater_skin/* http://[Mercury Business Availability Center server] /freshwater/* http://[Mercury Business Availability Center server] /filters/* http://[Mercury Business Availability Center server] /SampleBrowser/* http://[Mercury Business Availability Center server] /TopazSettings/*
For some reverse proxies, a reverse pass is also required. The reverse pass changes the HTTP headers returned from the server to relative headers. For an example of a reverse pass, see Apache 2.0.x Example Configuration on page 18.
16
Mercury Business Availability Center-Specific Configuration

In addition to configuring the reverse proxy to work with Mercury Business Availability Center, you must configure Mercury Business Availability Center to work with the reverse proxy.
Note: Mercury Business Availability Center must be configured only if application users are connected via a reverse proxy to Mercury Business Availability Center. If the reverse proxy is being used for data collectors only, skip the instructions in this section.
To configure Mercury Business Availability Center to work with the reverse proxy: 1 On the Infrastructure Settings Manager page (accessible from Platform Administrations Setup and Maintenance tab), in the Foundations > Platform Administration context, set the following parameters: Default Virtual Centers Server URL Verify that this parameter represents the URL of the machine (reverse proxy, load balancer, or another type of machine) used to access the Mercury Business Availability Center machine. Local Virtual Centers Server URL (optional) If you must use more than one URL (the one defined for the Default Virtual Centers Server URL parameter) to access the Mercury Business Availability Center machine, define a Local Virtual Centers Server URL for each machine through which you want to access the Mercury Business Availability Center machine. If this parameter is set, the Default Virtual Centers Server URL is overridden. HTTP Reverse Proxy IPs (optional) Configure the IP addresses of the reverse proxy or proxies used to communicate with the Mercury Business Availability Center machine. If the IP address of the reverse proxy sending the HTTP request is included in the list of IP addresses defined for this parameter, the URL returned to the client is either the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined). If the IP address of the reverse proxy sending the HTTP request is not included in the list of IP addresses defined for this parameter, the
17
Mercury Business Availability Center machine returns the base URL that it receives in the HTTP request.
Note: If no IP addresses are defined for this parameter (the default option), Mercury Business Availability Center works in Generic Mode and the Mercury Business Availability Center machine returns the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined) to the client in all cases.
Enable Reverse Proxy Set this parameter to true. Note that this must be done after the above parameters have been configured. 2 Restart the Mercury Business Availability Center service on the Mercury Business Availability Center machine.
Limitations
If you configured Mercury Business Availability Center to work in Generic Mode, all the Mercury Business Availability Center clients must access the Mercury Business Availability Center machine via the reverse proxy.
Apache 2.0.x Example Configuration

Below is a sample configuration file that supports the use of an Apache 2.0.x reverse proxy in a case where both data collectors and application users are connecting to a single machine Mercury Business Availability Center installation.
18
Note: In the example below, the Mercury Business Availability Center machines DNS name is AM_server.
1 Open the <Apache machine root directory>\conf\httpd.conf file. 2 Enable the following modules: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so 3 Add the following lines: ProxyRequests off <Proxy *> Order deny,allow Deny from all Allow from all </Proxy> ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse /mercuryam /mercuryam /MercuryAM /MercuryAM /topaz /topaz /ext /ext /webinfra /webinfra /freshwater_skin /freshwater_skin /freshwater /freshwater /filters /filters http://AM_server/mercuryam http://AM_server/mercuryam http://AM_server/MercuryAM http://AM_server/MercuryAM http://AM_server/topaz http://AM_server/topaz http://AM_server/ext http://AM_server/ext http://AM_server/webinfra http://AM_server/webinfra http://AM_server/freshwater_skin http://AM_server/freshwater_skin http://AM_server/freshwater http://AM_server/freshwater http://AM_server/filters http://AM_server/filters
19
ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse
/SampleBrowser /SampleBrowser /TopazSettings /TopazSettings
http://AM_server/SampleBrowser http://AM_server/SampleBrowser http://AM_server/TopazSettings http://AM_server/TopazSettings
Using a Reverse Proxy with a Distributed Server Installation

This section contains the following information regarding the use of a reverse proxy when the Core Services Server and Centers Server are installed on separate machines (as illustrated in the diagram below): Reverse Proxy Configuration see page 21 Mercury Business Availability Center-Specific Configuration see page 24 Limitations see page 25 Apache 2.0.x Example Configuration see page 26
20
Application Users
Data Collection
Reverse Proxy Reverse Proxy Server
Corporate Backbone
Core Services Server
Centers Server
Reverse Proxy Configuration

In this topology, the reverse proxy context is divided into two sections: communication that is redirected to the Core Services Server communication that is redirected to the Centers Server Reverse proxy Mercury Business Availability Center support should be configured differently in each of the following cases:
Mercury Business Availability Center Components Behind the Reverse Proxy Data collectors (Business Process Monitor, Client Monitor, Real User Monitor, SiteScope)
Scenario # 1
21
Scenario # 2 3
Mercury Business Availability Center Components Behind the Reverse Proxy Application users Data collectors and application users
Note: Different reverse proxies require different configuration syntaxes. For an example of an Apache 2.0.x reverse proxy configuration, see Apache 2.0.x Example Configuration on page 26.
Support for Mercury Business Availability Center Data Collectors The following configuration is required on the reverse proxy for data collectors to connect via the reverse proxy to the Core Services Server:
http://[Core Services Server]/topaz/* http://[Core Services Server]/ext/*
Support for Mercury Business Availability Center Application Users The following configuration is required on the reverse proxy for application users to connect via the reverse proxy to the Centers Server:
Requests for... on the Reverse Proxy Server /mercuryam/* /MercuryAM/* /topaz/* /webinfra/* Proxy Request to be Served by:
http://[Centers Server]/mercuryam/* http://[Centers Server]/MercuryAM/* http://[Centers Server]/topaz/* http://[Centers Server]/webinfra/*
22
Requests for... on the Reverse Proxy Server /freshwater_skin/* /freshwater/* /filters/* /SampleBrowser/* /TopazSettings/*
Proxy Request to be Served by:
http://[Centers Server]/freshwater_skin/* http://[Centers Server]/freshwater/* http://[Centers Server]/filters/* http://[Centers Server]/SampleBrowser/* http://[Centers Server]/TopazSettings/*
Support for Both Mercury Business Availability Center Data Collectors and Application Users The following configuration is required on the reverse proxy if data collectors are connecting to the Core Services Server and application users are connecting to the Centers Servers via the same reverse proxy:
Priority
1 1
http://[Core Services Server]/topaz/topaz_api/* http://[Core Services Server]/ext/*
2 2 2 2 2 2 2 2 2
/mercuryam/* /MercuryAM/* /topaz/* /webinfra/* /freshwater_skin/* /freshwater/* /filters/* /SampleBrowser/* /TopazSettings/*
http://[Centers Server]/mercuryam/* http://[Centers Server]/MercuryAM/* http://[Centers Server]/topaz/* http://[Centers Server]/webinfra/* http://[Centers Server]/freshwater_skin/* http://[Centers Server]/freshwater/* http://[Centers Server]/filters/* http://[Centers Server]/SampleBrowser/* http://[Centers Server]/TopazSettings/*
23
The priority column on the left means that the requests in priority 1 must be handled before those in priority 2. Make sure your reverse proxy supports priority handling logic, which enables a specific expression to be handled before a more generic one, if required. For example, the /topaz/topaz_api/* expression must be handled before the /topaz/* expression. For some reverse proxies, a reverse pass is also required. The reverse pass changes the HTTP headers returned from the server to relative headers. For an example of a reverse pass, see Apache 2.0.x Example Configuration on page 26.
Mercury Business Availability Center-Specific Configuration

In addition to configuring the reverse proxy to work with Mercury Business Availability Center, you must configure Mercury Business Availability Center to work with the reverse proxy.
Note: Mercury Business Availability Center must be configured only if application users are connected via a reverse proxy to Mercury Business Availability Center. If the reverse proxy is being used for data collectors only, skip the instructions in this section.
To configure Mercury Business Availability Center to work with the reverse proxy: 1 On the Infrastructure Settings Manager page (accessible from Platform Administrations Setup and Maintenance tab), in the Foundations > Platform Administration context, set the following parameters: Default Virtual Centers Server URL Verify that this parameter represents the URL of the machine (reverse proxy, load balancer, or another type of machine) used to access the Centers Server. Local Virtual Centers Server URL (optional) If you must use more than one URL (the one defined for the Default Virtual Centers Server URL parameter) to access the Centers Server, define a Local Virtual Centers Server URL for each machine through which you want to access the Centers Server. If this parameter is set, the Default Virtual Centers Server URL is overridden.
24
HTTP Reverse Proxy IPs (optional) Configure the IP addresses of the reverse proxy or proxies used to communicate with the Centers Server. If the IP address of the reverse proxy sending the HTTP request is included in the list of IP addresses defined for this parameter, the URL returned to the client is either the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined). If the IP address of the reverse proxy sending the HTTP request is not included in the list of IP addresses defined for this parameter, the Centers Server returns the base URL that it receives in the HTTP request.
Note: If no IP addresses are defined for this parameter (the default option), Mercury Business Availability Center works in Generic Mode and the Centers Server returns the Default Virtual Centers Server URL or the Local Virtual Centers Server URL (when defined) to the client in all cases.
Enable Reverse Proxy Set this parameter to true. Note that this must be done after the above parameters have been configured. 2 Restart the Mercury Business Availability Center service on the Mercury Business Availability Center machine.
Limitations
If you configured Mercury Business Availability Center to work in Generic Mode, all the Mercury Business Availability Center clients must access the Mercury Business Availability Center servers via the reverse proxy.
25
Apache 2.0.x Example Configuration

Below is a sample configuration file that supports the use of an Apache 2.0.x reverse proxy in a case where data collectors are connecting to the Core Services Server and application users are connecting to the Centers Servers through the same reverse proxy.
Note: In the example below, the Core Services Server DNS name is AM_core and the Centers Server DNS name is AM_centers.
1 Open the <Apache machine root directory>\conf\httpd.conf file. 2 Enable the following modules: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so 3 Add the following lines: ProxyRequests off <Proxy *> Order deny,allow Deny from all Allow from all </Proxy> ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass /ext /ext /topaz/topaz_api /topaz/topaz_api /mercuryam /mercuryam /MercuryAM /MercuryAM /topaz http://AM_core/ext http://AM_core/ext http://AM_core/topaz/topaz_api http://AM_core/topaz/topaz_api http://AM_centers/mercuryam http://AM_centers/mercuryam http://AM_centers/MercuryAM http://AM_centers/MercuryAM http://AM_centers/topaz
26
ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse
/topaz /webinfra /webinfra /freshwater_skin /freshwater_skin /freshwater /freshwater /filters /filters /SampleBrowser /SampleBrowser /TopazSettings /TopazSettings
http://AM_centers/topaz http://AM_centers/webinfra http://AM_centers/webinfra http://AM_centers/freshwater_skin http://AM_centers/freshwater_skin http://AM_centers/freshwater http://AM_centers/freshwater http://AM_centers/filters http://AM_centers/filters http://AM_centers/SampleBrowser http://AM_centers/SampleBrowser http://AM_centers/TopazSettings http://AM_centers/TopazSettings
27
28
3
Using SSL in Mercury Business Availability Center
This chapter describes how to configure your Mercury Business Availability Center platform to support communication using the Secure Sockets Layer (SSL) channel.
This chapter describes: Introducing SSL Deployment in Mercury Business Availability Center Mercury Business Availability Center Components Supporting SSL SSL-Supported Topologies in Mercury Business Availability Center Configuring SSL Between the Centers Server and Application Users Configuring SSL Between the Core Services Server and the Data Collectors Configuring the Web Guard to Support SSL Remote Auto Upgrading of Data Collectors when Using SSL On page: 29 32 33 37 43 52 55
Introducing SSL Deployment in Mercury Business Availability Center

The Mercury Business Availability Center platform fully supports the SSL version 3.0 protocol. The SSL channel is configured on the Mercury Business Availability Center servers/clients as required.
29
Chapter 3 Using SSL in Mercury Business Availability Center
SSL provides Mercury Business Availability Center with the following:
Server authentication provides authentication of the Mercury Business Availability Center server used for communication. Client authentication provides authentication of the client communicating with the Mercury Business Availability Center server. Encrypted channel encrypts the communication between the client and the server using a variety of ciphers. Data integrity helps ensure that the information sent by one side over SSL is the same information received by the other side. Possible SSL channels in Mercury Business Availability Center are illustrated in the following diagram:
Administration Console Applications
Mercury Business Availability Center Application Users
Mercury Business Availability Center Corporate Backbone

Centers Server Centers Server Core Services Server Core Services Server HTTP/HTTPS port (external, 80/443) HTTP/HTTPS to Data collectors
SiteScope
Client M onitor
Business Process M onitor
Real User M onitor
Data Collection External Network
30
Overview of Configuring SSL in Mercury Business Availability Center

The section SSL-Supported Topologies in Mercury Business Availability Center on page 33 discusses the various Mercury Business Availability Center-SSL topologies that are supported and provides links to each configuration step that is required. Before proceeding with the configuration steps, ensure that:
the Mercury Business Availability Center platform is operating as it is supposed to without an SSL channel you read this chapter in its entirety before you begin performing the configuration you define your secure communication requirements (only use an SSL channel where necessary) you consult the section SSL-Supported Topologies in Mercury Business Availability Center on page 33 to determine which topology is most suitable for the specific Mercury Business Availability Center-SSL architecture you are using you consult Chapter 6, Advanced Hardening Information, if you are using special network devices
Note: The configuration specified for each Mercury Business Availability Center server is also relevant for a single machine installation, in which both the Centers Server and Core Services Server reside on the same machine.
31
Mercury Business Availability Center Components Supporting SSL

You set a Mercury Business Availability Center server to support SSL by configuring the Web server installed on the Mercury Business Availability Center server to support SSL. If you are working with certain Mercury Business Availability Center topologies, you must perform additional steps as well. You configure Mercury Business Availability Center clients to support SSL by defining the appropriate settings for each particular type of client, as described in the relevant client sections later in this chapter.
Note: For each client configuration, the HTTPS URL must match the SSL certificate common name that is used by the Web server for server-side authentication.
Web Servers Supporting SSL

The following table details the Web serveroperating system combination that is required for SSL support.
Sun Java System Web Server Solaris Apache Web Server Solaris Windows 2000 Windows 2003
Microsoft IIS Operating System Windows 2000 Windows 2003
Note: Both the Centers Server and Core Services Server require Web servers to communicate with their clients.
32
Mercury Business Availability Center Clients Supporting SSL

The following Mercury Business Availability Center clients support SSL communication with the Mercury Business Availability Center servers:
Browsers when used as Mercury Business Availability Center machine (when Mercury Business Availability Center is installed on a single machine) or Centers Server clients Data collectors Business Process Monitor, Client Monitor, Real User Monitor, and SiteScope, when used as Mercury Business Availability Center machine (when Mercury Business Availability Center is installed on a single machine) or Core Services Server clients
SSL-Supported Topologies in Mercury Business Availability Center

SSL can be configured in one of two modes: optional or required. If you configure a Web server in SSL required mode, the Web server supports only HTTPS communication. If you configure a Web server in SSL optional mode, the Web server supports both HTTP and HTTPS communication. In addition, you can optionally configure SSL to force client authentication by using a client-side certificate. This configuration is referred to as clientside certification and is supported in Mercury Business Availability Center only in conjunction with the SSL required mode.
33
The following table describes the SSL modes supported for each type of Mercury Business Availability Center installation:
Mercury Business Availability Center Architecture Single Mercury Business Availability Center machine or Centers Server machine with/without multiple Core Services Server machines Multiple Mercury Business Availability Center machines or Centers Server machines with/without multiple Core Services Server machines
SSL Mode SSL optional mode SSL required mode
SSL optional mode SSL required mode
Configuration procedures differ, depending on the required topology. The following sections delineate the configuration procedures necessary for each topology:

Single Machine - SSL Optional Mode see below Single Machine - SSL Required Mode see page 35 Multiple Machines - SSL Optional Mode see page 36 Multiple Machines - SSL Required Mode see page 36
34
Single Machine - SSL Optional Mode

In this topology, there is only one Mercury Business Availability Center machine (single machine installation) or one Centers Server. The number of Core Services Servers does not impact the configuration procedure. To configure SSL support for this topology: If you require secure communication between application users and Mercury Business Availability Center, see Configuring SSL Between the Centers Server and Application Users on page 37. If you require secure communication between data collectors and Mercury Business Availability Center, see Configuring SSL Between the Core Services Server and the Data Collectors on page 43.
Note: The Web server(s) should be configured to enable both HTTP and HTTPS communication.
Single Machine - SSL Required Mode

In this topology, there is only one Mercury Business Availability Center machine (single machine installation) or one Centers Server. The number of Core Services Servers does not impact the configuration procedure. To configure SSL support for this topology: If you require secure communication between application users and Mercury Business Availability Center, see Configuring SSL Between the Centers Server and Application Users on page 37. If you require secure communication between data collectors and Mercury Business Availability Center, see Configuring SSL Between the Core Services Server and the Data Collectors on page 43. For each Mercury Business Availability Center server on which you enable SSL, you must configure the Web Guard to support SSL. For details, see Configuring the Web Guard to Support SSL on page 52.
35
Note: The Web server(s) should be configured to enable only HTTPS communication.
Multiple Machines - SSL Optional Mode

In this topology, Mercury Business Availability Center consists of more than one Mercury Business Availability Center machine (single machine installation) or Centers Server. The number of Core Services Servers does not impact the configuration procedure. To configure SSL support for this topology: If you require secure communication between application users and Mercury Business Availability Center, see Configuring SSL Between the Centers Server and Application Users on page 37. If you require secure communication between data collectors and Mercury Business Availability Center, see Configuring SSL Between the Core Services Server and the Data Collectors on page 43.
Note: The Web servers should be configured to enable both HTTP and HTTPS communication.
Multiple Machines - SSL Required Mode

In this topology, Mercury Business Availability Center consists of more than one Mercury Business Availability Center machine (single machine installation) or Centers Server. The number of Core Services Servers does not impact the configuration procedure. If you require secure communication between application users and Mercury Business Availability Center, see Configuring SSL Between the Centers Server and Application Users on page 37.
36
If you require secure communication between data collectors and Mercury Business Availability Center, see Configuring SSL Between the Core Services Server and the Data Collectors on page 43. For each Mercury Business Availability Center server on which you enable SSL, you must configure the Web Guard to support SSL. For details, see Configuring the Web Guard to Support SSL on page 52.
Note: The Web servers should be configured to enable only HTTPS communication.
Configuring SSL Between the Centers Server and Application Users

The instructions in this section describe how to configure the Centers Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) and application users to support SSL.
Mercury Business Availability Center Application Users Mercury Business Availability Center Corporate Backbone
Centers Server
Centers Server
37
This section describes:

SSL Configuration for the Centers Server see below SSL Configuration for the Application Users see page 42
SSL Configuration for the Centers Server

This section provides instructions for configuring the Centers Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) to support SSL. It contains the following instructions:

Enable SSL Support on the Web Server see below Enable SSL Support Between Centers Servers (Multiple Machines, SSL Required Mode Only) see page 39 Enable SSL Support on the Web Server You configure the Centers Server to support SSL by configuring the Web server used by the Centers Server. For each Web server, ensure that you configure the Web server in the correct SSL mode. For information on the available SSL modes, see SSL-Supported Topologies in Mercury Business Availability Center on page 33.
Microsoft Internet Information Server (IIS) 5.0 and 6.0 See http://support.microsoft.com/default.aspx?scid=kb;EN-US;298805 for information on enabling SSL for all interaction with the Web server. Note that SSL should be enabled for the entire IIS Web Site under which you installed the Mercury Business Availability Center applications. The Web Site includes the following directories: Topaz, ext, jakarta, TopazDC, and MercuryAM. Apache HTTP Server 2.0.49 See http://httpd.apache.org/docs-2.0/ssl/ for information on enabling SSL for all interaction with the Web server, using mod_ssl. SSL should be enabled for the following directories in the Mercury Business Availability Center Apache configuration file (httpd.conf):
<Mercury Business Availability Center server root directory>/AppServer/ webapps/site.war
38
<Mercury Business Availability Center server root directory> /AppServer/webapps/site.war/Imgs <Mercury Business Availability Center server root directory> /WebServer/manual
Sun Java System Web Server 6.0 See http://www.sun.com for information on enabling SSL for all interaction with the Web server. SSL should be enabled for the Sun Java System Web site under which Mercury Business Availability Center is installed. After performing the above procedures, the Web server installed on the Centers Server machine is configured to support HTTPS communication. Enable SSL Support Between Centers Servers (Multiple Machines, SSL Required Mode Only) If you configured one or more of the Centers Servers or Mercury Business Availability Center machines (in a scenario in which you have multiple Centers Servers or Mercury Business Availability Center machines) to work in SSL required mode, you must:
modify the Direct Centers Server URL setting on each server requiring SSL configure the JREs on all the Centers Servers or Mercury Business Availability Center machines to support SSL This enables HTTPS communication between the server(s) configured to require SSL and servers communicating with the server(s) requiring SSL. Modify the Direct Centers Server URL For each Centers Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) on which SSL is required, set the Direct Centers Server URL setting, in the Foundations > Platform Administration context on the Infrastructure Settings Manager page in Platform Administrations Setup and Maintenance tab, to the following: HTTPS://<Mercury Business Availability Center server URL>:<port number>
39
Configure the JREs on All Centers Servers to Support SSL Once the Direct Centers Server URL has been modified on one of the Centers Servers, the JREs on all the Centers Servers must be configured to communicate via SSL with the Web server(s) requiring SSL communication. The truststore, which contains the certification authorities (CAs) to be trusted by the JRE, enables the JRE on each Centers Server to communicate with the Web server(s) requiring SSL. The truststore to be used in the procedure below is: <Mercury Business Availability Center server root directory> \JRE\lib\security\cacerts If you configure the Web server on the Centers Server to require client authentication as well (an optional SSL handshake setting), the JRE must be configured to send a client-side certificate when connecting to the Web server requiring SSL. You enable the JRE to send a client-side certificate by linking the JRE to a keystore that includes the private key and client-side certificate used for client authentication in SSL. If you are using a CA that is not included in the truststore, you must import the CAs required for server-side certificate validation to the truststore. For details, see To import a required CA to the truststore on page 42. Once you have configured the truststore and keystore, or imported the required CAs to the truststore, you must restart the Mercury Business Availability Center service on all the Centers Server machines. To set the truststore and keystore to be used by the JRE:
On a Windows machine, open the <Mercury Business Availability Center server root directory>\EJBContainer\bin\run.bat batch file and add the following system properties to the end of the line that begins with set TOPAZ_OPTS: -Djavax.net.ssl.trustStore=<Mercury Business Availability Center root directory> \JRE\lib\security\cacerts -Djavax.net.ssl.trustStorePassword=changeit
40
If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server of the Centers Server that requests it.
Note: The keystore used can be in either PKCS12 or JKS format.
On a Solaris machine, open the <Mercury Business Availability Center server root directory>/EJBContainer/bin/run script file and add the following system properties to the end of the line that begins with set TOPAZ_OPT: -Djavax.net.ssl.trustStore=<Mercury Business Availability Center root directory> /JRE/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server of the Centers Server that requests it.
41
To import a required certificate authority to the truststore: Add the required CAs or certificate chains to the truststore in PEM format using the keytool.exe utility, located in the <Mercury Business Availability Center server root directory>/JRE/bin directory. The import command should be similar to the following: keytool -import -keystore <Mercury Business Availability Center root directory>/JRE/ lib/security/cacerts -storepass changeit -alias serverAcertificate -trustcacerts -file serverAcert.pem where: serverAcert.pem is the server-side certificate sent by the Web server for server-side authentication and serverAcertificate is an alias for the certificate in the truststore.
SSL Configuration for the Application Users

This section provides instructions for configuring the application users (Centers Server clients) to support SSL. When a session is started between the browser and the Centers Server, the Centers Servers Web server sends the browser a server-side certificate that was issued by a CA. If the certificate used by the Web server is issued by a known CA, the certificate can generally be validated by the browser and no configuration is required. However, if the CA is not trusted by the browser, the browser machine must be configured to validate the server-side certificate that is sent. For instructions on setting CA certificate recognition in the browser and configuring browser certificate validation, refer to your browser vendor documentation. For example, if you are working with Internet Explorer 6.0 and want to import a certificate to the truststore used by the browser: 1 Select Tools > Internet Options and click the Content tab. 2 Click the Certificates button. 3 In the Trusted Root Certification Authorities tab, click Import. 4 Link to the certificate you want to trust and import it.
42
Configuring SSL Between the Core Services Server and the Data Collectors
The instructions in this section describe how to configure the Core Services Server and the Mercury Business Availability Center data collectors to support SSL. To enable SSL support, you must make the required changes for the Core Services Server, as well as for all the Mercury Business Availability Center data collectors connecting to it using HTTPS.
Mercury Business Availability Center Corporate Backbone
Core Services Server Core Services Server HTTP/HTTPS port (external, 80/443)
SiteScope
Client Monitor
Business Process Monitor
Real User Monitor

SSL Configuration for the Core Services Server see below SSL Configuration for the Data Collectors see page 45
43
SSL Configuration for the Core Services Server

You configure the Core Services Server to support SSL by configuring the Web server used by the Core Services Server. For each Web server, ensure that you configure the Web server in the correct SSL mode. For information on the available SSL modes, see SSL-Supported Topologies in Mercury Business Availability Center on page 33.
Microsoft Internet Information Server (IIS) 5.0 and 6.0 See http://support.microsoft.com/default.aspx?scid=kb;EN-US;298805 for information on enabling SSL for all interaction with the Web server. Note that SSL should be enabled for the entire IIS Web Site under which you installed the Mercury Business Availability Center applications. The Web Site includes the following directories: Topaz, ext, jakarta, TopazDC, and MercuryAM. Apache HTTP Server 2.0.49 See http://httpd.apache.org/docs-2.0/ssl/ for information on enabling SSL for all interaction with the Web server, using mod_ssl. SSL should be enabled for the following directories in the Mercury Business Availability Center Apache configuration file (httpd.conf):
<Mercury Business Availability Center server root directory>/AppServer/ webapps/site.war <Mercury Business Availability Center server root directory> /AppServer/webapps/site.war/Imgs <Mercury Business Availability Center server root directory> /WebServer/manual
Sun Java System Web Server 6.0 See http://www.sun.com for information on enabling SSL for all interaction with the Web server. SSL should be enabled for the Sun Java System Web site under which Mercury Business Availability Center is installed. After performing the above procedures, the Web server installed on the Core Services Server machine is configured to support HTTPS communication.
44
SSL Configuration for the Data Collectors

This section provides instructions for configuring the following Mercury Business Availability Center data collectors to support SSL:

Business Process Monitor see below Client Monitor Agent see page 48 SiteScope see page 49 Real User Monitor see page 50
Note: These instructions are necessary only if the Core Services Server with which the data collector is communicating requires SSL.
Business Process Monitor Configuring SSL support for the Business Process Monitor involves the following procedures:
Configuring a Connection to the Core Services Server Using SSL see page 46 Configuring an SSL Client-Side Certificate see page 47
Note: You can also configure Business Process Monitor Admin to work with SSL, so that all communication between remote browsers and Business Process Monitor Admin (including passwords) is sent encrypted. For details, refer to the Mercury Business Process Monitor Administrators Guide (accessed from the Help menu in Business Process Monitor Admin on the Business Process Monitor machine.)
45
Configuring a Connection to the Core Services Server Using SSL When a session is started between the Business Process Monitor and the Core Services Server, the Core Services Server sends the Business Process Monitor a server-side certificate that was issued by a CA. The Business Process Monitor instance should be configured to trust the CA and to communicate via SSL. To configure the Business Process Monitor to connect to the Core Services Server using SSL: 1 Obtain the truststore file in PEM format, base64 encoded. The file can consist of the server-side certificate itself, or the certificate of the CA that issued the server side certificate, or all certificates required for the trust path (all certificates must be placed in the same PEM file). 2 Open Business Process Monitor Admin (http://<Business Process Monitor machine>:2696). 3 In the Business Process Monitor page, identify the Business Process Monitor instance you want to configure from the Instances list and click the Edit button for the instance. The Edit Instance page opens. 4 In the General section, change the Core Services Server URL to: HTTPS://<Core Services Server URL>/topaz/
Important: The URL must end with /topaz and not /MercuryAM.
5 In the SSL section, configure the SSL authority certificate file to point to the truststore file (so that the Business Process Monitor instance recognizes the file). The file must be in PEM format and base64 encoded. 6 Click Save Changes and Restart Instance.
46
Configuring an SSL Client-Side Certificate If the Core Services Server is supporting SSL with client-side certificates, you must configure a client-side certificate for the Business Process Monitor instance. To configure a client-side certificate on the Business Process Monitor machine: 1 Open Business Process Monitor Admin (http://<Business Process Monitor machine>:2696). 2 In the Business Process Monitor page, identify the Business Process Monitor instance for which you want to use SSL from the Instances list and click the Edit button for the instance. The Edit Instance page opens. 3 Enter the following SSL parameter values:
SSL client certificate file the path of the PEM file that holds the client-side certificate. SSL private key file the path of the PEM file that holds the private key used as a public/private pair key for the public key in the client-side certificate. SSL private key password the password of the private key, if the private key was encrypted with a password.
4 Click Save Changes and Restart Instance.
47
Client Monitor Agent Configuring SSL support for the Client Monitor Agent involves the following procedures:

Configuring a Connection to the Core Services Server Using SSL see below Configuring an SSL Client-Side Certificate see page 49 Configuring a Connection to the Core Services Server Using SSL When a session is started between the Client Monitor Agent machine and the Core Services Server, the Core Services Server sends the Client Monitor Agent machine a server-side certificate that was issued by a CA recognized by the Core Services Server. The Client Monitor Agent machine should be configured to trust the CA and to communicate via SSL. To configure the Client Monitor Agent to connect to the Core Services Server using SSL:
1 Install the CA certificate on the machine that runs the Client Monitor Agent. The certificate can be located in the local machines certificate store, or in the certificate store of the user executing the Client Monitor Agent. If you are using a certificate from a well-known authority, it is most likely already available in the certificate store on your machine.
Note: For detailed information on how to install certificates in the Windows certificate store, see http://www.microsoft.com.
2 Open the Client Monitor Agent Settings dialog box (Start > Programs > Mercury Client Monitor > Client Monitor Agent Settings). 3 In the Core Services Server URL box, change the HTTP in the URL to HTTPS. 4 Click Save & Exit. 5 Restart the Client Monitor Agent.
48
Configuring an SSL Client-Side Certificate If the Core Services Server is supporting SSL with client-side certificates, you must configure a client-side certificate for the Client Monitor Agent. To configure a client-side certificate on the Client Monitor Agent machine: 1 Install a client-side certificate on your machine certificate store registry from an authority that is recognized by the Core Services Server machine. Note that the client-side certificate can be installed in the Windows users personal certificate store. Make sure that the certificate and private key are stored in a format known to Windows as PKCS12 or PFX. 2 Import the file containing both the certificate and the private key into the users certificate store by double-clicking the file and following the instructions in the wizard that opens.
Note: If Client Monitor Agents have already been distributed to clients, they must be redistributed once the above changes have been made.
SiteScope If the SiteScope machine is required to communicate with the Core Services Server via SSL, the SiteScope machine must be configured to connect to the Core Services Server using SSL.
Note: The current version of SiteScope does not support client-side certificates. To work around this limitation, use a Core Services Server that does not require a client-side certificate or contact Mercury Customer Support.
49
To configure SiteScope to connect to the Core Services Server using SSL:
If you are configuring SiteScope using Mercury Business Availability Center Monitor Administration, right-click the SiteScope you want to instruct to use SSL, and select Edit. In the Main Settings section of the Edit SiteScope page, select the Use SSL check box. Click OK at the bottom of the page and restart the SiteScope instance.
If you are configuring SiteScope using the SiteScope interface, select Preferences > Mercury AM. In the Mercury Application Management Server Registration page, in the Optional Settings section, select the Use SSL (HTTPS protocol) check box. Click the Update button at the bottom of the page and restart the SiteScope instance. Real User Monitor Configuring SSL support for the Real User Monitor involves the following procedures:
Configuring a Connection to the Core Services Server Using SSL see below Configuring an SSL Client-Side Certificate see page 51 Configuring a Connection to the Core Services Server Using SSL When a session is started between the Real User Monitor engine and the Core Services Server, the Core Services Server sends the Real User Monitor engine a server-side certificate that was issued by a CA recognized by the Core Services Server. The Real User Monitor engine should be configured to trust the CA and to communicate via SSL. To configure the Real User Monitor to connect to the Core Services Server using SSL:
1 Obtain the truststore file in PEM format, base64 encoded. The file can consist of the server-side certificate itself, or the certificate of the CA that issued the server side certificate, or all certificates required for the trust path (all certificates must be placed in the same PEM file).
50
2 Open the Real User Monitor Web Console (http://<Real User Monitor engine name>:7777). 3 Click the Configuration tab. 4 Under General, change the value of the Mercury Business Availability Center URL to: HTTPS://<Core Services Server URL>/topaz/ 5 Under SSL, select the Use SSL check box. In the SSL certificate authority file box, enter the path to the truststore file mentioned above. 6 Click Save Configuration. 7 Restart the Real User Monitor engine. Configuring an SSL Client-Side Certificate If the Core Services Server is supporting SSL with client-side certificates, you must configure a client-side certificate for the Real User Monitor engine. To configure a client-side certificate on the Real User Monitor engine: 1 Open the Real User Monitor Web Console (http://<Real User Monitor engine name>:7777). 2 Click the Configuration tab. 3 Under SSL, ensure that the Use SSL check box is selected and that you completed the above configuration. 4 Enter the following SSL parameter values:
SSL client certificate file the path of the PEM base64 encoded file that holds the client-side certificate. SSL private key file the path of the PEM base64 encoded file that holds the private key used as a public/private pair key for the public key in the client-side certificate. SSL private key password the password of the private key, if the private key was encrypted with a password.
5 Click Save Configuration. 6 Restart the Real User Monitor engine.
51
Configuring the Web Guard to Support SSL

Web Guard is a component in each Mercury Business Availability Center server that tracks the validity of the Mercury Business Availability Center components using HTTP/HTTPS. If you changed your Web server to support only SSL (SSL required mode), the Web Guard must be configured to use SSL. To configure the Web Guard to use SSL, you must:

Set the Web Guards Configuration File to Support SSL Set the Web Guard JRE to Support SSL
Set the Web Guards Configuration File to Support SSL

If your Web server supports only SSL, you must configure the Web Guards configuration file to support SSL. To configure the Web Guards configuration file to support SSL: 1 Open the <Mercury Business Availability Center server root directory> /conf/webserver_guard.conf file. 2 Add the following lines to the bottom of the file: ssl=1 host_name=<host name> webserver_port=<SSL port number>
Set the Web Guard JRE to Support SSL

If you have already configured the Mercury Business Availability Center servers JRE to support SSL, you can skip this section. If not, you must configure the Web Guard JRE on the Mercury Business Availability Center server to communicate via SSL with the Web server(s) requiring SSL communication. The truststore, which contains the certification authorities (CAs) to be trusted by the Web Guard JRE, enables the Web Guard JRE on each Mercury Business Availability Center server to communicate with the Web server(s) requiring SSL. The truststore to be used in the procedure below is: <Mercury Business Availability Center server root directory>\JRE\lib\security\cacerts
52
If you configure the Web server on the Mercury Business Availability Center server to require client authentication as well (an optional SSL handshake setting), the Web Guard JRE must be configured to send a client-side certificate when connecting to the Web server requiring SSL. You enable the JRE to send a client-side certificate by linking the JRE to a keystore that includes the private key and client-side certificate used for client authentication in SSL. If you are using a CA that is not included in the truststore, you must import the CAs required for server-side certificate validation to the truststore. For details, see To import a required CA to the truststore on page 55. Once you have configured the truststore and keystore, or imported the required CAs to the truststore, you must restart the Mercury Business Availability Center service on all the Mercury Business Availability Center server machines. To set the truststore and keystore to be used by the Web Guard JRE:
On a Windows machine, open the <Mercury Business Availability Center server root directory>\EJBContainer\bin\run.bat batch file and add the following system properties to the end of the line that begins with set TOPAZ_OPTS: -Djavax.net.ssl.trustStore=<Mercury Business Availability Center root directory> \JRE\lib\security\cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
53
On a Solaris machine, open the <Mercury Business Availability Center server root directory>/EJBContainer/bin/run script file and add the following system properties to the end of the line that begins with set TOPAZ_OPT: -Djavax.net.ssl.trustStore=<Mercury Business Availability Center root directory> /JRE/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
54
To import a required certificate authority to the truststore: Add the required CAs or certificate chains to the truststore in PEM format using the keytool.exe utility, located in the <Mercury Business Availability Center server root directory>/JRE/bin directory. The import command should be similar to the following: keytool -import -keystore <Mercury Business Availability Center root directory> /JRE/lib/security/cacerts -storepass changeit -alias serverAcertificate trustcacerts -file serverAcert.pem where: serverAcert.pem is the server-side certificate sent by the Web server for server-side authentication and serverAcertificate is an alias for the certificate in the truststore.
Remote Auto Upgrading of Data Collectors when Using SSL

You can auto update the Business Process Monitor, Client Monitor, and SiteScope data collectors remotely by supplying a URL required to download the update from the Web server on which it is located. If you are auto updating the Business Process Monitor or SiteScope and the Web server from which you are downloading the update is using an HTTPS protocol, you must first set the data collectors JRE to support SSL, as detailed in Setting the Data Collectors JRE to Support SSL below. Before auto updating the Client Monitor, you must first perform the procedures detailed in Configuring SSL Support for the Client Monitor Agent on page 60. Once you have performed these procedures, you can auto upgrade the data collectors using the instructions detailed in Performing an Auto Upgrade of the Data Collectors on page 61.
55
Setting the Data Collectors JRE to Support SSL

The truststore, which contains the certification authorities (CAs) to be trusted by the JRE, enables the JRE on the data collector to communicate with the Web server requiring SSL. The truststore to be used in the procedure below is: <Data collector root directory>\JRE\lib\security\cacerts If the Web server from which you are downloading the update requires client-side SSL authentication as well, the JRE must be configured to send a client-side certificate when connecting to the Web server requiring SSL. You enable the JRE to send a client-side certificate by linking the JRE to a keystore that includes the private key and client-side certificate used for client authentication in SSL. Configuring SSL Support for the Business Process Monitors JRE To configure SSL support for the Business Process Monitors JRE, you must set the truststore and keystore (if necessary) to be used by the JRE. If you are using a CA that is not included in the truststore, you must import the CAs required for server-side certificate validation to the truststore. To set the truststore and keystore to be used by the JRE:
On a Windows machine, open the <Business Process Monitor root directory>\ServletContainer\bin\catalina.bat batch file and add the following system properties to the end of the line that begins with set CATALINA_OPTS: -Djavax.net.ssl.trustStore=<Business Process Monitor root directory>\JRE\ lib\security\cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
56
On a Solaris machine, open the <Business Process Monitor root directory>/ServletContainer/bin/catalina.sh script file and add the following system properties to the end of the line that begins with set CATALINA_OPT: -Djavax.net.ssl.trustStore=<Business Process Monitor root directory>/JRE/lib/ security/cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
To import a required certificate authority to the truststore: Add the required CAs or certificate chains to the truststore in PEM format using the keytool.exe utility, located in the <Business Process Monitor root directory>/JRE/bin directory.
57
The import command should be similar to the following: keytool -import -keystore <Business Process Monitor root directory>/JRE/ lib/security/cacerts -storepass changeit -alias serverAcertificate -trustcacerts -file serverAcert.pem where: serverAcert.pem is the server-side certificate sent by the Web server for server-side authentication and serverAcertificate is an alias for the certificate in the truststore. Configuring SSL Support for the SiteScopes JRE To configure SSL support for the SiteScopes JRE, you must set the truststore and keystore (if necessary) to be used by the JRE. If you are using a CA that is not included in the truststore, you must import the CAs required for serverside certificate validation to the truststore. To set the truststore and keystore to be used by the JRE:
On a Windows machine, add the following system properties to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SiteScope\ serviceParam registry key, after the -Dsun.net.inetaddr.ttl=0 parameter: -Djavax.net.ssl.trustStore=<SiteScope root directory>\JRE\lib\security\cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
58
On a Solaris machine, add the following system properties to the <SiteScope root directory>/classes/start-monitor script file, after the -Dsun.net.inetaddr.ttl=0 parameter: -Djavax.net.ssl.trustStore=<SiteScope root directory>/JRE/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit If you configured the Web server to require a client-side certificate, add the following three lines as well: -Djavax.net.ssl.keyStore=<keystore> -Djavax.net.ssl.keyStorePassword=<keystore password> -Djavax.net.ssl.keyStoreType=PKCS12 or JKS Ensure that the client-side certificate you use is trusted by the Web server that requests it.
To import a required certificate authority to the truststore: Add the required CAs or certificate chains to the truststore in PEM format using the keytool.exe utility, located in the <SiteScope root directory>/JRE/bin directory. The import command should be similar to the following: keytool -import -keystore <SiteScope root directory>/JRE/ lib/security/cacerts -storepass changeit -alias serverAcertificate -trustcacerts -file serverAcert.pem where: serverAcert.pem is the server-side certificate sent by the Web server for server-side authentication and serverAcertificate is an alias for the certificate in the truststore.
59
Configuring SSL Support for the Client Monitor Agent

Configuring SSL support for the Client Monitor Agent involves the following procedures:

Configuring a Connection to the Web Server Using SSL see below Configuring an SSL Client-Side Certificate see page 61 Configuring a Connection to the Web Server Using SSL When a session is started between the Client Monitor Agent machine and the Web server from which you are downloading the update, the Web server sends the Client Monitor Agent machine a server-side certificate that was issued by a CA recognized by the Web server. The Client Monitor Agent machine should be configured to trust the CA and to communicate via SSL. To configure the Client Monitor Agent to connect to the Web server using SSL: Install the CA certificate on the machine that runs the Client Monitor Agent. The certificate can be located in the local machines certificate store, or in the certificate store of the user executing the Client Monitor Agent. If you are using a certificate from a well-known authority, it is most likely already available in the certificate store on your machine.
Note: For detailed information on how to install certificates in the Windows certificate store, see http://www.microsoft.com.
60
Configuring an SSL Client-Side Certificate If the Web server is supporting SSL with client-side certificates, you must configure a client-side certificate for the Client Monitor Agent. To configure a client-side certificate on the Client Monitor Agent machine: 1 Install a client-side certificate on your machine certificate store registry from an authority that is recognized by the Web server machine. Note that the client-side certificate can be installed in the Windows users personal certificate store. Make sure that the certificate and private key are stored in a format known to Windows as PKCS12 or PFX. 2 Import the file containing both the certificate and the private key into the users certificate store by double-clicking the file and following the instructions in the wizard that opens.
Note: If Client Monitor Agents have already been distributed to clients, they must be redistributed once the above changes have been made.
Performing an Auto Upgrade of the Data Collectors

You perform the following procedure in Mercury Business Availability Center in order to enable the remote auto upgrade of your data collector. To auto upgrade a data collector remotely: 1 In Mercury Business Availability Centers Platform Administration, select Data Collection > Data Collector Maintenance. The Data Collector Maintenance page opens. 2 Click the SiteScope, Business Process Monitor, or Client Monitor tab, depending on the type of data collector you want to upgrade. 3 Select the check box for the data collector instance you want to upgrade. To make your selections, you can also use the buttons at the bottom of the page for, Select All, Clear All, and Invert Selection. 4 Click Upgrade at the bottom of the page. The Upgrade dialog box opens.
61
5 Enter the Setup file URL address. You obtain the setup file from your Mercury Customer Support representative. 6 Enter the HTTPS URL to the upgrade file. 7 Click Start Upgrade. The Actions Status window opens, and the upgrade process continues there. For details of the rest of the procedure, see Tracking Actions Status in Configuring and Administering the Platform.
62
4
Using Basic Authentication in Mercury Business Availability Center
This chapter describes how to configure your Mercury Business Availability Center platform to support authentication using the basic authentication protocol.
This chapter describes: Introducing Basic Authentication Deployment in Mercury Business Availability Center Mercury Business Availability Center Components Supporting Basic Authentication Configuring Basic Authentication Between the Centers Server and Application Users Configuring Basic Authentication Between the Core Services Server and the Data Collectors Auto Upgrading Data Collectors Remotely when Using Basic Authentication On page: 64 66 68 71 78
63
Chapter 4 Using Basic Authentication in Mercury Business Availability Center
Introducing Basic Authentication Deployment in Mercury Business Availability Center

The Mercury Business Availability Center platform fully supports the basic authentication protocol, which provides Mercury Business Availability Center with the ability to authenticate a client communicating with a Mercury Business Availability Center server via HTTP or HTTPS. The basic authentication protocol is based on the client sending its credentials to the server so that the server can authenticate the client. The clients credentials are sent in a base64 encoding format and are not encrypted in any way. If you are concerned about your network traffic being sniffed, it is recommended that you use basic authentication in conjunction with SSL. This ensures that the clients credentials are sent over an encrypted wire (after the SSL handshake has been completed). For information on configuring the Mercury Business Availability Center platform to support SSL communication, see Chapter 3, Using SSL in Mercury Business Availability Center.
64
Possible basic authentication channels in Mercury Business Availability Center are illustrated in the following diagram:
Application Users
Corporate Backbone
Centers Server
Centers Server
HTTP/HTTPS port (external, 80/443) HTTP/HTTPS to Data collectors
SiteScope
Client M onitor
Real User M onitor
65
Overview of Configuring Basic Authentication in Mercury Business Availability Center

Before proceeding with the configuration steps, ensure that:
the Mercury Business Availability Center platform is operating as it is supposed to without basic authentication you read this chapter in its entirety before you begin performing the configuration you define your authentication requirements and use basic authentication only where required
Note: The configuration specified for each Mercury Business Availability Center server is also relevant for a single machine installation, in which both the Centers Server and Core Services Server reside on the same machine.
Mercury Business Availability Center Components Supporting Basic Authentication

You set a Mercury Business Availability Center server to support basic authentication by enabling basic authentication support for the Web server installed on the Mercury Business Availability Center server and for the Web Guard component on the Mercury Business Availability Center server. You configure Mercury Business Availability Center clients to support basic authentication by defining the appropriate settings for each particular type of client, as described in the relevant client sections later in this chapter.
66
Web Servers Supporting Basic Authentication

The following table details the Web serveroperating system combination that is required for basic authentication support.
Sun Java System Web Server Solaris Apache Web Server Solaris Windows 2000 Windows 2003
Microsoft IIS Operating System Windows 2000 Windows 2003
Note: Both the Centers Server and Core Services Server require Web servers to communicate with their clients.
Mercury Business Availability Center Clients Supporting Basic Authentication

The following Mercury Business Availability Center clients support basic authentication communication with the Mercury Business Availability Center servers:
Browsers when used as Mercury Business Availability Center machine (when Mercury Business Availability Center is installed on a single machine) or Centers Server clients Data collectors Business Process Monitor, Client Monitor, Real User Monitor, and SiteScope, when used as Mercury Business Availability Center machine (when Mercury Business Availability Center is installed on a single machine) or Core Services Server clients
67
Configuring Basic Authentication Between the Centers Server and Application Users
The instructions in this section describe how to configure the Centers Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) and application users to support basic authentication.
Application Users
Corporate Backbone
Centers Server
Centers Server

Basic Authentication Configuration for the Centers Server see below Basic Authentication Configuration for the Application Users see page 70
Basic Authentication Configuration for the Centers Server

This section provides instructions for configuring the Centers Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) to support basic authentication. It contains the following instructions:

Enable Basic Authentication Support on the Web Server see below Enable Basic Authentication Support for the Centers Server Web Guard see page 70
68
Enable Basic Authentication Support on the Web Server The first step in configuring the Centers Server to support basic authentication is to configure the Web server used by the Centers Server.
Note: On each Web server, make sure that you enable basic authentication only and disable anonymous access. Once you have enabled basic authentication, validate the settings by requesting a Mercury Business Availability Center resource and ensuring that you are prompted to insert basic authentication parameters.
Microsoft Internet Information Server (IIS) 5.0 and 6.0 See http://www.microsoft.com for information on enabling basic authentication for all interaction with the Web server. Note that basic authentication should be enabled for the entire IIS Web Site under which you installed the Mercury Business Availability Center applications. The Web Site includes the following directories: Topaz, ext, jakarta, TopazDC, and MercuryAM. Apache HTTP Server 2.0.49 See http://httpd.apache.org/docs2.0/howto/auth.html for information on enabling basic authentication for all interaction with the Web server, using mod_auth. Note that basic authentication should be enabled on all the directories used by the Web server:

<Centers Server root directory>/AppServer/webapps/site.war <Centers Server root directory>/AppServer/webapps/site.war/Imgs <Centers Server root directory>/WebServer/manual
Sun Java System Web Server 6.0 See http://www.sun.com for information on enabling basic authentication for all interaction with the Web server. Once you have performed the above configuration procedures, when you are using a Microsoft IIS 5.0 or 6.0 Web server, you must set the required permissions for the Mercury Business Availability Center directories and files
69
on the platform you are using. For details, see Hardening File Permissions on Mercury Business Availability Center Directories and Files on page 91. After performing the above procedures, the Web server installed on the Centers Server is configured to support basic authentication for HTTP/S communication. Enable Basic Authentication Support for the Centers Server Web Guard Web Guard is a component in each Mercury Business Availability Center server that tracks the validity of the Mercury Business Availability Center components using HTTP/HTTPS. If you configured your Web server to use basic authentication, the Web Guard must also be configured to use basic authentication. To configure the Web Guard to use basic authentication: 1 Double-click the <Centers Server root directory>/bin/ setsiteauthentication.exe utility. 2 Select the Using basic authentication check box. 3 Enter the following parameter values:

User name the user name to be used to log in to the Centers Server Password the user password to be used to log in to the Centers Server Domain the domain name to be used to log in to the Centers Server
4 Restart the Mercury Business Availability Center service on the Centers Server.
Basic Authentication Configuration for the Application Users

This section provides instructions for configuring the application users (Centers Server clients) to support basic authentication. To connect as an application user to a Mercury Business Availability Center server that requires basic authentication, it is only necessary for you to know the credentials of the user permitted to log in to the Mercury Business Availability Center Web server. When connecting to the Web server, you will be prompted to enter these credentials. The authentication is then performed automatically.
70
Configuring Basic Authentication Between the Core Services Server and the Data Collectors
The instructions in this section describe how to configure the Core Services Server and the Mercury Business Availability Center data collectors to support basic authentication. To enable basic authentication support, you must make the required changes for the Core Services Server, as well as for all the Mercury Business Availability Center data collectors connecting to it using HTTP/S.
Corporate Backbone
SiteScope
Client M onitor
Real User M onitor

Basic Authentication Configuration for the Core Services Server see below Basic Authentication Configuration for the Data Collectors see page 74
71
Basic Authentication Configuration for the Core Services Server

This section provides instructions for configuring the Core Services Server (or a Mercury Business Availability Center machine, in the case of a single machine installation) to support basic authentication. It contains the following instructions:

Enable Basic Authentication Support on the Web Server see below Enable Basic Authentication Support for the Core Services Server Web Guard see page 73 Enable Basic Authentication Support on the Web Server The first step in configuring the Core Services Server to support basic authentication is to configure the Web server used by the Core Services Server.
Note: On each Web server, make sure that you enable basic authentication only and disable anonymous access. Once you have enabled basic authentication, validate the settings by requesting a Mercury Business Availability Center resource and ensuring that you are prompted to insert basic authentication parameters.
Microsoft Internet Information Server (IIS) 5.0 and 6.0 See http://www.microsoft.com for information on enabling basic authentication for all interaction with the Web server. Note that basic authentication should be enabled for the entire IIS Web Site under which you installed the Mercury Business Availability Center applications. The Web Site includes the following directories: Topaz, ext, jakarta, TopazDC, and MercuryAM.
72
Apache HTTP Server 2.0.49 See http://httpd.apache.org/docs2.0/howto/auth.html for information on enabling basic authentication for all interaction with the Web server, using mod_auth. Note that basic authentication should be enabled on all the directories used by the Web server:

<Core Services Server root directory>/AppServer/webapps/site.war <Core Services Server root directory>/AppServer/webapps/ site.war/Imgs <Core Services Server root directory>/WebServer/manual
Sun Java System Web Server 6.0 See http://www.sun.com for information on enabling basic authentication for all interaction with the Web server. Once you have performed the above configuration procedures, when you are using a Microsoft IIS 5.0 or 6.0 Web server, you must set the required permissions for the Mercury Business Availability Center directories and files on the platform you are using. For details, see Hardening File Permissions on Mercury Business Availability Center Directories and Files on page 91. After performing the above procedures, the Web server installed on the Core Services Server is configured to support basic authentication for HTTP/S communication. Enable Basic Authentication Support for the Core Services Server Web Guard Web Guard is a component in each Mercury Business Availability Center server that tracks the validity of the Mercury Business Availability Center components using HTTP/HTTPS. If you configured your Web server to use basic authentication, the Web Guard must also be configured to use basic authentication. To configure the Web Guard to use basic authentication:
1 Double-click the <Core Services Server root directory>/bin/ setsiteauthentication.exe utility. 2 Select the Using basic authentication check box.
73
3 Enter the following parameter values:
User name the user name to be used to log in to the Core Services Server Password the user password to be used to log in to the Core Services Server Domain the domain name to be used to log in to the Core Services Server
4 Restart the Mercury Business Availability Center service on the Core Services Server.
Basic Authentication Configuration for the Data Collectors

This section provides instructions for configuring the following Mercury Business Availability Center data collectors to support basic authentication:

Business Process Monitor see below Client Monitor Agent see page 47 SiteScope see page 49 Real User Monitor see page 49 Business Process Monitor If you configured the Core Services Server to require basic authentication, you must configure the Business Process Monitor to connect to the Core Services Server using basic authentication. To configure the Business Process Monitor to use basic authentication:
1 Open the Business Process Monitor Admin (http://<Business Process Monitor machine>:2696) 2 In the Business Process Monitor page, identify the Business Process Monitor instance you want to configure from the Instances list and click the Edit button for the instance. The Edit Instance page opens.
74
3 In the Authentication section, enter the following parameter values:
Authentication user name the user name to be used to log in to the Core Services Server Authentication user password the user password to be used to log in to the Core Services Server Authentication domain the domain name to be used to log in to the Core Services Server
4 Click Save Changes and Restart Instance. Client Monitor Agent If you configured the Core Services Server to require basic authentication, you must configure the Client Monitor Agent to connect to the Core Services Server using basic authentication. To configure the Client Monitor Agent to use basic authentication: 1 Open the Client Monitor Agent Settings dialog box (Start > Programs > Mercury Client Monitor > Client Monitor Agent Settings). 2 In the Security tab, select the Use basic authentication check box and enter the following parameter values:
User name the domain and user name to be used to log in to the Core Services Server (in the format domain\user name) Password the password to be used to log in to the Core Services Server
3 Click Save & Exit. 4 Restart the Client Monitor Agent.
75
SiteScope If you configured the Core Services Server to require basic authentication, you must configure the SiteScope machine to connect to the Core Services Server using basic authentication. To configure the SiteScope machine to use basic authentication:
If you are configuring SiteScope using Mercury Business Availability Center Monitor Administration, right-click the SiteScope you want to instruct to use SSL, and select Edit. In the Profile Settings section of the Edit SiteScope page, enter the following parameter values:
Web server authentication user name the user name and domain of the Core Services Server (in the format domain\user name) Web server authentication password the password of the Core Services Server
Click OK at the bottom of the page and restart the SiteScope instance.
If you are configuring SiteScope using the SiteScope interface, select Preferences > Mercury AM. In the Optional Settings section of the Mercury Business Availability Center Server Registration page, enter the following parameter values:
Authentication username the user name and domain of the Core Services Server (in the format domain\user name) Authentication password the password of the Core Services Server
Click the Update button at the bottom of the page and restart the SiteScope instance.
76
Real User Monitor If you configured the Core Services Server to require basic authentication, you must configure the Real User Monitor engine machine to connect to the Core Services Server using basic authentication. To configure the Real User Monitor engine machine to use basic authentication: 1 Open the Real User Monitor Web Console (http://<Real User Monitor engine name>:7777). 2 Click the Configuration tab. 3 Under Basic Authentication, select the Use basic authentication check box and enter the following parameter values:
Authentication user name the user name to be used to log in to the Core Services Server Authentication user password the user password to be used to log in to the Core Services Server Authentication domain the domain name to be used to log in to the Core Services Server
4 Click Save Configuration. 5 Restart the Real User Monitor engine machine.
77
Auto Upgrading Data Collectors Remotely when Using Basic Authentication

You can perform a remote auto update for the Business Process Monitor, Client Monitor, and SiteScope data collectors by supplying parameters required to download the update from the Web server on which it is located. If the Web server from which you are downloading the update is using basic authentication, you must perform the following procedure in Mercury Business Availability Center in order to enable the remote auto upgrade. To auto upgrade data collectors remotely when using business authentication: 1 In Mercury Business Availability Centers Platform Administration, select Data Collection > Data Collector Maintenance. The Data Collector Maintenance page opens. 2 Click the SiteScope, Business Process Monitor, or Client Monitor tab, depending on the type of data collector you want to upgrade. 3 Select the check box for the data collector instance you want to upgrade. To make your selections, you can also use the buttons at the bottom of the page for, Select All, Clear All, and Invert Selection. 4 Click Upgrade at the bottom of the page. The Upgrade dialog box opens. 5 Select Use Basic Authentication and enter the following authentication parameter values:
User Name the user name to be used to log in to the Core Services Server Password the user password to be used to log in to the Core Services Server Domain the domain name to be used to log in to the Core Services Server
6 Click Start Upgrade. The Actions Status window opens, and the upgrade process continues there. For details of the rest of the procedure, see Tracking Actions Status in Configuring and Administering the Platform.
78
5
Hardening Mercury Business Availability Center Components
This chapter specifies the hardening procedures that may be performed to secure certain components in the Mercury Business Availability Center platform against known and exploited security breaches.
This chapter describes: Hardening the HTTP Tomcat Coyote Connector Hardening the Web Servers Used by Mercury Business Availability Center Hardening File Permissions on Mercury Business Availability Center Directories and Files On page: 80 81 91
Note: A few of the hardening procedures affect administrative capabilities and must therefore be read carefully before being implemented.
79
Chapter 5 Hardening Mercury Business Availability Center Components
Hardening the HTTP Tomcat Coyote Connector

Mercury Business Availability Center uses the HTTP Tomcat Coyote connector (port 8080) for internal HTTP communication between components on a machine. By default, any machine can connect to the HTTP Tomcat Coyote connector to enable the JMX console over the network. For security reasons, it is recommended that you limit the HTTP Tomcat Coyote connector to local host connections only. Note that by doing so, the JMX console can be used only via the loopback address 127.0.0.1. To limit access to the HTTP Tomcat Coyote connector: 1 Open the <Mercury Business Availability Center server root directory> \EJBContainer\server\deploy\jbossweb-tomcat.41.sar\META-INF \jboss-service.xml file in a text editor. 2 Locate the following string: <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" 3 Change the address from: "$(jboss.bind.address)" to: "127.0.0.1" 4 Save the jboss-service.xml file.
80
Hardening the Web Servers Used by Mercury Business Availability Center

Mercury Business Availability Center uses a Web server on each server machine for the following purposes: to serve static files to clients (style sheets, HTML files, and so forth) to forward dynamic requests to a servlet container If you want to use a Microsoft IIS Web server, you must install it prior to installing Mercury Business Availability Center. If you want to use an Apache Web server, you can either install the server on your own and perform the hardening procedures below, or install the Apache Web server when you install Mercury Business Availability Center and automatically receive a hardened version of the Web server. This chapter details the hardening procedures for the following Web servers: Microsoft Internet Information Service (IIS) 5.0 see below Apache 2.0.49 (if not installed with Mercury Business Availability Center) see page 86
Note: Microsoft IIS 6.0 contains, by default, a better set of security features than Microsoft IIS 5.0. If you require a more secure configuration than that which is available by default for Microsoft IIS 6.0, contact Mercury Customer Support.
Hardening the Microsoft Internet Information Service (IIS) 5.0 Web Server
This section discusses the hardening procedures for the Microsoft IIS 5.0 Web server being used with a Windows 2000 operating system. Hardening procedures for IIS 5.0 Web servers being used with other operating systems are not discussed in this guide.
81
It is strongly recommended that you check the Microsoft Web site (http://www.microsoft.com/security/) for the latest security patch available for the IIS 5.0 Web server. To verify that your Web server has the most updated security patches installed on it, use the Microsoft MBSA tool (http://www.microsoft.com/technet/security/tools/mbsahome.mspx). To harden the Microsoft IIS 5.0 Web server you must perform the following procedures: Set the WWW Log File see below Run the IIS Lockdown Tool see page 82 Run the Microsoft UrlScan Tool see page 83 Deploy NTFS Permissions to Harden the Operating System see page 85 Clear the Integrated Windows authentication Option see page 85 Set the WWW Log File Setting the WWW log file enables tracing IIS communication for securityrelated issues. To set the WWW log file: 1 Enable the W3C Extended Log File Format logging. 2 Set the logging for a daily log time period. 3 Define the W3C Extended Log File Format size to be at least 100 MB. 4 Add Cookie and Host to the extended properties to be logged. Run the IIS Lockdown Tool IIS Lockdown Wizard version 2.1 (the supported version) works by turning off unnecessary features, thus reducing the surface available to attackers. For improved protection against attackers, Urlscan is integrated into the IIS Lockdown Tool, with customized templates for each supported server role. Note the following before running the IIS Lockdown Tool: Using this script does not replace the need for security service pack hotfixes or patches.
82
You can roll back this tool setting by repeating the run procedure. After installation, a setting summary can be found in the oblt-log.log file in the <Windows installation root directory>\system32\inetsrv directory. You can find the full documentation for this tool on the Microsoft Web site (http://www.microsoft.com).
Important: Use the IIS Lockdown Tool only on a new Web server installation, and only on a Mercury Business Availability Center-dedicated server.
To run the IIS Lockdown Tool: 1 Download the iislockd.exe tool (version 2.1 only) from the Microsoft Web site and follow the instructions in the Internet Information Services Lockdown Wizard to install it. 2 In the Select Server Template screen, select Static Web server and the View template settings check box. 3 In the Internet Services screen, select Web service (HTTP) and the Remove unselected services check box. 4 In the Script Maps screen, select all options except Active Server Pages (.asp). 5 In the Additional Security screen, select all of the available options. 6 In the UrlScan screen, select the Install UrlScan filter on server check box. Run the Microsoft UrlScan Tool The UrlScan 2.5 tool (the supported version) is a powerful security tool that works in conjunction with the IIS Lockdown Tool to enable IIS Web site administrators to filter HTTP requests.
Note: You can roll back the following procedure. For details, refer to the Microsoft UrlScan documentation.
83
To run the Microsoft UrlScan 2.5 tool: 1 Verify that the Microsoft IIS Lockdown Tool has installed the UrlScan filter on your computer. (See step 6 in the above procedure.) 2 Download the Urlscan.exe file (version 2.5) from the Microsoft Web site and install it. 3 Make a backup copy of the urlscan.ini file, located in the <Windows installation root directory>\system32\inetsrv\urlscan directory. 4 Open the file urlscan.ini for in a text editor. 5 To the section [AllowVerbs], add the verb POST (GET and HEAD are already there). 6 In the [DenyExtensions] section, locate the line ;Deny ASP requests, and enable .asp by commenting its line out, as follows: ; .asp 7 Under ; Deny executables that could run on the server, make sure the following lines are included: .bat .cmd .com .sh .war .ear .bak .sql .class 8 Save the urlscan.ini file. 9 Restart the IIS service on the Web server machine.
84
Important: Use the UrlScan 2.5 security tool only on a new Web server installation, and only on a Mercury Business Availability Center-dedicated server.
Deploy NTFS Permissions to Harden the Operating System The NTFS permissions synchronize the Microsoft IIS security settings with the machines operating system. The permissions required for the Mercury Business Availability Center IIS directories are specified in Hardening File Permissions on Mercury Business Availability Center Directories and Files on page 91. Clear the Integrated Windows authentication Option To complete the hardening process for your Microsoft IIS 5.0 Web server, you must clear the Integrated Windows authentication option in the IIS Internet Services Manager. To clear the Integrated Windows authentication option: 1 On the Microsoft IIS Web server, open the IIS Internet Services Manager. 2 Right-click Default Web Site and select Properties. 3 In the Default Web Site Properties dialog box, click the Directory Security tab. 4 Under Anonymous access and authentication control, click Edit. 5 Clear the Integrated Windows authentication check box in the Authentication Methods dialog box and click OK.
Note: To verify the Microsoft IIS configuration after the IIS hardening process, it is recommended that you use the IISPerms tool. This is a What if tool, designed to assist you in troubleshooting IIS security issues. For details, refer to the Knowledge Base on the Microsoft Product Support site, article 229694 (http://support.microsoft.com/default.aspx?scid=kb;enus;Q229694&sd=tech).
85
Hardening the Apache 2.0.49 Web Server

If you are using an Apache 2.0.49 Web server that was not installed by Mercury Business Availability Center, you can secure the Web server using the following hardening procedures: Disable the CGI Support see below Verify that SSI (Server-Side Includes) Support is Disabled see page 87 Verify that Support for Distributed Configuration Files (.htaccess files) is Disabled see page 87 Deny Access to All Web directories by Default see page 88 Limit HTTP Commands to GET, POST, and HEAD see page 88 Disable the HTTP TRACE Command for the Entire Web Server see page 89 Disable Support for the UserDir Module see page 89 Block Specific File Download by Extension see page 89 Disable Index Permission in the Mercury Business Availability Center Site Directory see page 90 Disable Client Access to the Online Documentation see page 90 Note that before you begin the hardening procedures, it is recommended that you make a backup copy of the Web server configuration file (httpd.conf), in case you need to roll back the security changes you made. Disable the CGI Support The first part of the procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. The second part of the procedure is applicable only to a Solaris 9 operating system. To disable the CGI support: 1 Open the Web server configuration file, httpd.conf. 2 Comment out the following line: LoadModule cgi_module modules/mod_cgi.so 3 On a Solaris platform, comment out the following line: ScriptAlias /cgi-bin/ "Mercury Business Availability Center/WebServer/cgi-bin/"
86
4 On a Solaris platform, comment out the CGI Directory definition: <Directory "Mercury Business Availability Center/WebServer/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> Verify that SSI (Server-Side Includes) Support is Disabled The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To verify that SSL support is disabled: 1 Open the Web server configuration file, httpd.conf. 2 Verify that the following lines are commented out: AddType text/html .shtml AddOutputFilter INCLUDES .shtml Verify that Support for Distributed Configuration Files (.htaccess files) is Disabled The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To verify that support for distributed configuration files is disabled: 1 Open the Web server configuration file, httpd.conf. 2 Verify that the AllowOverride None directive exists in the Mercury Business Availability Center Directory block: <Directory "Mercury Business Availability Center/AppServer/webapps/site.war"> ... AllowOverride None </Directory>
87
Deny Access to All Web directories by Default The Web server should be configured to deny access to all Web directories, unless the required permissions are explicitly defined in a directory. The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To limit access to all directories except those for which access is explicitly granted: 1 Open the Web server configuration file, httpd.conf. 2 Add the following block: <Directory> Order Deny,Allow Deny from all </Directory> Limit HTTP Commands to GET, POST, and HEAD The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To limit support on your Web server to these three verbs only: 1 Open the Web server configuration file, httpd.conf. 2 In the Mercury Business Availability Center Directory block, add a section such as the following: <Directory "Mercury Business Availability Center /AppServer/webapps/site.war/"> <LimitExcept POST GET HEAD> Require valid-user </LimitExcept> ... </Directory>
88
Disable the HTTP TRACE Command for the Entire Web Server The HTTP TRACE command can be used to execute a XST attack on your Web servers. Mercury Business Availability Center does not use the TRACE command and it is therefore recommended that you disable it. Note that the procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To disable the HTTP TRACE command: 1 Open the Web server configuration file, httpd.conf. 2 Directly below the RewriteEngine On line, add the following lines: RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
Note: The above lines should not be placed in Directory or Location block.
Disable Support for the UserDir Module The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To disable support for the UserDir module: 1 Open the Web server configuration file, httpd.conf. 2 Comment out the following line: LoadModule userdir_module modules/mod_userdir.so Block Specific File Download by Extension The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To block file download by extension: 1 Open the Web server configuration file, httpd.conf.
89
2 In the Mercury Business Availability Center Directory block, add a section such as the following: <Directory "Mercury Business Availability Center/AppServer/webapps/site.war/"> ... <FilesMatch "\.(sh|class|war|ear|bak)$"> Order allow,deny Deny from all </FilesMatch> ... </Directory> Disable Index Permission in the Mercury Business Availability Center Site Directory The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To disable index permission in the Mercury Business Availability Center Directory: 1 Open the Web server configuration file, httpd.conf. 2 Make sure the Indexes definition is deleted or commented out from the Mercury Business Availability Center Directory blocks: <Directory "Mercury Business Availability Center/AppServer/webapps/site.war"> # Options Indexes FollowSymlinks MultiViews Options FollowSymlinks MultiViews ... </Directory> Disable Client Access to the Online Documentation The procedure below is applicable to both Windows (2000 and 2003) and Solaris 9 operating systems. To disable the Apache online documentation on the Web server: 1 Open the Web server configuration file, httpd.conf.
90
2 Comment out the following line: # Alias /manual/"Mercury Business Availability Center/ WebServer/htdocs/manual/"
Hardening File Permissions on Mercury Business Availability Center Directories and Files
This section explains how to restrict permissions that were previously granted to Mercury Business Availability Center directories and files so that Mercury Business Availability Center can run more securely. It contains instructions for the following platforms: Windows see below Solaris see page 95 This section also explains how to configure permissions if you have configured your Mercury Business Availability Center servers to use basic authentication.
Permissions when Using Basic Authentication

If you choose to use basic authentication as the Web server authentication protocol for your Mercury Business Availability Center servers, you must verify that all permissions required by the operating system are compatible with the authentication protocol. Windows 2000/2003 The Permission Enhancements for Windows (NTFS) section below contains instructions on how to set the minimum permissions on Mercury Business Availability Center files and directories for anonymous access. If you are using basic authentication, the users to which you grant permission to use Mercury Business Availability Center should receive the same permissions as the IUSR_ user. Permissions should be revoked from the IUSR_ user. All other procedures should be performed as detailed in the Permission Enhancements for Windows (NTFS) section.
91
Solaris 9 The users granted permissions to use Mercury Business Availability Center vary according to the Web server being used (Apache or Sun Java System). For information on configuring basic authentication for the Web servers, see the appropriate Web server documentation.
Permission Enhancements for Windows (NTFS)

This section contains instructions on restricting permissions to Mercury Business Availability Center directories and files on Windows platforms so that the files and directories contain the minimum required set of permissions and are more secure as a result. Before reconfiguring file permissions, you must disable permission inheritance for the Mercury Business Availability Center server root directory. For details on permission inheritance, refer to the Microsoft Windows 2000/2003 Help. This section describes: Changing Inherited Permissions for the Mercury Business Availability Center Server Root Folder see below Assigning Permissions to Mercury Business Availability Center Folders/Files see page 93 Assigning Permissions to Mercury Business Availability Center Folders/Files on Microsoft IIS see page 94 Changing Inherited Permissions for the Mercury Business Availability Center Server Root Folder By default, when you create or modify permissions for a parent object, such as a directory, all existing child objects, such as files or subdirectories, inherit the modified permissions. As each Mercury Business Availability Center directory must have its own permissions and not those of its parent, you must disable permission inheritance for the Mercury Business Availability Center server root directory. To disable permission inheritance for the Mercury Business Availability Center server root directory: 1 Right-click the Mercury Business Availability Center server root directory, and select Properties. The directorys Properties dialog box opens.
92
2 Click the Security or Advanced (Windows 2003) tab. 3 Clear the Allow inheritable permissions from parent to propagate to this object check box. The Mercury Business Availability Center subdirectories will not inherit any permissions from the parent directory. The Security dialog box opens. 4 Click Copy to enable permission copying to the Mercury Business Availability Center subdirectories. Any permissions already inherited will continue to apply to the Mercury Business Availability Center subdirectories. 5 Click OK to close the directorys Properties dialog box. Assigning Permissions to Mercury Business Availability Center Folders/Files Once you have disabled permission inheritance, you can assign the various Mercury Business Availability Center groups/users permissions to the Mercury Business Availability Center directories/files. To assign permissions to administrators: 1 Right-click the Mercury Business Availability Center server root directory, and select Properties. The directorys Properties dialog box opens. 2 Click the Security or Advanced (Windows 2003) tab. 3 Select the administrators group, and grant this group Full Control permission. (If the administrators group does not appear in the list, click Add and add the administrators group to the list.) 4 Click OK to close the directorys Properties dialog box. To assign permissions to the SYSTEM group used by the operating system: 1 Right-click the Mercury Business Availability Center server root directory, and select Properties. The directorys Properties dialog box opens. 2 Click the Security or Advanced (Windows 2003) tab. 3 Select the SYSTEM group name and grant this group Full Control permission. 4 Click OK to close the directorys Properties dialog box.
93
To remove other group/user permissions to the Mercury Business Availability Center server root directory: 1 Right-click the Mercury Business Availability Center root directory, and select Properties. The directorys Properties dialog box opens. 2 Delete all user/group permissions, apart from those previously granted according to the above instructions. 3 Click OK to close the directorys Properties dialog box.
Note: Unless prior permission changes were made, only the permissions granted to the SYSTEM and administrators groups should appear in all Mercury Business Availability Center objects as implicit permissions.
Assigning Permissions to Mercury Business Availability Center Folders/Files on Microsoft IIS If you are working with a Microsoft IIS Web server, you must grant permissions to the IWAM_ and IUSR_ (users of the IIS process) users.
Note: IUSR_ user permissions must be granted only if you enable anonymous access to the Mercury Business Availability Center Web servers. If you using the basic authentication protocol, see Permissions when Using Basic Authentication on page 91.
To assign permissions to an IWAM_ and IUSR_ users: 1 Right-click the Mercury Business Availability Center server root directory, and select Properties. The directorys Properties dialog box opens. 2 Click the Security tab. 3 Select the IWAM_ user and grant this user Change permission. (If this user does not appear in the list, click Add and add this user to the list.)
94
The following table defines the minimum set of permissions that must be assigned to the IUSR_ user so that the Mercury Business Availability Center platform operates correctly, enabling anonymous access to the Web server. (\*.* means that all the subdirectories and files within the subdirectories must be granted the specified permissions):
Group/User Folder (including files) Explicit Permissions Modify Modify Read Modify
(U) IUSR_ (U) IUSR_ (U) IUSR_ (U) IUSR_
<Mercury Business Availability Center server root directory>\bin\ext\*.* <Mercury Business Availability Center server root directory>\log\*.* <Mercury Business Availability Center server root directory>\ServletContainer\bin\iis\i386\*.* <Mercury Business Availability Center server root directory>\Appserver\webapps\site.war\*.*
4 Click OK to close the directorys Properties dialog box.
Permission Enhancements for Solaris

This section contains instructions on restricting permissions that were previously granted to Mercury Business Availability Center directories and files on Solaris platforms. Mercury Business Availability Center Directory/File Permissions The permission instructions below assume that the Mercury Business Availability Center platform is running as a user called Mercury. If you installed the Mercury Business Availability Center platform using a different user name, refer to this name instead.
95
All Mercury Business Availability Center directories/files are located in a path referred to here as Mercury Business Availability Center server root directory. All Mercury Business Availability Center directories/files and subdirectories/files should be set to the same mode, as follows:
Path (including files) Mercury Business Availability Center server root directory Mode 700
Find World Writable Files The Mercury Business Availability Center platform does not require world writable files. Verify that you have no world writable files in your Topaz directories/files. In addition, any unnecessary world writable file on your machine should be modified so that it does not allow world writable access.
96
6
Advanced Hardening Information
This chapter discusses the use of NAT devices with Mercury Business Availability Center as well as the use of the LDAP server for authentication in Mercury Business Availability Center.
This chapter describes: On page: 97 101
Using NAT Devices with Mercury Business Availability Center

Using the LDAP Server for Authentication in Mercury Business Availability Center
Using NAT Devices with Mercury Business Availability Center

NAT (Network Address Translation) allows an Internet Protocol (IP) network to separate external IP addresses from internal ones by translating the IP addresses. A NAT device may be used to translate Mercury Business Availability Center client requests. In the following cases, Mercury Business Availability Center servers must be configured to recognize that a NAT device is being used: Mercury Business Availability Center application users are accessing Mercury Business Availability Center through a NAT device. The URL received by Mercury Business Availability Center is different than that requested by the application user.
97
Chapter 6 Advanced Hardening Information
Note that if you are using a NAT device to forward, proxy, or balance requests of Mercury Business Availability Center data collectors only, it is not necessary to configure Mercury Business Availability Center to recognize the NAT device.
Scenario 1: Mercury Business Availability Center Server Configuration Required

In this scenario, the use of a NAT device causes the Mercury Business Availability Center server to receive an HTTP request that includes a different URL than that sent by the application user. Because the Mercury Business Availability Center server returns, by default, the same URL it receives in the HTTP request, the URL returned to the application user in this case is different than that sent by the user. As a result, the HTTP session will probably be broken. This scenario occurs, for instance, in a case in which a reverse proxy is used. To make this architecture compatible with Mercury Business Availability Center, the Mercury Business Availability Center must be configured to recognize that a reverse proxy is in use. The case of a reverse proxy is illustrated in the following diagram (distributed Mercury Business Availability Center installation):
U R L r e c e iv e d : h t t p :/ / r p _ s e r v e r S o u r c e a d d r e s s : a p p lic a t io n u s e r D e s t in a t io n a d d r e s s : r e v e r s e p r o x y U R L r e c e iv e d : h t t p :/ / c e n t e r s _ s e r v e r S o u rce a d d re ss : re ve rse p ro x y D e s t in a t io n a d d r e s s : C e n t e r s S e r v e r
C e n te rs S e rv e r R e v e rs e P ro x y C o re S e rv ic e s S e rv e r
In the above diagram, the application user sends a request to the reverse proxy, assuming the request is being sent to the Mercury Business Availability Center server. The reverse proxy receives the following URL,
98
whose source IP address is the application user and whose destination IP address is the reverse proxy: http://rp_server/mercuryam/login The reverse proxy forwards the request to the Centers Server using its own IP address as the source IP address. The URL has now been changed to the following: http://centers_server/mercuryam/login By default, the Centers Server returns the HTTP request using the same URL it receives. In the above case, this URL is different than the initial URL sent by the application user and the HTTP session will be broken. To prevent this situation from occurring, the Centers Server must be configured to recognize that a reverse proxy is being used. For details on configuring both the Centers Server and the reverse proxy, see Chapter 2, Using a Reverse Proxy in Mercury Business Availability Center.
Scenario 2: Mercury Business Availability Center Server Configuration Not Required

In this scenario, although a NAT device is used, the Mercury Business Availability Center server receives an HTTP request that includes the same URL as sent by the application user. As a result, the URL returned to the application user is identical to the URL with which the user initiated the HTTP request and the HTTP session remains intact. In such a scenario, which generally occurs when a load balancer is used, no configuration of the Mercury Business Availability Center server is required.
99
This scenario is illustrated in the following diagram (distributed Mercury Business Availability Center installation):
U R L r e c e iv e d : h t t p :/ / lb _ s e r v e r S o u r c e a d d r e s s : a p p lic a t io n u s e r D e s t in a t io n a d d r e s s : lo a d b a la n c e r U R L r e c e iv e d : h t t p :/ / lb _ s e r v e r S o u r c e a d d r e s s : lo a d b a la n c e r D e s t in a t io n a d d r e s s : C e n t e r s S e r v e r
C e n te rs S e rv e r Load B a la n c e r C o re S e rv ic e s S e rv e r
In the above diagram, the application user sends a request to the load balancer, assuming the request is being sent to the Mercury Business Availability Center server. The load balancer receives the following URL, whose source IP address is the application user and whose destination IP address is the load balancer: http://lb_server/mercuryam/login However, instead of forwarding the request to the Centers Server using its own IP address as the source IP address, the load balancer forwards the original IP address it received. The Centers Server returns the HTTP request using the URL it receives, which is the same URL sent by the application user. The HTTP session thus remains intact and no Mercury Business Availability Center reconfiguration is required.
100
Using the LDAP Server for Authentication in Mercury Business Availability Center
By default, Mercury Business Availability Center uses an authentication mechanism that is based on data persistence in the management database as well as common encryption ciphers. However, you can configure the LDAP server to be used as the authentication server in Mercury Business Availability Center, instead of the default authentication mechanism. By using the LDAP server for authentication, you can benefit from the LDAP security framework during the authentication phase. The security framework includes the following benefits: Password policy restricts the complexity, length, and other characteristics of passwords Lockout policy locks out users that violate security in the login phase Each LDAP server has a different set of security features. Before implementing the integration with Mercury Business Availability Center, therefore, ensure that your LDAP server supports the security features you require. For a instructions on how to set the LDAP server as a Mercury Business Availability Center authentication, see Chapter 21, Authentication Strategies, in Configuring and Administering the Platform.
101
102
Index
A
Apache hardening the Web server 86 application users configuring basic authentication support for 68 configuring SSL support for 37 authentication using LDAP server for 101 components hardening 79 Core Services Server configuring basic authentication support for 71 configuring SSL support for 43
D
data collectors configuring basic authentication support for 71 configuring SSL support for 43 distributed deployment using a reverse proxy with 20
B
basic authentication permissions when using 91 using with Mercury Business Availability Center 63 basic authentication support configuring for application users 68 configuring for Centers Server 68 configuring for Core Services Server 71 configuring for data collectors 71 Business Process Monitor configuring basic authentication support for 74 configuring SSL support for 45
H
hardening advanced information 97 file permissions on Mercury Business Availability Center files 91 for Mercury Business Availability Center platform 1 HTTP Tomcat Coyote connector 80 Mercury Business Availability Center components 79 NAT devices used with Mercury Business Availability Center 97 Web servers 81 HTTP Tomcat Coyote connector, hardening 80
C
Centers Server configuring basic authentication support for 68 configuring SSL support for 37 Client Monitor Agent configuring basic authentication support for 75 configuring SSL support for 48
L
LDAP server using for authentication in Mercury Business Availability Center 101 103
Index
M
Mercury Business Availability Center components hardening 79 files hardening 91 using basic authentication with 63 using LDAP server as authentication server 101 using SSL with 29 Mercury Business Availability Center platform hardening 1 Microsoft IIS hardening the Web server 81
SiteScope configuring basic authentication support for 76 configuring SSL support for 50 Solaris platform permission enhancements 95 SSL using with Mercury Business Availability Center 29 SSL support configuring for application users 37 configuring for Centers Server 37 configuring for Core Services Server 43 configuring for data collectors 43
P
permissions when using basic authentication 91
W
Web servers hardening 81 Windows platform permission enhancements 92
R
Real User Monitor configuring basic authentication support for 77 configuring SSL support for 50 remote upgrade when using basic authentication 78 when using SSL 55 reverse proxy using in Mercury Business Availability Center 7
S
security advanced information 97 for Mercury Business Availability Center files 91 for Mercury Business Availability Center platform 1 for NAT devices used with Mercury Business Availability Center 97 for Web servers 81 HTTP Tomcat Coyote connector 80 single machine deployment using a reverse proxy with 13
104

Hardening

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hardening

Uploaded by

Copyright:

Available Formats

Mercury Business Availability Center

Hardening the Platform

Welcome to Hardening the Platform

Note: This guide is not relevant to Mercury Managed Services customers.

Using this Guide

Introduction to Hardening the Mercury Business Availability Center Platform

Using a Reverse Proxy in Mercury Business Availability Center

Using SSL in Mercury Business Availability Center

Using Basic Authentication in Mercury Business Availability Center

Hardening Mercury Business Availability Center Components

Advanced Hardening Information

Getting More Information

Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform

Introduction to Hardening for Mercury Business Availability Center

Before You Start

Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform

Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform

Using a Reverse Proxy Secure Architecture

Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform

Using the Hardening Guidelines

Chapter 1 Introduction to Hardening the Mercury Business Availability Center Platform

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Overview of Reverse Proxies

Security Aspects of Using Reverse Proxies

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Mercury Business Availability Center and Reverse Proxies

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Data collectors Application users

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Default Virtual Centers Server URL

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Using a Reverse Proxy with a Single Machine Installation

Reverse Proxy Reverse Proxy Server

HTTP/HTTPS port (external, 80/443)

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Reverse Proxy Configuration

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Mercury Business Availability Center-Specific Configuration

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Apache 2.0.x Example Configuration

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

ProxyPass ProxyPassReverse ProxyPass ProxyPassReverse

/SampleBrowser /SampleBrowser /TopazSettings /TopazSettings

http://AM_server/SampleBrowser http://AM_server/SampleBrowser http://AM_server/TopazSettings http://AM_server/TopazSettings

Using a Reverse Proxy with a Distributed Server Installation

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Reverse Proxy Reverse Proxy Server

HTTP/HTTPS port (external, 80/443)

Reverse Proxy Configuration

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

http://[Core Services Server]/topaz/* http://[Core Services Server]/ext/*

http://[Centers Server]/mercuryam/* http://[Centers Server]/MercuryAM/* http://[Centers Server]/topaz/* http://[Centers Server]/webinfra/*

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Proxy Request to be Served by:

http://[Core Services Server]/topaz/topaz_api/* http://[Core Services Server]/ext/*

/mercuryam/* /MercuryAM/* /topaz/* /webinfra/* /freshwater_skin/* /freshwater/* /filters/* /SampleBrowser/* /TopazSettings/*

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center

Mercury Business Availability Center-Specific Configuration

Chapter 2 Using a Reverse Proxy in Mercury Business Availability Center