© Sophie McAulay, 123RF

Linux kommt mit verschiedenen VPN-Lösungen klar: Mit IPsec- und L2TP-VPN-Verbindungen genauso wie mit dem weitverbreiteten Open VPN. Will ein Administrator aber mehrere dieser Protokolle gleichzeitig anbieten, kann er nun auf eine Lösung zurückgreifen, die alles unter einem Dach bietet.

Softether wurde an der Universität von Tsukuba in Japan im Rahmen einer Diplomarbeit entwickelt und 2013 von Daiyuu Norobi zum freien Download bereitgestellt. Neben zwei eigenen Protokollen unterstützt die Software IPsec, L2TP, Microsofts SSTP und Open VPN. Damit sind Windows, Mac OS X, Android und I-OS als Clients abgedeckt, ohne dass der Anwender auf einem der Geräte einen extra Client installieren muss.

Im Internet stellt das Projekt [1] sich im Vergleich zu Open VPN dar und behauptet, Gigabit-Tempo zu beherrschen, was im Vergleich zu den 100 MBit/s für Open VPN eine Beschleunigung um den Faktor 10 wäre. Das bestätigte sich jedoch im Test des Linux-Magazins nicht.

Die Software steht für Linux, Mac OS X, Windows, Solaris und Free BSD bereit. Dabei gibt es Linux-Binaries für x86 (32 und 64 Bit), ARM, MIPS, Power PC sowie SH-4. Bei Solaris lassen sich Sparc- oder Intel-CPUs mit 32 und 64 Bit verwenden. Mac OS X unterstützt die Software in allen CPU-Architekturen seit dem G4. Free BSD sowie Windows sind nur auf Intel-CPUs möglich.

Wenn an beiden Enden der Verbindung die Softether-Software im Einsatz ist und die konfigurierten Ports zum Beispiel aus Sicherheitserwägungen gesperrt sein sollten, dann weicht die Software automatisch auf Port 53 beziehungsweise ICMP (Ping-Pakete) aus, um den verschlüsselten Payload zu übertragen.

Zum Aufbau einer VPN-Verbindung gehört auch die Authentisierung. Dabei unterstützt Softether sowohl Preshared Keys als auch eine Zertifikat-basierte Anmeldung. Client-seitig (für Remote-Access-VPNs) kommen sogar Smartcards in Frage. Neben einer eigenen Benutzerdatenbank kann der Softether-Server auf Active Directory oder Radius zugreifen.

Die Projektseite bietet Links zu Downloads an. Abgesehen von der Windows-Version erhält der Anwender ein komprimiertes Tar-Archiv, das Bibliotheken und ein passendes Makefile enthält.

Eine einfache Installation

Zur Installation ist bei allen Unix-Derivaten eine GCC-Entwicklungsumgebung notwendig. Nach dem Aufruf von »make« entstehen zwei Binaries: »vpncmd« , der Kommandozeilenclient, und – je nach heruntergeladener Software – ein Binary namens »vpnclient« , »vpnbridge« oder »vpnserver« .

Der Admin startet die Software durch das Kommando »vpnserver|bridge|client start« . Die Anleitung verschweigt leider, dass er vor dem Start notwendige Kernelmodule laden muss. Das betrifft auf jeden Fall das Modul für Softethers TAP-Interfaces (die via Layer 2 arbeiten und ein Ethernet-Gerät simulieren). Beim VPN-Server sind auch die l2TP-Module notwendig, sofern der Kompatibilitätsmodus Verwendung findet.

Nach dem Start (und der Bestätigung der Lizenz beim ersten Aufruf) ruft der Administrator »vpncmd« auf. Das Kommando fragt zunächst ab, ob der Anwender einen Server oder eine Bridge oder einen Client konfigurieren will. Im zweiten Schritt geht es darum, wo die Softether-Komponente laufen soll, deren Konfiguration der Administrator in Angriff genommen hat. Drückt er hier einfach die [Enter]-Taste, erfolgt die Installation auf dem lokalen Host. Es existiert auch ein GUI-Client, der aber nur für Windows bereitsteht (Abbildung 1).

