Leseprobe - Amazon S3 · »Netzwerksicherheit herstellen« ... gen. Nach einer Einführung in die...

LeseprobeDie Security-Experten Holger Stumm und Daniel Berlin vermitteln Ihnen in dieser Leseprobe, wie Sie die Sicherheit Ihrer SAP-Systeme auf jeder Netzwerk-Ebene herstellen. Sie erhalten einen Überblick über die wichtigen Begriffe und Architekturgrundlagen und lernen die im SAP-Umfeld stark genutzten Netzwerkprotokolle kennen. Außerdem wissen Sie nach der Lektüre, wie Sie Ihre Netzwerke und Komponenten härten können. Dazu enthält diese Leseprobe das Inhaltsverzeichnis und das gesamte Stichwortverzeichnis des Buchs.

Holger Stumm, Daniel Berlin

SAP-Systeme schützen426 Seiten, gebunden, Februar 2016 69,90 Euro, ISBN 978-3-8362-3851-9

www.sap-press.de/3907

Kapitel 4: »Netzwerksicherheit herstellen«

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

mailto:?body=Leseproben-Empfehlung: �SAP-Systeme sch�tzen� von SAP PRESS, http://gxmedia.galileo-press.de/leseproben/3907/leseprobe_sappress_sap-systeme_schuetzen.pdf&subject=Leseprobe: �SAP-Systeme sch�tzen�

https://www.rheinwerk-verlag.de/sap-systeme-schutzen_3907/?GPP=lpn

101

Kapitel 4

»Das Internet? Gibt’s den Unsinn immer noch?«

Homer J. Simpson

4 Netzwerksicherheit herstellen

In diesem Kapitel betrachten wir die Sicherheit der Netzwerke imSAP-Umfeld. Diese entsprechen den Netzwerken, die für die gesam-ten Unternehmensbereiche zum Einsatz kommen, denn in der Regelgibt es keine abweichende Netzwerkarchitektur für die SAP-Lösun-gen. Nach einer Einführung in die wichtigsten Begriffe und Architek-turgrundlagen werfen wir einen Blick auf die Netzwerkprotokolle,die im SAP-Umfeld stark genutzt werden. Wir geben Ihnen Hin-weise, wie Sie diese Netzwerke und Komponenten härten können.Abschließend geben wir noch einen Ausblick, wie die Zukunft derNetzwerke in Gestalt der Software Defined Networks aussehen wird.

4.1 Netzwerk, Switches, Router und Firewalls

In diesem Abschnitt erklären wir Ihnen zunächst wichtige Begriffeim Zusammenhang mit den Netzwerken anhand des ISO/OSI-Refe-renzmodells.

4.1.1 Das ISO/OSI-Referenzmodell

Um die Elemente, die in Unternehmen ein komplettes SAP-Netz bil-den, besser zu verstehen, ist es oft hilfreich, diese in einen normier-ten Zusammenhang zu stellen. Bei allen Diskussionen um das Wie,Wo und Was in einem Unternehmensnetzwerk hat es sich als hilf-reich erwiesen, hier auf das Netzwerkmodell der Standardisierungs-gremien ISO bzw. OSI zurückzugreifen, Diese haben die gesamteNetzwerkkommunikation in einzelne Ebenen isoliert und den Ebe-nen jeweils einen definierten Funktionsumfang zugewiesen. So kannman auch in komplexen Netzwerken den Verkehr jeweils in diese

3851.book Seite 101 Dienstag, 9. Februar 2016 3:12 15

Netzwerksicherheit herstellen4

102

funktionalen Ebenen (Layer) unterteilen und die Diskussion gezieltauf einzelne Segmente führen. Denn auch die Funktionen von Ether-net-Adaptern, Clients, Switches, Routern und Firewall lassen sichhervorragend semantisch und syntaktisch im Rahmen dieser Normbeziehungsweise dieses Modells erklären.

Ohne es hier im Detail vorzustellen (das würde den Rahmen diesesBuches sprengen) werden wir in den Kapiteln über SAP-Netzwerkeimmer wieder auf das ISO/OSI-Referenzmodell zurückgreifen. Des-halb wollen wir die wichtigsten Funktionsmerkmale kurz erläuternund in den SAP-Netzwerkkontext stellen

Netzwerk-referenzmodell

In dem ISO/OSI-Referenzmodell wird beschrieben, wie ein Datenpa-ket von einer Anwendung selbst (die nicht im OSI-Referenzmodellbeschrieben wird) über die Anwendungsschnittstelle (Ebene 7) bishinunter auf die Bit-Ebene (Ebene 1) und dann letztlich auf das Über-tragungsmedium (z. B. Kupferkabel) kommt. Abbildung 4.1 zeigt dieverschiedenen Ebenen im Überblick. Wie die Anwendung ist auchdas potenzielle Kupferkabel nicht in ISO definiert, wohl aber dieMethode, wie das Bit auf das Medium kommt.

Abbildung 4.1 Das Sieben-Schichten-Modell nach ISO/OSI

(1) Bit-Übertragungsschicht (Physical Layer)

(2) Sicherungsschicht (Data Link Layer)

(3) Vermittlungsschicht (Network Layer)

(4) Transportschicht (Network Layer)

(5) Sitzungsschicht (Session Layer)

(6) Darstellungsschicht (Presentation Layer)

(7) Anwendungsschicht (Application Layer)

ISO/OSI-Modell


Netzwerk, Switches, Router und Firewalls 4.1

103

Ebene 1: Netzwerkebene (Physical Layer)

Für die Betrachtung der Netzwerke sind vor allem die Ebenen 1 (Bit-Ebene, physische Ebene) bis 4 (Transportschicht) relevant. Diese bil-den die Elemente ab, die als akademische Norm das abbilden, wasman in Unternehmen und in der IT gemeinhin als Netzwerke versteht.

Die physikalische Ebene der Übertragung

Die erste Ebene ist die der bitweisen Übertragung, der Netzwerk-topologie und der Infrastruktur (im englischen Original auch als Phy-sical Layer bezeichnet). Die dabei verwendeten Verfahren bezeichnetman als übertragungstechnische Verfahren. Geräte und Netzkompo-nenten, die der Bit-Übertragungsschicht zugeordnet werden, sindz. B. die Antenne und der Verstärker, Stecker und Buchse für dasNetzwerkkabel, der Repeater, der Hub oder der Switch. Hier gibt eskeine technische Verknüpfung zu spezifischen SAP-Protokollen.

Ebene 2: Sicherungsschicht (Data Link Layer)

Die zweite Ebene, die auf Deutsch etwas unbeholfen mit Sicherungs-schicht übersetzt ist, wird im Englischen als Data Link Layer funktio-nal deutlicher bezeichnet. In der Nomenklatur ist schon zu erken-nen, dass es darum geht, die Verbindung und Sicherstellung derfehlerfreien Datenübertragung zwischen zwei Netzwerkpunkten zugewährleisten. Nach der amerikanischen Normungsbehörde IEEE istEbene 2 in zwei Unterebenen (sub layers) unterteilt: LLC (Logical LinkControl, Ebene 2b) und MAC (Media Access Control, Ebene 2a).

Die Verbindung der physischen Kommunikation

Die Hardware, die dieser Schicht zugeordnet ist, sind Bridges, Swit-ches und Multiport-Bridges. Das Ethernet-Protokoll beschreibt so-wohl Ebene 1 als auch Ebene 2, wobei auf dieser als Zugriffskon-trolle CSMA/CD zum Einsatz kommt. Letztlich sind in Ebene 2 dieElemente definiert, die für ein Netzwerk das definieren, was man ge-meinhin als »Topologie« bezeichnet. Im Bereich des Ethernets sindes vor allem die Idee der Leitungen aus Ebene 1, in die sich die Netz-werkeinheiten einklinken und über die sie sich an das Netzwerk an-schließen. Diese Leitungen können so miteinander kommunizierenund sich gegenseitig auf bestehende Kollisionen und Störungen hinüberprüfen (CSMA/CD). So verbundene Leitungen bilden einenStrang, an dem die einzelnen Netzwerkelemente (Taps) hängen.Auch hier gibt es noch keine Verbindung zu einem SAP-Protokoll, inder SAP-Netzwerkarchitektur ist dies eine Ebene, die den Herstellernvorbehalten ist.



104

Ebene 3: Vermittlungsschicht (Network Layer)

Die Ebene 3 ist die Vermittlungsschicht, der Network Layer. Es ist dieSchicht, die im Router adressiert ist. Hier erfolgt das Handling derAdressen, die Identifikation der Weiterleitung zu anderen Netzwerk-segmenten etc. Das »IP« im Interchange Protocol von TCP/IP findethier statt. Die zugehörige Hardware auf dieser Schicht sind Routerund Layer-3-Switches.

Ein Netzwerkbilden

Auch hier gibt es noch keine direkte Verknüpfung mit einem SAP-Protokoll, da hier noch die klassische Netzwerkadressierung, Weg-suche und Transportfindung (Routing) stattfinden.

Ebene 4: Transportschicht (Transport Layer)

Die Ebene 4 ist die Anwendungsebene, auf der die SAP-Protokolleaufsetzen. Sie wird als Transportschicht bezeichnet (engl. TransportLayer; auch Ende-zu-Ende-Kontrolle oder Transport-Kontrolle), die den»Payload« (Nutzdaten) weiterleitet. Aufgabe der Transportschicht istdie Segmentierung des Datenstroms. Sie stellt auch für die höherenEbenen eine definierte Schnittstelle dar, auf die diese einheitlichzugreifen können.

Datentransportieren

Ein Datensegment ist dabei eine Dateneinheit (Data Unit) die zurDatenkapselung auf der vierten Schicht (Transportschicht) verwendetwird. Es besteht aus Protokoll-Elementen, die Schicht-4-Steuerungs-informationen enthalten. Als Adressierung wird dem Datensegmenteine Schicht-4-Adresse vergeben, also ein Port. Das Datensegmentselbst wird in der Schicht 3 in ein Datenpaket gekapselt. Hier setzendie Netzwerkprotokolle der SAP auf. Um von verschiedenen Plattfor-men unabhängig zu sein, hat SAP für alle Netzwerkverbindungen dieZwischenschicht Network Interface (NI) entwickelt. Diese wird vonSAProutern und allen SAP-Programmen, sowie von den SoftwareDevelopment Kits für CPI-C und Remote Function Call (RFC) genutzt.

Somit setzt auch das DIAG-Protokoll von SAP auf die Transport-schichten auf. Aus Sicht des Angreifers sind dies die Schichten, diebei einer Attacke adressiert werden. Dies sind vor allem die Proto-kolle selbst sowie der Router-Verkehr.



105

Ebene 5: Sitzungsschicht (Session Layer)

Auf der Ebene 5 (Sitzungsschicht oder Session Layer) wird die Pro-zess-Kommunikation definiert. Dies ist nicht nur die technischeKommunikation, die auf den Schichten 1–3 stattfindet, sondern defi-niert den Session Context, den Zusammenhang und die Abfolge derKommunikation.

