Page tree
Skip to end of metadata
Go to start of metadata

Purpose

This Wiki space describes specific configurations, scenarios and features for security settings on Web Dispatcher and ICM.

Overview

Optimizing the Web Dispatcher/ICM security settings is a critical step for system administrators that often miss the security optimization aspect on the service.

Security settings are rules that administrators should configure on the service for the purpose of protecting resources. This Wiki aims to provides our tips for using today’s most popular features available on Web Dispatcher and ICM.

Following these tips will greatly increase the security of your Web Dispatcher and ICM.

Although we use the wording for the Web Dispatcher from now on, most of the features being discussed apply to the ICM too. We make an observation if it is related to the Web Dispatcher only.

Table of content

  1. Enabling SSL communication
    1. Connections between clients and Web Dispatcher
    2. Connections between Web Dispatcher and Application Server (for Web Dispatcher only)
    3. Metadata exchange with Message Server (for Web Dispatcher only)
  2. Limit the IP address where the service listen
  3. Access Control Lists (ACL)
  4. Slowloris attack
  5. Request Throtteling (for Web Dispatcher only)
  6. Limiting the number of connections a single IP can create
  7. Certificate Revocation Lists
  8. Content Scan Interface
  9. Authentication Handler
  10. Modification Handler
  11. Web Administrator interface
    1. Subparameter ALLOWPUB
    2. SSL access
    3. Control the hosts that can access the service
    4. Limit the access to internal network hostnames
  12. Remove details about error handling
  13. Customize error pages
  14. Disable server headers information
  15. Tracing information
    1. icm/HTTP/trace_info
    2. icm/trace_secured_data
    3. rdisp/TRACE_HIDE_SEC_DATA
    4. icm/HTTP/logging_<XX>
    5. icm/security_log

1. Enabling SSL communication

SSL connections are required to ensure that requests and responses are encrypted prior to transmission. Therefore, the usage of HTTPS protocol instead of HTTP avoids the communication with unencrypted data. To enhance the security it is suggest to use HTTPS protocol on the communication channels. Below we list three common communication channels where using HTTPS protocol is recommended.

1. 1. Connections between clients and Web Dispatcher

A web client is an application that communicates with the Web Dispatcher, this may be a browser or any application that uses a web protocol. By definition, the protocol HTTPS should be enabled on the icm/server_port_<xx> parameter. The usage of HTTPS protocol instead of HTTP is recommended.
However, if an HTTP port still required it is possible to create a redirect in Web Dispatcher forcing all connections to use HTTPS protocol instead of HTTP, using the Rewrite Handler. The Rewrite Handler is configured with the parameter icm/HTTP/mod_<xx> and a rule like the following forces the switch from HTTP to HTTPS protocol in every HTTP request handled by Web Dispatcher.

if %{SERVER_PROTOCOL} !stricmp "https" 
begin 
	RegIRedirectUrl /(.*) https://%{HTTP_HOST}/$1?%{QUERY_STRING} [code=permanent] 
end

A simpler redirect rule can be created using the parameter "icm/HTTP/redirect_<xx>":

icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https, HOST=webdisp.example.com
1. 2. Connections between Web Dispatcher and Application Server (for Web Dispatcher only)

Requests that Web Dispatcher receives should be forwarded to an Application Server and the communication channel can be defined with different protocols depending of the configuration. To improve the security it is recommended the usage of HTTPS protocol setting "wdisp/ssl_encrypt=1" on the Web Dispatcher profile. See SAP Web Dispatcher and SSL for more details. 

Note that the ICM at the backend Application Servers have to provide an HTTPS port as well. To check if the HTTPS port is active and communicable with the backend, the -checkconfig can be used:

> ./sapwebdisp pf=<WDP profile> -checkconfig
Checking SAP Web Dispatcher Configuration
=========================================
Server info will be retrieved from host: <server>:<port> with protocol: https
Checking connection to message server of system SID...OK
Retrieving server info from message server...OK
Message Server instance list of system <SID>
+---------------------+----------+---------+----------+
| instance name | hostname |HTTP port|HTTPS port|
+---------------------+----------+---------+----------+
| <server>_<SID>_00 |<server> | 8000 | 2000 |
| <server>_<SID>_02   |<server>  | 8002    |          |
+---------------------+----------+---------+----------+

HTTPS port 2000 is open on Application Server <server>_<SID>_00

If you are using a system on wdisp/system_<xx> with EXTSRV subparameters, ensure to configure the external list of web services using HTTPS protocol and not HTTP, given that the external system has HTTPS enabled.

wdisp/system_0 = ... EXTSRV=https://<server>:<port>;https://<server2>:<port>...
1. 3. Metadata exchange with Message Server (for Web Dispatcher only)

