Netzwerksegmentierung: Warum ein VLAN allein noch keine Sicherheitsgrenze ist

Ein Netzwerk in mehrere VLANs aufzuteilen, fühlt sich zunächst nach einem deutlichen Sicherheitsgewinn an. Geräte befinden sich nicht mehr alle im selben Layer-2-Netz, Broadcast-Domänen sind getrennt und die Struktur sieht auf dem Papier wesentlich aufgeräumter aus.

Trotzdem würde ich ein VLAN allein noch nicht als Sicherheitsgrenze bezeichnen.

Für mich beginnt die eigentliche Segmentierung erst dort, wo ich festlege, welche Systeme über diese Grenze hinweg miteinander kommunizieren dürfen – und welche nicht.

Diese Unterscheidung ist wichtig. Denn ein VLAN schafft zunächst Trennung. Eine Sicherheitsarchitektur entsteht daraus erst durch Routing, Firewall-Regeln, nachvollziehbare Vertrauenszonen und regelmäßige Überprüfung.

Vom flachen Netz zur Segmentierung

In einem kleinen Netz landet anfangs schnell alles im selben Subnetz:

Ein typisches flaches Netz: Clients, Server, Drucker, IoT-Geräte, Management und Gastgeräte teilen sich zunächst dasselbe Netz.

Das ist einfach zu betreiben. Gleichzeitig besitzen sehr unterschiedliche Geräte damit häufig eine unnötig direkte Erreichbarkeit untereinander.

Wird beispielsweise ein IoT-Gerät kompromittiert, interessiert mich nicht nur dieses eine Gerät. Ich muss auch fragen, welche anderen Systeme von dort aus erreichbar sind.

Genau hier wird Segmentierung aus Security-Sicht interessant: Sie kann Kommunikationswege begrenzen und damit laterale Bewegung erschweren.

Mein Ziel ist deshalb nicht, möglichst viele VLANs zu besitzen. Mein Ziel ist, Systeme mit unterschiedlichen Aufgaben und unterschiedlichem Schutzbedarf sinnvoll voneinander zu trennen.

Was ein VLAN tatsächlich leistet

Ein VLAN trennt auf Layer 2 logische Netze voneinander.

Ein mögliches Modell könnte so aussehen:

Damit befinden sich diese Bereiche nicht mehr in derselben Broadcast-Domäne.

Sollen Geräte aus unterschiedlichen VLANs miteinander kommunizieren, muss der Verkehr über ein Layer-3-System geroutet werden – beispielsweise über eine Firewall oder einen Router.

Und genau an dieser Stelle liegt für mich der entscheidende Punkt:

Das VLAN schafft die Trennung.

Die Firewall entscheidet, was diese Trennung sicherheitstechnisch bedeutet.

Wenn zwischen allen VLANs anschließend pauschal jeder Verkehr erlaubt wird, habe ich zwar mehrere Netze gebaut, aber kaum eine wirksame Begrenzung der Kommunikationsmöglichkeiten erreicht.

Sicherheitszonen statt VLAN-Sammelleidenschaft

Ich versuche deshalb zuerst in Funktionen und Vertrauensbereichen zu denken und erst danach in VLAN-IDs.

Ein vereinfachtes Modell könnte sein:

Die Firewall bildet dabei den kontrollierten Übergang zwischen den Zonen. Vereinfacht gedacht:

Das Management behandle ich als besonders geschützte Zone, deren Zugriffe gezielt freigegeben werden.

Die entscheidenden Fragen lauten dann nicht:

Wie viele VLANs brauche ich?

Sondern:

Welche Kommunikationsbeziehungen sind tatsächlich erforderlich?

Ein Client muss vielleicht einen internen DNS-Resolver erreichen und per HTTPS auf eine Webanwendung zugreifen.

Ein IoT-Gerät benötigt dagegen möglicherweise ausschließlich DNS, NTP und eine bestimmte Verbindung ins Internet.

Das Management-Netz darf administrative Schnittstellen erreichen, die aus normalen Client- oder IoT-Netzen nicht erreichbar sein sollen.

Damit entsteht aus einer Netzstruktur ein Regelmodell.

Erlaubte Kommunikation sollte begründet werden können

Ich halte Regeln für besonders wertvoll, wenn ich ihren Zweck auch Monate später noch erklären kann.

Ein stark vereinfachtes Beispiel:

Das ist ein anderes Denkmodell als:

VLAN 10 darf VLAN 20 erreichen.

Die zweite Regel ist bequem, aber sehr grob.

Die erste Variante beschreibt, warum Kommunikation notwendig ist.

Je genauer ich das ausdrücken kann, desto kleiner wird die unnötig freigegebene Angriffsfläche.

Default Deny ist für mich der bessere Ausgangspunkt

Bei Segmentierungsregeln arbeite ich gedanklich lieber von „nicht erlaubt“ zu „notwendig erlaubt“ als umgekehrt.

Vereinfacht:

Mein Grundprinzip ist deshalb:

