Netzsegmentierung und Firewallregeln: Warum flache Servernetze zum Risiko werden

Die meisten Serverlandschaften wachsen organisch. Ein Webserver kommt dazu, eine Datenbank, ein Build-Runner, ein Monitoring-System. Alle laufen im selben Netz, alle erreichen sich gegenseitig, und niemand hat je entschieden, dass das so sein soll. Es hat sich einfach ergeben. Dieser Beitrag beschreibt, warum das ein Problem ist und wie ein Segmentierungskonzept aussieht, das im Alltag auch durchhaltbar bleibt.

Das Problem mit flachen Netzen

In einem flachen Netz entscheidet der schwächste Dienst über das Sicherheitsniveau aller anderen. Wird eine veraltete Webanwendung kompromittiert, steht der Angreifer nicht vor der nächsten Hürde, sondern in einem Netz, in dem er die Datenbank, das Backup-Ziel und das Monitoring direkt erreichen kann. Die eigentliche Schwachstelle war vielleicht klein. Der Schaden ist es nicht.

Dieses seitliche Weiterbewegen im Netz, oft als Lateral Movement bezeichnet, ist in der Praxis der teuerste Teil eines Vorfalls. Der initiale Einbruch lässt sich selten ganz verhindern. Das realistische Ziel ist nicht, jeden Einbruch auszuschließen, sondern seinen Radius klein zu halten. Genau dafür ist Segmentierung da.

Ein zweiter Effekt kommt hinzu: In einem flachen Netz weiß niemand mehr, welcher Dienst eigentlich mit welchem spricht. Jede Änderung wird zum Risiko, weil Abhängigkeiten unsichtbar sind. Segmentierung zwingt dazu, diese Abhängigkeiten aufzuschreiben.

Segmentieren nach Funktion, nicht nach Zufall

Der sinnvolle Schnitt verläuft entlang der Vertrauensgrenzen, nicht entlang der Hardware. Ein pragmatischer Einstieg für typische Anwendungslandschaften sieht so aus:

• Ein Segment für alles, was direkt aus dem Internet erreichbar ist: Reverse Proxy, Loadbalancer, Mailgateway.
• Ein Segment für Anwendungsserver, die nur vom Proxy angesprochen werden.
• Ein Segment für Datenhaltung: Datenbanken, Caches, Objektspeicher.
• Ein getrenntes Segment für Management und Monitoring, inklusive Sprungserver.
• Ein eigenes Segment für Backup-Systeme, das von produktiven Systemen nicht beschreibbar ist.

Entscheidend ist die Richtung der Verbindungen. Der Anwendungsserver darf die Datenbank erreichen, die Datenbank hat keinen Grund, Verbindungen in Richtung Anwendungsserver oder ins Internet aufzubauen. Wer ausgehenden Verkehr aus den inneren Segmenten einschränkt, nimmt Angreifern eine wichtige Fähigkeit: Daten unauffällig abfließen zu lassen oder Nachladecode zu holen.

Das Backup-Segment verdient besondere Aufmerksamkeit. Wenn der produktive Server seine Sicherungen selbst löschen oder überschreiben kann, hilft das Backup bei Ransomware nur begrenzt. Ein Pull-Modell, bei dem das Backup-System die Daten aktiv abholt, ist hier deutlich robuster als ein Push vom Produktivsystem aus.

Default Deny als Grundregel

Ein Regelwerk hat zwei mögliche Grundhaltungen: alles ist erlaubt, was nicht verboten ist, oder alles ist verboten, was nicht ausdrücklich erlaubt ist. Nur die zweite Variante ist im Serverbetrieb tragfähig. Default Deny bedeutet, dass jede Verbindung eine bewusste Entscheidung war.

Der Einwand lautet üblicherweise, das koste zu viel Zeit. In der Einführungsphase stimmt das. Danach dreht sich das Verhältnis: Ein Regelwerk mit expliziten Freigaben ist lesbar, prüfbar und lässt sich bei einer Störung schnell auswerten. Ein gewachsenes Regelwerk mit großzügigen Freigaben wird nach zwei Jahren von niemandem mehr angefasst, weil keiner weiß, was beim Entfernen einer Regel kaputtgeht.

Praktisch heißt das: Freigaben werden auf Quelle, Ziel, Port und Protokoll eingegrenzt. Nicht ein Segment zu einem anderen auf allen Ports, sondern Anwendungsserver zu Datenbankserver auf dem Datenbankport. Je genauer die Regel, desto kleiner der Nutzen eines kompromittierten Systems für den Angreifer.

