(Mikro-)Segmentierung aus praktischer Sicht

Bevor wir uns mit Best Practices und Strategien befassen können, müssen wir zunächst definieren, womit wir es zu tun haben. Bei der Netzwerksegmentierung wird das Netzwerk in Teile (Segmente) unterteilt und es wird festgelegt, wer auf welche Weise auf welche Services zugreifen kann – z. B. kann der Zugriff auf Webserver auf HTTP/S beschränkt werden. 

Traditionell wurde dies mithilfe von VLANs und physischen Firewalls erreicht, doch in letzter Zeit erleben wir immer häufiger softwarebasierte Ansätze für Firewalls und Segmentierung (Akamai Guardicore Segmentation). Wir werden keine Empfehlung für einen der beiden Ansätze aussprechen, denn beide haben ihre Vor- und Nachteile. Unsere empfohlenen Richtlinien und Strategien sind anbieterunabhängig und können überall angewendet werden.

Wenn Sie von der Traffic-Kontrolle über VLANs, Zugriffssteuerungslisten (Access Control Lists, ACLs) und IP-Bereiche zur Verwendung nutzerdefinierter, anbieterunabhängiger Labels wechseln, dann betreten Sie das Reich der Mikrosegmentierung. Bei all unsere Strategien in diesem Blogbeitrag gehen wir davon aus, dass wir Mikrosegmentierung einsetzen.

Zwar sollte es möglich sein, die Strategien und Richtlinien so anzupassen, dass keine Segmentierung erforderlich ist. Doch der Prozess, alle VLANs, ACLs und IP-Listen zu definieren und dann zu verwalten, ist wahrscheinlich kaum zu handhaben – und selbst wenn, kann er Netzwerkadministratoren und Techniker schnell überlasten: Versuchen Sie mal, den IP-Bereich oder die -Gruppe aller Finanzserver zu definieren. Es ist vielleicht machbar, aber wie lange können Sie diese Liste genau führen? Und das ist nur eine Servergruppe – in einem Unternehmensnetzwerk gibt es viel mehr: Endnutzer, Domaincontroller und -administratoren, Drucker usw.

Bevor wir uns mit der Segmentierung befassen, müssen wir eine wichtige Voraussetzung dafür besprechen: Transparenz. Mikrosegmentierung existiert nicht im Vakuum. Was Sie nicht sehen können, können Sie nicht schützen. Eine gute Segmentierung ist nur in Verbindung mit Netzwerktransparenz effektiv, die den Traffic organisiert und zusammenfasst. Normalerweise gibt es zu viel Traffic, als dass er realistisch mit bloßem Auge analysiert werden könnte.

Bevor wir uns den eigentlichen Segmentierungsstrategien zuwenden, erörtern wir einige Leitlinien oder Grundsätze, die unserer Meinung nach für eine gute Segmentierung von entscheidender Bedeutung sind.

Im Allgemeinen sind Server, bei denen viel Traffic eingeht, eher für die Verarbeitung von Anfragen zuständig, wie z. B. Web- oder Fileserver (selbst Domaincontroller fallen in diese Kategorie). Dementsprechend sollte bei ihnen nicht viel ausgehender Traffic auftreten – oder zumindest sollte er genau definiert werden. 

Darüber hinaus besteht das Risiko, dass der Server von Angreifern als Ausgangspunkt verwendet wird, da Server für Angreifer leichter zugänglich sind und für den Zugriff auf einen größeren Teil des Netzwerks ausgenutzt werden können.

Es gibt einige Maschinen, für die Richtlinien relativ locker sein müssen, da der Traffic, der von diesen Maschinen eingeht, zu stark variiert. In solchen Fällen müssen viele Ausnahmen definiert werden. 

Nehmen wir zum Beispiel Jumpbox-Server: Verschiedene Nutzer verwenden sie, um eine Verbindung zu verschiedenen Servern mit unterschiedlichen Protokollen herzustellen. Sie können nicht alle Anwendungsfälle abdecken, ohne dass zu viel Freiraum entsteht (was dem Zweck der Segmentierung widerspricht). 

