Netzwerksegmentierung testen: Die ultimative Checkliste

Ist Ihre Netzwerksegmentierung tatsächlich wirksam? Eine Firewall zwischen zwei Netzen ist noch kein Beweis dafür, dass unerwünschte Zugriffe verhindert werden. Entscheidend ist, welche Systeme aus welcher Sicherheitszone erreichbar sind, welche Dienste antworten und ob ein Angreifer einen erlaubten Kommunikationsweg missbrauchen kann. Ein gezielter Pentest der Zonenübergänge macht genau diese Unterschiede sichtbar.

Kurzantwort: Um die Netzwerksegmentierung zu testen, definieren Unternehmen zunächst erlaubte und verbotene Verbindungen zwischen ihren Sicherheitszonen. Anschließend werden die Übergänge aus realistischen Angreiferpositionen kontrolliert überprüft – einschließlich Erreichbarkeit, Dienstesicherheit, Berechtigungen und möglicher Angriffsketten. Die Ergebnisse werden mit der vorgesehenen Segmentierungsrichtlinie abgeglichen.

Was bedeutet es, Netzwerksegmentierung zu testen?

Netzwerksegmentierung trennt Systeme mit unterschiedlichen Aufgaben oder Schutzbedarfen. Typische Zonen sind das Internet, eine demilitarisierte Zone (DMZ), Büroarbeitsplätze, Servernetze, Produktionsumgebungen und administrative Netze. Firewalls, Router, Zugriffskontrolllisten und hostbasierte Regeln sollen die Kommunikation zwischen diesen Bereichen begrenzen.

Bei einem Segmentierungstest geht es nicht nur um die Frage, ob eine Firewall-Regel existiert. Es wird geprüft, ob die beabsichtigte Sicherheitsgrenze aus der Perspektive eines möglichen Angreifers tatsächlich funktioniert. Dabei können auch Cloud-Sicherheitsgruppen, VPN-Zugänge, Proxys und Anwendungsberechtigungen relevant sein.

Ein wichtiger Unterschied: Ein erreichbarer Port ist nicht automatisch eine Sicherheitslücke. Umgekehrt ist ein gesperrter Port allein kein Nachweis für eine insgesamt sichere Zone. Der fachliche Maßstab ist die dokumentierte Soll-Kommunikation und das Risiko eines möglichen Missbrauchs.

Sieben gefährliche Fehler an Zonenübergängen

1. Eine DMZ darf mehr als vorgesehen

Eine öffentlich erreichbare Anwendung in der DMZ benötigt möglicherweise eine Verbindung zu einem internen Backend. Problematisch wird es, wenn die Regel nicht nur den benötigten Dienst, sondern ganze interne Subnetze freigibt. Ein kompromittierter Webserver könnte dann als Ausgangspunkt für weitere Angriffe dienen.

Im Test wird deshalb nicht nur die Verbindung Internet → DMZ betrachtet, sondern auch DMZ → internes Netz. Beide Übergänge beantworten unterschiedliche Sicherheitsfragen.

2. Administrative Schnittstellen sind aus Benutzerzonen erreichbar

Management-Oberflächen von Hypervisoren, Firewalls, Backup-Systemen oder Servern sollten nur aus ausdrücklich autorisierten Verwaltungsumgebungen erreichbar sein. Häufig entstehen Ausnahmen durch Wartungsarbeiten oder historisch gewachsene Regeln. Ein Segmentierungstest untersucht, ob solche Schnittstellen von normalen Arbeitsplätzen oder weniger vertrauenswürdigen Netzen aus zugänglich sind.

3. Nur die Richtung zum Ziel wird geprüft

Wer ausschließlich testet, ob ein Client einen Server erreichen kann, übersieht möglicherweise Rückwege und ausgehende Verbindungen. Gerade bei Datenabfluss oder Command-and-Control-Kommunikation ist entscheidend, welche Ziele ein kompromittiertes System selbst kontaktieren darf. Daher gehören eingehende und ausgehende Kommunikationsbeziehungen in den Prüfplan.

4. DNS, Proxys und IPv6 bleiben außerhalb des Blickfelds

Eine Segmentierung kann für IPv4 sauber wirken und trotzdem unerwartete Wege über IPv6, Proxys, Dual-Homed-Systeme oder alternative Namensauflösung zulassen. Auch ein Anwendungsproxy kann technisch erlaubte Verbindungen vermitteln, die in der ursprünglichen Netzskizze nicht offensichtlich sind. Der Pentest prüft deshalb die tatsächlich vorhandenen Kommunikationspfade statt ausschließlich die dokumentierten Firewall-Regeln.

5. Erlaubte Dienste besitzen zu weitreichende Berechtigungen

Manche Verbindungen sind fachlich notwendig: etwa von einem Anwendungsserver zur Datenbank. Doch auch auf einem erlaubten Port können schwache Authentifizierung, überprivilegierte Dienstkonten oder fehlende Mandantentrennung ein Risiko darstellen. Ein wirksamer Test betrachtet daher sowohl die Netzwerkfreigabe als auch die Sicherheit des erreichbaren Dienstes – soweit dieser Teil des vereinbarten Scopes ist.

6. Ein kompromittierter Arbeitsplatz wird nicht mitgedacht

Die äußere Firewall schützt nicht vor jeder internen Bedrohung. Gelangt ein Angreifer über Phishing, einen Dienstleisterzugang oder ein kompromittiertes Gerät in ein Benutzersegment, stellt sich die Frage nach der seitlichen Ausbreitung (Lateral Movement). Können Server, Identitätsdienste oder Backup-Systeme erreicht werden? Eine Prüfung aus einer realistischen internen Ausgangsposition liefert hier andere Erkenntnisse als ein ausschließlich externer Scan.

7. Nach Änderungen findet kein Retest statt