Die Grundkonfiguration des Servers besteht aus den folgenden Schritten:

• Anlegen eines virtuellen Hub (einer mit Namen »DEFAULT« existiert bereits) und Auswahl desselben.
• Benutzer anlegen, gegebenenfalls auch Gruppen, wenn komplexere Zugriffsrechte abzubilden sind.
• Anlegen einer Bridge, die die Pakete, die im virtuellen Hub ankommen, an ein echtes Netzwerkinterface weiterleitet. Dies entspricht Open VPN im TAP-Modus. Soll das VPN geroutet werden, lässt sich dies nachbilden.

Abbildung 1: Das native Softether-Administrations-GUI gibt es nur für Windows.

Die Bedienung des Kommandozeilen-Clients ist etwas gewöhnungsbedürftig. Zwar besitzt er eine Kommando-Historie, aber er verfügt über keine Funktion für die Autovervollständigung via Tabulatortaste, wie dies bei gängigen Shells und auch den meisten Interpretern von Netzwerkkomponenten üblich ist. Dafür darf der Administrator Kommandos aber abkürzen, indem er nur so viele Zeichen des Kommandos eingibt, bis es eindeutig ist. Es existiert auch eine Onlinehilfe (»help« oder »?« ).

Gibt der Admin nur den nicht eindeutigen Anfang eines Kommandos ein, etwa »User« , erhält er von »vpncmd« alle Kommandos, die so beginnen samt einer kurzen Funktionsbeschreibung. Mit »help vollständiges Kommando« gibt »vpncmd« eine detaillierte Hilfe aus. Wenn Kommandos Parameter benötigen, können diese entweder auf der Kommandozeile mitgegeben werden (in DOS-Kommandozeilen-Schreibweise »/Parametername:Wert« ) oder die Software fragt sie einzeln ab.

Listing 1 zeigt das Anlegen eines virtuellen Hub mit dem Namen »LM-Test« und des Benutzers »testi« (ohne Gruppe) sowie das Binden dieses virtuellen Hub an das physische Interface »eth1« .

Es ist anzumerken, dass der Admin zum Anlegen der Bridge aus dem Administrationsmodus des Hub wieder auf die Hauptebene wechseln muss. Trotzdem wird dieses Kommando manchmal mit der Antwort »Not enough privileges« beantwortet. In dem Fall beendet der Administrator den Client und startet ihn nochmals neu.

01 
  
   VPN Server>
  HubCreate LM-Test
02 HubCreate command - Create New Virtual Hub
03 Please enter the password. To cancel press the Ctrl+D key.
04
05 Password: *******
06 Confirm input: *******
07
08
09 The command completed successfully.
10
11 
  
   VPN Server/LM-Test>
  usercreate
12 UserCreate command - Create User
13 
  
   User Name:
   testi
14
15 Assigned Group Name:
16
17 
  
   User Full Name:
   Testi Tester
18
19 User Description:
20
21 The command completed successfully.
22
23 
  
   VPN Server/LM-Test>
  userpasswordset
24 UserPasswordSet command - Set Password Authentication for User Auth Type and Set Password
25 
  
   User Name:
   testi
26
27 Please enter the password. To cancel press the Ctrl+D key.
28
29 
  
   Password:
   ********
30 
  
   Confirm input:
   ********
31
32
33 The command completed successfully.
34
35 
  
   VPN Server/LM-Test>
   hub
36 Hub command - Select Virtual Hub to Manage
37 The command completed successfully.
38
39 
  
   VPN Server>
  BridgeCreate
40 BridgeCreate command - Create Local Bridge Connection
41 
  
   Virtual Hub Name to Create Bridge:
   LM-Test
42
43 
  
   Bridge Destination Device Name:
   tap1

Es fehlt nur noch die Konfiguration des Clients, die Listing 2 zeigt. Dazu konfiguriert der Admin den Benutzernamen sowie die IP-Adresse und den Port des VPN-Servers. Durch das Kommando »AccountConnect« verbindet sich der Client mit dem Server, nachdem er nach dem Verbindungsnamen gefragt hat. Ob alles funktioniert hat, lässt sich auf dem Server in der Datei »VPN-Server-Dir/server_log/vpn_Datum.log« überprüfen.