In solchen Fällen halten wir es für das Beste, andere Abwehrmechanismen einzusetzen und sie strenger zu gestalten (z. B. durch eine stärkere Nutzerzugriffskontrolle im Jumpbox-Beispiel oder durch niedrigere Warnungsschwellenwerte für Überwachungsservices).

Nur weil ein Traffictyp bereits vorhanden ist, wenn Sie mit der Segmentierung beginnen, heißt das nicht, dass Sie ihn weiterhin zulassen sollten. Manchmal müssen Sie bestehende Konfigurationen von Anwendungen oder Servern ändern, wenn Sie entscheiden, dass der von ihnen generierte Traffic unnötig ist. Manchmal müssen Sie auch vorhandene Konfigurationen untersuchen, um zu verstehen, warum bestimmte Arten von Traffic überhaupt übertragen werden.

In diesem Fall funktioniert die Segmentierung wie eine herkömmliche Firewall: Sie blockieren eingehenden Traffic von außerhalb Ihres Netzwerks, der nicht in das Netzwerk gelangen sollte. Dieser Traffic stammt in der Regel aus das Internet, kann aber auch über Drittanbieternetzwerke eingehen, die mit Ihrem eigenen verbunden sind. 

Das Blockieren öffentlich zugänglicher SSH- (Secure Shell) oder RDP-Ports (Remote Desktop Protocol) – oder im Grunde aller Ports im Abschnitt zu lateraler Netzwerkbewegung – wird empfohlen. So sollten Sie für den Traffic von außerhalb Ihres Netzwerks lieber eine Zulassungsliste verwenden als eine Sperrliste – insbesondere wenn der Traffic aus dem Internet stammt (denken Sie beispielsweise daran, wie viele Internetscanner jederzeit aktiv sind).

Natürlich gilt wie bei jedem anderen Sicherheitstool: Richtlinienbasierte Segmentierung ist kein Allheilmittel gegen Bedrohungen. Segmentierung kann nicht alle anfänglichen Zugriffsvektoren abdecken – wenn Sie sich also nur auf die Segmentierung verlassen, ist Ihr Netzwerk Risiken ausgesetzt. Viele Angriffe beginnen mit Phishing-E-Mails oder -Links oder anderen Formen von Social Engineering. 

Einige Attacken beginnen auch mit Schwachstellen in Protokollen, die zugelassen werden müssen, oder mit schwachen Anmeldeinformationen für Services, die über das Internet zugänglich sind, wie z. B. VPN-Server. Aus diesem Grund empfehlen wir, sich nicht nur auf Segmentierung zu verlassen, um den ersten Zugriff zu verhindern, sondern zusätzlich zur Segmentierung auch Sicherheitslösungen für Host- und E-Mail-Schutz einzusetzen.

Es gibt viele Möglichkeiten für laterale Netzwerkbewegung, von denen wir nicht alle abdecken werden. Wir werden uns speziell auf die Verhinderung lateraler Netzwerkbewegung konzentrieren, die durch legitime, bereits auf der Maschine vorhandene Prozesse erfolgen kann – über Protokolle wie RDP oder SSH, RPC-basierte Services wie Service Manager oder Task Scheduler, Verwaltungstools wie PowerShell oder WMI oder auch einige der Linux-Protokolle und -Tools, die wir in einem separaten Beitrag besprochen haben.

Wir werden nicht über eintägige oder Zero-Day-Schwachstellen sprechen, da sie in jedem Produkt und mit unterschiedlichen Implementierungen vorkommen können. Deshalb lässt sich hier kaum eine allgemeine Strategie definieren, die sie alle abdeckt. Das einzige, was wir empfehlen können, ist Segmentierung. Denn wenn etwas nicht zugänglich ist, ist es auch viel schwieriger auszunutzen.

Bevor wir uns mit den verschiedenen Überlegungen zu den einzelnen Protokollen befassen, gibt es zwei Prinzipien, die für alle gelten.

