Anzeige

SAP Security: 4 Empfehlungen für mehr Sicherheit

Thomas WerthWie gehen Einbrecher in SAP-Systeme vor? Sie versuchen zunächst auf den leichtesten Wegen in die SAP-Systeme zu gelangen. Wenn Sie für den Betrieb oder die Sicherheit Ihrer SAP-Landschaft verantwortlich sind, sollten Sie typische Angriffswege kennen und absichern.

In seinem Gastbeitrag stellt Thomas Werth, Geschäftsführer von werth IT und Spezialist für IT- und SAP-Security Services, die ersten vier Quick-Wins vor, die mit wenig Aufwand einen großen Sicherheitsgewinn bringen können. Es geht dabei um das Einspielen von SAP Security Patches, die Absicherung des SAP RFC Gateways, die Passworte für SAP-Standardbenutzer und die Gefahr bei RFC Destinations.

 

 

Quick-Wins für mehr Sicherheit in SAP-Systemen

SAP Security Tipps

Die Härtung eines SAP-Netweaver ABAP Systems ist eine Herausforderung für sich. Allein der monatliche Security Patch Day ist teilweise schwer zu bewältigen. Wie startet man also die Reise zu einem sicheren System? Diese Anleitung liefert acht Quick-Wins (vier davon in diesem ersten Teil) für einen schnellen und erfolgreichen Start für das Abenteuer, ein besser abgesichertes SAP-System zu schaffen.

Dabei liegt der Fokus auf einfache und schnelle Handgriffe zur Verbesserung der Sicherheit. Somit ist offensichtlich, dass hier keine Berechtigungskonzeption, nicht die Erstellung eines ausführlichen Patch-Prozesses oder eine Secure-ABAP-Coding-Richtlinie besprochen werden.

 

„Als Experte für die Bewertung der Sicherheit von SAP-Systemen, sind mir die Strategien potenzieller Angreifer wohl bekannt. Mit den hier vorgestellten Quick-Wins lassen sich diese naheliegenden Angriffswege mit wenig Aufwand versperren!“
Thomas Werth – Geschäftsführer werth IT

 

 

1. Fast-Lane Patches erhöhen SAP-Sicherheit

Und doch dreht sich der erste Tipp um die SAP Security Patches. Ich möchte einen Kniff vorstellen, der zwar keinen richtigen Patch-Prozess ersetzen, aber gegen die monatlich wiederkehrenden Ohnmachtsanfälle helfen kann.

Wer noch keinen praktikablen Weg zum Umgang mit den Patches gefunden hat, der kann wie folgt einsteigen: Zunächst legt man fest, das System jährlich auf den aktuellen Service-Pack Stand zu aktualisieren. Zugegeben, der zugehörige Aufwand ist groß, aber einmal im Jahr muss diese Leistung vollbracht werden.

Dazwischen nimmt man jedoch diese Abkürzung: Monatlich sind die Security-Patches zu kontrollieren. Hier begrenzt man die Auswahl auf Patches mit einem hohen CVE Wert (>= 7) und jene, die als Auswirkung Remote Zugriff auf das System gewähren oder einen Denial of Service ermöglichen.

Damit reduziert man die Anzahl einzuspielender Patches und schließt zugleich die gefährlichsten bekannten Angriffswege. Bei solchen Patches ist die Bedrohung für das System derart hoch und der Patch derart granular, dass ein schnelles Einspielen mit einem minimalen Prüfaufwand gerechtfertigt ist. Sie werden mit jedem eingespielten Patch feststellen, dass dieser Weg praktikabel ist.

 

2. Härtung des SAP RFC Gateways

Das SAP RFC Gateway regelt die Kommunikation mit anderen SAP-Systemen, externen RFC Clients sowie registrierten externen RFC Servern. Es ist eine sehr wichtige Kernkomponente eines SAP-Systems.

In der Vergangenheit sind verschiedene Angriffe gegen diese Schnittstelle bekannt geworden, die es einem Angreifer — ohne gültige Logindaten — erlauben, tief in das System einzudringen. Selbst das Einschleusen eines neuen SAP_ALL Users in das System ist möglich.

