Zugriff zwischen zwei per VPN verbundenen Standorten begrenzen

Ein Site-to-Site-Tunnel beantwortet eine Frage, ob die beiden Standorte Pakete austauschen können, und lässt die wichtige offen: Welches Filialgerät darf welchen zentralen Dienst erreichen. Den Tunnel als gegenseitiges Vertrauen zu behandeln, führt dazu, dass ein Gast-Laptop auf demselben Weg landet wie der Finanzserver. Die Lösung ist kein besserer Tunnel, sondern eine ausdrückliche Erlaubnisliste, die nach der Entschlüsselung durchgesetzt wird. Dieses Runbook führt diese Liste von der Definition bis zur nachgewiesenen Ablehnung.

Arbeiten Sie in dieser Reihenfolge und erweitern Sie die Tunnelroute nicht, bevor die Richtlinienschritte unten bestehen.

Schreiben Sie die Matrix, bevor Sie das Gateway anfassen

Eine brauchbare Zeile nennt drei Dinge: eine Quellgruppe, einen Zielhost oder ein Dienstnetz sowie das Protokoll und den Port, die die Anwendung tatsächlich nutzt. Die Filiale und das Rechenzentrum sind keine Einträge. Private DNS- und Authentifizierungsdienste verdienen eigene Zeilen nur dann, wenn die Anwendung ohne sie nicht arbeiten kann.

Gruppieren Sie Quellen nach Rolle statt nach Subnetz-Bequemlichkeit: Mitarbeiter, Gäste, Administration. Wenn alle drei ein flaches LAN teilen, kann das Gateway sie auf der Netzwerkschicht nicht unterscheiden, also müssen Identitätskontrollen oder Segmentierung zuerst kommen. Halten Sie die Matrix dann schriftlich fest, mit einem Verantwortlichen und einem Prüfdatum in jeder Zeile.

Setzen Sie durch, wo die Pakete entschlüsselt werden

Die Regeln, die IKE und ESP erlauben, bauen nur den äußeren Tunnel auf. Der innere Verkehr kommt im Klartext auf der Tunnelschnittstelle an, und dort gehört die Erlaubnisliste hin: eine Weiterleitungskette auf dem entschlüsselnden Gerät, Standard-Drop, eine Regel pro Matrixzeile. Auf Linux-Gateways bedeutet das aktivierte Weiterleitung und Filterregeln auf dem Tunnelgerät, nicht auf dem physischen Uplink, wie strongSwan-Leitfaden zur Weiterleitung erläutert.

Traffic-Selektoren sind eine Routing-Entscheidung, keine Autorisierung. Ein weiter Selektor, der beide Subnetze abdeckt, kann für das Routing richtig sein, während die Firewall weiterhin nur TCP 443 zu einem Host erlaubt. Der Selektor wird für den Tunnel ausgehandelt und beschreibt, was in ihn eintreten darf, nicht was ein bestimmtes Gerät nutzen darf. Erweitern Sie niemals eine Firewallregel, weil der Selektor weit ist.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT und überlappende Subnetze ändern die Regeln

Wenn das Filial-Gateway jeden Host vor dem Tunnel auf eine einzige Adresse übersetzt, fallen alle quellbasierten Zeilen in dieser einen Adresse zusammen. Übersetzen Sie den Tunnelverkehr entweder nicht mehr, oder akzeptieren Sie, dass Regeln auf etwas anderem beruhen müssen, etwa der ursprünglichen Quelladresse, die vor der Übersetzung erfasst wurde. Die Gegenseite hat dasselbe Problem, weil der Zielhost die Adresse nach dem NAT sieht und nicht die ursprüngliche.

Überlappende Bereiche sind die andere Falle. Zwei Standorte, die beide 192.168.1.0/24 nutzen, lassen sich nicht in einer Richtlinientabelle beschreiben, ohne eine Seite abzubilden, und eine Abbildung ersetzt keine Adressierung, die nicht kollidiert. Korrigieren Sie den Plan, bevor Sie Regeln schreiben, die Sie später wieder auflösen müssen.

Weisen Sie eine Ablehnung nach, nicht nur einen Erfolg

Nur die erlaubte Anwendung zu testen beweist sehr wenig, denn eine freizügige Regel irgendwo weiter oben liefert dasselbe Ergebnis.

Erreichen Sie von einem gewöhnlichen Filialgerät den vorgesehenen Dienst und bestätigen Sie, dass die ganze Sitzung funktioniert. Versuchen Sie dann ein Ziel, das geschlossen bleiben muss, etwa einen administrativen Port auf einem Server, mit dem die Filiale nichts zu tun hat, und lesen Sie den Zähler oder Logeintrag, der es verworfen hat. Das Regelset abzuschalten, um zu prüfen, ob es funktioniert, macht den Test ungültig und lässt das Gateway offen, während Sie nachsehen.

Halten Sie die Liste lebendig

Anwendungen ziehen um, und eine Regel, die ihre Anwendung überlebt, wird zu einem Loch, das niemand besitzt. Hängen Sie das Prüfdatum an die Zeile und ändern Sie den Selektorbereich und die Firewallregel im selben Wartungsschritt, wenn ein Dienst die Adresse wechselt.

Beschränkungen auf Host-Ebene zählen auch hinter dem Tunnel: Die eigene Firewall des Servers sollte den Filialbereich nur für den Dienst annehmen, den sie veröffentlicht. Zwei Ebenen, die übereinstimmen, sind leichter zu prüfen als eine Ebene, der vollständig vertraut wird.