Web Dispatcher retrieves details about active Application Servers and logon groups from the Message Server, these details are called metadata information. To ensure the security of this communication channel the HTTPS can be configured.

The Message Server should provide an HTTPS port configured on the parameter ms/server_port_<xx> on Message Server side. The HTTPS port from Message Server can be checked directly on dev_ms trace file from Message Server backend instance.

> cat dev_ms | grep LISTEN
[Thr 01] set HTTPS state to LISTEN
[Thr 01] *** HTTPS port 4300 state LISTEN ***

The port 4300 should be configured in subparameter MSSPORT of wdisp/system_<xx> parameter

Further information about the Web Dispatcher setup, see Metadata Exchange Using SSL Help page.

See additional information about SSL on the following WIki pages:

How to Configure SAP Web Dispatcher to Trust Backend System SSL Certificate
How to Configure SAP Web Dispatcher to Forward SSL Certificates for X.509 Authentication
How to Setup a Valid Server Certificate in SAP Web Dispatcher

2. Limit the IP address where the service listens

The parameter icm/server_port_<xx> allows to define the subparameter HOST to specify the network interface where the port should be bound, instead of all host names (default behavior) of the server where the service runs. Therefore, only the clients with access to this server's network interface will be able to reach the service.

icm/server_port_0 = ...HOST=<hostname>,...

On this example, only the IP address of host <hostname> will be bond

3. Access Control Lists (ACL)

The ACL feature is a low level control that can limit the client's IP address (or range) allowed to access the Web Dispatcher service. To enable the feature, the subparameter ACLFILE should be set on the icm/server_port_<XX> parameter. If the feature is enabled, only the explicit permit listed IPs will be able to access the service. Note that a "deny all" rule is added at the end of the file, at runtime. Therefore, it is required to create the permit list and allow IPs and all others are denied.

See Setting Up Access Control Lists (ACL) help documentation.

4. Slowloris attack

A Slowloris attack may block the availability of the Web Dispatcher, therefore, the parameter icm/server_port_<XX> allows to control connection data rate of requests with the subparameters MIN_RECEIVE_RATE, CHECK_RECEIVE_RATE_AFTER and MAX_RECEIVE_TIMEOUT.
The the following documentation with details and examples of its usage.

1981955 - Enforcing minimal request transfer rates on SAP Web Dispatcher and ICM

Mitigating Slowloris Attacks

The Traffic Control timeout feature can be used as well.

5. Request Throtteling (for Web Dispatcher only)

There are two options that can be used on wdisp/system_<XX> parameter to control the number of processed requests and avoid overload:

- PENDING_REQUEST_LIMIT_WARN defines when a warning is written into the trace file, syslog, etc;
- PENDING_REQUEST_LIMIT_REJECT declares when a request is actually rejected;

Both subparameters contain the absolute limit for pending requests. They specify the maximum number of connections are sent to the backend Application Server.

6. Limiting the number of connections a single IP can create

The Client IP counter feature controls the maximum number of connections a specific client can establish with the Web Dispatcher. To limit the number of connections a single IP can create to the Web Dispatcher, and avoid shortage of its resources by a single IP, the parameter icm/client_ip_connection_limit can enable the feature. The control is based on the parameter icm/max_conn. For every network connection which is established, the number of existing connections per client IP address is checked. If the current number of connections exceeds the defined limits, either a warning is issued or the connection is rejected. In both cases a system log entry is written.

This feature can help to prevent a DoS (Denial of Service) attack.

icm/client_ip_connection_limit = WARN=30, REJECT=50

This means a single IP cannot exceed the REJECT limit of 50% of icm/max_conn

7. Certificate Revocation Lists

A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the Certificate Authority (CA) before their scheduled expiration date. Therefore, these certificates should not be trusted and belong to a blacklist.
The CR control is a feature that can be activated by SAP CommonCryptoLib.

It is possible to follow the configuration of the SAP Note 2507917 to enable it on Web Dispatcher profile.

8. Content Scan Interface

The CSI interface is active by default on Web Dispatcher. Just ensure that the parameter csi/enable is not disabling it on the profile. This security interface evaluate the user input for program commands. Additional details on Checking User Input for Program Commands.

9. Authentication Handler

Use the authentication handler to set up URL filters.
The Authentication handler is executed before the any other handler (just after the log handler, see Processing HTTP Requests). It can be activated with the parameter icm/HTTP/auth_<XX> to control and limit the access to specific URLs before any other Web Dispatcher handlers act on the request. Rules on the authentication handler can also refer to specific client IP addresses, or to server IP addresses.

In additional to the permit list control, it is possible to define the URLs that will require HTTPS protocol with the option "S". See the SAP KBA 2400856 with examples of rules and configuration.

