Angenommen, Ihr Webserver wird morgen kompromittiert. Welche anderen Geräte erreicht er dann? Diese Frage entscheidet mit darüber, ob ein Vorfall auf einen Dienst begrenzt bleibt oder weitere Teile des Unternehmens gefährdet. Ein Patch schützt vor einer bekannten Lücke. Eine gut geplante Netzwerkarchitektur begrenzt zusätzlich die möglichen Folgen.
Unser Beispiel ist ein fiktives Kundenportal: Menschen melden sich an, sehen Aufträge und laden Dokumente herunter. Die Anwendung benötigt einen definierten Datenbankzugang. Sie braucht deshalb noch keinen Zugriff auf die Verwaltung des NAS, den Sicherungsserver oder den Virtualisierungshost. Genau diese Unterscheidung muss technisch wirksam werden.
Ein kompromittierter Dienst nutzt die vorhandenen Wege
Eine Sicherheitslücke kann es ermöglichen, dass fremder Code mit den Rechten der Webanwendung läuft. Was danach möglich ist, hängt unter anderem von Netzwerkregeln, Dienstkonten, gespeicherten Zugangsdaten und weiteren Schwachstellen ab. Erreichbarkeit bedeutet noch keinen erfolgreichen Zugriff. Ein kompromittierter Webserver übernimmt auch nicht automatisch das gesamte LAN.
Problematisch wird es, wenn erreichbare interne Dienste und zu weit gefasste Berechtigungen zusammenkommen. Der Angreifer muss dann weniger Grenzen überwinden. Diese mögliche Ausbreitung zu weiteren Systemen wird als laterale Bewegung bezeichnet. Für die Planung ist daher sinnvoll, eine bereits kompromittierte Anwendung als Ausgangslage anzunehmen.
Netz A: Das Portal steht im flachen Firmennetz
Im ersten Aufbau laufen Portal, Datenbank, Dateispeicher und Verwaltungsoberflächen in einem gemeinsamen Netz. Die Internetfirewall beschränkt zwar eingehende Verbindungen. Zwischen den internen Systemen gibt es aber breite Freigaben oder keine ausreichend wirksame Trennung. Aus Sicht des Webservers sind dadurch deutlich mehr Ziele erreichbar, als seine Aufgabe verlangt.
Ein gemeinsam genutztes Administratorkonto verschärft die Situation. Dasselbe gilt für ein eingebundenes Sicherungsverzeichnis mit Schreibrechten oder im Anwendungsverzeichnis abgelegte weitreichende Zugangsdaten. Ein funktionierendes Backup hilft wenig, wenn der kompromittierte Dienst auch dessen Verwaltung oder sämtliche Sicherungskopien verändern darf.
Netz B: Zonen und Regeln begrenzen die Verbindungen
Im zweiten Aufbau erreicht das Internet zunächst einen definierten Frontend- oder Reverse-Proxy-Dienst. Dieser darf die benötigte Anwendung in einem eigenen Websegment ansprechen. Die Anwendung erhält ausschließlich die erforderliche Verbindung zum festgelegten Datenbankziel. Verwaltung, Sicherungssysteme und weitere interne Dienste liegen in getrennten Zonen; unnötige Zugänge aus dem Websegment werden blockiert.
Ein VLAN schafft eine logische Netzaufteilung. Ob daraus eine wirksame Sicherheitsgrenze wird, entscheidet die Kontrolle der Verbindungen. Zu großzügiges Inter-VLAN-Routing verbindet getrennte Netze wieder weitgehend miteinander. Auch innerhalb eines VLANs kann zusätzliche Filterung zwischen einzelnen Workloads notwendig sein.
OPNsense oder Sophos Firewall sind mögliche Plattformen für passende Regeln; ebenso kommen andere geeignete Produkte infrage. Entscheidend sind konkrete Quellen, Ziele, Dienste, Zuständigkeiten und eine überprüfte Umsetzung. Die Bedienung und verfügbaren Funktionen unterscheiden sich je Plattform. Ein Produktname allein beschreibt keine geprüfte Sicherheitsarchitektur.
Reverse-Proxy und WAF bleiben Teil des Schutzes
Ein Reverse-Proxy kann öffentliche Zugänge bündeln, TLS-Verbindungen behandeln und Anfragen gezielt an Backends weiterleiten. HAProxy unterstützt dafür unter anderem HTTP- und TCP-Betriebsarten. Daraus folgt keine allgemeine Proxy-Funktion für beliebige Protokolle. Eine vorgeschaltete Web Application Firewall kann bestimmte schädliche Webanfragen erkennen und abweisen.
Diese Komponenten ersetzen weder sichere Anwendungen noch zeitnahe Updates und restriktive Backend-Zugriffe. Fehlerhafte Regeln oder ein anderer erreichbarer Zugang können Schutzmaßnahmen umgehen. Im Beispiel darf daher auch eine hinter dem Proxy kompromittierte Anwendung nur ihre ausdrücklich benötigten Ziele erreichen.
Ausgehend und seitlich denken
Die entscheidende Frage lautet nicht nur: Wer darf zum Webserver? Ebenso wichtig ist: Wohin darf er selbst Verbindungen aufbauen? Darf er den Verwaltungszugang des NAS erreichen? Muss er beliebige Internetziele kontaktieren? Welche internen Dienste benötigen andere Container tatsächlich?
Für ausgehenden Verkehr, also Egress, gehören unter anderem Namensauflösung, Zeitabgleich, Updates und externe Schnittstellen in die Planung. Notwendige Ziele werden gezielt freigegeben. Kommunikation zwischen internen Systemen, oft als East-West-Traffic bezeichnet, braucht ebenfalls nachvollziehbare Regeln. Auch IPv6 und alternative Routen müssen dieselbe beabsichtigte Trennung einhalten.
Ein Verbindungsplan hält Quelle, Ziel, benötigten Dienst, Zweck und Verantwortlichen fest. Anschließend werden erlaubte und gesperrte Wege kontrolliert getestet. Protokolle und Monitoring sollen sowohl unerwartete erfolgreiche Verbindungen als auch auffällige blockierte Versuche erkennbar machen. Eine Regel ohne überprüfte Wirkung ist noch kein belastbarer Nachweis.
VM und Container brauchen jeweils passende Grenzen
Eine virtuelle Maschine besitzt ein eigenes Gastbetriebssystem; Container teilen sich typischerweise den Kernel ihres Hosts. Beide Modelle benötigen eine passende Netz- und Rechtekonfiguration. Proxmox VE bietet Firewall-Regeln für Hosts und Gäste. Welche Ebenen und Funktionen wirksam sind, hängt auch vom eingesetzten Firewall-Backend und der konkreten Aktivierung ab.
Bei Docker können Container desselben Bridge-Netzes miteinander kommunizieren. Ausgehende Verbindungen sind nicht automatisch auf öffentliche Ziele beschränkt. Veröffentlichte Ports können zusätzliche Zugänge schaffen. Im Host-Netzwerkmodus teilen Container den Netzwerk-Namensraum des Hosts; eine eigene Netzwerkisolation besteht dort nicht.
Zusätzliche Privilegien, unnötige Host-Mounts und Zugriff auf den Docker-Socket können die Folgen eines Vorfalls erheblich erweitern. Getrennte Anwendungsnetze, minimale Rechte, passende Host-Firewall-Regeln sowie kontrollierte DNS- und Egress-Wege gehören deshalb zusammen. Auch hier entscheidet die tatsächlich wirksame Konfiguration.
Ein überschaubarer Einstieg für kleinere Unternehmen
- Dienste erfassen: öffentliche Anwendungen, Abhängigkeiten und zuständige Personen dokumentieren.
- Zonen festlegen: öffentliche Workloads, Daten, Verwaltung und Sicherungen nach Schutzbedarf trennen.
- Verbindungen begründen: nur definierte Quellen, Ziele und Dienste freigeben; sonst blockieren, wo betrieblich sinnvoll.
- Verwaltung absichern: vertrauenswürdige Zugangswege, geeignete VPN- und MFA-Verfahren sowie getrennte Konten verwenden.
- Betrieb einbeziehen: Updates, zentrale Protokolle, Alarmierung und unabhängig geschützte Backups mit getesteter Wiederherstellung vorsehen.
- Wirkung nachweisen: Regeln regelmäßig prüfen, Ausnahmen befristen und nach Änderungen erneut testen.
Änderungen brauchen Vorbereitung, ein geeignetes Wartungsfenster und einen Rückweg. Eine pauschale Sperre kann berechtigte Anwendungen oder den eigenen Verwaltungszugang unterbrechen. Deshalb zuerst Abhängigkeiten erfassen, dann kontrolliert umstellen und die fachliche Funktion gemeinsam mit den Verantwortlichen abnehmen.
Wenn eine Anwendung fällt, muss das Netz dahinter nicht mitfallen
Die PHP2Shell-Beiträge zur Reaktion auf PHP-Sicherheitslücken und zur Bestandsaufnahme mit AI-Unterstützung liefern den aktuellen Anlass. Die ergänzende Prüfung von NAS, Docker und öffentlichen Diensten führt zur dauerhaften Architekturfrage: Welche Verbindungen und Rechte sind für den jeweiligen Dienst wirklich notwendig?
DAXS unterstützt bei Bestandsaufnahme, Kommunikationsplan, Umsetzung und überprüfbarem Betrieb. Ob die Anwendung lokal, in einer Private Cloud oder auf einer öffentlichen Cloud-Plattform läuft: Die Schutzgrenzen müssen zum tatsächlichen Bedarf passen. Besprechen wir Ihre konkrete Umgebung.
Quellen: OPNsense: Regeln und zustandsbehaftete Filterung · Sophos Firewall: Zonen, Regeln und Protokollierung · HAProxy: HTTP- und TCP-Betriebsarten · Docker: Bridge-Netzwerke · Docker: Host-Netzwerkmodus · Docker: Daemon, Rechte und Sicherheitsgrenzen · Proxmox VE: Firewall-Dokumentation · NCSC: Ausbreitung begrenzen, Verwaltung und Backups schützen.