Eine stateful Firewall macht dieses Modell praktikabel. Wird beispielsweise eine erlaubte Verbindung aus einem Client-Netz zu einem Server aufgebaut, kann der zugehörige Rückverkehr über den Verbindungszustand behandelt werden. Ich muss dafür nicht wahllos beide Richtungen öffnen.

Das bedeutet allerdings auch, dass ich verstehen muss, wo eine Firewall ihre Regeln auswertet und in welcher Reihenfolge sie greifen.

Bei OPNsense beispielsweise werden Regeln unter anderem interfacespezifisch verarbeitet; zusätzlich existieren Floating- und Gruppenregeln. Die Reihenfolge ist deshalb kein kosmetisches Detail.

Eine scheinbar richtige Regel an der falschen Stelle kann zu einem anderen Ergebnis führen als erwartet.

Ein Management-Netz verdient besondere Aufmerksamkeit

Ein Bereich, den ich bewusst von normalen Clients trennen würde, ist die Administration.

Management-Zugänge besitzen oft deutlich weitergehende Rechte:

Dazu zählen beispielsweise Hypervisor, Switches, Firewalls, Server-Administration, Management-Webinterfaces und Out-of-Band-Management.

Wenn jeder normale Arbeitsplatzrechner diese Schnittstellen direkt erreichen kann, vergrößert sich die Angriffsfläche unnötig.

Ein separates Management-Segment kann deshalb sinnvoll sein.

Aber auch hier gilt wieder: Das VLAN allein löst das Problem nicht.

Wenn anschließend beispielsweise das gesamte Client-Netz pauschal auf das Management-Netz zugreifen darf, existiert die Trennung nur auf dem Netzplan.

Ich möchte stattdessen definieren können:

und nicht:

Beliebige Zugriffe aller internen Geräte auf die Management-Zone sind gerade nicht das Ziel.

IoT und Gastgeräte sind ein gutes Beispiel für unterschiedliche Vertrauensniveaus

IoT-Geräte zeigen sehr anschaulich, warum ich Netze nicht nur nach Standort sortiere.

Eine smarte Steckdose und mein Administrationsrechner können physisch im selben Raum stehen. Sicherheitstechnisch gehören sie für mich trotzdem nicht in dieselbe Vertrauenszone.

Dasselbe gilt für Gäste.

Ein Gastgerät soll möglicherweise ins Internet gelangen, benötigt aber keinen Zugriff auf Server, Management-Systeme oder andere interne Clients.

Eine einfache Policy könnte daher lauten:

Bei IoT-Geräten würde ich zusätzlich genau beobachten, welche internen und externen Dienste tatsächlich benötigt werden.

Segmentierung wird damit nicht nur zu einer technischen Trennung, sondern zu einer Möglichkeit, Vertrauen bewusst zu begrenzen.

VLAN-Trunks gehören ebenfalls zum Sicherheitsmodell

Bei VLANs konzentriert sich die Diskussion schnell auf Firewall-Regeln. Die Layer-2-Konfiguration gehört aber ebenfalls dazu.

Ein Trunk transportiert mehrere VLANs über dieselbe physische Verbindung. Tagged und untagged Traffic müssen deshalb bewusst geplant werden.

Gerade bei Verbindungen zwischen Firewall und Managed Switch möchte ich eindeutig wissen:

Dabei möchte ich vier Fragen eindeutig beantworten können: Welche VLANs sind auf dem Port erlaubt? Welche Frames sind getaggt? Gibt es ein untagged beziehungsweise Native VLAN? Und wenn ja: Warum existiert es?

Eine unklare Trunk-Konfiguration kann nicht nur die Fehlersuche erschweren, sondern auch unerwartete Netzwerkpfade erzeugen.

Für mich gehört deshalb zur Segmentierung immer beides:

Erst zusammen entsteht das gewünschte Verhalten.

Segmentierung ist nicht automatisch Zero Trust

Bei Security-Themen fällt an dieser Stelle schnell der Begriff Zero Trust.

Ich würde Netzwerksegmentierung trotzdem nicht mit Zero Trust gleichsetzen.

Eine sauber segmentierte Infrastruktur kann ein wichtiger Sicherheitsbaustein sein. Zero Trust geht aber weiter: Ein System oder Benutzer erhält nicht allein deshalb Vertrauen, weil er sich in einem bestimmten internen Netz befindet.

Das ist ein wichtiger Gedanke.

Auch innerhalb eines vermeintlich vertrauenswürdigen Netzes sollte ich mich nicht darauf verlassen, dass Netzwerkposition allein ausreichende Authentisierung oder Autorisierung ersetzt.

Für mich ergänzen sich die Konzepte deshalb:

Dabei erfüllen beide Ebenen unterschiedliche Aufgaben:

• Netzwerksegmentierung begrenzt mögliche Kommunikationspfade und damit die unmittelbar erreichbare Angriffsfläche.
• Identität, Authentisierung und Autorisierung entscheiden darüber, ob ein Zugriff auf die eigentliche Ressource zulässig ist.

Ein VLAN kann also Teil einer Sicherheitsarchitektur sein. Es ist aber kein Ersatz für Zugriffskontrolle auf Anwendungsebene.

Mehr VLANs bedeuten nicht automatisch mehr Sicherheit