Eine behobene Firewall-Regel kann später durch neue Anwendungen, Migrationen oder Notfallfreigaben wieder aufgeweicht werden. Außerdem kann eine Korrektur unbeabsichtigt legitime Kommunikation unterbrechen. Nach der Behebung sollten deshalb sowohl zuvor unerlaubte als auch ausdrücklich erforderliche Verbindungen erneut geprüft werden.

So läuft ein Pentest von Zonenübergängen ab

Schritt 1: Zonen und Schutzziele festlegen

Zu Beginn werden die relevanten Sicherheitszonen, ihre Eigentümer und die gewünschten Trennungsziele erfasst. Ein Krankenhaus könnte beispielsweise Internet, Patientenportal-DMZ, Verwaltungsnetz, medizinische Systeme und Managementnetz unterscheiden. Die konkrete Architektur ist immer organisationsspezifisch; das Beispiel beschreibt keine tatsächliche Kundenumgebung.

Schritt 2: Eine Soll-Kommunikationsmatrix erstellen

Eine einfache Matrix hält fest, welche Quelle welches Ziel über welchen Dienst erreichen darf. Beispielsweise:

• Internet → Web-DMZ: HTTPS zum veröffentlichten Portal erlaubt.
• Web-DMZ → Datenbankzone: ausschließlich definierte Backend-Verbindungen erlaubt.
• Office-Netz → Managementnetz: direkter Administrationszugriff grundsätzlich untersagt; genehmigte Zugänge gesondert geregelt.
• Gastnetz → interne Server: keine direkte Kommunikation vorgesehen.

Diese Angaben sind illustrative Soll-Vorgaben, keine universell gültigen Regeln. Ohne eine solche Matrix lässt sich ein technischer Fund oft nicht eindeutig als Fehlkonfiguration bewerten.

Schritt 3: Testpositionen und Regeln vereinbaren

Ein externer Test beginnt im Internet. Für interne Zonenübergänge werden zusätzlich autorisierte Testpositionen benötigt, etwa ein isolierter Prüfclient im Gast-, Office- oder Servernetz. Vorab werden IP-Bereiche, erlaubte Verfahren, Zeitfenster, sensible Systeme, Ansprechpartner und Abbruchkriterien schriftlich vereinbart. Kritische Produktions- und Medizinsysteme erfordern gegebenenfalls besonders zurückhaltende Prüfmethoden.

Schritt 4: Erreichbarkeit und Angriffspfade kontrolliert verifizieren

Die technische Prüfung erfasst erreichbare Hosts und Dienste, überprüft die vorgesehenen Sperren und bewertet auffällige Kommunikationswege. Bei freigegebenen Zielen können anschließend Schwachstellen, Authentifizierung und mögliche Rechteausweitung untersucht werden. Dabei wird zwischen technisch erreichbar, unerlaubt erreichbar und praktisch ausnutzbar unterschieden.

Ein guter Bericht dokumentiert den Ausgangspunkt, den getesteten Übergang, das erwartete Verhalten, das beobachtete Ergebnis und nachvollziehbare Nachweise. So können Administratoren eine Regel gezielt korrigieren und später erneut überprüfen.

Was sollte im Bericht stehen?

Für die IT-Leitung ist eine bloße Liste offener Ports wenig hilfreich. Ein aussagekräftiger Bericht sollte mindestens die geprüften Quell- und Zielzonen, den Umfang der Tests, erlaubte und unerlaubte Verbindungen, bestätigte Schwachstellen, potenzielle Angriffsketten und konkrete Maßnahmen enthalten. Wichtig sind auch dokumentierte Einschränkungen: Nicht geprüfte Segmente dürfen nicht stillschweigend als sicher gelten.

Die Bewertung sollte sich am geschäftlichen Risiko orientieren. Ein unerwarteter Zugriff auf eine unkritische Testanwendung ist anders zu priorisieren als ein Weg von einer öffentlich erreichbaren Zone zu einem Backup- oder Administrationssystem.

Wann lohnt sich ein Segmentierungs-Pentest?

Besonders sinnvoll ist er nach Firewall-Migrationen, der Einführung neuer Standorte, Cloud-Anbindungen, VPN-Änderungen oder der Trennung von Office- und Produktionsnetzen. Auch vor der Inbetriebnahme sensibler Anwendungen oder nach einem Sicherheitsvorfall kann die Prüfung entscheidende Fragen beantworten.

Die Fachpublikation NIST SP 800-41 Rev. 1 behandelt unter anderem das Konfigurieren, Testen und Verwalten von Firewalls. NIST SP 800-207 ergänzt diese Perspektive: In einer Zero-Trust-Architektur soll allein die Zugehörigkeit zu einem internen Netz kein automatisches Vertrauen begründen. Segmentierung und identitätsbasierte Zugriffskontrolle ergänzen sich deshalb.

Fazit: Entscheidend ist die tatsächliche Trennung

Eine gut dokumentierte Firewall ist ein Anfang. Ob Ihre Sicherheitszonen Angriffe tatsächlich begrenzen, zeigt erst die Prüfung aus den relevanten Ausgangspositionen. Unternehmen gewinnen damit eine belastbare Grundlage, um unnötige Freigaben zu schließen, kritische Übergänge zu härten und seitliche Angriffsbewegungen zu erschweren.

Sie möchten Ihre Zonenübergänge unabhängig prüfen lassen? yatesh untersucht im Rahmen eines Netzwerk-Penetrationstests die Erreichbarkeit, Segmentierung und mögliche Angriffspfade zwischen vereinbarten Netzbereichen. Bei komplexeren Umgebungen kann ein Infrastruktur-Pentest ergänzend sinnvoll sein. Informationen zu Aufwand und Kosten helfen bei der ersten Planung.