Auf dem Client stellt Softether das Kommando »AccountStatusGet« bereit. Hat er sich erfolgreich verbunden, findet der Admin auf dem Client das neue Interface »vpn_vpn« vor (das zweite »vpn« entspricht hier dem Namen, der in der Konfiguration angegeben wurde). Dabei handelt es sich um ein TAP-Interface. Was jetzt allerdings noch fehlt, das ist die IP-Konfiguration. Softether pusht keine IP-Adressen oder Routen in einer solch einfachen Konfiguration. Es gibt auch kein konfigurierbares IP-up-Skript (oder etwas Ähnliches).

Damit der Client sich nun auch mit anderen Rechnern unterhalten kann, sollte ein DHCP-Server auf der Seite des VPN-Servers arbeiten und auf dem Client ein DHCP-Client starten, der Adressen einfordert. Admins sollten bei einem Test beachten, dass das Interface, zu dem die Bridge führt, von einem Client aus nicht anpingbar ist.

01 
  
   VPN Client>
  AccountCreate
02 AccountCreate command - Create New VPN Connection Setting
03 Name of VPN Connection Setting: LM-Test
04
05 Destination VPN Server Host Name and Port Number: 192.168.20.1:443
06
07 Destination Virtual Hub Name: LM-Test
08
09 Connecting User Name: testi
10
11 Used Virtual Network Adapter Name: vpn
12
13 The command completed successfully.
14
15 
  
   VPN Client>
  AccountPasswordSet
16 AccountPasswordSet command - Set User Authentication Type of VPN Connection Setting to Password Authentication
17 Name of VPN Connection Setting: LM-Test
18
19 Please enter the password. To cancel press the Ctrl+D key.
20
21 Password: *******
22 Confirm input: *******
23
24
25 Specify standard or radius: standard
26
27 The command completed successfully.

Verbindungen bündeln

Wie die Dokumentation erläutert, arbeitet Softether mit mehreren parallel geschalteten Verbindungen (TCP oder UDP), die logisch einen Tunnel implementieren. Das beschleunigt laut Aussage des Projekts Verbindungen und macht sie auch ausfallsicherer.

Erreicht der Client den Server nicht auf dem konfigurierten Port, versucht er es mit zwei Ausweichstrategien. Die verschlüsselten Pakete werden über Port 53/UDP gesendet, um sich als DNS-Pakete zu tarnen. Wenn das auch nicht hilft, schaltet Softether auf Übertragung via ICMP um und packt die Daten als Nutzlast in ICMP-Echo-Pakete.

Das sind keine neuen Ideen, es war schon immer möglich, beispielsweise Open VPN auf Port 53 zu packen, und es gibt auch VPN-Lösungen, die Nutzdaten in ICMP Pakete kapseln. Immerhin sehen die Pakete auf Port 53 wie gültige DNS Pakete aus. Allerdings geht Softether dabei nicht so weit wie Iodine, das gültige Anfragen über eine DNS-Server-Infrastruktur sendet. Die Pakete halten lediglich einem Check durch ein Intrusion-Detection-System oder intelligenten Firewalls stand. Aber dazu mehr im Abschnitt über die Sicherheit.

Auf dem Server ist konfigurierbar, wie viele TCP- oder UDP-Verbindungen pro VPN-Session maximal zum Einsatz kommen. Ob Softether DNS- oder ICMP-Pakete akzeptiert, ist am Server ebenfalls an- und abschaltbar, nicht aber am Client. Das Paket unterstützt auch IPv6 an den Endpunkten (Übertragung der verschlüsselten Daten über IPv6), was bei dem höheren Verbreitungsgrad von IPv6 in Japan nicht verwunderlich ist. Im Tunnel ist dies aufgrund der Tatsache, dass es sich um eine Layer-2-Verbindung handelt, kein Thema.

Andere Protokolle