Nutzer müssen nicht wirklich auf die Computer anderer Nutzer zugreifen, insbesondere nicht über das Netzwerk. Wenn eine Person nicht in der IT arbeitet, gibt es für sie keinen wirklichen Grund, sich per Remotezugriff mit dem Computer eines anderen Nutzers zu verbinden. Deshalb sollte es möglich sein, den Traffic zwischen Nutzergeräten einzuschränken, ohne die Netzwerkfunktionalität merklich zu beeinträchtigen.

Da die in diesem Abschnitt beschriebenen Protokolle für Remotesteuerung oder -ausführung verwendet werden können, können sie auch als erste Zugriffsvektoren dienen. Aus diesem Grund weisen wir erneut darauf hin, wie wichtig es ist, den willkürlichen Internetzugang über diese Protokolle zu beschränken.

Da diese Services auf interaktive und grafische Weise funktionieren, ist ihre automatisierte Nutzung ziemlich begrenzt. Deshalb können Sie davon ausgehen, dass diese Protokolle nur selten von Servern verwendet werden – wenn sie aber dennoch auftreten, sollten Sie unbedingt den Grund untersuchen. 

Das gleiche gilt für die Maschinen Ihrer Nutzer: Auch sie sollten sich nicht miteinander verbinden können. Es gibt jedoch Ausnahmen: darunter Jumpboxes und Terminalserver, mit denen Nutzer Umgebungen wechseln oder auf Server zugreifen können, Verbindungen zwischen IT-Mitarbeitern und Nutzern sowie Fälle, in denen Application Owner eine Verbindung zum Anwendungsserver herstellen. 

Solche Ausnahmen sollten durch die Erstellung geeigneter Segmentierungsrichtlinien gehandhabt werden. Diese Bemühungen sollten jedoch auch durch geeignete Lösungen für Identity Access Management (IAM) ergänzt werden.

Obwohl SSH im Konzept den RDPs ähnelt, ist dieses Protokoll etwas komplizierter: Da SSH auf Terminals (und Text) basiert, lässt sich dieses Protokoll viel einfacher für die Interaktion mit Software einzusetzen – und es gibt Programme und Skripte, die dieses Protokoll nutzen. Darüber hinaus wird SSH auch verwendet, um weniger sichere Protokolle einzukapseln, wie bei SFTP, der SSH-Kapselung des File Transfer Protocols.

Aus diesen Gründen erfordert SSH einen viel detaillierteren Ansatz als andere RDPs. Ohne eine angemessene Transparenz des Traffics ist es sehr schwierig, SSH ordnungsgemäß zu segmentieren, ohne Endnutzer oder Netzwerkfunktionalität zu beeinträchtigen.

Sowohl MS-RPC als auch SMB lassen laterale Netzwerkbewegung nicht sofort zu – doch andere Protokolle, die auf diesen beiden basieren, tun genau das (siehe Abbildung 4). SMB wird für Dateiübertragung und Kommunikation verwendet, während RPC für den Aufruf von Remotefunktionen über definierte Schnittstellen verwendet wird. RPC wird manchmal auch über SMB übertragen, sodass sie eng miteinander verbunden sind. Sie sind zudem bekanntermaßen schwer zu segmentieren, da sie in das Windows-Domainsystem eingebettet sind. 

Beispielsweise ist die Domainauthentifizierung in Netlogon, einem RPC-basierten Protokoll, implementiert. Richtlinien und Anmeldeskripte für Domaingruppen werden in einem freigegebenen Ordner auf dem Domaincontroller namens SYSVOL gespeichert – und domainverbundene Maschinen greifen über SMB darauf zu.

SMB und RPC zu blockieren ist also praktisch unmöglich, ohne die gesamte Domain zu zerstören. Was können Sie also tun? Mit SMB können Sie Richtlinien basierend auf logischen Einheiten erstellen. Die meisten Server und Computer sollten nicht über SMB miteinander kommunizieren, es sei denn, das Ziel ist ein Fileserver. Deshalb sollte eine ordnungsgemäße Ringfencing-Segmentierung dazu beitragen, das SMB-Risiko zu mindern.

