As the central communication component in an SAP system network, the message server should be protected against undesirable external access.
You can make the following settings to increase the security when the SAP message server is in operation.
Permit or forbid external monitors, like the msmon monitoring program, to connect to the message server.
Specify conditions for the administration of the message server from the browser
Stipulate ACL (Access Control List) for the message server
With parameter ms/monitor you can define that an application server can change or delete the internal memory of the message server. The external msmon monitoring program then has restricted access. The parameter can have the following values:
0: Only application servers are allowed to change the internal memory of the message server and perform monitoring functions (default).
1: External (monitoring ) programs are also allowed to do this.
With parameter ms/admin_port = <no.> (default 0) you can open and close TCP ports of the message server for administration. An external client can connect to the message server through this port to carry out administration tasks on the message server. By default, administration from external programs is deactivated (ms/monitor = 0). To enable this for individual programs, a special a port can be opened. Clients that log on to the message server through this port are allowed to carry out all administration tasks.
The parameter can be changed dynamically. A value smaller or equal to 0 closes the admin port again. If you have administrator authorization, you can see this parameter in the parameter list.
To open, change, or close the admin port in productive operation, in the message server monitor choose
(transaction SMMS).To prevent unwanted clients pretending to the message server to be application servers, you can use parameter rdisp/msserv_internal = <no.>. Value 0 (default setting) means that a separate port is not used for internal communication.
For internal communication a different data channel is used from the one used for external communication, where external clients only have read-only access.
The message server opens another port <no.>, in addition to its port sapms<SID> (rdisp/msserv), which is used for internal communication with the application servers. This port must be used to log on to an application server. Clients that log on through the 'normal' port sapms<SID> are denied access (MSEACCESSDENIED).
Caution
If you want to use this parameter, you must define it on the central system and it must have the same value on all application servers.
The normal sapms<SID> port can still be used for queries. Load distribution functions and the retrieval of application server lists and logon groups are not affected.
With an ACL (Access Control List) you can control which hosts are permitted to open a connection to the message server. A separate ACL can be used for each port on the message server.
You use the following profile parameters for the different message server ports.
Parameter |
Port |
---|---|
ms/acl_file_admin |
Administration port on the message server, which is set with parameter ms/admin_port (see above). |
ms/acl_file_ext |
External port on the message server, which all clients can use. This port is set with parameter rdisp/msserv. |
ms/acl_file_extbnd |
Port number under which an external binding program (icmbnd) has to log on to in order to bind a port. This port is set with parameter rdisp/extbnd_port. For more information, see: Message Server Parameters |
ms/acl_file_int |
External port on the message server, which is set with parameter rdisp/msserv_internal (see above). |
Lines in the ACL must have the following syntax:
Syntax
<permit | deny> <ip-address[/mask]> [tracelevel] [# comment]
Where,
permit = permits a connection, and deny = denies a connection.
<ip address>: The IP address must be an IPv4 or IPv6 address in the following form:
IPv4: 4 byte, decimal, '.' separated: e.g. 10.11.12.13
IPv6: 16 byte, hexadecimal, ':' separated. '::' is supported
<mask>: If a mask is specified, it must be a subnetwork prefix mask:
IPv4: 0-32
IPv6: 0-128
<trace level>: Trace level, with which ACL hits (matches of addresses based on the subnetwork mask) are written to the relevant trace file (default value 2).
<# comment>: Comment lines begin with a hash sign (#).
The file can contain blank lines.
As the last rule a general ban is inserted automatically.
To make it obvious, an explicit deny should be entered anyway as the last rule. The rules are checked sequentially from the “top down”. The first relevant rule determines the result (“first match”).
Example
|
With parameter ms/acl_info you can specify a file with access authorizations to the message server. If this file exists, it must include all host names, domains, IP addresses and/or subnetwork masks from which application servers are allowed to log on to the message server.
The names can be either put in a list or written in separate lines.
This file has no affect on external client who want only to get information from the message server. This is possible in any case.
The entries must have the following syntax:
Syntax
HOST=[*| ip-adr | hostname | Subnetz-Maske | Domäne ] [, ...]
You create the file at operating system level. You can then display and reload the file in the message server monitor (SMMS). To do so, choose
.Example
HOST = sapapp1, sappapp2 means: (Only logons from sapapp1 and sapapp2 are allowed).
HOST = *.sap.com means: (all host names are allowed from sap.com).
HOST = 157.23.45.56, 157.23.45.57 means: Only hosts with these IP addresses are allowed.
HOST = 157.23.45.* means: All hosts from this subnetwork are allowed.