Perimeter und Host-Firewall ergänzen sich

Eine zentrale Firewall am Netzübergang und eine lokale Firewall auf jedem Server sind keine Alternativen, sondern zwei Ebenen. Die zentrale Instanz regelt den Verkehr zwischen den Segmenten und macht das Gesamtbild sichtbar. Die Host-Firewall schützt den Server auch dann, wenn jemand innerhalb desselben Segments steht.

Wichtig ist, dass beide Ebenen aus derselben Quelle gepflegt werden. Wenn die Host-Regeln manuell gesetzt und nie dokumentiert werden, entsteht ein zweites, unsichtbares Regelwerk, das Fehlersuchen verlängert. Konfigurationsmanagement oder zumindest versionierte Regeldateien lösen das Problem zuverlässiger als Disziplin.

Ein weiterer häufiger Fehler: Dienste binden auf alle Netzwerkschnittstellen, obwohl sie nur lokal oder nur im internen Segment erreichbar sein müssten. Die Bindung eines Dienstes an eine bestimmte Adresse ist die billigste Form der Zugriffsbeschränkung und sollte vor jeder Firewallregel geprüft werden.

Management-Zugänge gehören nicht ins Internet

Administrative Schnittstellen sind das lohnendste Ziel: SSH, Datenbank-Oberflächen, Hypervisor-Konsolen, IPMI oder vergleichbare Out-of-Band-Zugänge. Diese Dienste gehören hinter einen definierten Zugangsweg, nicht auf eine öffentliche Adresse.

Zwei Modelle haben sich bewährt. Entweder ein Sprungserver, über den sämtliche administrativen Sitzungen laufen und protokolliert werden, oder ein VPN-Zugang, der die Administration in ein internes Segment holt. Beides reduziert die Angriffsfläche auf ein einzelnes, gut gepflegtes System.

Besonders kritisch sind Out-of-Band-Managementkarten. Sie laufen mit eigener Firmware, werden selten aktualisiert und haben vollen Zugriff auf die Hardware. Sie gehören ausnahmslos in ein eigenes, vom produktiven Verkehr getrenntes Netz.

Regelwerke altern, wenn niemand aufräumt

Firewallregeln werden angelegt, wenn etwas gebraucht wird. Entfernt werden sie fast nie. Nach einigen Jahren enthält jedes Regelwerk Freigaben für Systeme, die es nicht mehr gibt, und für Projekte, die abgeschlossen sind.

Dagegen helfen drei einfache Gewohnheiten:

1. Jede Regel bekommt einen Kommentar mit Zweck, verantwortlicher Person und Datum. Ohne diese Information ist später keine Entscheidung möglich.
2. Temporäre Freigaben bekommen ein Ablaufdatum und werden danach aktiv entfernt, nicht nur zur Prüfung vorgemerkt.
3. Ein wiederkehrender Review, zum Beispiel halbjährlich, geht das Regelwerk durch und streicht, was keinen aktuellen Zweck mehr hat.

Hilfreich ist außerdem, Treffer auf Regeln zu protokollieren. Eine Regel ohne Treffer über mehrere Monate ist ein starker Hinweis darauf, dass sie entfallen kann. Das Protokollieren verworfener Verbindungen wiederum zeigt, wo Dienste etwas versuchen, das niemand eingeplant hat.

Der Einstieg ohne Großprojekt

Eine bestehende Umgebung muss nicht in einem Schritt umgebaut werden. Sinnvoll ist diese Reihenfolge: zuerst aufnehmen, welche Dienste tatsächlich auf welchen Ports lauschen und welche Verbindungen zwischen Systemen laufen. Dann die administrativen Zugänge aus dem Internet nehmen. Danach die Datenhaltung in ein eigenes Segment ziehen, weil dort der größte Schaden entstehen kann. Erst zum Schluss die feinere Trennung der Anwendungsschichten.

Jeder dieser Schritte wirkt für sich. Wer nur die Management-Zugänge hinter einen Sprungserver legt und die Datenbanken aus dem öffentlichen Netz nimmt, hat bereits die beiden häufigsten Einfallswege geschlossen. Der Rest lässt sich im normalen Betriebsrhythmus nachziehen, am besten gekoppelt an ohnehin geplante Wartungsfenster.