Ein ähnlicher Ansatz kann auf RPC angewendet werden – hier können Sie jedoch noch restriktiver vorgehen, da RPC-Traffic zu Fileservern nicht zugelassen werden muss, anders als bei SMB. Da RPC im Nutzermodus verarbeitet wird, können Segmentierungsrichtlinien basierend auf dem Zielservice oder -prozess erstellt werden. So müssen Sie nur mit RPC-Schnittstellen arbeiten, die für laterale Netzwerkbewegung missbraucht werden können (und nur, wenn Sie über einen Segmentierungsagent verfügen, der prozess- oder servicebasierte Regeln verarbeiten kann). 

Die folgende Tabelle zeigt RPC-Schnittstellen, die verwaltet werden sollten, um laterale Netzwerkbewegung zu verhindern.

Da nicht alle Vorgänge über diese RPC-Schnittstellen schädlich sind – beispielsweise interagieren einige Überwachungslösungen und Watchdogs per Fernzugriff mit dem Service Manager, um den Zustand des Service zu überprüfen –, empfehlen wir, die vorhandene RPC-Kommunikation zu überprüfen. Wenn normalerweise kein Remotezugriff auf die Schnittstellen erfolgt (oder wenn Sie die Quellenliste eingrenzen können), empfehlen wir Ihnen, Segmentierungsrichtlinien um die Schnittstellen herum zu erstellen und so die Sicherheit weiter zu steigern.

Sowohl PowerShell als auch WMI sind in der Lage, mit Remotemaschinen zu interagieren – und diese Interaktion basiert auf Windows Remote Management (WinRM). Da die legitime Nutzung in der Regel Remoteverwaltung oder -überwachung (mit WMI) betrifft, sollte es in Ihrem Netzwerk nur wenige Anwendungsfälle geben. Sie sollten also Segmentierungsrichtlinien erstellen können, die eine willkürliche Nutzung der Protokolle einschränken, damit sie nur von Überwachungsservern oder IT-Computern genutzt werden können. 

Natürlich sind Ausreißer möglich. So haben wir bereits einige Fälle erlebt, in denen Entwickler Remote-PowerShell für die Nutzerfreundlichkeit ausgiebig genutzt haben. Dementsprechend müssen Sie diese Entscheidung wahrscheinlich von Fall zu Fall treffen.

Sofern Sie nicht den gesamten ausgehenden Traffic strengstens kontrollieren, können Sie nicht realistisch erwarten, dass bloße Segmentierung Datenextraktion bei Angriffen verhindern kann. Das Internet ist riesig. Es ist nicht realistisch, ein genaues Urteil für jede Website und jeden Server zu fällen, zu der Nutzer über Ihr Netzwerk eine Verbindung herstellen. So können Cyberkriminelle ihre Extraktionsversuche leicht hinter anderem ausgehenden Traffic verbergen.

Anstatt den ausgehenden Traffic zu prüfen, lässt sich einfacher kontrollieren, wer auf vertrauliche Daten zugreifen kann. Der einzige Ort, an dem es möglich ist, den ausgehenden Traffic einzuschränken, ist auf Servern im Netzwerk. Im Gegensatz zu Nutzercomputern sollte bei den ausgehenden Zielen dieser Server deutlich weniger Variabilität auftreten.

Das übergeordnete Prinzip für diesen gesamten Abschnitt lautet: „Nur weil es schon passiert, heißt das nicht, dass es erlaubt sein sollte.“ Wenn Sie einen Teil Ihres Netzwerks segmentieren – egal, ob es sich um eine geschäftskritische Anwendung (wie SWIFT), eine Betriebseinheit (wie den Domaincontroller) oder eine Umgebung (wie Produktionsserver) handelt –, besteht die erste Aufgabe darin, den vorhandenen Traffic zu untersuchen (Abbildung 5). 

