SAP Gateway Security mittels secinfo und reginfo

Das SAP Systeme laut Sicherheitsleitfaden besonderer Schutzvorkehrungen bedürfen ist schon lange kein Geheimnis mehr. In der Regel stellt man die Systeme in eine eigene DMZ und sichert so schon mal die vielen Netzwerk Ports der Systeme ab und verhindert direkte Datenbankverbindungen, die nicht erwünscht sind. Soweit, so gut. Gegebenenfalls wird noch ein SAP Router als zentraler Zugangspunkt für Verbindungen eingerichtet. Den Rest erledigt man über die SAP hinterlegten Berechtigungsabfragen.

Sollte reichen wird der ein oder andere denken. Stimmt, reicht ja auch. Wenn da nicht das SAP Gateway einer jeden SAP Instanz wäre. Ist doch nicht so schlimm, ich habe doch extra eine DMZ eingerichtet, an das Gateway kommt man von außen nicht direkt. Und wie sieht es mit dem SAP Router aus? Sicher, dass nicht doch irgendwo eine unglückliche Portrange freigeschaltet ist? Und selbst wenn – solange der entsprechende Eindringling kein passenden ABAP User samt Passwort hat kann ja nichts passieren wird man jetzt argumentieren.

Leider stimmt das nicht ganz.

Sofern keine Gateway Security hinterlegt ist (secinfo) kann jeder, der Zugriff auf das Gateway hat sämtliche Betriebssystemkommandos starten. Das bedeutet, dass man nicht nur Dateien erstellen, löschen und modifizieren kann sondern auch die Datenbank – am ABAP vorbei – editieren kann. So ist es zum Beispiel möglich einen sqlplus „/as sysdba“ abzusetzen und Tabellen bzw. Datensätze zu modifizieren, lesen und zu löschen. Dem findigen SAP Kenner steht hier Tür und Tor offen. Mit so trivialen Dingen wie einem Brutforce Angriff auf einen Benutzer muss man sich gar nicht mehr abgeben. Die wenigsten Administratoren sind sich dieser Gefahr wirklich bewusst. Ebenfalls vergessen wird oft, dass die Angriffe natürlich auch aus der DMZ selbst erfolgen können. Zum Beispiel wenn die einzelnen Systeme einer Linie nicht gegeneinander abgeschottet sind. Ein entsprechender Benutzer im Entwicklungssystem sollte keine Probleme haben ein externes Betriebssystemkommando aus dem SAP heraus an zu starten. Zum Beispiel ein kleines Script, was den entsprechenden RFC Aufruf gegen das Produktionssystem ausführt…

Die SAP schreibt hierzu in ihrer Onlinedokumentation:

Standardmäßig ist diese Datei nicht vorhanden, d.h. dass alle Programme von jedem Benutzer gestartet werden können. So können unautorisierte Benutzer durch einen Zugriff auf das SAP Gateway über das Netzwerk sämtliche Betriebssystemkommandos auf einem SAP System ausführen. Wenn diese Datei vorhanden ist, aber keine Einträge enthält, kann überhaupt kein Programm angestartet werden. Um das Verhalten mit externen Programmen zu steuern, wird eine secinfo-Konfiguration des SAP-Systems dringend empfohlen.

Doch was tun wenn guter Rat teuer ist? Eigentlich ist es gar nicht so schwer die Systeme ordentlich abzusichern. Wenn man weiß wie. Und auch hier hilft help.sap.com weiter – zumindest mit dem groben Ansatz.

Hier noch ein paar erklärende Hinweise. Der Dateiaufbau der reginfo / secinfo Konfigurationsdateien sollte in allen SAP Systemen innerhalb der SAP DMZ einheitlich vorgenommen werden. Hierbei wird im Header der Datei per Kommentar die IP Adresse und das entsprechende System genannt um die Lesbarkeit der Dateien zu verbessern. Zudem sollte wenn Möglich die Konfigurationsversion 2 gewählt werden.

Die Struktur der Dateien sollte so gewählt werden, dass zunächst eine White List mit den erwünschten Verbindungen aufgeführt wird und diese dann mit einem Deny-All abgeschlossen ist. Somit ist sichergestellt, dass alle nicht in der White List aufgeführten Verbindungen geblockt werden. Die folgenden Gateway Security Dateien sind der Zentralinstanz des SAP E01 entnommen (DVEBMGS01, E01, Systemnummer 01):

reginfo – Datei:

#VERSION=2
#
# Other external programs to register go here before the local stuff
#
# Jede zugelassene Verbuindung muss explizit aufgefuehrt werden (P)
# Fuer jeden Hosteintrag muss der CANCEL/ACCESS Parameter gepflegt sein.
#
# E01: DVEBMGS01
# sape01(Host-IP)=192.168.1.1
# SAP Router=192.168.1.99
# dk-parma(saptrans-kfall)=10.70.88.55
# webserver01=10.10.10.10
#
P TP=* HOST=192.168.1.1 CANCEL=192.168.1.1 ACCESS=192.168.1.1
P TP=* HOST=local CANCEL=local ACCESS=local
P TP=JCO_PROGRAM HOST=192.168.1.1,192.168.1.99,10.10.10.10 CANCEL=192.168.1.1,192.168.1.99,10.10.10.10 ACCESS=192.168.1.1,192.168.1.99,10.10.10.10
D TP=* HOST=*
#

secinfo – Datei:

#VERSION=2
#
# Jede zugelassene Verbuindung muss explizit aufgefuehrt werden inkl. aller beteiligten IPs (P)
#
# E01: DVEBMGS01
# sape01(Host-IP)=192.168.1.1
#
P USER=* USER-HOST=local HOST=local TP=*
P USER=* USER-HOST=192.168.1.1 HOST=1192.168.1.1 TP=*
D USER=* USER-HOST=* HOST=* TP=*
#