Session-Kontext und RPC/RFC

Der Unix Remote Procedure Call (RPC) und somit auch das SAP-Deri-vat Remote Function Call (RFC) sind hier zu finden. SAP hat eineAbfolge definiert und die Ebene 5 definiert die Synchronisations-und Wiederaufsetzpunkte hierzu.

Ebene 6: Darstellungsschicht (Presentation Layer)

Die Darstellungsschicht (Presentation Layer; setzt die systemabhän-gige Darstellung der Daten in eine unabhängige Form um undermöglicht somit den syntaktisch korrekten Datenaustausch zwi-schen unterschiedlichen Systemen. Das heißt, dass hier die Funktio-nen des SAP GUI durch das DIAG-Protokoll umgesetzt werden.

DIAG und SNCEbenso findet hier nominell die SNC-Verschlüsselung statt, da SNC jaletztlich die Anwendungsdaten verschlüsselt, aber natürlich nicht diedarunter liegenden Schichten des Protokolls. Die Darstellungsschichtgewährleistet, dass Daten, die von der Anwendungsschicht einesSystems gesendet werden, von der Anwendungsschicht eines ande-ren Systems gelesen werden können.

Ebene 7: Anwendungsschicht (Application Layer)

SAP-GUI-Schnittstelle

Die Ebene 7 ist die technische Schnittstelle des Netzwerks zur Anwen-dungsebene und wird oft von Programmierern als Application Pro-gramming Interface (API) wahrgenommen. Es handelt sich um dieSchnittstelle des Anwendungsprogramms. Ebene 7 beschreibt alsonicht die Anwendung selbst, sondern definiert die Art und Weise, wieProgramme mit den Netzwerkkomponenten kommunizieren kön-nen. In aktuellen Programmiersprachen wird eine solche Schnittstellein der Regel als API bezeichnet. In der SAP-Welt stellt etwa das Pro-tokoll Dynamic Information and Action Gateway (DIAG) die Schnitt-stelle zu Ebene 7 des Modells dar.



106

Gesamtsicht auf das ISO/OSI-Modell

Wichtig ist es aus sicherheitstechnischer Sicht, das Netzwerk alsAbfolge von Funktionen wahrzunehmen: Es gibt das Netzwerk selbstmit seinen technischen Elementen wie Repeatern etc. und es gibtden Zugang zu den Netzwerken wie Netzwerkadapter und Switches.Dann folgen die »intelligenten« Funktionen des Netzwerks wie Rou-ter und darüber liegen die session-bezogenen Layer wie RFC-Proto-koll, RFC-Gateway und die Anwendungsschnittstellen. Verschlüsse-lung ist eine Form des Darstellungsschicht, das SAP GUI eine Formdes Presentation Layers.

4.1.2 Verschlüsselung der Netzwerkverbindungen mit SNC

Mit den Secure Network Communications, den SNC-Verbindungen,hat SAP eine eigene Verschlüsselungsebene geschaffen. In den letz-ten Jahren wird speziell die Verschlüsselung von Verbindungen zwi-schen kommunizierenden Komponenten in SAP-Landschaften beiAudits immer wieder gefordert. Bei vielen Kunden war sie bishernoch nicht im Einsatz.

Verschlüsselungmit SNC

Im Standardfall, z. B. bei einer Kommunikation zwischen einemBenutzer mit SAP GUI und dem SAP NetWeaver Application Servererfolgt die Kommunikation unverschlüsselt im Klartext bzw. zwarkomprimiert, aber trotzdem ungesichert. Das bedeutet, dass bei ei-nem Mitschnitt der Verbindung, einem Sniff, die Daten (inkl. Pass-wort und weiteren Anmeldedaten) unverschlüsselt zu sehen sind.Abhilfe schafft hier eine auf kryptografischen Grundlagen vorge-nommene Verschlüsselung. SAP hat hierfür das SNC-Protokoll ge-schaffen.

SNC sichert die Datenkommunikationspfade zwischen verschiede-nen Client- und Serverkomponenten des SAP-Systems. Es gibtbekannte kryptografische Algorithmen, die von den unterstütztenSicherheitsprodukten implementiert wurden; mit SNC können Siediese Algorithmen auf Ihre Daten im Netzwerkverkehr anwenden,um die Sicherheit zu erhöhen. Die gesamte Kommunikation zwi-schen zwei mit SNC geschützten Komponenten wird gesichert (z. B.zwischen dem SAP GUI und dem Anwendungsserver). Sie können sozusätzliche Sicherheitsfunktionen von Drittanbietern verwenden(z. B. Smartcards).



107

Voraussetzung für die Nutzung aller Verschlüsselungsfunktionen,aber auch aller weitergehenden Funktionen im Bereich Sicherheits-zertifikate und digitaler Signierung ist die Installation der SAP Cryp-tographic Library. Dies ist ein Produkt, das Kunden auch für SNC-Verbindungen zwischen Systemkomponenten zur Verfügung steht.Weitere Informationen über Verschlüsselung im SAP-Bereich, demSNC-Protokoll und der Implementierung dieser Technolgien erhal-ten Sie im SAP Help Portal unter der Rubrik SAP Cryptographic

Library.

4.1.3 Firewall in der SAP-Umgebung (ISO/OSI)

Eine klassische Firewall, die immer wieder als zentrales Element injedem Sicherheitskonzept aufgeführt ist, ist keiner Ebene des ISO/OSI-Modells direkt zugeordnet. Sie ist eher komplementär zur Archi-tektur von Netzwerk und Anwendungskommunikation.

Firewall und SAP-Systeme

Eine Firewall ist eine Software, die sich in das Netzwerk einklinktund dieses von dem Rechnernetz (Topologie), das sich jeweils vor derFirewall befindet, segregiert damit jedes angeschlossene Netzwerk-segment eine eigene Sicherheitsebene, eine Policy bilden kann. Sowerden logische Ebenen gebildet, sogenannte Tiers, die voneinandergetrennt sind. Die Firewall stellt dabei beim Übergang von einemNetzwerksegment zu einem anderen die Einhaltung des in derFirewall hinterlegten Regelwerks sicher. Ein klassisches Beispiel sinddie Regeln, welcher Client auf Systeme hinter der Firewall zugreifendarf. Wichtig ist, dass Sie die verschiedenen Richtungen der Kommu-nikation einzeln betrachten. So überprüft die Firewall z. B., ob einSAP GUI von einem bestimmten Rechner auf ein SAP-System zugrei-fen darf, stellt aber auch sicher, das umgekehrt der Server nichtbeliebige Verbindungen öffnen kann, sondern dem Client nur aufder gerade geöffneten Leitung antwortet. Dies sind die grundlegen-den Anwendungen der Firewall, die man den Ebenen 1 bis 4 desISO/OSI-Modells zuordnen kann.

Darüber hinaus beschränken sich moderne Firewalls nicht nur aufdie physikalische Kontrolle von Verbindungen, sondern erweiterndie Funktionen um die intelligente Analyse des Datenverkehrs. Siesetzen dann auf den Ebenen 4 bis 7 des ISO/OSI-Modells auf undbeziehen damit auch Komponenten aus der Anwendungskontrollemit in die Sicherheitsbetrachtung ein.



108

Paketfilter

Die einfache Filterung von Datenpaketen anhand der Netzwerk-adressen ist die Grundfunktion aller Firewalls (in einem TCP/IP-Netzist damit die Filterung des Ports und der IP-Adresse des Quell- undZielsystems gemeint). Filterung bezeichnet hier sowohl das positiveals auch das negative Routing, also den Zugang (Access) oder dieAblehnung (Deny) einer Route.

Stateful Inspection

Diese zustandsgesteuerte Filterung ist eine erweiterte Form derPaketfilterung. Damit gelingt es, den Zugriff auf eine etablierte Ver-bindung genauer zu beschränken und so das interne Netz besser vorungewollten Zugriffen von außen zu schützen. Bei dieser Betrach-tung eines Paketes bzw. einer Kommunikation wird auch der Kom-munikationszustand (Ebene 5 ISO/OSI, der Session Layer) mitberücksichtigt.

Firewall undKontext

Hier wird kontrolliert, ob eine etablierte Verbindung auch keine Sei-tenkommunikation aufbaut, um etwa aus einer Session auf eineandere zu verzweigen. In SAP-Systemen kann solch eine StatefulInspection sich z. B. als Verbindungsabbruch manifestieren, wennInhalte (z. B. Content Header) sich während der Kommunikation vonClient zu Server verändern. SAP Web Services können in diese Kate-gorie fallen.

Proxyfilter

Ein Proxyfilter stellt stellvertretend für den anfragenden Client dieVerbindung mit dem Zielsystem her und leitet die Antwort des Ziel-systems an den ursprünglichen Client weiter. Da er die Kommunika-tion selbst führt, kann er sie nicht nur einsehen, sondern auch belie-big beeinflussen. Während in großen Netzen die Proxy-Funktion oftvon dedizierten Servern übernommen wird, kann dies in Einzelsitu-ationen auch von spezialisierten Firewalls übernommen werden.

SAP WebDispatcher

Der SAP Web Dispatcher übernimmt einige dieser Funktionen, wennim SAP-Bereich Webanwendungen angesprochen werden. Eine Son-derform ist der Reverse Proxy, dessen Aufgaben im SAP-Bereich vondem inzwischen bei den meisten Kunden in Vergessenheit geratenenSAP Business Connector übernommen werden konnten.


SAP-Landschaft analysieren 4.2

109

Content-Filter

Dieser Inhaltsfilter ist eine Form des Proxyfilters, der die Nutzdateneiner Verbindung auswertet und z. B. dafür gedacht ist, auf belie-bigen Inhalt der Kommunikation zu filtern.

SAP Web Dispatcher als Content Filter

Auch diese Funktionen können nicht nur von einer Firewall über-nommen werden, sondern auch von einem SAP Web Dispatcher.Gerade bei SAP-NetWeaver-AS-Java-Servern wird diese Funktionbenutzt, um gewisse bekannte und gefährliche Kommandos vonaußen aus dem Verkehr heraus zu filtern. Auch das Sperren vonunerwünschten Webseiten anhand von Schlüsselwörtern und Ähnli-ches fallen darunter. Auch können in Bezug auf SAP-Traffic mitFirewalls der neuesten Generation verhaltenstechnische und seman-tische Analysen des Datenstroms ausgeführt werden, wie z. B.: Darfein HR-Nutzer CRM-Daten herunterladen? Solche Fälle können dannerkannt und geblockt werden.

4.2 SAP-Landschaft analysieren

Wenn die Sicherheitsbedürfnisse einer SAP-Landschaft betrachtetwerden, ist es wichtig, sich über die grundlegenden Komponentenzu verständigen. In den 1980er Jahren, als es im SAP-Umfeld nochkein umfängliches Internet gab (von den Anfängen als DARPA-Netz-werk der amerikanischen Verteidigungsministerien einmal abgese-hen), waren auch das Ethernet und die damit verbundenen Proto-kolle nicht wie im heutigen Ausmaß vorhanden. Die SAP-Ingenieuremussten sich Teile ihres Netzwerkprotokolls selbst realisieren undhaben deshalb eigene Teilkomponenten erstellt.

Diese Elemente, die sich auch oft nicht eindeutig im ISO/OSI-Modellwiederfinden, sollen hier als Grundlage für die Sicherheitsbetrach-tungen aufgezählt werden.

Die Implementierung der Netzwerkkomponenten der 3-Tier-SAP-Architektur auf einem TCP/IP Stack war geprägt von den Anforde-rungen der Portierung der Kommunikation der alten IBM-Welt mitihren Terminals. Viele Artefakte im SAP-GUI-Protokoll resultierendaraus.

Deshalb müssen die Angriffe auf diese Protokolle auch sehr SAP-spe-zifisch sein. Hier versagen oft die standardisierten Netzwerk-Hacker-



110

Werkzeuge der Internet-Ära und müssen durch Programmierer mitprofunden SAP-Protokoll-Kenntnissen selbst erschaffen werden. Dasist mit Sicherheit eines der Hauptgründe, warum es in der Vergan-genheit wenig ausgewiesene Hacker für die SAP-Netzwerke gibt. Dashat sich aber gerade in den letzten Jahren stark geändert.

Multi-Tier-Architektur im

SAP-Umfeld

Schon im Bereich der Mainframe-Kommunikation war es immer dasCredo der SAP-Entwickler, sich nie auf spezifische Hardwareproto-kolle einzulassen. Deshalb wurde zur Integration der SiemensBS/2000- und IBM/370-Architektur die jeweilige Ebene immer ab-strahiert angesprochen. Diese Weitsicht zahlte sich aus, als man mitSAP R/3 in die Unix-Welt migrierte. Die eigene abstrakte Architekturpasste hervorragend zu den Client-Server-Strukturen. Und mit dendrei Komponenten Präsentationsebene (SAP GUI), Anwendungsser-ver (SAP NetWeaver AS ABAP und RFC) und Datenbankabstraktionhatte man die notwendigen Elemente für die herstellerunabhängigenImplementierungen beisammen. Auf diese drei Ebenen gehen wirim Folgenden genauer ein.

4.2.1 Tier 1: SAP-GUI-Client

Der Hauptzugang zu SAP-Systemen basiert in allen Systemen aufdem SAP GUI. Dieser Zugang basiert auf einem Rich-Client-Konzept,das ein proprietäres Netzwerkprotokoll verwendet. Das Konzept, dasdas SAP GUI verwirklicht, kommt ursprünglich aus der Terminal-Steuerung; dort wurden pro Bildwechsel 24 × 80 Zeichen übermitteltund der Server (damals: Mainframe) leitete daraus die notwendigennächsten Schritte (basierend auf den Benutzereingaben) ab. Auf die-ser Basis wurde in SAP R/3 dann eine client-/server-basierte Dialog-steuerung entwickelt. Durch die damals schon praktizierte Herstel-lerunabhängigkeit der verwendeten Protokolle war die SAP-Dialog-steuerung in allen Netzwerkvarianten ablauffähig.

Das Protokoll, das in der alten Welt benutzt wurde, war die SNA-Architektur der 3270-Terminals. Für die Unix-Welt von SAP R/3wurde die Dialogsteuerung auf dem TCP-IP-Stack realisiert bezie-hungsweise wurde die DIAG-Struktur der übermittelten Pakete dar-auf angelegt. Deshalb liegt die Zuordnung des DIAG-Protokolls auchauf Ebene 6 des ISO/OSI-Modells (des Presentation Layers) und nichtauf Ebene 3 oder 4 (Network bzw. Transport Layer).



111

SAP-GUI-HackAus Sicht eines Angreifers ist das SAP GUI sehr interessant. Zumeinen bietet die auf dem Client liegende SAPINI-Datei einen hohenInformationswert, denn dort sind SAP-Systeme mit Adressen undZielrouten hinterlegt. Zum anderen kann man sicher sein, das dieStrecke vom Client zum SAP-System für diesen Desktop freigeschal-tet ist.

SAP GUI Hack zur Übernahme der IP-Adresse

Wenn man Zugang zu einer Workstation oder einem Desktop hat, aufdem SAP GUI installiert ist, möchte man von hier aus mit seinen eigenenHacker-Werkzeugen wie Nmap oder Metasploit weiter arbeiten. Da aberselbst einfach geschützte Arbeitsplätze in Unternehmen es nicht erlauben,Software zu verändern oder installieren, muss man hier einen Trick ver-wenden. Ich benutze dafür oft meinen Laptop mit einer Kali-Linux-Distri-bution. Hiermit versuche ich, die MAC-Adresse des PCs oder Laptops,den ich übernehmen will, zu ermitteln. Das geht meistens in der DOS-Kommandozeile mit dem Windows-Befehl ipconfig /all. Dieser zeigtmir für den Ethernet-Adapter die MAC-Adresse an. Diese gebe ich dannin Kali-Linux ein (»MAC Spoofing«). Dann stecke ich den Netzwerksteckervom Desktop in den Laptop um. Ich bin jetzt zwar mit meiner neuenMaschine nicht angemeldet, habe aber auf der Netzwerkebene vollenZugriff auf die Infrastruktur. Viele werden sagen, dass dies ein simplerHack ist, aber trotzdem gehört er zum Standard-Repertoire und verdientes, hier erwähnt zu werden.

Eine klassische Gegenmaßnahme liegt im Betrieb des Netzwerks. In vielenUnternehmen wird bei dem für die Sicherheit zuständigen Netzwerk-administrator eine Warnung ausgelöst, wenn an Arbeitsplätzen Netzwerk-kabel ausgesteckt und wieder eingesteckt werden. Darüber können solcheVersuche identifiziert werden. Bei sicherheitsbewussten Unternehmenwird dann auch gleich jener berühmte breitschultrige Herr im schlecht sit-zenden dunklen Anzug (mit der Beule in der Brusttasche) losgeschickt, umnachzusehen, was dort passiert.

4.2.2 Tier 1: Zugang aus dem Internet und Übergang ins Intranet

Dieses Netzwerksegment ist der Übergang vom Benutzer im anony-men Internet zum authentifizierten Intranet-Benutzer und kenn-zeichnet auch die Grenze zum Unternehmensnetzwerk. Traditionellnennt man eine solche Zone auch Demilitarisierte Zone (DMZ),abhängig von der jeweiligen Architektur. Wichtig ist, das hier, meistdurch eine Firewall geschützt, der Prozess oder der Benutzer sich in



112

irgendeiner Form anmelden muss, sei es durch ein Ticket, einenVPN-Zugang oder ein simples Log-in. Aus Sicht eines SAP-Netzwerksist Tier 1 eine weit außen liegende Grenze, denn in klassischenUnternehmensnetzwerken liegen die Anwendersysteme im Tier 2und erst die SAP-Systeme selbst in Tier 3.

Das DIAG-Protokoll

Für die Kommunikation zwischen SAP GUI und dem Anwendungs-server wurde das Dynamic Information and Action Gateway Protocol(kurz DIAG) entwickelt. Es ist ein proprietäres Protokoll, dessen Spe-zifikation nicht veröffentlicht wurde – einige Details sind jedochinzwischen bekannt geworden. DIAG übertragt binäre Daten, die imStandard komprimiert sind, es findet jedoch ohne die zusätzlicheVerschlüsselung per SNC keine Absicherung des Datenverkehrsgegen Sniffing statt.

SAP-GUI-Netz-werkverkehrdekodieren

Die Art der Datenkompression ist inzwischen bekannt und es existie-ren bereits Add-ons für bekannte Netzwerkdiagnose-Tools, wie z. B.Wireshark, die den DIAG-Datenverkehr dekomprimieren und so dieRohdaten lesbar machen. Ein Angreifer, der die Workstation kom-promittiert hat, auf der das SAP GUI läuft, kann sogar die Kompres-sion einfach ausschalten; der Benutzer merkt dies zwar, da einPop-up-Fenster im SAP GUI ihn warnt – ein findiger Angreifer könntedies allerdings umgehen (ein Ansatz hierzu ist den Autoren bekannt).Zudem ist fraglich, ob es sich für einen Hacker lohnt, den zusätzlichenAufwand der Dekompression des Datenverkehrs zu vermeiden, wodies doch recht einfach möglich ist. Dazu muss einfach die Windows-Umgebungsvariable TDW_NOCOMPRESS auf den Wert 1 gesetzt werden.Ob dies auf einem mutmaßlich gehackten Windows-Rechner der Fallist, können Sie einfach über die erweiterten Systemeinstellungenprüfen:

1. Öffnen Sie die Systemsteuerung über das Startmenü.

2. Klicken Sie auf System und dann auf Erweiterte Systemeinstel-

lungen.

3. Im Pop-up-Fenster wählen Sie den Reiter Erweitert und klickendann auf Umgebungsvariablen.

4. Sollte die Variable gesetzt sein, erhalten Sie folgendes Bild (sieheAbbildung 4.2):



113

Abbildung 4.2 Umgebungsvariable zur Deaktivierung der DIAG-Kompression

Analyse eines Netzwerk-Mitschnitts

Trotzdem kennt damit ein Angreifer noch nicht die Protokollinternaund ist nicht in der Lage, eine SAP-GUI-Sitzung vollständig in ver-ständliche Kommandos und Antworten zu übersetzen. Um an Benut-zername/Passwort-Kombinationen zu gelangen oder kritische Datenzu extrahieren, ist dies jedoch auch nicht unbedingt notwendig! Istdem Angreifer der Benutzername bekannt, so findet er das Passwortim Klartext in direkter »Nähe«. In Abbildung 4.3 ist ein Mitschnittdes Netzwerkverkehrs eines SAP-GUI-Log-ins als Benutzer ddic zusehen. Das Passwort abcd1234 ist nur einige Bytes nach dem Benut-zernamen sichtbar (siehe Markierungen auf der rechten Seite).

Abbildung 4.3 Benutzername und Passwort im Klartext



114

Das DIAG-Protokoll ist also im Standard – komprimiert oder nicht –ungeschützt! Ein Angreifer kann ohne tiefgreifendes, technischesWissen Log-in-Daten Ihrer Benutzer aus mitgeschnittenem Netz-werkverkehr extrahieren. Doch es gibt Abhilfe. Sie können auchohne eine Sign-on-Infrastruktur in SAP NetWeaver den Netzwerk-verkehr zwischen SAP GUI bzw. dem BEx Analyzer und dem ASABAP verschlüsseln.

SNC ClientEncryption

Mithilfe von SNC Client Encryption können Sie die Kommunikationzwischen dem Client und einem AS ABAP per Secure Network Com-munications (SNC) verschlüsseln und die Daten vor neugierigen Bli-cken und Manipulationen absichern. Da der komplette Verkehrgeschützt ist, können Hacker weder Log-in-Daten mitzulesen, nochgeschäftliche Vorgänge ausspionieren oder in sie eingreifen. Als ein-zige technische, nicht in jedem Falle bereits vorhandene Vorausset-zung ist ein Microsoft Active Directory Server zu nennen.

Eine verschlüsselte SAP-GUI-Sitzung, wie sie in Abbildung 4.4 zusehen ist, läuft dann folgendermaßen ab:

1. Der Anwender meldet sich an einer Windows-Domäne an undstartet eine SAP-GUI-Verbindung zu einem AS-ABAP-System, dasSNC Client Encryption verwendet.

2. Die SNC-Client-Encryption-Komponente fordert ein Service-Ticketvom Microsoft Active Directory Server an.

3. Der Microsoft Active Directory Server gibt das Ticket an die SNC-Client-Encryption-Komponente zurück.

4. Der Benutzer wird vom SAP GUI zur Eingabe seiner Log-in-Datenaufgefordert.

5. Alle Kommunikation mit dem AS-ABAP-System findet nun ver-schlüsselt statt.

Das genaue Vorgehen zur Einrichtung von SNC Client Encryptionkann je nach Release-Stand der beteiligten Systeme variieren – bitterufen Sie daher immer die zur Version ihres AS-ABAP-Systems gehö-rige SAP-Dokumentation auf; dort gibt es ein eigenes Kapitel »SNCClient Encryption für Kennwortanmeldung verwenden«, in demauch weiterführende Hinweise verlinkt sind.



115

Abbildung 4.4 Ablauf einer SAP-GUI-Sitzung mit Client Encryption (Quelle: SAP)

4.2.3 Tier 2: Übergang von Intranet zur SAP-Tier

Der Übergang von Tier 1 (der DMZ) nach Tier 2 funktioniert in der Re-gel wieder durch eine Firewall, die das DMZ-Intranet gegen das in-terne Netzwerk, manchmal auch Campusnetzwerk genannt, abgrenzt.In Tier 2 liegen oft die Mitarbeiter-Systeme, auf denen dann auch derSAP Rich Client (SAP GUI) läuft. Aber auch externe Programme undnicht unternehmenskritische Anwendungen können hier laufen. Ausdieser Ebene 2 werden dann die Verbindungen zu den SAP-Systemenim inneren Tier 3 aufgebaut.

RFC-ProtokollRemote Function Call (RFC) ist ein proprietäres SAP-Protokoll. DerRFC-Gateway ist die funktionale Verbindung der Endpunkte derKommunikation mit einer äußeren Komponente. Es gibt in einemStandard-SAP-System zehntausende solche Funktionsaufrufe, vondenen in der Regel nur ein kleiner Teil wirklich von außen aufgeru-fen wird. In vielen Fällen sprechen SAP-Server mit anderen SAP-Ser-vern auf der Basis von ABAP-Anwendungen miteinander und benut-zen das RFC-Protokoll zwischen AS-ABAP-Stacks. Ein System, derRFC Client, initiiert die Kommunikation und der Server nimmt dieseKommunikation auf. Abbildung 4.5 zeigt einen Überblick dieserunterschiedlichen Verbindungen.

MicrosoftActive

Directory

(1) SAP GUI starten

(2) Anfrage (3) Sicherheitstoken

(4) Benutzer gibt

Benutzer-kennung undPasswort ein

(5) Sichere Kommunikation

SAP BusinessSuite

SAP S/4 HANA

Geschäfts-prozess



116

Abbildung 4.5 Überblick über das RFC-Protokoll (Quelle: SAP)

Aber auch externe Anwendungssysteme können diese Kommunika-tion initiieren. Es gibt Implementierungen der SAP-Kommunikati-onsbibliothek als SAP-Konnektoren in Java und als .NET-Implemen-tierung für Microsoft-Umgebungen.

RFC-Verbin-dungen und

Verschlüsselung

RFC-Verbindungen können sich auch der Verschlüsselungsfunktio-nen der SNC-Bibliotheken bedienen, ähnlich wie es das SAP GUI unddas DIAG-Protokoll auch machen (siehe Abbildung 4.6). Diese Kom-munikation wird dann in den entsprechenden Basis-TransaktionenSTRUST, SM59 und RZ11 konfiguriert. Für die Clients gibt es eben-falls entsprechende Bibliotheken, die alle auf der SAP Cryptolibbasieren und diese implementieren.

Abbildung 4.6 RFC mit SNC-Verschlüsselung (Quelle: SAP)

SAP NetWeaver ApplicationServer ABAP, RFC-Server

SAP NetWeaver Application Server ABAP, RFC-Client

Programm RFC-Destination

Programm

registrierter externer RFC-Server

RFC-Funktionsmodul

externer RFC-Client

Programm RFC-Destinationgestarteter RFC-Server

RFC-Funktionsmodul

RFC-Funktionsmodul

RFC-Funktionsmodul

RFC

-Gat

eway RFC-Funktionsmodul

ABAP-Laufzeit-umgebung

Firmennetzwerk

Endanwender-netzwerk

Servernetzwerk

Fire

wal

l

Fire

wal

l

Fire

wal

l

SNC(empfohlen)

SNC(optional)

SNC(empfohlen)

ABAP

DB

WA

N

Anderes Servernetzwerk

SAP GUI, RFC Clients

ABAP

DB

ABAP-Programmier-sprache

DB


Virtuelle Netzwerke und Software-Defined Networks 4.3

117

4.2.4 Tier 3: Die SAP-Systeme

Bis zur Einführung von SAP HANA hatte SAP zu Datenbanken eineähnliche Haltung wie zu den Netzwerken. SAP wollte weitestgehendunabhängig von Datenbanken sein und implementierte nur eineSchnittstelle zu den Datenbanken hin und nannte diese Open SQL. Eswar letztlich eine klassische Implementierung einer Datenbank-schnittstelle, wie man sie auch im Bereich ODBC kennt, einem Pro-tokoll, das letztlich von und zu Datenbanken redet.

ODBC und DBCON

Dieses Protokoll heißt DBCON und ist in der gleichnamigen Tabelleimplementiert. Auf dieser Schnittstelle werden ausführbare SQL-Befehle gesendet und das SAP-System (in der Regel der laufendeABAP-Serverdienst) erhält die Antwort in Form von einer mehr oderweniger komplexen Tabelle als Datenbereich zurück. Dieses Result Setist die rohe Datenbasis, die das ABAP-Programm weiter bearbeitet.

Die Kommunikation zwischen SAP-System und Datenbank wurdebis vor ein paar Jahren kaum als Sicherheitsproblem gesehen. Manbetrachtete die Server als sicher (da diese ja bereits in den Netzwerk-segmenten standen, die durch eine oder mehrere Firewalls geschütztwaren). Zudem waren die Datenbankserver von einem ehemaligenMarktführer wie Oracle ja auch noch einmal besonders geschützt.SAP allerdings kommunizierte in der Regel über Verbindungen vomAnwendungs- zum Datenbankserver, die keinen oder nur sehr rudi-mentären Schutz auf den Verbindungen hatte. Bis vor einigen Jahren(und in vielen Systemen heute noch existierenden Produktivversio-nen) war die Oracle-Verbindung komplett ungeschützt. Ein Angrei-fer konnte (und kann) auch heute noch diese passwortlose Verbin-dung jederzeit übernehmen.

4.3 Virtuelle Netzwerke und Software-Defined Networks

Der Begriff der Software-Defined Networks (SDN) ist schon seit vielenJahren im Umlauf, aber seinen Weg aus dem Elfenbeinturm der Wis-senschaft in die Welt der industriell genutzten Netzwerke begann2008. So wie die In-Memory-Datenbanktechnologie SAP HANA ausStanford-Forschungen heraus entstand, wurde auch das Software-Defined Networking hier weiterentwickelt.



118

Stanford undOpen Network

Foundation

Da die Stanford-Universität in Palo Alto liegt, also im Herzen des Sili-con Valley und in direkter Nähe zu Google, Facebook, SAP undOracle, wurde die Idee entsprechend gut aufgenommen. Aus demzuerst einmal in akademischen Kreisen bekannten Modell wurde2001 die Open Networking Foundation gegründet, die das Modellals Open-Source-Modell weiter benutzt.

Die Hauptidee ist es, nur noch die Layer 1 und 2 (und eventuell 3)von entsprechenden Switches vornehmen zu lassen und die Switchesdirekt mit einem rein auf Software basierenden Controller kommu-nizieren lassen, der die anderen Funktionen (Ebene 3 bis 7) einesNetzwerks implementiert in reiner Software übernimmt. Bisher lagja die überwiegende Funktion in dedizierter Hardware, von Netz-werkadaptern über Switches und Router bis hin zu den entsprechen-den Adaptern in den Zielservern. Nun sollte dies alles von einer eige-nen (Software-)Appliance vorgenommen werden.

Nur die Switchesbleiben bestehen

Switches mit mehreren Dutzend Anschlüssen gibt es heute als soge-nannte »Commodity«, also als Massen-Billigware vor allem ausChina. Dort werden die Switches mit integrierten Schaltungen herge-stellt, so dass ein 48-Port-Switch für ein paar hundert Euro zubekommen ist. Dieser Switch brauchte nur ein Interface nach derNorm der in Stanford initiierten Open Network Foundation, und mankann den Rest des Netzwerks über entsprechende Frameworks ab-bilden.

Der Ansatz mit den billigen Switches und Softwareframeworks sollteneue Möglichkeiten bringen. Netzwerke sollten direkt programmier-bar werden und zentral durch einen reinen softwarebasierten Ansatzzu managen sein. Damit sollten Sie den Netzwerkverkehr optimalorganisieren, lenken und verwalten können. Dadurch wären auchAnforderungen aus neuen Diensten wie Videostreams, cloud-basie-renden Diensten oder die Separierung von Kundenetzen in großenDatacentern direkt möglich.

Separierung vonKontrollfluss und

Datenfluss

Der Datenfluss in einem Netzwerk wird in eine Control Plane aufge-splittet, in der das ganze Routing stattfindet. Hier wird ein Netzwerk-Request von und nach einem Ziel geleitet. Auf der Data Plane läuftder assoziierte Datenverkehr. Sieht man sich heute einen beliebigenBackbone eines großen Providers an, so sind dort 30–50 % der Aus-lastung auf Streaming Video Services wie YouTube und Amazonzurückzuführen. Die immer größere Menge an Video-Konferenzen



119

kommt hinzu. Solch ein Verkehr würde davon profitieren, wenn erseparat als Stream und nicht paketorientiert weitergeleitet wird.

Gerade große Datacenter haben begonnen, in ihren RechenzentrenSDN-Netzwerke zu schaffen und produktiv einzusetzen. Zwar gibt esnoch keine Standards, aber die Möglichkeiten, die sich die Betreiberhier selbst schaffen, sind den Aufwand nach eigenem Bekundenwert. Gerade in den Bereichen Kundensegmentierung (Multi-Ten-ant) und content-basiertem Routing (Streaming, Packeting) sind dieVorteile sehr hoch.

Auch der Bereich Security wächst deutlich. Wo es protokollunabhän-gige Ebenen gibt, die nur für die Kontrolle zuständig sind und wo esDatenebenen gibt, die die kompletten Datenströme steuern, ist esmöglich, ganz neue Sicherheitskontrollen einzubauen. Die Security-Information- und Event-Management-Systeme (SIEM, siehe Abschnitt1.2.7, »Bestimmung der technischen Auswirkungen eines Angriffs«)mit ihren Datenmustern lassen sich hier in Echtzeit auf die Daten-ströme anwenden. So können auch kontrolltechnisch komplett neueAnwendungen entstehen.

Die neue Architektur der Software Defined Networks wird dieImplementierung von Netzwerken in den Datacentern grundlegendverändern. Und mit der Architektur wird auch die Sicherheit in Netz-werken komplett neu definiert. In jeder der neuen Komponentendieser Architektur steckt auch ein starker Sicherheitsaspekt, dernicht mehr an eine Protokoll-Implementierung wie bei ISO/OSIgekoppelt ist, sondern sich ausschließlich über Software und derenSchnittstellen definiert. Dieser Ansatz hat heute schon neue Sicher-heitssysteme erzeugt, die in den noch wenigen proprietären Imple-mentierungen in ausgewählten Datacentern zu sehen ist. Die flä-chendeckende Einführung und Adaptierung dieser Technologie wirdaber in den nächsten Jahren zu einer radikalen Änderung auch in derSicherheit der Netzwerke führen. In Abbildung 4.7 wird solch eineArchitektur gezeigt.

Control PlaneDie grundlegende Idee ist es, dass eine Control Plane die eigentlichenDatenströme kontrolliert und bewegt. Die Control Plane hat einNorthbound Interface, das die Anwendungen kontrolliert, die aufdiese Control Plane einwirken.



120

Abbildung 4.7 SDN-Architektur: Überblick der Open Networking Foundation

Application Plane Die Anwendungen selbst bestimmen das Verhalten des Netzwerksund haben die Intelligenz und die Attribute zur Steuerung. Die Aus-führung dieser Logik wird dann aber der Control Plane übergeben.Die klassischen Funktionen wie Session Handling, intelligentes Rou-ting und Datenanalyse sind in den Anwendungen und nicht mehrFunktionen des Netzwerks.

CDPI Ebenso verhält es sich mit dem Control to Data Plane Interface (CDPI).Das CDPI übergibt die Steuerungen (von der Control Plane an dieData Plane) an die Schicht, die die Daten enthält und die Destinatio-nen, von denen und an die die Daten bewegt werden sollen. Somitsind Netzwerksteuerung, Netzwerklogik und Daten vollkommenentkoppelt. Dadurch ist eine wesentlich höhere Flexibilität möglichals in herkömmlichen Netzwerkmodellen nach ISO/OSI. Die Seg-mentierung und Paketorientierung der Netzwerke sowie die Fokus-sierung auf Endpunkt-Kommunikation fällt hier komplett weg.

Data Plane Aus Sicht der Endpunkte entsteht durch die Control Plane, die Datenvon A nach B bewegt, ein Datenpfad. Hier können auch große Daten-

SDN-Anwendungslogik

NBI-Treiber

SDN-Anwendung

NBI Agent

SDN Kontrolllogik

CDPI-Treiber

Sicherheit: IPS, IDS, SIEM

SDN Controller

SDN-Anwendungslogik

NBI-Treiber

SDN-Anwendung

SDN-Anwendungslogik

NBI-Treiber

SDN-Anwendung

Ver

wal

tung

& A

dmin

istr

atio

n

Netzwerkelement

SDN-Datenpfad

CDPI Agent

Weiterleitungsmodul/Verarbeitung

Netzwerkelement

SDN-Datenpfad

CDPI Agent

Weiterleitungsmodul/Verarbeitung

Service Level

Agreement

Policy-Konfiguration

Performance-Monitoring

Setup der

Elemente

Northbound Interface NBI

SDN-Steuerungsschichtschnittstelle

Dat

ensc

hich

tSt

euer

ungs

schi

cht

Anw

endu

ngss

chic

ht

Instrumentierung

Statistik

Events

Anforderungen



121

mengen wie Videostreams bewegt werden, ohne diese stark zu seg-mentieren, oder es können Datenmengen gezielt geroutet werden,wie es in einem Multimandanten-Rechenzentrum nötig ist.

Forwarding EngineLetztlich muss das SDN in letzter Konsequenz wieder Switches bedie-nen, die die Umsetzung auf die »letzte Meile«, die Netzwerktopologieder ISO/OSI-Ebenen 1 und 2 bringt. In großen Datacentern werdendiese SDN-Segmente aber auch direkt gekoppelt, gerade bei hohenDatenmengen. Die neue Generation von Netzwerken jenseits der10-Gbit-Datenmengen, die Backbone-Netze mit 100 Gbit, benötigenneue Methoden, solch hohe Datenmengen zu bewegen.

4.3.1 Die Idee einer neuen offenen Netzwerkarchitektur

Die offene SDN-Architektur erregte natürlich das Missfallen allerHersteller, die bisher teure Appliances verkauft haben. Dies betrifftalle Switch-Hersteller wie IBM und andere, aber vor allem die gro-ßen Netzwerkausrüster wie Cisco, CheckPoint Juniper und viele an-dere. Natürlich sahen sie eine Vision von billigen Switch-Appliancesaus China und offener, kostenloser Software als nicht zielführend an.Aber auch die Hersteller konnten nicht ignorieren, das herkömmli-che Netzwerkarchitekturen an ihre Leistungsgrenzen kommen, undkonnten die vom großen Data-Center-Markt schon antizipierte Ar-chitektur nicht mehr zurücknehmen.

Open Network Foundation

So umarmte man, was man nicht mehr bekämpfen konnte undwurde Mitglied in der Open Networking Foundation, um fortan dieEntwicklung so zu lenken, dass kommerzielle Interessen und Portie-rungen weiterhin berücksichtigt werden. Es gibt mittlerweile SDN-Lösungen von allen großen Anbietern, die aber eher eine proprietäreTendenz haben. Die SDN-Frameworks im Umfeld der Standford-Ini-tiative sind langsam verblichen, vor allem, weil keines der Frame-works so hochskalierbar und belastbar ist, wie es vor allem von gro-ßen Datacenter gefordert wird. Die Datacenter wiederum haben, alsgrößte Kunden der Netzwerkausrüster, funktionierende eigeneImplementierungen, die sie aber gerne gegen kommerzielle Imple-mentierungen austauschen würden, um nicht weiterhin selbst entwi-ckeln zu müssen.

SDN im Data-center heute

SDN ist weiterhin im Fluss: Große Kunden und Datacenter könnenund werden unter dem Innovationsdruck hier weiter entwickeln.Man erwartet in den nächsten fünf Jahren auch den flächendecken-



122

den Durchbruch dieser Technologien. Dann wird SDN das Networ-king, wie wir es heute kennen, komplett verwandelt haben.

4.3.2 Sicherheit im Software-Defined Network

SDN bietet komplett neue Ansatzmöglichkeiten, Sicherheit imRechenzentrum zu implementieren. Ist es bisher softwaretechnischein mühseliges Unterfangen, die Pakete der ISO/OSI-Ebenen 1 bis 4zu sammeln, auszuwerten und in einen Kontext wie SAP zu stellen,fällt all dies weg. Bei Netzwerkgeschwindigkeiten von 10 bis 100Gbit/s würden auch herkömmliche Ansätze nicht mehr funktionie-ren.

Im Zusammenspiel von Application Plane, Control Plane und DataPlane lassen sich Datenströme gezielt analysieren. Es muss nichtkünstlich ein Kontext hergestellt werden (was den Echtzeit-Ansatznicht realisierbar macht), sondern der Datenfluss kann ebenso wieein Stream betrachtet und analysiert werden. Mustererkennung undReaktion auf die Muster kann direkt in der Application Plane imple-mentiert werden. Durch die Einwirkung der Control Plane auf dieData Plane kann dann direkt eine Aktion (wie z. B. der Abbruch) aus-geführt werden und es muss nicht umständlich eine weitere Net-work Appliance angesteuert werden.

Angriffe auf SDN Aber auch das Hacking auf diese Infrastrukturen wird sich in demsel-ben Maße entwickeln und als Sicherheitsberater werden wir unsdann damit beschäftigen, wo die Angriffsvektoren auf die Data undControl Planes entstehen und wie man diese bekämpft.

Zukunft von SDN SDN wird heute schon von großen Datacentern als proprietäreLösung eingesetzt und hat das Potenzial bewiesen, das es in einemsolchen Umfeld haben kann. Es wird noch einige Jahre dauern, bisdiese Technologie in den klassischen IT der Unternehmen ankommt,vermutlich mit dem nächsten Generationenwechsel der Applianceswie Firewalls, Load Balancern und Switches. Und diese Technologiesteckt auch schon in allen virtualisierten Netzwerkumgebungen wieNSX von VMware, die bereits zeigen, wie Security auf einem solchenLayer funktioniert.


Auf einen Blick

1 Risiko- und Bedrohungsanalyse für SAP-Systeme ........ 25

2 Eine Sicherheitsstrategie entwickeln ........................... 53

3 SAP-Sicherheit – Standards und aktuelle SAP-Werkzeuge ......................................................... 79

4 Netzwerksicherheit herstellen .................................... 101

5 Werkzeugkasten des SAP-Sicherheitsexperten ............ 123

6 Schutz von SAProuter und SAP Web Dispatcher ......... 145

7 Schutz des SAP NetWeaver AS ABAP ......................... 163

8 Schutz des SAP NetWeaver AS Java ............................ 191

9 Schutz von Remote Function Calls .............................. 209

10 Passwortschutz ........................................................... 233

11 Schutz des Transportsystems ...................................... 263

12 Schutz der Datenbank ................................................ 281

13 SAP HANA und die Sicherheit der In-Memory-Datenbanken ........................................... 309

14 Erkennung von Angriffsmustern und Forensik ............. 329

15 Mobile Anwendungen sichern .................................... 361

16 Sicherheit im Internet der Dinge ................................ 383


7

Inhalt

Einleitung .................................................................................. 17

1 Risiko- und Bedrohungsanalyse für SAP-Systeme ........................................................... 25

1.1 SAP-Systeme und die Cyber-Bedrohung .................. 291.2 Vorgehen zum Erstellen einer Risikomatrix .............. 31

1.2.1 Risikoinformationen kritisch bewerten ....... 311.2.2 Risikoanalyse auf Basis internationaler

Normen ..................................................... 331.2.3 Ein Risiko identifizieren ............................. 341.2.4 Grafische Darstellung des Risikos ............... 381.2.5 Bestimmung des Angriffsvektors und der

Verletzbarkeit ............................................ 391.2.6 Bestimmung des Angreifers und der

Verletzbarkeit ............................................ 401.2.7 Bestimmung der technischen

Auswirkungen eines Angriffs ...................... 411.2.8 Formalisierter Risikofaktor aus dem

Modell ...................................................... 431.3 Internationale Standardmethoden für eine

Risikoanalyse .......................................................... 441.3.1 Open Web Application Security Project ..... 441.3.2 NIST Risk Assessment ................................ 461.3.3 Bundesamt für Sicherheit in der

Informationstechnik .................................. 48

2 Eine Sicherheitsstrategie entwickeln ...................... 53

2.1 Ziele einer Sicherheitsstrategie ................................ 572.1.1 Interne und externe Aufgaben ................... 582.1.2 Status quo feststellen ................................ 602.1.3 Penetrationstest zur Überprüfung des

Status quo ................................................. 612.2 Kosten und Nutzen abwägen .................................. 652.3 Unternehmensbeispiele für Sicherheitsstrategien .... 67

2.3.1 Übungszentrum Netzverteidigung .............. 682.3.2 Cyber Control Center der Telekom ............. 73


Inhalt

8

2.4 Abschließende Überlegungen zur Sicherheitsstrategie ................................................. 77

3 SAP-Sicherheit – Standards und aktuelle SAP-Werkzeuge .............................................................. 79

3.1 SAP-Sicherheit in der klassischen Sicht .................... 793.1.1 Ebene 1: Rich Client bzw. SAP GUI ............ 803.1.2 Ebene 2: Anwendungsserver und

Message Server .......................................... 813.1.3 Ebene 3: Datenbankserver ......................... 813.1.4 Die klassische Drei-Ebenen-Architektur ...... 823.1.5 Verletzbarkeit der historischen

SAP-Architektur ......................................... 823.1.6 SAP-Sicherheitshinweise ............................ 83

3.2 SAP NetWeaver: Sicherheit mit neuer Softwaregeneration ................................................. 84

3.3 SAP Enterprise Threat Detection .............................. 863.3.1 Einsatz in der SAP-internen IT .................... 863.3.2 Architektur der Komponenten .................... 873.3.3 Archive ...................................................... 883.3.4 Anonymisierung personenbezogener

Daten ......................................................... 883.3.5 Muster in Log-Dateien erkennen lernen ..... 90

3.4 SAP Code Vulnerability Analysis .............................. 913.5 SAP Solution Manager als Steuerungsinstrument ..... 97

3.5.1 SAP EarlyWatch ......................................... 973.5.2 Security Self-Service über den

SAP Solution Manager ............................... 983.5.3 Custom Code Lifecycle Management .......... 98

3.6 Ausblick .................................................................. 99

4 Netzwerksicherheit herstellen ................................ 101

4.1 Netzwerk, Switches, Router und Firewalls ............... 1014.1.1 Das ISO/OSI-Referenzmodell ..................... 1014.1.2 Verschlüsselung der Netzwerk-

verbindungen mit SNC ............................... 1064.1.3 Firewall in der SAP-Umgebung

(ISO/OSI) ................................................... 107


Inhalt

9

4.2 SAP-Landschaft analysieren ..................................... 1094.2.1 Tier 1: SAP-GUI-Client ............................... 1104.2.2 Tier 1: Zugang aus dem Internet und

Übergang ins Intranet ................................ 1114.2.3 Tier 2: Übergang von Intranet zur

SAP-Tier .................................................... 1154.2.4 Tier 3: Die SAP-Systeme ............................ 117

4.3 Virtuelle Netzwerke und Software-Defined Networks ................................................................ 1174.3.1 Die Idee einer neuen offenen

Netzwerkarchitektur .................................. 1214.3.2 Sicherheit im Software-Defined Network ... 122

5 Werkzeugkasten des SAP-Sicherheitsexperten ..... 123

5.1 Kali-Linux-Distribution ........................................... 1235.1.1 Die Geschichte der Kali-Distribution .......... 1245.1.2 Download und Installation ........................ 1245.1.3 Kali Linux und SAP .................................... 125

5.2 Rot gegen Blau: Werkzeuge für Angriff und Verteidigung ........................................................... 1265.2.1 Vor dem Angriff: Die Zielanalyse ................ 1265.2.2 Angriff: Netzwerkerkennung und -analyse

mit Nmap .................................................. 1295.2.3 Angriff: Server-Erkennung und -analyse

mit Metasploit ........................................... 1335.3 Kommerzielle Produkte für Penetrationstests im

Bereich SAP ............................................................ 1365.3.1 Onapsis X1 und Onapsis OSP .................... 1365.3.2 ERPScan .................................................... 1375.3.3 Virtual Forge ............................................. 1375.3.4 ESNC: Enterprise Security and

Compliance ............................................... 1375.3.5 Werth IT Auditor ....................................... 137

5.4 Gegenmaßnahmen zum Schutz des Netzwerks ........ 1385.5 Patch-Management mit dem SAP Solution

Manager ................................................................. 1395.6 Klassische Angriffsvektoren für Hacker und

Penetrationstester ................................................... 1415.6.1 Oracle-Hack .............................................. 142


Inhalt

10

5.6.2 Gegenmaßnahmen zum Schutz der Datenbank ................................................. 143

5.6.3 Gegenmaßnahmen zum Schutz der Netzwerke ................................................. 143

6 Schutz von SAProuter und SAP Web Dispatcher ... 145

6.1 Der SAProuter im SAP-Netzwerk ............................. 1456.1.1 Wann wird der SAProuter eingesetzt? ........ 1466.1.2 Wann wird der SAProuter nicht

eingesetzt? ................................................. 1476.1.3 SAProuter installieren ................................. 1486.1.4 Kontrolle und Protokollierung von

Verbindungen zu SAP-Systemen ................. 1496.1.5 SAProuter und Secure Network

Communications SNC ................................. 1506.1.6 SAProuter-String-Information ..................... 151

6.2 Angriff auf den SAProuter ........................................ 1526.3 Gegenmaßnahme: Härten des SAProuters ................ 1536.4 Der SAP Web Dispatcher im SAP-Netzwerk ............. 1546.5 Angriff auf den SAP Web Dispatcher ....................... 1576.6 Gegenmaßnahme: Härten des SAP Web

Dispatchers ............................................................. 160

7 Schutz des SAP NetWeaver AS ABAP ..................... 163

7.1 Die ABAP-Laufzeitumgebung .................................. 1637.2 Der SAP NetWeaver AS ABAP als Angriffsziel .......... 1647.3 Berechtigungen nach dem Need-to-know-Prinzip .... 168

7.3.1 Need-to-know-Prinzip umsetzen ................ 1687.3.2 Benötigte Anwendungen und Programme

ermitteln .................................................... 1707.4 Schutz des SAP NetWeaver AS ABAP gegen

Angriffe ................................................................... 1797.4.1 Angriffsfläche verringern ............................ 1797.4.2 Sicherheitslücken aufspüren ....................... 1827.4.3 Kritische Rechte kontrollieren .................... 184

7.5 Dokumentation der Absicherungsmaßnahmen ......... 1877.5.1 Generelle Anforderungen ........................... 1887.5.2 Das Sicherheitskonzept .............................. 1897.5.3 Das Berechtigungskonzept ......................... 189


Inhalt

11

8 Schutz des SAP NetWeaver AS Java ....................... 191

8.1 Härten des SAP NetWeaver AS Java ........................ 1928.1.1 Zugriffe einschränken ................................ 1928.1.2 Nicht benötigte Dienste deaktivieren ........ 1958.1.3 Kommunikationssicherheit herstellen ........ 1978.1.4 Passwort-Regeln festlegen ......................... 2028.1.5 Java-Berechtigungen verstehen .................. 205

8.2 Angriffe auf den AS Java und Gegenmaßnahmen ..... 206

9 Schutz von Remote Function Calls ......................... 209

9.1 Technische Komponenten der RFC-Verbindungen ................................................. 210

9.2 RFC-Berechtigungen verstehen und einsetzen ......... 2149.3 Unified Connectivity: eine weitere Schutzebene ...... 2239.4 RFC-Sicherheit auf Client-Seite herstellen ............... 2249.5 RFC-Callback-Sicherheit aktivieren .......................... 2269.6 Den RFC-Gateway absichern ................................... 2289.7 Verschlüsselung aktivieren ...................................... 230

10 Passwortschutz ....................................................... 233

10.1 Technologie und Logik von Hash-Prüfungen ........... 23310.2 Technische Implementierung der Passwörter im

SAP-System ............................................................ 23610.3 Werkzeuge: John the Ripper und HashCat .............. 24210.4 Wörterbücher beim Angriff ..................................... 24410.5 Angriff auf die Passwörter (Hashes) ......................... 24410.6 Gegenmaßnahmen: harte Passwörter, SSO und

Hashes löschen ....................................................... 24510.6.1 Schutz gegen Hash-Diebstahl .................... 24510.6.2 Nutzung eines sicheren Hash-

Algorithmus .............................................. 25110.6.3 Bereinigung alter Hash-Werte .................... 25610.6.4 Passwort-Policy einführen ......................... 25710.6.5 Single Sign-on statt lokale Passwörter

nutzen ....................................................... 261


Inhalt

12

11 Schutz des Transportsystems ................................. 263

11.1 Transport Management System ............................... 26311.2 Angriffe auf das Transportsystem ............................. 265

11.2.1 Schutz vor Angriffen über das Dateisystem ............................................... 265

11.2.2 Schutz vor Angriffen mit speziellen Transportobjekten ...................................... 269

11.2.3 Schutz vor Angriffen über die System-benutzer des TMS ...................................... 271

11.2.4 Transport von Schad-Code und Sicherheitslücken ....................................... 273

11.3 Gegenmaßnahme: Härtung des CTS mithilfe des SAP Solution Managers ........................................... 278

12 Schutz der Datenbank ............................................. 281

12.1 Die Rolle der Datenbank in SAP-Systemen .............. 28112.2 Generelle Risiken und Absicherungsmaßnahmen ..... 283

12.2.1 Zugriff und Zugang ..................................... 28312.2.2 Daten und Inhalte ...................................... 288

12.3 Funktionstrennung in einer Oracle-Datenbank ........ 29012.4 Angriffe auf SAP-Datenbanken ................................ 293

12.4.1 SAP-Datenbankschnittstelle ....................... 29312.4.2 Datenbankangriffe aus SAP-

Anwendungen ............................................ 29512.4.3 Gegenmaßnahmen zum Schutz vor

ABAP-basierten Angriffen ........................... 29712.4.4 Ausspähen des SAP-Datenbankservers ....... 29812.4.5 Direkte Angriffe auf

Betriebssystemebene .................................. 30112.4.6 Gegenmaßnahmen zum Schutz vor

Angriffen auf Betriebssystemebene ............. 30312.4.7 Beispiel: Datenbanksicherheit mit IBM

Guardium ................................................... 304

13 SAP HANA und die Sicherheit der In-Memory-Datenbanken ........................................................... 309

13.1 Sicherheit in SAP HANA .......................................... 31013.2 Architektur von SAP HANA ..................................... 312


Inhalt

13

13.2.1 Die Datenbankwelt aus der Sicht des Hauptspeichers .......................................... 312

13.2.2 In-Memory Column Stores ........................ 31313.3 Grundlagen der Sicherheitskonzepte für HANA ....... 315

13.3.1 Speicherorientierte Datenbank: Die SAP HANA XS Engine ....................................... 316

13.3.2 Benutzer- und Rollenmanagement ............. 31613.3.3 Authentifizierung und Single Sign-on ......... 317

13.4 Absicherung der Webanwendungen ....................... 31813.4.1 Angriffsvektoren auf die neuen

Werkzeuge ................................................ 32013.4.2 Serverseitiges JavaScript ............................ 32013.4.3 Maßnahmen zur Härtung von

Webanwendungen .................................... 32213.5 Penetrationstest auf SAP-HANA-Applikationen

ausführen ............................................................... 32313.6 Angriffe auf den Hauptspeicher ............................... 324

13.6.1 Risikoabschätzung zum Angriffsvektor Hauptspeicher ........................................... 325

13.6.2 Verschlüsselung bei SAP HANA ................. 32613.6.3 Cloud und Verschlüsselung ........................ 327

14 Erkennung von Angriffsmustern und Forensik ....... 329

14.1 Die Quelle der Muster: die wichtigsten Log-Dateien ............................................................ 33014.1.1 Vorbemerkung zur forensischen Analyse .... 33114.1.2 Security Audit Log ..................................... 33214.1.3 Systemlog .................................................. 33414.1.4 Gateway-Logging ...................................... 33514.1.5 Logging von Internet Communication

Manager und SAP Web Dispatcher ............ 33614.1.6 Logging des SAP NetWeaver Application

Server Java ................................................ 33814.1.7 Logging des Message Servers ..................... 33914.1.8 Logging von Datenänderungen in

Tabellen .................................................... 33914.1.9 Logging von Änderungen an Benutzern

und Berechtigungen .................................. 34114.1.10 Logging von Änderungsbelegen ................. 34114.1.11 Systemtrace ............................................... 342


Inhalt

14

14.1.12 Entwickler-Trace ........................................ 34314.1.13 Logging des SAProuter ............................... 34514.1.14 Logging von Datenbankzugriffen

(SQL Audit) ................................................ 34614.2 Auswertung mit Transaktion ST03 ........................... 34614.3 Auswertung mit Funktionsbausteinen ...................... 34714.4 Usage and Procedure Logging ................................. 34914.5 Netzwerkinformationen, Terminals und

SAP-Benutzer-Sessions ............................................ 35114.5.1 Snort .......................................................... 35114.5.2 Onapsis Detection and Response ............... 35314.5.3 IBM Guardium ........................................... 354

14.6 Werkzeuge zur Auswertung der Muster: Security Information and Event Management ....................... 35414.6.1 IBM Security QRadar SIEM und HP

ArcSight ..................................................... 35514.6.2 SAP Enterprise Threat Detection ................ 35514.6.3 Splunk ........................................................ 356

14.7 Sicherheitsmuster .................................................... 35714.8 Grundlegende Sicherheitsaktivitäten ........................ 358

15 Mobile Anwendungen sichern ................................ 361

15.1 Netzwerkarchitektur für den mobilen Zugriff auf SAP-Systeme ........................................................... 362

15.2 Komponenten der Sicherheitsstrategie für die SAP-Mobile-Infrastruktur ........................................ 36615.2.1 Sicherheit für mobile Geräte ....................... 36715.2.2 Sicherheit für mobile Anwendungen .......... 36715.2.3 Sicherheit für mobile Dokumente ............... 37015.2.4 Enterprise Integration ................................ 370

15.3 Angriffe auf die mobile Landschaft ........................... 37815.3.1 Wireless Access Point ................................. 37815.3.2 Single Sign-on und Identity Access

Management .............................................. 38015.3.3 Gestohlene Cookies .................................... 38115.3.4 SAP Web Dispatcher .................................. 38115.3.5 SAP Gateway und SAP-Backend ................. 381


Inhalt

15

16 Sicherheit im Internet der Dinge ............................ 383

16.1 Sicherheitsebenen des Internets der Dinge ............. 38516.1.1 Hardware- und Softwareebene des

Internets der Dinge ................................... 38516.1.2 Ebene der Daten – Big Data ....................... 38916.1.3 Ebene der Anwendungs- und

Produktentwicklung .................................. 39016.1.4 Ebene der Fertigung .................................. 39216.1.5 Ebene des technischen Betriebs ................. 39316.1.6 Ebene des Marketings für das Internet

der Dinge .................................................. 39516.2 SAP-Architektur für das Internet der Dinge ............. 39616.3 Kryptografie im Internet der Dinge ......................... 400

16.3.1 Verschlüsselung auf ASIC und FPGA .......... 40216.3.2 Das Spiel mit dem Zufall ............................ 404

16.4 Gefährdungspotenzial für das Internet der Dinge im SAP-Bereich ....................................................... 406

16.5 Angriffswerkzeuge für Hardware-Hacks ................... 40716.6 Anatomie eines Hardware-Hacks ............................ 41016.7 Anatomie eines Industrieanlagen-Hacks .................. 413

Die Autoren .............................................................................. 417

Index ........................................................................................ 419


419

Index

A

ABAP Test Cockpit 93ABAP-Laufzeitumgebung 163Access-Control-Liste 229ACL 229Active Directory 363ALE 209Altera 386, 398Amazon 28Änderungsbeleg, Logging 341Angriff

Angreifer bestimmen 41AS ABAP 164Client Side 322durch Systembenutzer 271Hauptspeicher 310, 324Java 206Microsoft SQL 246mit Transportobjekt 269Oracle 246SAP HANA 324SAP Web Dispatcher 157SAProuter 152technische Auswirkungen 41Transportsystem 265Vulnerability 41

Angriffsvektor 39, 141, 394Apache Cordova 367apm atlantis 186Application Layer 105Application Link Enabling 209Arbeitsmittel 123Arbitrary Routing 346Architektur, Angriffspunkte 82Archiv 88ArcSight 355AS ABAP � SAP NetWeaver

AS ABAPAS Java 191ASIC 387ATC 93Audit 187Audit Logging 318Authentifizierung 364

B

Backdoor 328, 402BAPI 209Baseline 65BCODE 237BEAST 199Bedrohung klassifizieren 32Bedrohungsanalyse 25Behavioural Firewall 328Behavioural Pattern 89Benutzerverwaltung, zentrale 252Berechtigung 364

AS Java 205fehlende 174Konzept 189kritische 184, 186S_RFC 215Tabellenzugriff 250Trace 342verwalten 168

Bilanzrelevanz 35Bizsploit 136Black-Box-Test 63Bluetooth-Sniffer 410brconnect 285Browser Exploit against SSL/TLS 199Brücke 381BSI 33, 48Building Block 383Bundesamt für Sicherheit in der

Informationstechnik 33Bundestag 39Business Application Programming

Interface 209

C

Campus-Netzwerk 115CDPI 120CERT 73Chief Information Officer 53Chief Information Security Officer 53Chip 387CIO 53Ciphertext 401


420

Index

CISO 53CLEANUP_PASSWORD_HASH_

VALUES 256Client schützen 193Cloud 327Code Vulnerability Analysis � SAP

Code Vulnerability AnalysisCode, dynamischer 92Code-Analyse 276CodeProfiler 277Code-Scanner 277Command Rule 292Common Vulnerability Scoring

System 44, 83Config Tool 193Content-Filter 109Control Plane 118, 119Control to Data Plane Interface 120Cookie 364, 381Cookie Stealing 207Cordova 367Cross-Site Request Forgery 321Cross-Site Scripting 207, 321CSS 320, 368CSS3 320, 368CUDAhashcat 243Custom Code Lifecycle

Management 98CVA � SAP Code Vulnerability

AnalysisCVSS Base Vector 44, 83Cyber Control Center 60, 73

Team 74Telekom 68

Cyber Defense Center 74Cyber Emergency Response Team 73Cyber Resilience 26Cyber Security 55Cyberspace 26

D

Data Breach 291Data Lake 330Data Link Layer 103Data Plane 120Data Volume Security 318Datenanonymisierung 88Datenbank 281

Angriff 142

Datenbank (Forts.)Benutzer 283, 285Berechtigungen 291Datendiebstahl 288Direktzugriff 291Kopie 288Managementsystem 281Schicht 281schützen 143transparente Verschlüsselung 289Zugang 283

Datenpunkt 393Datenschutz 35, 37DBA Cockpit 298DBCON 117DBMS 281DDIC 272Debugging mit Replace 166Demilitarisierte Zone � DMZDetection and Response 353DIAG 81, 105, 112Dienst deaktivieren 195Dienstleister 59DMZ 111, 154, 363, 364Dokumentation 187Dokumentation, Anforderungen 188Dreischichtenarchitektur 362Dynamic Information and Action Gate-

way Protocol � DIAG

E

Enterprise Integration 370Entropie-Pool 405Entwickler-Trace 338ERPScan 137ESNC 137ESP � SAP Event Stream ProcessorETD � SAP Enterprise Threat

DetectionExploit 84, 134

F

Factor 292False Positive 354, 355FIDO 375Firewall 107, 138, 208, 362Forensik 330


421

Index

Forwarding Engine 121Foundry 388FPGA 386Funktionstrennung 274Fuzzing 337

G

Geheimnis 411Google Exploit 127Grey-Box-Test 63

H

HackRF One 408hak5 409Hardwarebaustein, Verschlüs-

selung 402Hardware-Hack 407, 410Härtung 138Hash

Algorithmus 234Code-Version 236Diebstahl vermeiden 245entschlüsseln 235Prüfung 233sicherer Algorithmus 251Wert 233Wert bereinigen 256Wörterbuch 244

Hash Table 313HashCat 243Hauptspeicher

Angriff 310, 324Risikoanalyse 325schützen 328

Hex-Editor 289Honeypot 132Hop 149HP ArcSight 355HTML5 320, 368HTTP Fuzzing 337HTTP Log 338

I

IAM 363, 372IBM Guardium 304, 354

IBM Security QRadar SIEM 355ICM 336Identity and Access Management

363, 372Incident Management 59Industrie 4.0 55, 396Industrieanlagen-Hack 413Industriesteuerung 71Information Gathering 127, 128, 146In-Memory-Datenbank 309Intel Atom 398Intel IoT Gateway 386, 397Intellectual Property 387internationale Norm 33Internet Communication

Manager 336Internet der Dinge 383, 385

Architektur 396Hardware 387Kryptografie 400

Internet of Things � Internet der Dinge

Intrusion Detection System 208Intrusion Prevention System 208IoT � Internet der DingeIP 387IPS 208ISO 27001 187ISO/OSI-Referenzmodell 102

J

Java User Management Engine 202JavaScript 320, 369Java-Server-Log 338Java-Sicherheitsrolle 205Jeep-Hack 384John the Ripper 243Jurisdiktion 35, 37

K

Kali Linux 123, 125Kapsel 368Key Logger 380Kiss of Death 158, 208Known Vulnerabilities 208Kommandozeile 267Kommunikation sichern 197


422

Index

KRITIS 49Kryptografie 401

Geheimnis 411mobile Anwendungen 374

L

LDAP 199, 363Linux 123, 399Log 153, 330Log Learner 90Log-Datei 90, 330Logical Unit of Work 164LUW 164

M

Machine Learning 356Maltego 128Man in the Middle 157, 199McAfee Embedded Control 399MDM 367Memory Attack 324Message Server, Logging 339Metasploit 133, 320Microsoft SQL Server, transparente

Verschlüsselung 290Mikroprozessor 387Mobile 361mobile Anwendungen

Datensicherheit 373Kryptografie 374

Mobile Application Management 367Mobile Device Management 367Mobile-Architektur 361, 370Mobile-Endknoten 372mobiles Gerät 366

N

Nachricht, Verschlüsselung 401National Institute of Standards and

Technology 46Native Routing 345Native SQL 295Near Field Communication 374Need-to-know-Prinzip 168, 178Network Layer 103, 104

NetzwerkAnalyse 129Ebenen 103Erkennung 129Netzwerkverkehr verschlüsseln

114, 230Protokoll 198Scan 130schützen 143Sicherheit 101, 138Tunnel 201vertrauenswürdiges 376

Next-Generation-Firewall 365NFC 374NIST 46Nmap 129, 300

O

Objektprivileg 291oclHashcat 243ODBC 117Onapsis 353Onapsis OSP 136Onapsis Security Platform 353Open SQL 294, 346OPS$-Mechanismus 285Oracle 142

Passwortregeln 284Verschlüsselung 289

Oracle Listener 287Organisation, interne 58Oszilloskop 412OWASP 44

P

Padding Oracle on Downgraded Legacy Encryption 199

Paketfilter 108PASSCODE 238Passwort

Angriff 244im Altsystem sichern 252Policy einführen 257Prüffunktion 284SAP-Implementierung 236schützen 202, 233, 245Tabelle schützen 246


423

Index

Patch 138Patch Management 139Payload 301Peer Review 404Penetrationstest 60, 61

Abschlussgespräch 65Dokumentation 65SAP HANA 323Varianten 63Vorbereitung 62

Personalisierung 404Phishing 63PhoneGap 367Physical Layer 103Pineapple 378, 409Pivoting 167Policy 107POODLE 199Port Mirroring 353Port Monitoring 353Presentation Layer 105PRNG 405Protokoll verschlüsseln 198Proxyfilter 108PWDSALTEDHASH 238, 253

Q

QRadar 355Qualitätssicherung 275

R

Radio Frequency 408Rauschen 405Realm 292Reconnaissance 298Remote Function Call � RFCRemote Procedure Call 81, 105Replay 412REPOSRC 302Reputation 35Reverse Engineering 326, 412RFC 81, 105, 115, 141

ACL 229Baustein 142Berechtigung ermitteln 217Berechtigung prüfen 214Callback 226

RFC (Forts.)Client 115, 224Funktionsbaustein 215, 219Gateway sichern 228schützen 209technische Komponenten 210Trusted 211Verschlüsselung 230

RFC-Gateway 115RF-Hack 408Risiko

Analyse 25, 33darstellen 38Faktor 34formalisierte Betrachtung 30, 43Formel 30identifizieren 34Informationen bewerten 31Klassifikation 36Matrix 31

Rolle, Beschreibung 190Route String 151Route-Permission-Tabelle 149,

152, 154RPC 81RSA-Schlüssel-Generator 375RTFM 126Rule Set 292RZ11 332

S

Safe Harbour 390Salt 235SAML 317SAP Afaria 367SAP Attack Vectors 29SAP Business Suite 372SAP Code Inspector 277, 359SAP Code Vulnerability Analysis 86,

91, 92, 297SAP Cryptographic Library 107SAP EarlyWatch Session 97SAP Enterprise Threat Detection

86, 355Architektur 87Lernmodus 90

SAP Event Stream Processor 87, 397SAP Fiori 320, 369


424

Index

SAP Gateway 372SAP GUI 80SAP GUI, Hack 111SAP HANA

Angriff 324Architektur 312Authentifizierung 317Column Store 313in der Cloud 327Internet der Dinge 396Penetrationstest 323Persistenz 315Sicherheit 309Verschlüsselung 326

SAP HANA Cloud Platform 396SAP HANA Studio 319SAP HANA XS 88, 316, 320SAP Java Virtual Machine 191SAP Logon Ticket 317, 364, 381SAP Mobile Document

Management 370SAP Mobile Platform 367, 368SAP NetWeaver 84SAP NetWeaver Administrator 193SAP NetWeaver AS ABAP 163

absichern 179Rechte prüfen 184schützen 163Sicherheitslücken finden 182

SAP NetWeaver AS Java 191SAP Patch Day 83SAP Solution Manager 97, 139

Angriffsziel 168Usage and Procedure Logging 351

SAP SQL Anywhere 397SAP Web Dispatcher 376, 381

Angriff 157Funktionen 154, 156härten 160Logging 336

SAPCAR 148SAProuter

Angriff 152Einsatzgebiet 146härten 153im Netzwerk 145Kaskadierung 154Logging 153

SAP-Sicherheitshinweis 83SAPSSO2 364, 381

SAPUI5 322Sarbanes-Oxley Act 35SCADA 392, 413SDN 117SDR 408Secure Keystore 374Secure Network Communication

� SNCSecure Storage in File System 286Security Assertion Markup

Language 317Security Audit Log 332Security Baseline Template 189Security Event 329, 354Security Log 337Security Operations Center 74Security Optimization Self-

Service 183Security Optimization Service 183Security Self-Service 98SELECT-Statement 346Sensor 386Server

Analyse 133Erkennung 133

Session Layer 105Shell-Administrator 194shodan.io 126Sicherheit 79

Bereich 323Konzept 189Maßnahmen dokumentieren 187Organisation 59politische Dimension 56Rolle 59SAP Solution Manager 97Software 75Veränderungen 56

SicherheitsstrategieBewertung 55entwickeln 53Fallbeispiele 67Kosten 65Nutzen 65Ziele 57

Sicherheitsvorfall 332, 354SIEM 42, 119, 354Single Sign-on 261, 376SM20 333SM21 335


425

Index

SMICM 337SMMS 339SNC 106, 230SNC Client Encryption 114Sniff 106, 381Snort 351SoC 385Social Hacking 394SOC-Manager 74Software-Defined Network 117Software-Defined Radio 408SOX 35SPAN 353Splunk 356SPWD 249SQL Audit 346SQL Injection 94, 273, 277, 296SQL*Plus 291SSFS 286SSL 198, 317SSO 261, 376ST01 342ST04N 298ST11 344Stateful Inspection 108Status quo

Dokumentation 57feststellen 60

STMS 340strings 289stunnel 201Stuxnet 326, 413S-User 148Switch 118Switched Port Analyzer 353SWNC_STATREC_READ 347System Landscape Directory 191System on a Chip 385System Profiler 137System Recommendations 139Systemlog 334Systemprivileg 291Systemtrace 342Systemumgebung 36

T

Tabelle/SDF/UPL_LOG 350DBTABLOG 340

Tabelle (Forts.)Protokollierung 339REPOSRC 302USR02 301

Tablespace, Verschlüsselung 289Tap 103, 305TDE 289Tier 107, 363TMS 263Tokenized Event 333Topologie 107Transaktion

ATC 93DBACOCKPIT 298RSRFCCHK 213RZ11 332SCU3 340SM20 333SM21 335SMICM 337SMMS 339sperren 181ST01 342ST11 344STAUTHTRACE 218STMS 340SU24 221UCONCOCKPIT 223

Transistor 405Transparent Data Encryption 289Transport

Domäne 264Layer 104Schad-Code 273sichern 265Verzeichnis 265Weg 264

Transport Management System � TMS

TransportsystemAngriff 265schützen 263

TRNG 405Trojaner 413


426

Index

U

Ubertooth 394, 410Übungszentrum Netzverteidigung

67, 68UCON 223UCON Cockpit 223UME-Rolle 206Unified Connectivity Framework 223UPL 349URL-Filtering 156Usage and Procedure Logging 349USB/UART-Adapter 412User Interface 368USR02 301

V

Verb Tampering 338Verschlüsselung 106, 400Verschlüsselung, transparente 289Virtual Forge Code Profiler 297Visual Administrator 193VMware 122

W

WAP 372Waterhole 63

Wearable 394Web Client 193Webanwendung, sichern 318, 322Werkzeug 123, 125Werth IT Auditor 137White-Box-Test 64Wind River 399Wireless Access Point 372, 378

X

X1 136.xsaccess 323XSJS 319, 320XSRF 321XSS 207, 321

Z

ZenMap 129zentrale Benutzerverwaltung 252Zero-Day-Exploit 32, 84Zertifikat 362, 380Zielanalyse 126Zufallszahl 47, 404Zugriff begrenzen 192Zwei-Faktor-Authentifizierung 375ZYBO-Board 400


Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstel- lung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nut-zungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Holger Stumm ist Gründer und Geschäftsführer von log(2), einem auf SAP-Sicherheit spezialisierten Beratungsunter- nehmen. Für seine Kunden entwickelt er strategische Sicherheitskonzepte, analysiert die Systeme in Hinblick auf deren Sicherheit und erstellt Risikoanalysen, u.a. mit Hilfe von Penetrationstests. Holger Stumm ist seit 2014 zertifi-zierter Partner der Allianz für Cyber-Sicherheit des Bundes-amts für Sicherheit in der Informationstechnik.

Holger Stumm, Daniel Berlin

SAP-Systeme schützen426 Seiten, gebunden, Februar 2016 69,90 Euro, ISBN 978-3-8362-3851-9

www.sap-press.de/3907

Daniel Berlin ist Security-Spezialist mit langjähriger Erfah-rung und arbeitet in einer internationalen Bankengruppe. Er führt Analysen im Bereich SAP-Sicherheit durch und bewertet Bedrohungsszenarien. Daniel Berlin hat mehrere SAP-Sicherheitszertifizierungen abgeschlossen und erstellt regelmäßig Konzepte zu SAP-Berechtigungen. Seine Er-fahrungen in der Programmierung erlauben es ihm, auch technische Aspekte der Systemsicherheit zu analysieren und zu bewerten.

Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/sap-systeme-schutzen_3907/?GPP=lpn

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

Leseprobe - Amazon S3 · »Netzwerksicherheit herstellen« ... gen. Nach einer Einführung in die...

Documents

Transcript of Leseprobe - Amazon S3 · »Netzwerksicherheit herstellen« ... gen. Nach einer Einführung in die...