Nach der Analyse des vorhandenen Traffics können Sie Richtlinien erstellen, die relevante Vorgänge zulassen und den Rest einschränken. (Hierbei haben Sie auch Gelegenheit, Fehlkonfigurationen zu finden, um die sich der Application Owner kümmern muss.) 

Es wird empfohlen, nicht sofort eine Blockierungsrichtlinie zu implementieren, sondern eine Zeit lang im reinen Warnmodus zu arbeiten. Sie sollten erst zu einer einschränkenden Richtlinie wechseln, wenn Sie glauben, dass die Richtlinie wie beabsichtigt ausgeführt wird und dass Warnungen bei Richtlinienverstößen auf ein Minimum begrenzt sind – oder zumindest auf eine kontrollierte Menge. 

Es ist auch wichtig, Ihre aktuelle Umgebung (wie sie vor Beginn der Segmentierung bestand) und Ihre zukünftige Umgebung (nach Implementierung der Segmentierungsrichtlinie) zu unterscheiden. Bei der ersten Implementierung der Segmentierung sollten Sie vorsichtig sein und sich mit dem Netzwerk vertraut machen, um Schäden zu vermeiden. 

Bei Ergänzungen des Netzwerks sollten Sie jedoch die bestehende Segmentierungsrichtlinie berücksichtigen. Legen Sie Ausnahmen und Abweichungen von Richtlinien fest, wenn dies für den normalen Betrieb erforderlich ist, aber missachten Sie die bestehenden Richtlinien nicht, nur weil Sie das Netzwerk erweitern.

Beim Ringfencing interessieren uns vor allem die Schnittstellen des Segments mit dem Rest des Netzwerks und mit der Welt. Wir möchten kontrollieren, was in dem Teil des Netzwerks ein- und ausgeht, den wir segmentieren möchten – und zwar, ohne zu berücksichtigen, was innerhalb des Segments geschieht.

Wir können den Ringfencing-Prozess noch einen Schritt weiter vorantreiben und Richtlinien auf einzelne Maschinen anwenden, basierend auf ihrem Zweck. Wenn beispielsweise ein Server nur als Datenbank fungiert, sollte ihm nur Zugriff über die Datenbankports gewährt werden, Webserver sollten nur Zugriff auf Webports haben usw.

Aber ganz so einfach ist natürlich nicht. Es gibt in der Regel weitere Services, die Zugriff auf diese Server benötigen, wie Watchdogs, Performanceüberwachung oder IT. Diese Zugangsports ähneln in der Regel stark den Techniken lateraler Netzwerkbewegung, da es hier normalerweise um eine Art Remotesteuerung geht. (So fragen beispielsweise Remote-Watchdogs den Service-Manager auf ähnliche Weise ab wie die laterale Bewegungstechnik „PsExec“. Die einzige Möglichkeit, zwischen den Aufrufen zu unterscheiden, ist Deep Packet Inspection, die normalerweise nicht verfügbar ist.)

Um diese Herausforderung zu meistern, empfehlen wir Ihnen – in Fällen, in denen Sie zusätzlichen Traffic für den Service zulassen müssen –, die zulässigen Quellen auf das Segment zu beschränken, das die Überwachung durchführen soll.

Darüber hinaus können wir den Nutzerzugriff auf sensible Standorte einschränken, die sie nicht benötigen. Wenn die Datenbank nur interne Anwendungen bereitstellt, gibt es kaum Gründe, sie von beliebigen Nutzern abfragen zu lassen. Das Blockieren dieses willkürlichen Nutzerzugriffs ist unserer Meinung nach der wichtigste Sicherheitsschritt, da viele Angriffe von kompromittierten Nutzern ausgehen.