Hier noch ein paar Besonderheiten die sich je nach Systemaufbau bei der Netzwerkkommunikation ergeben können. Sollte ein SAP System als Shared Host System mit der virtuellen IP Adresse installiert sein ergibt sich daraus ggf ein kleines Problem bei der Netzwerkkommunikation. Eingehende Verbindungen gegen das System laufen immer unter Verwendung der virtuellen IP Adresse ab. Gegen die virtuelle IP Adresse, die auch in der Konfiguration hinterlegt ist werden die Netzwerk Ports gebunden.

Aufgrund technischer Gegebenheiten wird die ausgehende Netzwerkkommunikation daher gegebenenfalls nicht über die virtuelle IP des SAP Systems abgewickelt, sondern über das Hostinterface des Servers selbst. Das bedeutet, dass nicht das SAP System mit seiner virtuellen IP eine Netzwerkverbindung zu einem anderen System aufbaut, sondern in diesem Fall der Host selbst. Entsprechend muss bei der Erstellung der secinfo sowie reginfo Dateien darauf geachtet werden, die passenden IPs einzutragen.

Bei Verbindungen über den SAP Router muss beachtet werden, dass dieser bei Beteiligung an der Verbindung ebenfalls mit in die reginfo bzw. secinfo Datei eingebunden werden muss. Je nach Installationsart ggf. ebenfalls mit der IP des Hosts anstatt einer ggf. virtuellen IP.

Wichtig bei Systemen, die aus mehreren Instanzen mit entsprechend mehreren Gateways bestehen ist zu wissen, dass die Dialoginstanzen, sofern sie Jobs an starten wollen, die z.B. für die Datenbankwartung notwendig sind (CheckDB) zugriff auf SAPXPG benötigen. Angenommen die Zentralinstanz beherbergt ebenfalls die Datenbank und es gibt eine Dialoginstanz auf einem anderen Server. Damit die Dialoginstanz auf das Programm SAPXPG, das wiederum den brconnect -u / -f check aufruft, der Zentralinstanz zugreifen kann muss in der secinfo Datei der Zentralinstanz nicht nur das Starten von SAPXPG seitens der Zentralinstanz erlaubt werden, sondern auch von der Dialoginstanz aus. Dies ob dies möglich ist kann man z.B. auf der Dialoginstanz über die Verwaltung der RFC Verbindungen (SM59) testen. Dort unter den TCP Verbindungen die entsprechende SAPXPG Verbindung auswählen und einen Verbindungstest ausführen.

Sind SAP Systeme als Clusterpakete installiert wird in der Regel die virtuelle Paket IP mitgeschwenkt. Jedoch ändert sich ggf. der Host bzw. die Host IP, wenn die Ressource auf einen anderen Host geschwenkt wird. Auch dies sollte man bei der Erstellung der Security-Dateien für das SAP Gateway beachten. So kann es vorkommen, dass ein P(ermit) Eintrag innerhalb einer Konfigurationsdatei für ein System Quellsystem in Verbindung mit Benutzung des SAP Routers und einem Zielsystem ganze 7 IP Adressen beteiligt und entsprechend hinterlegt werden sollten um spätere Probleme zu vermeiden.

Zum Beispiel:

sapp01 (Paket auf node-a/b, virtuelle IP 10.10.10.100)
node-a (Host-a, physikalische IP 10.10.10.20)
node-b (Host-b, physikalische IP 10.10.10.30)
saprouter (Paket auf node-c/d, virtuelle IP 10.10.10.110)
node-c (Host-c, physikalische IP 10.10.10.40)
node-d (Host-d, physikalische IP 10.10.10.50)
webserver (webserver, physikalische IP 172.128.10.50)

Die Regeln lassen sich ungefähr so lesen:

P = permit -> die folgende Verbindung zulassen (D = deny, Verbindung ablehnen)
TP=JCO_* -> Alle Programme mit JCO_* zulassen (z.B. JCO_WEBSERVER). Hier unbedingt auf die Schreibweise achten, da zwischen Groß- und Kleinschreibung unterschieden wird.
HOST=…, Source-IP des Zugriff auf das Gateway von den dort hinterlegten IP Adressen. Wenn der Quellserver über den SAP Router auf das SAP System zugreift um dort ein Programm zu registrieren muss sowohl der Quellserver eingetragen sein, als auch der SAP Router und ggf. dessen Hostinterface(s).
CANCEL=…, ACCESS=…, Um den Zugriff auf das registrierte Serverprogramm einzuschränken werden mittels der Parameter CANCEL und ACCESS die möglichen Zugriffe auf die an der Kommunikation beteiligten IP Adresse eingeschränkt.

Die folgende Regel sorgt dafür, dass alle Verbindungen, die in der Datei nicht explizit mittels „P …“ erlaubt werden vom System abgewiesen werden:

D TP=* HOST=*

Übersetzung der Regel

D = deny
TP=* Alle Programme
HOST=* Alle IP Adressen

Der unterschied in secinfo und reginfo Dateien lässt sich kurz (und zugegeben etwas unscharf) so beschreiben: Während die secinfo Datei für das Starten lokaler Programme über das Gateway des Application Servers (und dem Programmstart von fremden Systemen auf dem lokalen Gateway!) genutzt wird kann mittels der reginfo Datei festgelegt werden, welches System sich mit welchem Programm auf dem Gateway des Application Servers registrieren darf.

About the author