Neben seinem eigenen Protokoll unterstützt Softether IPsec, L2TP in mehreren Ausprägungen, Microsofts SSTP, Open VPN und Ether IP. Der vorliegende Test verwendete L2TP over IPsec, wie es zum Beispiel bei Mac OS X und älteren Android-Geräten zum Einsatz kommt, und die Open-VPN-Emulation.

Um die jeweiligen Protokolle zu aktivieren, stellt der Server Enable-Kommandos bereit, etwa »Open VPNEnable« . Zu welchem virtuellen Hub die Verbindung gehört, bestimmt der Benutzername. Es ist nicht möglich, ein Zusatzprotokoll pro virtuellem Hub zu (de-)aktivieren. Dies muss der Anwender bei Verwendung eines dieser Protokolle bei der Wahl des Benutzernamens beachten. Wenn der Benutzer »test« sich an den virtuellen Hub »foo« verbinden möchte, dann resultiert daraus der Benutzername »test@foo« .

Performance

Die Webseite des Projekts behauptet, Softether sei schneller als Open VPN. Da für den Test, der das überprüfen sollte, keine High-End-Server bereitstanden, wählten die Tester den Weg in die Gegenrichtung: Den VPN-Server stellte ein schwacher Raspberry Pi. Ist die VPN-Software effizienter als Open VPN, mit dem sich das Softether-Team mehrfach vergleicht, dann sollte sich dies gerade im Test mit langsamer Hardware zeigen.

Bei Netzwerkdurchsatz-Tests (besonders im VPN-Bereich) sind die bewältigten MBit pro Sekunde nicht der einzige relevante Parameter. Auch die maximale Anzahl übertragener Pakete pro Sekunde ist von Bedeutung, da etwa Voice over IP aus einem kontinuierlichen Strom kleiner Pakete besteht und Verzögerungen zu Beeinträchtigungen der Sprachqualität führen. Es kann so weit kommen, dass das Ein- und Auspacken der Pakete mehr CPU-Last erzeugt als das Ver- und Entschlüsseln.

Da der Raspberry Pi nur ein Netzwerkinterface besitzt, legten die Tester ein VLAN-Interface an, um den Traffic in ein geschütztes LAN abzuleiten. Abbildung 2 zeigt den Testaufbau schematisch. Als Testwerkzeug diente Iperf [2], das es in einfacher Weise erlaubt, Pakete unterschiedlicher Größen zu schicken und damit auch die Rate der Pakete pro Sekunde (PPS) zu manipulieren.

Der Test bestand jeweils aus einer »iperf« -TCP-Verbindung, die die maximale Paketgröße verwendete und dabei die Verbindung mit TCP-Flussmechanismen steuerte. Der Test lief mehrmals zwischen einem Server im LAN und dem VPN-Client sowie in der anderen Richtung. Danach wurde der Test in UDP mit voller Paketgröße wiederholt, wobei während der Testdauer nur ein nicht übertragenes Paket akzeptiert wurde. Dabei manipulierten die Tester die Rate so lange, bis der Wert für den Paketverlust nicht mehr überschritten war.

Schließlich wiederholten die Tester den UDP-Lauf mit nur 64 Byte großen Paketen, um die maximale Paketübertragungsrate zu finden. Auch in diesem Fall suchten sie das Maximum, bevor mehr als ein Paket verloren ging. Als symmetrischen Algorithmus wählten sie AES256 mit SHA1. In einem kurzen Gegentest ergab aber auch das schwache RC4-MD5 keinen großen Unterschied.

Um das theoretische Maximum zu ermitteln, das die Hardware in Bezug auf Paketanzahl und MBit/s erzielen kann, lief der erste Test mit gerouteten Paketen ohne Verschlüsselung. Zum Vergleich traten dann Softether, Open VPN und ein Open-VPN-Client gegen den Softether-Server an. Tabelle 1 fasst die Ergebnisse zusammen.

Summa summarum kann gelten, dass Softether keinesfalls “deutlich schneller” überträgt. In manchen Szenarien hat auch Open VPN die Nase vorn. Für einen vollständigen Test sind sicherlich weitere Fälle notwendig, etwa Tunnelaufbau-Raten und der Durchsatz bei vielen simultanen Verbindungen.