Mit Mikrosegmentierung wird unsere Segmentierungsrichtlinie noch präziser: Hierbei trennen wir die Maschinen im Segment nach ihrer Rolle oder Sensibilität. Sie können sich das Ganze wie eine Mischung aus Ringfencing für Anwendungen und allgemeinem Ringfencing vorstellen. Der Hauptunterschied zum Ringfencing besteht darin, dass wir jetzt auch den Traffic innerhalb des Segments kontrollieren und Nachbarn nicht automatisch vertrauen.

Unser Grundsatz lautet hier, dass wir dem Traffic benachbarter Maschinen nicht vertrauen sollten, nur weil sie sich im selben Segment befinden. Angreifer nutzen jede Verbindung, um sich im gesamten Netzwerk zu verbreiten, unabhängig von Segmenten. 

Selbst wenn es im Segment mehrere Anwendungsserver der gleichen Art gibt, besteht kein Grund, dass sie über jeden Port und jedes Protokoll miteinander kommunizieren können. Mikrosegmentierung bedeutet, dass wir Richtlinienregeln auf alle Arten von Traffic anwenden, sogar innerhalb des Netzwerksegments und zwischen Maschinen mit derselben Rolle.

Natürlich sind Maschinen innerhalb desselben Segments in der Regel enger miteinander verbunden, sodass es schwieriger ist, Richtlinien hinzuzufügen, ohne zu viel Freiraum zu bieten.

Je nachdem, wie Sie die Segmente in Ihrem Netzwerk definieren, können die Prinzipien für das Anwendungs-Ringfencing häufig auch für die Mikrosegmentierung angewendet werden. Wenn wir beispielsweise unser Netzwerk in ein Nutzersegment, ein Datenbanksegment und ein Webserversegment aufteilen, eignen sich die in Ringfencing für Anwendungen definierten Prinzipien auch für die Mikrosegmentierung. Die einzige Ergänzung besteht darin, dass diese Prinzipien in jedem Anwendungssegment auf verschiedenen Maschinen angewendet werden müssen.

Wenn unser Netzwerk jedoch in ein Finanzsegment, ein Vertriebssegment und ein IT-Segment unterteilt ist und jedes Segment eine Mischung aus Servern und Nutzergeräten enthält, müssen wir kreativer sein. Nach der Anwendung der allgemeinen Ringfencing-Strategien auf die Segmente müssen wir Richtlinien zwischen und innerhalb dieser Segmente erstellen. Wir können jedes Segment als Mini-Netzwerk betrachten und dann jedes von ihnen in die verschiedenen Anwendungen und Maschinentypen aufteilen, die ihm zugrunde liegen. (Bei einem Vertriebssegment gibt es beispielsweise einen Fileserver, eine Datenbank sowie Nutzercomputer.) Wir können jede Art von Maschine als ein neues Segment behandeln und erneut die Leitlinien für (Anwendungs-)Ringfencing befolgen.

Abbildung 6 fasst die Beziehungen zwischen den verschiedenen Segmentierungsstrategien zusammen.

Die Netzwerksegmentierung ist ein nützliches Tool zur Steigerung der Netzwerksicherheit und zum Umgang mit netzwerkbasierten Bedrohungen. Sie ist außerdem ein Instrument, das unmittelbare Sicherheitsvorteile bieten kann, da Sie nicht mit langen oder mühsamen Segmentierungsprojekten beginnen müssen. Stattdessen können Sie Ihre Arbeit in mehrere Teilprojekte aufteilen, die jeweils die Sicherheit des Netzes schrittweise verbessern. 

Wir haben Leitlinien für verschiedene Segmentierungsrichtlinien und -strategien zusammengestellt, um Netzwerkadministratoren dabei zu unterstützen, genau das zu erreichen. Wir hoffen, dass unsere Empfehlungen nützlich sind und dazu beitragen, die Sicherheit von Unternehmen zu erhöhen.

Die Akamai Security Intelligence Group wird weiterhin eine Vielzahl von Sicherheitsthemen überwachen, untersuchen und entsprechende Forschungsergebnisse veröffentlichen. Um Echtzeitupdates und neue Forschungsergebnisse zu erhalten, folgen Sie uns auf Twitter!