RFC Gateway security, part 6 – Logging

With this blogpost series i try to give a comprehensive explanation of the RFC Gateway Security:

Part 1: General questions about the RFC Gateway and RFC Gateway security.

Part 2: reginfo ACL in detail.

Part 3: secinfo ACL in detail.

Part 4: prxyinfo ACL in detail.

Part 5: ACLs and the RFC Gateway security.

RFC Gateway Logging

What about logging functionality of the RFC Gateway in general?

The logging in RFC Gateway is event based. The various event types are specified by letters which are also used to configure the to be logged events.

These letters are reused in the log file to indicate which event type lead to the log entry. The respective letter recurs as first character of a line in the log file.

Each line represents a logged event.

How to configure logging in the RFC Gateway?

Logging is configured by profile parameter ‘gw/logging’. This profile parameter offers several sub-parameters where some of them are explained below.

While the RFC Gateway logging settings could also be adjusted on SAP NetWeaver AS ABAP in transaction SMGW or in general by the command line tool ‘gwmon’, only settings defined in the profile parameter are persistent.

Which usage types are covered by the logging?

As we learned in part 1 the RFC Gateway serves for different usage types. The logging covers all these usage types. For some the logging is more detailed than for others.

What events should be logged by the RFC Gateway?

Logging is always a trade of between log volume and meaningful data for forensics. For the RFC Gateway we should log at least the following events:

X = Start/stop of RFC Gateway, Log file rotation

S = Security events

Z = Rejected access without rules denied by implicit deny all rule

P = Dynamic Parameter Changes

E = External Programs

R = Registered programs

Which results in the sub-parameter ACTION=ERSZPX.

What about log file handling?

The RFC Gateway comes with a functionality to rotate log files

a) on a hourly, daily, weekly, monthly or yearly basis, defined in sub-parameter ‘SWITCHTF’ (the rotation happens at the first log event after midnight),

b) or depending on the file size, defined in sub-parameter ‘MAXSIZEKB’,

c) or a combination of both.

Log retention can be configured by sub-parameter ‘MAXFILES’ .

We could for example set MAXSIZEKB=0 – while making sure there is sufficient disk space – in combination with MAXFILES=90 specifying the number of files to be retained. With SWITCHTF=day this results in daily log rotation with 90 days log retention.

For a reliable log file handling the file name should be specified as unique as possible, e.g., by setting the sub-parameter LOGFILE=gw_log_$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)-%y-%m-%d.

Anything specific to look for in this logs?

During the initial creation of custom ACLs we should consider to monitor the log files for

◉ ‘secinfo accepted:’ and ‘secinfo denied:’,

◉ ‘reginfo accepted:, ‘reginfo denied:’, and ‘reginfo (no rule found):’

◉ ‘prxyinfo accepted:’ and ‘prxyinfo denied:’.

Later during day to day business we should consider to monitor the log files at least for

◉ ‘secinfo (no rule found):’

◉ ‘reginfo (no rule found):’

◉ ‘prxyinfo denied:’

◉ log entries starting with ‘E’

◉ log entries starting with ‘P’

for suspicious activities while still collecting all events mentioned above for forensics.