S /sap/public/*
D * * * *

/sap/public/* requests are allowed with HTTPS protocol. All others requests are denied

10. Modification Handler

The Modification Handler setup by the parameter icm/HTTP/mod_<xx> can be used to perform deeper checks on the request the Web Dispatcher receives. It is possible to create rules to deny specific requests that match specific unwanted situations. This handler take advantage of regular expressions, therefore, it make this a powerful feature to control and act over requests.

Some details and examples about rules on Web Dispatcher as a URL filter.

11. Web Administrator interface

Web Dispatcher has a web interface to manage its features and functions. The parameter icm/HTTP/admin_<XX> is used to activate the interface and the following features are used for security purpose:

11. 1. Subparameter ALLOWPUB

It is used to define the access of Web Dispatcher admin interface. The interface enable access to management operations, statistics and others operations. However, part of this information is public hence do not require authentication. The subparameter ALLOWPUB configured to FALSE disable the unauthenticated access to these public pages that may revel important information.

icm/HTTP/admin_0 = ... ALLOWPUB=FALSE ...
11. 2. SSL access

It is possible to restrict the access to the interface using an specific TCP port setting the subparameter PORT that should be defined as well in the icm/server_port_<XX>. Using a port from a service defined with HTTPS protocol will require HTTPS access from client side.

icm/HTTP/admin_0 = PREFIX=/sap/wdisp/admin, DOCROOT=./admin, PORT=8888
icm/server_port_0 = PROT=HTTPS, PORT=8888 ...

The access is restricted to https://<hostname>:8888/...

11. 3. Control the hosts that can access the service

The subparameter CLIENTHOST can be used to limit the client hosts that are allowed connect to the administration interface. It is required to limit the access to internal network or just specific clients.

icm/HTTP/admin_0 = ... CLIENTHOST=loclahost;<host123>;<host456>...
11. 4. Limit the access to internal network hostnames

Setting the subparameer HOST defines host names that clients must use to connect on the web interface. This allows only access for a server name or IP address that can be reached from the specific name.

icm/HTTP/admin_0 = ... HOST=internal.example.com, ...

Web admin access allowed only if the client used internal.example.com to reach the Web Dispatcher

12. Remove details about error handling

This feature determines the standard form of HTTP error messages that the Web dispatcher creates and sends to the client. Ensure that the detailed errors are disabled with the parameter is/HTTP/show_detailed_errors. Disabling this feature means that the error page does not contain details about the cause of the error. 

This information may be required for troubleshooting purpose. However, for security reasons, it is important to remove it not to disclose the service identity. 

13. Customize error pages

This is an alternative option to the default error pages. Configure your own error pages to ensure that the system does not provide with the technical reason for the error to the client. To activate this configuration, the parameter icm/HTTP/error_templ_path should be set and your own error templates created to avoid the default error pagess that may disclose information about the service.

14. Disable server headers information

Server header are send to the clients on the headers of responses. To avoid security issues, it is recommended that the information should not be forwarded to the clients.The parameter is/HTTP/show_server_header can be used to avoid the inclusion of the header.

15. Tracing information

It is possible to trace information on Web Dispatcher trace file (dev_webdisp) from several forms. See list of the parameters that can be used to activate trace information and its security aspects:

15. 1. icm/HTTP/trace_info

This parameter is the most safe way to trace requests and responses without writing sensitive data into the trace file. However, this parameter might not provide enough information to analyze all cases. See details on  How to configure traces on Web Dispatcher or ICM.

15. 2. icm/trace_secured_data

This parameter should be used only for analysis purpose when the SSL data must be written to the trace file. By default, its value is set to FALSE and usually should be set to TRUE together with parameter rdisp/TRACE if an analysis is required. See details in the help documentation. Ensure this parameter is set to FALSE and only activate it for troubleshooting purposes.

15. 3. rdisp/TRACE_HIDE_SEC_DATA 

Due to security reasons critical information is hidden on the trace file. The Web Dispatcher remove header like authorizations, passwords and cookie from the payload written in the trace by default and this is a feature controlled by the mentioned parameter. If, for troubleshoot reasons, these data are required, this parameter must be set to FALSE, however, for security reasons it should be kept as TRUE (default) during normal operation.

See also  Tracing HTTP headers in trace file.

15. 4. icm/HTTP/logging_<XX>

The HTTP logging handler allows the creation of a log file with all details about requests the service receives. This feature may help security analysis to identify issues, attacks or even troubleshot connections. This feature log generic details about requests to the service, methods, IPs, paths, etc.

All details about how to activate the logging on this help documentation.

15. 5. icm/security_log

This feature can be used to help identify any potential unauthorized access to the system. The security log gives an indication of the possible security procedures that could be followed. In particular cases a decision must be made as to whether the entry really is a serious security risk.

See details on Security Log help documenation.

 

 

 

 

  • No labels