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. prxyinfo ACL Please make sure you have read at least part 1 of this series to be familiar with the basics of the RFC Gateway and the terms i use to describe things. What exactly is defined in the rules in the prxyinfo ACL? The prxyinfo ACL contains rules related to ‘Proxy to other RFC Gateways‘. Every line corresponds one rule. A rule defines ◉ if it specifies a permit or a deny. This is specified by the letter P or Dat the beginning of a rule. ◉ which source is allowed to proxy. This is specified in SOURCE=. ◉ which target is allowed to be reached. This is specified in DEST=. What are the common use-cases? The RFC Gateway may be used to circumvent network level restrictions. For example a SAP system ‘SRC’ cannot directly connect to the SAP system ‘TGT’. The system ‘SRC’ can connect to the stand-alone RFC Gateway ‘PXY’. The stand-alone RFC Gateway ‘PXY’ is allowed to connect to ‘TGT’. In this scenario system ‘SRC’ may proxy requests via ‘PXY’ to the target system ‘TGT’. To identify this use-case on system ‘SRC’ we can look for any connection in transaction SM59 with ‘Gateway Host’ different to the application servers of the same system where the ‘Target Host’ is not directly accessible from at least one of these servers, e.g.,: To identify if a RFC Gateway is used to proxy requests we have to look at the log files of the RFC Gateway and search for ‘prxyinfo accepted:’ or ‘prxyinfo denied:’, e.g.,: To always allow proxying SAP introduced an internal rule in the in the prxyinfo ACL: P SOURCE=* DEST=* This rule is applied when no custom prxyinfo ACL was defined.