Abbildung 2: Schema des simplen Testaufbaus mit einem Raspberry Pi als Server.

Benutzerauthentisierung und Rollen

Benutzer, die sich bei einem Softether-VPN-Server anmelden können, werden auf Ebene eines virtuellen Hub definiert. Da diese Konfigurationseinheit auch die Bindung an ein Netzwerkinterface regelt, bietet dies so etwas wie Mandantenfähigkeit, wenn die Abschirmung innerhalb der Software keine Fehler aufweist. Neben einer lokalen Datenbank erlaubt Softether den Anschluss an einen Radius-Server oder einen Active Domain Controller in einer Windows-Umgebung.

Benutzer lassen sich zu Gruppen zusammenfassen, die dann wieder als Konfigurationspunkt dienen, dem der Administrator eine Policy zuordnet. Eine Policy besteht dabei aus Sicherheitseinstellungen, die etwa bestimmen, welche Pakete passieren dürfen oder ob ein Benutzer sein Passwort ändern kann.

Anstelle einer Authentisierung über Benutzername und Passwort kann Softether auch mit Zertifikaten arbeiten. Dabei kann der Administrator sowohl einzelne Zertifikate pro Anwender hinterlegen als auch alle von einer bestimmten Certificate Authority signierten Zertifikate akzeptieren. Clients können dabei auch mit Zertifikaten auf Smartcards arbeiten.

Bedenklich: Die Sicherheit

Mit dem Kommando »ServerCipherGet« erhält der Administrator eine Liste der möglichen Kombinationen aus symmetrischem Verschlüsselungsalgorithmus und Hashfunktion. Diese Liste sieht wie folgt aus:

RC4-MD5
RC4-SHA
AES128-SHA
AES256-SHA
DES-CBC-SHA
DES-CBC3-SHA

Dabei ist RC4-MD5 die Standardeinstellung. Beide Algorithmen gelten als unsicher und sollten nicht mehr eingesetzt werden. Es ist unverantwortlich, dass eine VPN-Software im Jahr 2014 dies als Standardalgorithmus verwendet. Auch die weiteren Algorithmen sind – abgesehen von den beiden AES-Varianten – nicht als sicher einzustufen. Bei einem Einsatz der Software sollte der Administrator auf jeden Fall den Server auf AES256-SHA umstellen!

Der zweite Grund für Sicherheitsbedenken der Tester ist die verwendete Open-SSL-Bibliothek. Wie bei der Installation beschrieben, gehört zur Installation der Aufruf von »make« , der die Programme gegen die ausgelieferten Bibliotheken und die lokal vorhandene C-Bibliothek linkt. Aus Sicht der Entwickler ist es verständlich, dass die Open-SSL-Bibliotheken, mit denen das funktioniert, mitgeliefert werden, da es hier in der Vergangenheit immer mal wieder kleine API-Änderungen gab. Allerdings sollte sie der Anbieter dann auch aktuell halten.

Softether liefert aber noch heute das zwei Jahre alte Open SSL 0.9.8x mit aus! Selbst im 0.9.8er Branch gibt es noch ein CVE das mit 0.9.8y behoben wurde. Auch dies darf bei einer Sicherheitssoftware nicht passieren, zumal die Releases von Softether doch zeitlich nah aufeinanderfolgen. Hier sollte der Administrator sich damit behelfen, den Sourcecode herunterzuladen und das Paket in Gänze zu übersetzen.

Schließlich ist da noch die Secure-NAT-Funktion. Sie erlaubt es dem Anwender auch unter Windows, die Softether-Bridge vollständig im Userspace laufen zu lassen, das heißt, es sind keine Admin-Rechte notwendig. Damit wird es auch gewöhnlichen Anwendern möglich, Sicherheitsmaßnahmen in Firmennetzen vollständig zu unterlaufen.

Durch die Hintertür spazieren

