RFC Gateway security, part 6 – Logging
From my experience the RFC Gateway security is for many SAP Administrators still a not well understood topic. As a result many SAP systems lack for example of proper defined ACLs to prevent malicious use.
After an attack vector was published in the talk “SAP Gateway to Heaven” from Mathieu Geli and Dmitry Chastuhin at OPDCA 2019 Dubai (https://github.com/gelim/sap_ms) the RFC Gateway security is even more important than ever. This publication got considerable public attention as 10KBLAZE.
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
Part 6: RFC Gateway Logging.
Part 7: Secure communication
Part 8: OS command execution using sapxpg
Part 9: enhanced security for sapxpg
2023-03-21: Added Part 9: enhanced security for sapxpg2023-02-28: Added Part 8: OS command execution using sapxpg
2021-11-10: Added Part 7: Secure communication
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
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
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.