Tür zu – es zieht! – SAP Web Dispatcher URL Filter konfigurieren
Autor: Tobias Harmes | 21. September 2018
Alle Welt setzt den SAP Web Dispatcher ein, um Web-Apps und Webservices aus dem SAP für das Internet erreichbar zu machen. Allerdings gibt der Web Dispatcher im Standard alles frei, was das SAP System zu bieten hat. Ein URL Filter für den SAP Web Dispatcher hilft, die Tür nur so weit aufzumachen, wie wirklich nötig.
Der Bedarf für die Anbindung von SAP Systemen an das Internet ist in den letzten Jahren sprunghaft gestiegen. Apps und Webservices entwickelt und veröffentlicht auf dem SAP System werden zum Internet hin freigegeben. Eine praktische Methode das zu tun ist der SAP Web Dispatcher – er fungiert als Reverse Proxy und kann Anfragen aus dem Internet an das interne SAP System durchreichen. So muss das interne ERP System nicht direkt mit dem Internet verbunden werden. Zusätzliche Informationen zu SAP Web Dispatcher finden Sie hier.
Warum eigentlich URLs filtern?
Das Dilemma ist, dass zwar viele Unternehmen den Rat beherzigen, einen SAP Web Dispatcher vor ihr SAP System zu schalten. Aber es erfolgt keine Einschränkung des Zugriffs hinsichtlich der freigegebenen Zugriffspfade bzw. URLs. So kann ich nicht nur die gewünschten Apps und Webservices aus dem Internet erreichen, sondern auch viele Testwebservices, Webdynpros und auch System-Programme. Und natürlich auch die SAP WebGUI mit voller Anmeldung. Alles nützlich um mehr von Ihrem Unternehmen zu erfahren und im schlimmsten Fall diese Informationen zu stehlen und/oder gegen Sie zu verwenden.
Einfacher Selbsttest: Googlen Sie nach site:meinefirma.de inurl:/sap/bc/bsp (Testlink)
Unter Umständen muss man einmal bestätigen, dass man kein Roboter ist – diese Art von Anfragen wird halt tatsächlich von Bots durchgeführt, die das Internet durchforsten nach leichter Beute. Und jetzt kann man überlegen, ob die Ergebnisse nicht angepasst werden können. Man könnte URL-Bingo spielen und neue URLs formen. Z.B. den seit mehr als 10 Jahren bekannten Klassiker – aus /sap/bc/bsp ein /sap/public/info machen (siehe Bild).
Nur weil bei Ihnen da nichts angezeigt wird, muss es natürlich nicht heißen, das nicht doch etwas da ist. Vielleicht kennen Sie nur die richtige URL noch nicht. Das liegt daran, dass im Standard der Web Dispatcher erst einmal alles freigibt, was auch im internen SAP System freigegeben ist. Während das Risiko dafür im internen Netz vielleicht noch überschaubar ist, ist es im Internet ungleich höher. Denn dort gibt es keine Client-Richtlinien oder Firewalls die irgendwelche Roboter-Angriff erkennen und unterbinden.
Grund genug also für die alte Wahrheit: nur das an Diensten freigeben, was man auch wirklich benötigt.
Glücklicherweise geht das im Web Dispatcher relativ einfach.
SAP Access Control SPM - Installation und Migration - RZ10.de Partner
Sie möchten gerne Umsteigen auf SAP GRC 12 Access Control Firefighter? Profitieren Sie von unsere langjährigen Projekterfahrung und Expertise.
Die Schritte um den URL Filter zu konfigurieren
1. Logging aktivieren
Es macht Sinn das Zugriffslogging zu aktivieren, um eine Liste von gerade genutzten Diensten und URLs zu erhalten. Falls noch nicht vorhanden, muss in das Web Dispatcher Profil folgender Parameter aufgenommen werden:
icm/HTTP/logging_0 = PREFIX=/, LOGFILE=access_log-%y-%m, MAXSIZEKB=10000, SWITCHTF=day, LOGFORMAT=SAP |
Logformat „SAP“ ist eine Abkürzung für den String %t %h %u – „%r2″ %s %b %L “
%b sind die Bytes der Anfrage, %L ist die Verarbeitungszeit in Millisekunden.
Wenn mehrere Systeme über verschiedene Ports abgewickelt werden, empfiehlt sich noch %v %S. Diese stehen für den Zielserver und den Ziel-Port. Z.B. webdispatcher.example.com 8443
Also:
icm/HTTP/logging_0 = PREFIX=/, LOGFILE=access_log-%y-%m, MAXSIZEKB=10000, SWITCHTF=day, LOGFORMAT=%t %h %u - "%r2" %s %b %L %v %S |
Dies würde dann im work-Verzeichnis ein access_log-File anlegen. Beispiel-Log-Eintrag
[21/Sep/2018:15:41:35 +0100] 10.10.10.10 - - "GET /dummy HTTP/1.1" 200 86 10 webdispatcher.example.com 8443 |
Packungsbeilage: bei einer großen Anzahl von Zugriff kann das Logging Performance-Einfluß haben. Auch muss der Platz auf dem Filesystem (automatisch) überwacht werden, um dort Probleme zu vermeiden. Das wird ja auch primär für den Moment benötigt, wo der URL Filter aufgebaut wird.
2. Aus dem Log eine URL-Filter-Access-Liste machen
Das Access-Log kann dann ausgewertet werden um alle relevanten URLs zu ermitteln. Ich verwende sehr gerne Excel. Aber unter Linux geht es wohl mit cut bzw. sed schneller. Die URLs müssen in eine bestimmte Form als Permission File aufbereitet werden. Im Wesentlichen muss man vor jede gewünschte URL ein „P“ für Permitted, also erlaubt bzw. eher „S“ für HTTPS erlaubt eintragen. Siehe Beispiel weiter unten. Die Datei kann z.B. unter /usr/sap/<SID>/SYS/profile/perm_filter.txt abgelegt werden. Achtung: keine Leerzeilen verwenden. Diese haben in einem bekannten Fall im Web Dispatcher den Start verhindert.
Ich würde die Liste am besten auch vom Fachbereich/Applikationsbetreuern verifizieren lassen.
Beispiel für perm_filter.txt:
# This is the "permission file" used by the Web Dispatcher Authentication handler # Each line has to start with either "P" (for "Permit"), "D" (for "Deny") or "S" (for "Secure", meaning that the access is permitted only if HTTPS is used). # The next field on the line is the URI pattern, or URL path / prefix. For example, "/sap/bc/*". # The next fields define a user ID, group, client IP address (IP address from the end user) and server IP address (IP address of the Web Dispatcher server). # Admin # webadmin und ping nur von Admin-Stationen 10.10.10.0/24 erlauben P /sap/bc/ping * * 10.10.10.0/24 * P /sap/wdisp/admin/* * * 10.10.10.0/24 * # Webapps and WebGUI (https only)from internal IPs S /sap/bc/webdynpro/* * * 10.0.0.0/8 * S /sap/bc/gui/sap/its/webgui * * 10.0.0.0/8 * # Webapps and WebGUI (https only)from Internet S /sap/bc/srt/rfc/meinwebservice * * * * * # Everything not listed above will be denied because of the final implicit rule "D * * * * *" |
3. AUTH-Handler für URL Filtering aktivieren
Wenn die Datei gespeichert ist (Achtung, auf die Rechte achten), dann kann die Datei im Instanzprofil des Webdispatchers referenziert werden. Der Pfad muss dem Parameter PERMFILE mitgegeben werden.
icm/HTTP/auth_0 = PREFIX=/, PERMFILE=/usr/sap/<SID>/SYS/profile/perm_filter.txt |
Der Web Dispatcher muss für die Aktivierung gestoppt und gestartet werden.
4. Testen
Nach dem Neustart des Web Dispatchers ist der Filter aktiv. Sollte der Web Dispatcher nicht starten, sollten Sie kontrollieren, ob sich nicht doch eine Leerzeile in das Permission-File eingeschlichen hat. Wenn ich nun über den Web Dispatcher auf nicht freigegebene Ressourcen zugreife, erhalte ich ein HTTP 403 – Access Denied.
Ich kann den aktuellen Status der Access List auch über das Web Admin Interface abrufen (HTTP Handler -> Access Handler). Dort kann ich übrigens auch die Filter-Liste nach Veränderung ohne Neustart neu laden (danke für diesen Kundentipp!).
Fazit
Eine Einschränkung auf gewünschte URLs lässt sich schnell auf dem Web Dispatcher realisieren. Allerdings muss wie bei Firewall-Regeln genau geprüft werden, ob die Liste wirklich vollständig ist. Ansonsten gibt es lange Gesichter bei legitimen Benutzern. Es gibt grundsätzlich auch noch andere Ansätze, diesen URL Filter zu realisieren. Wenn die Regeln z.B. komplizierter werden müssen, dann kann auch mit regulären Ausdrücken gearbeitet werden. Weitere Infos dazu gibt es z.B. hier
Übrigens: Das Vorgehen mit dem Web Dispatcher kann natürlich auch noch eine Ebene früher verwendet werden. So eine Einschränkung macht auch für interne ERP-Systeme Sinn. Denn wenn etwas schon im LAN nicht erreichbar ist, dann muss es auch nicht zum Internet hin abgeschottet werden. Entsprechende Filterregeln gibt es auch für den ICM im ABAP Stack.
War das hilfreich oder ist noch etwas unklar? In jedem Fall freue ich mich über einen Kommentar. Und wer es lieber direkt klären möchte: ich biete auch eine Online Sprechstunde an.