In diesem Video ist ein solcher Angriff zu sehen.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

 

Secinfo und Reginfo

Zur Härtung des Gateways ist eine Zugriffssteuerung zu aktivieren. Erst in Systemen ab 7.4 ist diese „per default“ aktiv. Das Aktivieren oder die Kontrolle der Zugriffssteuerung ist über die secinfo und reginfo Dateien möglich. Diese Dateien enthalten Zugriffsregeln für das SAP RFC Gateway.

Die SAP Note 1408081 beschreibt den Aufbau der Dateien. Grundlegendend sollte nur das SAP-System selbst, die Systeme des internen Applikation-Verbundes und zwingend notwendige Kommunikation mit weiteren Systemen in diesen Dateien zugelassen werden.

Konkret sieht der Inhalt dann beispielsweise wie folgt aus:

secinfo:
P TP=* USER=* USER-HOST=local HOST=local
P TP=* USER=* USER-HOST=internal HOST=internal
[P TP=* USER=* USER-HOST=internal HOST=<IP weiteres System>]

reginfo:
P TP=* HOST=local
P TP=* HOST=internal

Der Pfad zu diesen Dateien ist in den Profilparametern gw/sec_info und gw/reg_info anzugeben. Die Pflege der Regeln in den Dateien soll gemäß SAP Vorgaben über die SMGW vorgenommen werden.

 

Sicherheitsparameter

Der Parameter gw/acl_mode regelt, ob diese ACL-Dateien zur Anwendung kommen. Bei einem Wert von 0 gibt es keine Einschränkung, und die Regeln in den Dateien werden ignoriert. Folglich ist dieser Parameter auf 1 zu setzen, damit die Regeln der Dateien verwendet werden. Eine Änderung dieses Parameters erfordert einen Neustart des Servers.

Ähnlich verhält es sich mit dem Parameter gw/sim. Ist dieser aktiv (1), so werden weiterhin alle Zugriffe zugelassen, Verstöße gegen die definierten Regeln werden lediglich protokolliert, aber nicht geblockt.

 

10KBLAZE

Im Rahmen der 10KBLAZE Veröffentlichung sind zusätzliche Angriffswege auf das SAP-Gateway bekannt geworden. Im Kern werden unsichere Konfigurationen von SAP-Routern oder Message-Servern ausgenutzt, um die „sicheren“ ACL-Regeln auszuhebeln. Mit einfachen Mitteln ist aber auch diesem Risiko zu begegnen:

Erstens ist bei der Einrichtung des SAP-Routers zu beachten, dass dieser nicht auf dem SAP-System oder einem SAP-System des Applikation-Verbundes betrieben wird. Der SAP-Router darf keine IP-Adresse erhalten, die zum „internen“-Verbund gehört. Damit kann der SAP-Router schon nicht mehr für einen Angriff missbraucht werden.

Zweitens darf der SAP Monitor Port (39NN) für interne Kommunikation nicht von außen erreichbar sein. Zum effektiven Schutz sind diese Profilparameter zu konfigurieren:

ms/monitor = 0

Dies erlaubt nur Applikationsservern Änderungen durchzuführen

rdisp/msserv_internal = 0

Damit wird verhindert, dass sich beliebige Clients als Applikationsserver ausgeben können.

ms/acl_info = <ACL File analog zu Secinfo>

Dies setzt wie beim SAP RFC Gateway eine Zugriffssteuerung auf den Messageserver.

Die Security Note 821875 liefert dazu ausführliche Informationen.

 

3. Einfallstor Standardbenutzer schließen

Standardzugangsdaten sind immer ein einfacher Weg, um ein IT-System anzugreifen. SAP-Systeme bilden hier keine Ausnahme. Es existieren einige kritische Standard-Benutzer, die allgemein bekannt sind:

vor zurück

User: SAP*
Passwort: 06071992 oder PASS
Mandanten: 000, 001, 066, Kundenmandanten

User: DDIC
Passwort: 19920706
Mandanten: 000, 001, Kundenmandanten

User: TMSADM
Passwort: PASSWORD oder $1Pawd2&
Mandanten: 000

