Der Internetzugriff funktioniert, der Mailserver synchronisiert und der Blog ist erreichbar. Trotzdem zählt eine neue Firewall-Regel plötzlich weit über tausend blockierte Verbindungen. Genau dieser Moment wurde bei unserer Firewall-Umstellung besonders interessant: Was versucht da eigentlich, nach draussen zu gelangen?
Bei einer Firewall-Umstellung haben wir die benötigten Verbindungen schrittweise geprüft. Dabei ging es um Netztrennung, ausgehenden Verkehr und den Erhalt bestehender Funktionen. Die aufschlussreichste Fehlersuche führte bis in einen eingebetteten Kubernetes-Dienst innerhalb eines Containers. Der Beitrag konzentriert sich auf das Diagnoseverfahren statt auf eine Abbildung unserer aktiven Regelbasis.
Die Verbindung zwischen Webserver, Namensauflösung und Netzumstellung beschreibt der Beitrag Wie unser Technikblog online ging. Hier geht es um die genauere Prüfung benötigter Verbindungen bei einer Firewall-Zusammenlegung.
Die Aufgaben der alten Firewall übernehmen
Bei einer Firewall-Zusammenlegung können interne Dienste, drahtlose Zugänge und öffentliche Anwendungen betroffen sein. Diese Aufgaben müssen auch nach der Zusammenlegung getrennt und mit passenden Zugriffsregeln betrieben werden.
Das Umstecken der Kabel ist dabei nur ein Teil der Arbeit. Jeder Netzbereich braucht passende Adressen, seinen vorgesehenen Verbindungsweg und nachvollziehbare Regeln. Der Austausch eines Geräts darf die gewünschte Trennung nicht unbeabsichtigt aufheben.
Bei dieser Zusammenlegung wollten wir bestehende Funktionen erhalten und die Regeln verständlicher machen. Alte Freigaben ungeprüft zu übernehmen hätte die Unklarheiten lediglich auf das neue Gerät verschoben. Deshalb verglichen wir Konfigurationsexporte, prüften die benötigten Zugänge und entfernten später zwei bereits deaktivierte Altregeln. Ein Vergleich bestätigte, dass der übrige Konfigurationsstand dabei unverändert geblieben war.
Derselbe öffentliche Name kann intern einen anderen Weg nehmen
Nach einer Umstellung genügt der erfolgreiche Aufruf einer Website von aussen noch nicht. Ein internes Gerät kann denselben Domainnamen verwenden und damit zunächst ebenfalls an der öffentlichen Adresse landen. Damit die Firewall diese Verbindung wieder zum eigenen Dienst führt, braucht es einen passenden Rückweg über NAT-Loopback.
Bei der Prüfung zeigte sich, dass ein normaler Domainname je nach Ausgangsnetz einen anderen Weg nehmen kann. Die Kontrolle muss deshalb Namensauflösung, Adressübersetzung und die anschliessende Zugriffsentscheidung zusammen betrachten.
Entscheidend war die Zieladresse nach der Übersetzung. In den Firewall-Logs war zu sehen, welches interne System tatsächlich erreicht werden sollte und welche Regel die Verbindung sperrte. So konnten wir die erforderliche Ausnahme setzen und die übrige Trennung zwischen WLAN und internem Netz erhalten. Anschliessend funktionierten die geprüften Zugänge wieder über ihre normalen Namen.
Auch die Verwaltung der Firewall begrenzen
Die Firewall selbst braucht ebenfalls Schutz. Nicht benötigte Verwaltungsdienste sollten deaktiviert werden. Für die Überwachung bietet SNMPv3 Authentifizierung und Verschlüsselung; ältere Abfrageverfahren sollten nicht ohne begründeten Bedarf parallel weiterlaufen.
Monitoringzugriffe sollten auf die vorgesehenen Quellen und notwendigen Rechte begrenzt werden. Nach einer Anpassung muss eine reale Abfrage bestätigen, dass die benötigten Daten weiterhin ankommen. Schutzprofile und Zonenzuordnung gehören als getrennte Punkte in die Konfigurationsprüfung.
Solche Einstellungen brauchen einen Funktionsvergleich. Ein Häkchen in der Verwaltung sagt wenig darüber aus, ob das Monitoring nach der Änderung noch lesen kann. Eine erfolgreiche Abfrage wiederum belegt keinen vollständigen Schutz gegen Angriffe. Für diese Arbeit war das Ziel konkret: Verwaltungsflächen reduzieren und den vorgesehenen Überwachungsweg erhalten.
Ausgehende Verbindungen nach Aufgaben einschränken
Danach nahmen wir den Verkehr ins Internet in Angriff. Ein Update-Server, ein Identitätsdienst und eine Linux-Containerumgebung haben unterschiedliche Aufgaben. Daraus ergeben sich unterschiedliche erlaubte Verbindungen.
Wir begannen mit einzelnen Systemen und erfassten deren tatsächlich benötigte Verbindungen. Protokoll, Ziel und Verwendungszweck müssen zusammen betrachtet werden. Eine Freigabe sollte aus einer belegten Abhängigkeit entstehen und nach ihrer Aktivierung praktisch geprüft werden.
Protokollbegrenzung und Zielbegrenzung sind unterschiedliche Härtungsschritte. Bei Cloud-Diensten und wechselnden Downloadadressen kann die Zielpflege aufwendig sein. Diese Abhängigkeiten gehören in die Planung und in einen wiederholbaren Funktionstest.
Die Regelreihenfolge war dabei besonders wichtig. Benötigte gezielte Freigaben müssen vor einer allgemeineren Sperre wirksam werden können. Welche Regel eine Verbindung tatsächlich trifft, muss anhand der konkreten Verarbeitung geprüft werden.
Neue Regeln erfassten wir zuerst inaktiv und kontrollierten sie vor der Aktivierung. Das Logging muss anschliessend eine sinnvolle Auswertung erlauben: Quelle, Ziel, Protokoll und die getroffene Regel helfen, benötigte und unerwartete Verbindungen auseinanderzuhalten.
Ein Sperrzähler führte zu Rancher
Die ersten Funktionstests gelangen, während bei einem Containerhost ein Sperrzähler deutlich anstieg. In den zentralen Logs fanden wir wiederholte DNS-Anfragen an einen öffentlichen Resolver. Der Host und die zunächst untersuchten Container waren dagegen für interne Resolver konfiguriert.
Zunächst passte das nicht zum bekannten Aufbau. Der Linux-Host verwendete unsere internen DNS-Server. Auch die Resolver-Dateien der auslesbaren Docker-Container verwiesen auf diese Server. Trotzdem verliessen die Anfragen den Host.
Ein Paketmitschnitt zeigte den Weg vor und nach der Adressübersetzung. Die Quelle war ein Container im Docker-Netz. Über dessen Adresse konnten wir ihn Rancher zuordnen. Innerhalb dieses Containers läuft ein eigener kleiner Kubernetes-Cluster für die Verwaltung. Dessen DNS-Dienst CoreDNS leitete Anfragen an öffentliche Google-Resolver weiter. In seinen Logs fanden wir sogar fehlgeschlagene Versuche, den internen Rancher-Namen dort aufzulösen.
Damit war auch klar, weshalb die bisherige Prüfung der Docker-Resolver nicht ausgereicht hatte. Innerhalb des Containers gab es eine weitere Ebene mit einer eigenen DNS-Konfiguration. Die Firewall sah am Ende die übersetzte Adresse des Linux-Hosts. Erst der lokale Mitschnitt und die CoreDNS-Logs verbanden diese Beobachtungen miteinander.
Wir stellten die Weiterleitung auf unsere internen DNS-Server um. Nach dem automatischen Neuladen löste ein kurzlebiger Test-Pod sowohl den internen Rancher-Namen als auch einen externen Namen erfolgreich auf. Im anschliessenden Mitschnitt verschwanden die Anfragen an Google-DNS; auch die betrachtete Graylog-Suche blieb danach leer.
Für die dauerhafte Anpassung legten wir eine eigene CoreDNS-Erweiterung im persistent gespeicherten K3s-Verzeichnis ab. K3s las sie automatisch ein. Anschliessend wiederholten wir die Auflösungstests. Der vorgesehene Anpassungsweg ist in der K3s-Dokumentation zu DNS und eigenen Erweiterungen beschrieben. Die Prüfung nach einem späteren Neustart oder Upgrade gehört zur nächsten Wartung.
Den zweiten Internetanschluss gezielt verwenden
Ein zweiter Internetzugang kann als Ersatzweg für einen festgelegten Bedarf dienen. Im Test verwendeten wir eine begrenzte Gerätegruppe und einen Routingpfad mit aktiver Hauptleitung und passiver Ersatzleitung.
Bei einem solchen Aufbau muss die Routingentscheidung interne und externe Ziele unterscheiden. Ein Ersatzweg für Internetverkehr darf interne Verbindungen nicht unbeabsichtigt umlenken. Routing und Firewallfreigabe sind dabei getrennt zu prüfen.
Danach kam der praktische Test: Wir trennten das Kabel des Hauptanschlusses. Auf dem Testgerät wechselte die angezeigte öffentliche Adresse auf die Ersatzleitung. Nach Wiederanschliessen der Hauptleitung zeigte eine neue Verbindung wieder deren Adresse. Damit waren Umschaltung und Rückkehr für diesen Test nachgewiesen.
Eine neue Verbindung war für die Rückprüfung wichtig. Bestehende Sitzungen können einen anderen Verlauf nehmen, und beim Wechsel der öffentlichen Adresse können Anmeldungen oder Verbindungen abbrechen. Auch die DNS-Auflösung nach Ablauf vorhandener Cacheeinträge ist für einen längeren Ausfall zu prüfen. Der Kabeltest beantwortet zunächst, ob das getestete Gerät auf die Ersatzleitung wechseln und wieder zurückkehren kann.
Ergebnisse und Prüfgrenzen festhalten
Die geprüften Zugänge funktionierten nach der Umstellung. Auch Umschaltung und Rückkehr beim Ausfalltest waren für das getestete Gerät nachgewiesen. Solche Ergebnisse gehören mit ihrem konkreten Umfang in den Änderungsnachweis.
Unerklärte Verbindungen sind ein Anlass für weitere Diagnose. Aus einem erfolgreichen Webaufruf lässt sich nicht ableiten, dass alle Funktionen einer Anwendung arbeiten. Eine vorschnelle zusätzliche Freigabe kann die eigentliche Ursache verdecken.
Am meisten gelernt haben wir an den blockierten DNS-Anfragen. Die Härtung machte eine bisher verdeckte Abhängigkeit sichtbar. Mit Zähler, zentralen Logs, lokalem Mitschnitt und einem Test aus der Anwendung konnten wir sie bis zur Ursache verfolgen und dort korrigieren. Diese nachvollziehbare Kette hilft uns auch beim nächsten System, dessen ausgehende Verbindungen wir einschränken.