Auch Segmentierung kann übertrieben werden.

Wenn ich für nahezu jeden einzelnen Dienst ein eigenes VLAN anlege, wächst die Anzahl der Netze, Regeln, Ausnahmen und Abhängigkeiten schnell.

Dann entsteht ein neues Risiko: Niemand versteht das Regelwerk mehr vollständig.

Eine Änderung führt zur nächsten Ausnahme, temporäre Freigaben bleiben bestehen und irgendwann weiß niemand mehr sicher, warum eine Regel überhaupt existiert.

Deshalb bevorzuge ich wenige, nachvollziehbare Sicherheitszonen gegenüber einer möglichst großen VLAN-Anzahl.

Eine gute Segmentierung kann ich dokumentieren.

Ich kann erklären:

Für jede Zone möchte ich deshalb beantworten können, warum sie existiert, welche Systeme hineingehören, welche anderen Zonen sie erreichen darf, welche Dienste dafür erforderlich sind und welche Ausnahmen es gibt.

Wenn diese Fragen nicht mehr beantwortbar sind, ist die Architektur für meinen Geschmack zu komplex geworden.

Docker-Netzwerke sind eine weitere Ebene

Bei containerisierten Systemen kommt noch eine zusätzliche Netzebene hinzu.

Docker-Netzwerke können Container voneinander trennen und Kommunikationsbeziehungen strukturieren. Ich würde sie aber nicht einfach mit klassischen VLAN-Sicherheitszonen gleichsetzen.

Ein Host kann beispielsweise gleichzeitig Teil eines Server-VLANs sein und intern mehrere Docker-Netze besitzen:

Damit existieren mehrere Ebenen von Segmentierung.

Welche Sicherheitsgrenze tatsächlich wirksam ist, hängt dann unter anderem von Routing, veröffentlichten Ports, Host-Firewall, Docker-Regeln und der konkreten Container-Netzarchitektur ab.

Das ist umfangreich genug für einen eigenen Artikel. Für die klassische Netzwerksegmentierung reicht mir an dieser Stelle die Erkenntnis:

Nicht jede logische Netztrennung besitzt automatisch dieselben Sicherheitseigenschaften.

Wie ich Segmentierung überprüfe

Nach dem Aufbau einer Segmentierung würde ich nicht nur testen, was funktionieren soll.

Mindestens genauso wichtig ist für mich der Gegenbeweis.

Wenn Clients den Webserver auf TCP 443 erreichen dürfen, teste ich diese Verbindung.

Danach teste ich aber auch beispielsweise:

• Client zu Management: muss scheitern
• IoT zu Servernetz: muss scheitern
• Gast zu internen Netzen: muss scheitern

Eine Firewallregel, die auf dem Bildschirm plausibel aussieht, ist noch kein Nachweis dafür, dass der tatsächliche Netzwerkpfad korrekt eingeschränkt ist.

Zusätzlich helfen Firewall-Logs und Regelzähler dabei, unerwartete Kommunikation zu erkennen.

Dabei interessiert mich nicht nur:

Was wurde blockiert?

Sondern auch:

Welche Freigabe wird überhaupt noch benutzt?

Eine alte Allow-Regel ohne nachvollziehbaren Zweck ist für mich ein guter Kandidat für eine Überprüfung.

Dokumentation gehört zur Sicherheitsfunktion

Bei Segmentierung ist Dokumentation für mich keine nachträgliche Fleißarbeit.

Sie ist Teil der Sicherheitsarchitektur.

Zu einer Zone möchte ich mindestens festhalten:

Dazu gehören mindestens Name und Zweck, Subnetz/VLAN, die enthaltenen Systemgruppen, erlaubte Kommunikationsziele, benötigte Dienste und besondere Ausnahmen.

Noch wichtiger ist die Begründung der Ausnahmen.

Eine Regel mit der Beschreibung:

allow server access

hilft später wenig.

Eine Beschreibung wie:

Clients zum internen DNS-Resolver, TCP/UDP 53

ist wesentlich aussagekräftiger.

Das zahlt sich spätestens bei Fehlersuche, Änderungen oder einer Sicherheitsanalyse aus.

Mein Fazit

Netzwerksegmentierung beginnt für mich nicht mit der Frage, welche VLAN-ID ich einem Switchport gebe.

Sie beginnt mit der Frage:

Welche Systeme müssen tatsächlich miteinander sprechen?

VLANs liefern dafür eine wichtige technische Grundlage. Sie trennen Layer-2-Netze und ermöglichen es, Kommunikation über kontrollierbare Routing-Punkte zu führen.

Die eigentliche Sicherheitswirkung entsteht aber erst durch die Policy dazwischen.

Ich möchte deshalb nicht möglichst viele Netze bauen. Ich möchte wenige, nachvollziehbare Sicherheitszonen mit klar begründeten Kommunikationswegen.

Das führt für mich zu einer einfachen Kette:

Ein VLAN ist dabei ein Werkzeug.

Zur Sicherheitsgrenze wird es erst dann, wenn ich den Verkehr über diese Grenze bewusst kontrolliere.