M 5.83 Sichere Anbindung eines externen Netzes mit Linux FreeS/WAN
Verantwortlich für Initiierung: Administrator, Leiter IT
Verantwortlich für Umsetzung: Administrator
In vielen Institutionen besteht die Anforderung, die lokalen Netze, die an den einzelnen Standorten installiert sind, miteinander zu verbinden. Dies erfolgt in den meisten Fällen über gemietete Leitungen oder öffentliche Netze, die nicht der Kontrolle der Institution unterliegen. Hier besteht z. B. die Gefahr, dass die übertragenen Daten abgehört oder manipuliert werden oder dass sich ein Angreifer als berechtigter Kommunikationspartner ausgibt (Maskerade). Diesen Gefährdungen kann durch den Einsatz eines so genannten Virtuellen Privaten Netzes (VPN) entgegengewirkt werden. Mit Hilfe kryptographischer Verfahren können dabei die Integrität und Vertraulichkeit der Daten geschützt und die Kommunikationspartner sicher authentisiert werden. Linux FreeS/WAN ist ein freies Programmpaket für das Betriebssystem Linux, mit dessen Hilfe ein zum IPsec-Standard konformes VPN aufgebaut werden kann.
Planung
In der Planungsphase sollte als Erstes ermittelt werden, welche Anforderungen das Produkt, das für den Schutz der Kommunikationsverbindung verwendet werden soll, erfüllen muss. Hierzu gehört beispielsweise, ob es mit bestimmten bereits vorhandenen Komponenten zusammenarbeiten muss oder ob außer TCP/IP noch andere Protokolle transportiert werden müssen. Anschließend sollte die Dokumentation von FreeS/WAN durchgearbeitet und für die Entscheidung herangezogen werden, ob dieses Programmpaket für die vorliegende Aufgabenstellung geeignet ist. Wenn dies der Fall ist, sollte festgelegt und dokumentiert werden, welche Funktionalitäten von FreeS/WAN wofür genutzt werden sollen und wie es in die vorhandene Netzstruktur eingefügt werden soll.
Installation
FreeS/WAN läuft auf dem freien Betriebssystem Linux und greift in den IP-Protokollstapel des Kernels ein. Es wird empfohlen, FreeS/WAN auf nur für diesen Zweck konfigurierten PCs zu betreiben und - abgesehen von eventuell erforderlichen Routing-Funktionen - keine anderen Dienste auf diesen PCs zu aktivieren (siehe auch M 4.97 Ein Dienst pro Server). Insbesondere sollten sie keine Firewall-Funktionen wahrnehmen, sondern unabhängig vom Firewall-System sein. Für die Installation des Betriebssystems sollte auf eine Linux-Distribution zurückgegriffen werden, bei der FreeS/WAN bereits enthalten ist. Dies erleichtert die Installation erheblich, da anderenfalls in der Regel auch der Linux-Kernel neu kompiliert werden muss. Hierzu wird auf die Dokumentation von FreeS/WAN verwiesen. Weiterhin sollten von der Linux-Distribution nur die unbedingt erforderlichen Programmpakete installiert werden.
Konfiguration
FreeS/WAN implementiert eine ganze Reihe verschiedener Funktionalitäten, die in IPsec definiert sind. Durch entsprechende Konfiguration ist es daher möglich, dieses Programmpaket in vielen verschiedenen Umgebungen für unterschiedlichste Anwendungsgebiete einzusetzen. Im Folgenden wird anhand eines Beispiels erläutert, wie FreeS/WAN dazu verwendet werden kann, die Kommunikation zwischen zwei lokalen Netzen über das Internet abzusichern. Hierzu wird folgende Anordnung von Komponenten in den Netzen betrachtet:

