[Genel]

Security on WebDispatcher

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.

[Genel]
[Genel]

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

[Genel]
[Genel]

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_R
ECEIVE_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:

[Genel]
[Genel]

- 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.

[Genel]
[Genel]

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 ...

[Genel]
[Genel]

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

[Genel]
[Genel]

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.

[Genel]
[Genel]

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.

[Genel]