User: SAPCPIC
Passwort: ADMIN
Mandanten: 000, 001

User: EARLYWATCH
Passwort: SUPPORT
Mandanten: 066

User: IDEADM
Passwort: admin
Mandanten: IDES Clients

User: CTB_ADMIN
Passwort: sap123
Mandanten: Java Nutzer

vor zurück

Zum Schutz jedes SAP-Systems sind alle vorbelegten Standard-Passwörter umgehend zu ändern. Ordnen Sie diese Benutzer der Gruppe „Super“ zu. In diese Gruppe gehören auch alle System-Administratoren Ihrer Organisation. Sperren Sie nicht benötigte Standard-Benutzer und setzen Sie diese zudem „ungültig“.

 

Im Zusammenspiel mit dem Solution Manager gibt es zusätzliche gerne übersehene Standard-Accounts, die gerade bei älteren Systemen alle das Passwort „init1234“ haben:

  • SMD_ADMIN
  • SMD_RFC
  • SOLMAN_ADMIN
  • SOLMAN<SID><CLNT>
  • SMD_AGT
  • SMDAGENT_<SID> (zusätzlich auch Satellit!)

Vorsicht auch vor „heimlichen“ Standard-Zugangsdaten. Wird beispielsweise bei der Vergabe von Initialkennwörtern stets dasselbe Kennwort genutzt oder nach einem speziellen Muster verfahren, so hat man defacto ein weiteres Default-Kennwort geschaffen. Dies kann missbraucht werden, um Initial Accounts zu übernehmen. Eine sichere Vergabe von Initialkennwörtern ist demnach notwendig.

 

4. RFC-Destinations sicherer machen

RFC-Destinationen sind definierte Verbindungen zwischen SAP-Systemen. Beispielsweise in der klassischen P-Q-D Landschaft zur Nutzung des Transport-Systems. Auch hier ist Vorsicht geboten, da Test- und Entwicklungssysteme meist weniger abgesichert sind, weil hier keine Produktivdaten liegen sollten.

Ein findiger Angreifer kann versuchen, ein vermeintlich weniger sicheres Testsystem zu attackieren. Er nutzt dann die definierten RFC-Destinationen zum legitimen Sprung bis zum Produktiv-System. Ein solcher Angriff kann jedoch nur gelingen, wenn RFC-Verbindungen von einem niedrig privilegierten System zu einem höheren bestehen. Zudem müssen diese Verbindungen entweder einen „Benutzer mit Passwort“ gespeichert haben oder eine Trusted Verbindung sein.

Zum Schutz vor diesem Szenario sollten bei RFC-Verbindungen nur technische Nutzer oder Systemnutzer verwendet werden, die nur über die für diesen Zweck erforderlichen Berechtigungen verfügen. Auf Trusted Verbindungen von niedrigen zu höheren Systemen ist unbedingt zu verzichten.

Die Nutzung von SNC zur Verschlüsselung der Kommunikation kann die Sicherheit zusätzlich erhöhen, ist aber nicht als Quick-Win zu betrachten, sofern SNC noch nicht implementiert ist.

 

 

Wie man RFC-Schnittstellen absichern, wie man Schnittstellen schützen, wie man ABAP Custom Code mit „authority checks“ absichern und wie man das „SAP Audit Log“ aktivieren kann, erfahren Sie im zweiten Teil der Empfehlungen von Thomas Werth zur „SAP Sicherheit„.

 

Wir danken Ihnen, wenn Sie diesen Artikel jetzt weiterempfehlen:

Anzeige

Über die Redaktion IT-Onlinemagazin

SAP-Community Nachrichten, die Entscheider kennen sollten: Abonnieren Sie jetzt unseren IT-Onlinemagazin Newsletter. Lesen Sie Umfrageergebnisse, Insights aus dem SAP-Ecosystem, Interviews und Artikel ... und Sie bleiben kompakt informiert.

Lesetipp für Sie:

Was SAP-Kunden 2024 zur SAP-Security planen

45 Prozent der SAP-Systeme sind wahrscheinlich nicht ausreichend geschützt, nur 40 Prozent der Unternehmen sehen …