Das Szenario dazu sieht folgendermaßen aus: Im Internet steht ein Softether-VPN-Server, der Verbindungen auf Port 443 für SSL-Verbindungen akzeptiert. Im Firmen-LAN wird die Softether-VPN-Bridge installiert und so konfiguriert, dass sie sich mit dem draußen stehenden Server verbinden kann. Der Anwender, der jetzt auf Ressourcen im Firmen-LAN zugreifen möchte, verbindet sich mit dem Server im Internet und dieser leitet die Pakete dann weiter. Das NAT in Secure NAT sorgt dafür, dass alle Zugriffe im LAN hinter der IP des Clients mit der Bridge verborgen bleiben.

Findige Linux- und Open-VPN-Anwender mögen jetzt einwenden: “Ist doch nichts Neues, kann ich auch”, und das ist richtig, da sich ein solches Szenario mit Open VPN unter Linux, etwas NAT und ein paar »route« – und »iroute« -Kommandos in der Open-VPN-Konfiguration genauso bauen lässt. Aber dafür benötigt man Admin-Rechte und am besten einen Linux-Rechner im geschützten LAN.

Der Kritikpunkt ist hier, dass es auch technisch weniger versierten Anwendern möglich gemacht wird, notwendige Schutzmaßnahmen zu unterlaufen. Der Abschnitt über diese Komponente in der Dokumentation des Produkts weist zwar ausdrücklich darauf hin, dass man das nicht ohne Abstimmung mit den lokalen Administratoren machen soll und dass es gefährlich sein kann, aber die Praxis zeigt, dass Poweruser solche Warnungen gerne ignorieren.

Andererseits zeigt ein Blick in das Benutzerforum, dass diese Funktionen in Ländern, die versuchen VPNs zu sperren, um ihre Bewohner besser zu überwachen und zu kontrollieren, auch zu guten Zwecken einsetzbar sind.

Was allerdings dem Fass den Boden ausschlägt: Die Software telefoniert nach Hause und übermittelt dabei Teile der Konfiguration wie die verwendeten IP-Adressen an einen Server in Japan. Eine der über den Client abschaltbaren Funktionen ist dabei das Eintragen des Servers in den DDNS-Server des Softether-Projekts. Um den Rest zu deaktivieren, muss man die Konfigurationsdatei »vpn_server.config« manuell anpassen und den Eintrag »DisableNatTraversal« auf »true« setzen.

Es ist ja schön und gut, dass die Software eine Funktion hat, die es erlaubt, bei behindernden Umgebungen einen Treffpunkt zu definieren. Aber dies sollte erstens in der Standardeinstellung abgeschaltet sein, zweitens sollte der Admin konfigurieren, wohin diese Verbindung geht, und den Dienst selbst anbieten können. Drittens sollte dies auf jeden Fall verschlüsselt und nicht im Klartext kommuniziert werden.

Positiv ist anzumerken, dass die Software über ausführliche Filterlisten verfügt, mit denen der Admin einschränken darf, welche Systeme und Dienste über eine VPN-Verbindung erreichbar sind, und zwar sowohl für IPv4 als auch für IPv6.

Eigenwillig, unsicher – und telefoniert nach Hause

Die Software hinterlässt einen zwiespältigen Eindruck. Hat sich der Administrator an die Eigenheiten der Konfiguration gewöhnt, kann er mit relativ wenigen Einträgen ein funktionierendes VPN aufsetzten. Die proprietären Clients aller weitverbreiteten Plattformen sind verwendbar. Die unterstützten Algorithmen, besonders die Standardeinstellungen, sind jedem sicherheitsbewussten Admin ein Dorn im Auge, hier sollte das Projekt unbedingt nachbessern.

Auf jeden Fall sollte der Anwender die Software aus den Quellen aufbauen, um immer aktuelle Kryptobibliotheken zu verwenden. Vor dem Einsatz sollte er die Software zudem einem aggressiven Sicherheitscheck unterziehen. Der Hang zum Nach-Hause-Telefonieren ist nicht tragbar. Das lässt sich zwar abschalten, aber wer möchte schon heutzutage seine Kommunikation noch mit einer Software absichern, die erst einmal ungefragt Kontakt nach Hause aufnimmt?