Abbildung: Komponenten in den Netzen
Die beiden Standorte West und Ost einer Institution verfügen beide über eine Anbindung an das Internet. Auf beiden Seiten kommt dabei ein mehrstufiges Firewall-System zum Einsatz, das zur Vereinfachung jedoch in der Abbildung jeweils nur durch ein einzelnes Symbol dargestellt ist. gateway.west und gateway.ost sind IT-Systeme unter dem Betriebssystem Linux, die mit Hilfe von FreeS/WAN als Gateways für die lokalen Netze lan.west und lan.ost dienen sollen. Die Gateways haben jeweils zwei Netzwerkkarten, über die sie mit den Firewall-Systemen und den lokalen Netzen verbunden sind. Ziel ist, dass alle IT-Systeme in lan.west und lan.ost sicher miteinander kommunizieren können. Die Absicherung der Kommunikation soll für diese IT-Systeme transparent sein.
Wichtig ist die Auswahl eines geeigneten Verfahrens für das Schlüsselmanagement. Es wird empfohlen, automatischen Schlüsselaustausch über Public-Key-Verfahren (RSA) zu verwenden. Dies bietet, verglichen mit den übrigen von FreeS/WAN unterstützten Verfahren, das höchste Sicherheitsniveau. Der erste Schritt der Konfiguration besteht daher in der Erzeugung von RSA-Schlüsselpaaren für die beiden Gateways. Dies kann beispielsweise über das Kommando ipsec rsasigkey erfolgen. Die Schlüssel sollten mindestens 768 Bit lang sein. Wie in der Dokumentation vermerkt, dürfen die so erzeugten Schlüssel nur für Signaturen, nicht für Verschlüsselung verwendet werden. Innerhalb des Programmpakets FreeS/WAN ist dies gewährleistet. Die Ausgabe des Kommandos ipsec rsasigkey enthält jeweils den öffentlichen und den privaten RSA-Schlüssel. Entscheidend für die Sicherheit des VPN ist, dass der private Schlüssel auf keinen Fall kompromittiert werden darf (siehe auch M 2.46 Geeignetes Schlüsselmanagement).
Der private Schlüssel wird in der Datei /etc/ipsec.secrets auf dem Gateway abgelegt, Ownership und Permissions sind wie folgt zu setzen:
-rw------- root root /etc/ipsec.secrets
Der öffentliche Schlüssel dagegen wird in die Datei /etc/ipsec.conf eingetragen (siehe unten). In dieser Datei werden auch alle anderen Einstellungen für FreeS/WAN vorgenommen. Das Format ist so angelegt, dass auf beiden Gateways möglichst die gleiche Datei verwendet werden kann. Die Konfiguration erfolgt in mehreren Abschnitten, in denen jeweils Einstellungen in der Form Parameter = Wert vorgenommen werden. Die Parameter, die eine Unterscheidung zwischen den beiden Gateways erfordern, tragen jeweils das vorangestellte Schlüsselwort left bzw. right. Die jeweilige Instanz von FreeS/WAN erkennt anhand der IP-Adresse selbständig, welcher der beiden Parameter für sie gültig ist. In der Regel unterscheiden sich die auf den beiden Gateways gespeicherten Versionen der Datei /etc/ipsec.conf daher höchstens beim Parameter interfaces, beispielsweise weil auf einer Seite Ethernet und auf der anderen Seite Token Ring verwendet wird. Für das betrachtete Beispiel werden nachfolgend Empfehlungen zur Konfiguration in der Datei /etc/ipsec.conf vorgestellt.
Abschnitt config setup
In diesem Abschnitt werden allgemeine, nicht verbindungsspezifische Einstellungen vorgenommen.
interfaces = ipsec0=eth0
Zunächst ist mit dem Parameter interfaces festzulegen, über welche Netzschnittstellen gesicherte Verbindungen aufgebaut werden sollen. Über alle anderen Schnittstellen werden keine verschlüsselten Pakete gesendet. In dem oben dargestellten Beispiel wird die Verbindung zur Firewall jeweils durch die Schnittstelle eth0 des Gateways hergestellt.
forwardcontrol = yes
Wird der Parameter forwardcontrol auf den Wert yes gesetzt, so schaltet FreeS/WAN die Weiterleitung von IP-Paketen selbständig ein oder aus, wenn IPsec aktiviert bzw. deaktiviert wird. Dies wird empfohlen, da hierdurch verhindert wird, dass Pakete unverschlüsselt übertragen werden, wenn das VPN nicht verfügbar ist. Beim Hochfahren des Linux-Systems sollte sichergestellt sein, dass die Weiterleitung von IP-Paketen ausgeschaltet wird, bevor die Netzschnittstellen aktiviert werden. Wie diese Einstellung vorgenommen wird, hängt von der verwendeten Linux-Distribution ab.
dumpdir =
Der Parameter dumpdir sollte auf einen leeren Wert gesetzt werden, damit die Komponenten von FreeS/WAN im Falle eines Programmfehlers keine Speicherabbilder (core dumps) erzeugen. Anderenfalls besteht die Gefahr, dass Unbefugte diesen Speicherabbildern z. B. geheime Schlüssel entnehmen können.
plutoload = %search
plutostart = %search
Der Daemon pluto ist Bestandteil des Pakets FreeS/WAN und dient dem automatischen Schlüsselmanagement. Mit den Parameter plutoload und plutostart wird festgelegt, welche Verbindungen beim Start automatisch in die Datenbank von pluto geladen bzw. aktiviert werden. Es ist zweckmäßig, diese Parameter jeweils auf den speziellen Wert %search zu setzen. Dadurch werden diejenigen Verbindungen geladen bzw. aktiviert, die durch den Parameter auto entsprechend gekennzeichnet sind.
Abschnitt conn west-ost
In diesem Abschnitt werden Einstellungen vorgenommen, die speziell für eine bestimmte Verbindung, beispielsweise west-ost, gelten.
type = tunnel
Mit Hilfe des Parameters type wird der Betriebsmodus für diese Verbindung festgelegt. Da im vorliegenden Fall der Netzverkehr zwischen zwei lokalen Netzen über Gateways abgesichert werden soll, muss zwingend der Modus tunnel verwendet werden. Der Modus transport ist nur bei Host-zu-Host-Kommunikation, passthrough nur bei manuellem Schlüsselmanagement zulässig.
auto = start
Sind die Parameter plutoload bzw. plutostart auf den speziellen Wert %search gesetzt, dann legt der Parameter auto für die vorliegende Verbindung fest, ob sie beim Start automatisch in die Datenbank von pluto geladen bzw. aktiviert wird. Im Beispiel soll die Verbindung direkt aktiviert werden, daher wird der Parameter auto auf den Wert start gesetzt.
auth = esp
Der Parameter auth legt fest, mit welchem der beiden IPSEC-Funktionalitäten, Encapsulating Security Payload (ESP) oder Authentication Header (AH), die Authentisierung stattfindet. Im vorliegenden Fall kann sowohl die Verschlüsselung als auch die Authentisierung mit ESP erfolgen. Dies ist die Standardeinstellung.
authby = rsasig
Es wird empfohlen, die Authentisierung mit Hilfe von digitalen Signaturen über den RSA-Algorithmus durchzuführen (Einstellung rsasig). Dies bietet gegenüber dem Verfahren "shared secrets" (Einstellung secret) eine höhere Sicherheit und eine vereinfachte Administration.
pfs = yes
pfs steht für Perfect Forward Secrecy und bedeutet, dass Nachrichten, die in der Vergangenheit ausgetauscht wurden, selbst bei Bekanntwerden der privaten Schlüssel der beiden Gateways nicht kompromittiert werden. (Die Sicherheit zukünftiger Verbindungen kann dagegen nicht mehr gewährleistet werden.) Der Standardwert yes ist die empfohlene Einstellung für diesen Parameter.
keyingtries = 0
Der Parameter keyingtries legt die maximale Anzahl der Versuche fest, die entsprechende Verbindung aufzubauen oder zu aktualisieren. Es wird empfohlen, den speziellen Wert 0 einzustellen, d. h. die Anzahl der Versuche ist nicht begrenzt. Der voreingestellte Wert 3 für den Parameter keyingtries ist für die meisten Anwendungen unzureichend.
left = <IP-Adresse von gateway.west>
right = <IP-Adresse von gateway.ost>
Mit Hilfe der Parameter left und right werden die IP-Adressen der beiden beteiligten Gateways eingestellt. Es wird empfohlen, die IP-Adressen numerisch einzutragen und nicht auf den speziellen Wert %defaultroute zurückzugreifen. Durch Vergleich mit den IP-Adressen, die den entsprechenden Netzschnittstellen des IT-Systems zugewiesen sind, erkennt FreeS/WAN, welche von beiden Rollen (left oder right) dieses IT-System übernimmt.
leftnexthop = <IP-Adresse von firewall.west>
rightnexthop = <IP-Adresse von firewall.ost>
Als Wert für die Parameter leftnexthop und rightnexthop ist jeweils die IP-Adresse derjenigen Komponente einzutragen, die die Pakete über das unsichere Netz weiterleitet. Im vorliegenden Beispiel ist diese Komponente Bestandteil des Firewall-Systems. Je nach Segmentierung und Anordnung der aktiven Netzkomponenten im lokalen Netz ist hier jedoch in vielen Fällen der nächstliegende Router auf der Strecke zur Internet-Firewall einzutragen.
leftsubnet = <Subnetz/Maske von lan.west>
rightsubnet = <Subnetz/Maske von lan.ost>
Durch diese beiden Parameter wird festgelegt, welche beiden Subnetze gesichert miteinander kommunizieren sollen. Im vorliegenden Beispiel sind dies die lokalen Netze lan.west bzw. lan.ost. Die Werte sind in der Form Subnetz/Maske einzutragen, beispielsweise 10.10.0.0/16.
leftid = @gateway.west
rightid = @gateway.ost
Über die Parameter leftid und rightid werden Namen für die beiden Gateways vergeben, die für die Authentisierung erforderlich sind. Es wird empfohlen, die Namen in Form von DNS-Namen mit vorangestelltem "@"-Zeichen festzulegen. Hierdurch wird verhindert, dass FreeS/WAN die DNS-Namen vor der Verwendung durch eine Anfrage beim DNS-Server in IP-Adressen umwandelt.
leftrsasigkey = <öffentlicher RSA-Schlüssel von gateway.west>
rightrsasigkey = <öffentlicher RSA-Schlüssel von gateway.ost>
Mit Hilfe dieser beiden Parameter werden die öffentlichen Schlüssel der Gateways festgelegt. Die entsprechenden geheimen Schlüssel sind dagegen in die Datei /etc/ipsec.secrets auf dem jeweiligen Gateway einzutragen.
Routing
Für die Weiterleitung von IP-Paketen verwendet FreeS/WAN die Routing-Tabellen des darunter liegenden Linux. Mit Hilfe des Kommandos route müssen daher auf beiden Gateways Regeln erzeugt werden, so dass Pakete für das lokale bzw. entfernte Netz über die entsprechende Netzwerkkarte weitergeleitet werden.
Fernadministration eines Gateways
gateway.west und gateway.ost können in der vorgestellten Konfiguration nicht über das VPN kommunizieren. Der sichere Tunnel transportiert nur Daten zwischen lan.west und lan.ost. Dies ist aus Sicherheitsgründen erwünscht, es sei denn, eines der beiden Gateways soll von der jeweils anderen Seite aus administriert werden. In diesem Fall ist in der Datei ipsec.conf eine weitere Verbindung einzurichten. Diese zusätzliche Verbindung unterscheidet sich von der Verbindung west-ost dadurch, dass der Parameter leftsubnet fehlt (wenn gateway.west von lan.ost aus fernadministriert werden soll) bzw. rightsubnet fehlt (wenn gateway.ost von lan.west aus fernadministriert werden soll).
Firewall-Einstellungen
firewall.west und firewall.east sollten so konfiguriert werden, dass zwischen den beiden Gateways die verschlüsselten Nutzpakete und die erforderlichen Managementpakete ausgetauscht werden können. Im vorliegenden Beispiel sind dafür folgende Regeln erforderlich:
- IP-Pakete mit Protokollnummer 50 von gateway.west nach gateway.ost und umgekehrt sind erlaubt.
- UDP-Pakete, Port 500 von gateway.west nach gateway.ost und umgekehrt sind erlaubt.
Falls abweichend vom Beispiel für den Parameter auth der Wert ah eingestellt wurde, müssen IP-Pakete mit Protokollnummer 51 durchgelassen werden. Jede andere Kommunikation mit dem Gateway oder dem lokalen Netz muss vom jeweiligen Firewall-System unterbunden werden.
Da das Firewall-System und das Gateway getrennt voneinander realisiert sind, sollten die Parameter leftfirewall und rightfirewall, sowie leftupdown und rightupdown nicht verwendet werden.
Beim Einsatz von Network Address Translation (NAT) ist zu beachten, dass die Adressumsetzung entweder auf einer Komponente zwischen dem Gateway und dem lokalen Netz oder auf dem Gateway selbst erfolgen muss. Die Adressen können im Allgemeinen nicht innerhalb des Firewall-Systems umgesetzt werden. Grund hierfür ist, dass Teile der IP-Pakete beim Einsatz von NAT modifiziert werden, sodass die Integritätsprüfung von IPsec in der Regel fehlschlägt. NAT darf daher erst "hinter" dem IPsec-Gateway erfolgen. Falls die Adressumsetzung auf dem gleichen IT-System durchgeführt werden soll, auf dem auch FreeS/WAN betrieben wird, ist zu beachten, dass dadurch die Verarbeitung der IP-Pakete auf diesem IT-System sehr komplex wird. Hinweise hierzu finden sich in der Dokumentation von FreeS/WAN. Übersichtlicher und damit leichter zu administrieren ist es, NAT auf einer separaten Komponente zwischen dem Gateway und dem lokalen Netz vorzunehmen.
Funktionstest des VPN
Vor dem Einsatz im Wirkbetrieb sollte geprüft werden, ob das VPN wie gewünscht funktioniert. Anstelle der beiden lokalen Netze sollten während der Testphase nur Testrechner an die Gateways angeschlossen werden. Anderenfalls ist nicht auszuschließen, dass Daten aus dem Wirkbetrieb ungeschützt über das Internet gesendet werden, wenn das VPN nicht auf Anhieb korrekt funktioniert.
Geprüft werden sollte, ob die Pakete tatsächlich verschlüsselt werden. Wie in der Dokumentation beschrieben, geschieht dies am einfachsten über die Tools ping und tcpdump. Mit Hilfe von ping lassen sich leicht zu erkennende IP-Pakete erzeugen, und tcpdump kann dazu verwendet werden, den daraus von FreeS/WAN generierten Netzverkehr mitzulesen. Zu beachten ist, dass das ping-Kommando auf dem Testrechner und nicht auf dem Gateway ausgeführt werden muss. In der vorgestellten Beispiel-Konfiguration schützt das VPN nur den Verkehr zwischen den lokalen Netzen (die in der Testphase durch einen oder mehrere Testrechner ersetzt sind) und nicht den Verkehr von oder zu den Gateways. (Siehe hierzu auch den Abschnitt Fernadministration eines Gateways.) Das Kommando tcpdump zum Mitlesen des generierten Netzverkehrs kann auf einem beliebigen IT-System zwischen den beiden Gateways ausgeführt werden.
Für den Fall, dass das VPN nicht wie gewünscht funktioniert, beispielsweise dass gar keine Kommunikation möglich ist oder der Netzverkehr nicht verschlüsselt wird, bietet FreeS/WAN umfangreiche Diagnosemöglichkeiten an. Informationen über den Status des Programmpakets erhält man z. B. über den Inhalt der Pseudodatei /proc/net/ipsec_tncfg und über das Kommando ipsec look. Weitere Informationen hierzu finden sich in der Dokumentation von FreeS/WAN.
Prüffragen:
-
Sind die Eignung des Programmpaketes FreeS/WAN und die eingesetzten Funktionen auf Grundlage der Anforderungen an das VPN festgestellt und dokumentiert worden?
-
Wird das mit FreeS/WAN geplante VPN sicher installiert und konfiguriert?
-
Sind die jeweiligen Terminierungseinheiten der VPNs an geeigneter Stelle in mehrstufigen Firewall-Installationen integriert?
-
Ist sichergestellt, dass private RSA-Schlüssel auf den VPN-Terminierungseinheiten geschützt sind?
-
Einsatz von NAT: Wird die Network Address Translation (NAT) durch eine VPN-Terminierungseinheit umgesetzt?
-
Unterstützen die eingesetzten Client-Produkte eine sichere Version von SSL/TLS?