Vorweg: das Spannungsfeld Usability-Sicherheit – bei VPN gut sichtbar

Hier ist guter Rat meist teuer – im Wortsinn: Sicherheit bekommt man leicht über primitiv genagelte Latten und elegant über viel Entwicklungsarbeit und endloses Ausprobieren im Feld. … oder ist hier schon irgendwer flächendeckend(!) über das Passwort-Zeitalter hinaus? Keine Frage: Passwörter können schmerzarm und verträglich organisiert werden, letzten Endes sind sie aber ein Relikt. Nicht anders als physische Schlüssel: man basht hier gerne die IT-Metapher davon, redet aber nicht über die Schlüssel für Haustür, Auto, Fahrradschloss, Müllhäuschen etc. die man seit eh und je mit sich herumschleppt. Da sind wir auch nicht wirklich weiter.

Seit wenigen Jahren klappt bei einigen Handys das Entsperren über Fingerabdrücke ganz gut. Das ist ein Beispiel für eine gelungene Innovation in diesem Bereich. Aber siehe oben: auf so etwas zu kommen und es zuverlässig zu implementieren ist immenser Entwicklungsaufwand nötig:

  • Erst einmal mussten Handys lernen Fingerabdrücke überhaupt halbwegs robust zu erkennen,
  • dann mussten entsprechende Sensorbauteile mit ausreichender Auflösung entwickelt …
  • … und dann als Massenbauteil verfügbar gemacht und eingebaut werden.
  • Nicht zuletzt muss man auch hierbei die „Austricksbarkeit“ im Blick haben: noch ist nicht ausgeschlossen, dass irgendein Hacker mit einem Fettfleck eines Fingers und etwas Wachs die schöne Technik zu Alteisen degradiert.
Erschlagen vom Wissen

IT-Sicherheit: das nötige Wissen erschlägt leider jeden Einsteiger

Bei den ersten Systemen vor einigen Jahren haben aufgeweckte Sicherheitstester recht schnell Fingerabdruck-„Dietriche“ gebastelt gehabt. Damit wären Angreifer dann schneller an geschützten Systemen gewesen als beim Passwortknacken.

Viele schöne Laborideen scheitern bei den ersten Versuchen im Feld auch wieder oder benötigen Weiterentwicklungen. Das ist meist natürlich wieder aufwendig. Quintessenz dieser Vorrede: Ergonomie/Komfort und Sicherheit stehen sich sehr oft diametral gegenüber. Natürlich möchte man aus Komfortsicht an alle seine Sachen einfach ran – genauso natürlich kann es dann aber auch jemand Unerwünschtes. Dieser Zielkonflikt bleibt uns noch lange erhalten.

VPN einrichten: über Linux-Kommandozeilen, Verschlüsselung, Superuser und andere Untiefen – Beispiel Synology

Eigentlich soll nur ein VPN-Zugang eingerichtet werden. Damit kann man dann z.B. unter Windows Laufwerke im Windows-Explorer einblenden, die auf entfernten/externen IT-Systemen bereitgestellt werden. Wer etwa mit einem Notebook unterwegs ist und auf seine Daten auf Büro- oder Heimsystemen zugreifen will, ist praktisch ein Kandidat dafür.

Dazu gibt es bei Synology eigentlich ein eine ganz einfach zu installierendes Paket im Paket-Zentrum, etwa hier beschrieben: https://www.synology.com/de-de/knowledgebase/DSM/help/VPNCenter/vpn_setup. Kurz danach beginnt die Odyssee für viele Anwender.

Hier befinden wir uns auf der Ebene zwischen Technik und Nutzung – eigentlich möchte man Auto fahren, muss aber nur noch eben das Ventilspiel einstellen. Letzteres haben vermutlich nur sehr wenige Autofahrer je selbst gemacht. Mit einem Mechaniker, der einen führt und und dem richtigen Werkzeug ist auch das kein Problem. Ohne Beides werden aber ein Großteil der Menschen das Auto stehen lassen müssen.

Welchen Schlüssel nehmen wir denn

Welchen Schlüssel nehmen wir denn da nur … ?

So auch hier: PPTP, OpenVPN oder L2TP? Synology wirft hier einen offenen Werkzeugkasten hin und zieht sich auf das Beschreiben der Atome zurück. Sinngemäß sind die Erklärungen meist auf der Ebene: „Mit einem 12er-Rundschlüssel können sie 12er-Schrauben lösen oder festschrauben“. Klingt wie ein Erklärung – aber nur weil man die Antwort weiß. Wer wirklich keine Idee hat, was das ist – aber womöglich sogar das passende Problem hat – wird mit einer derart selbstbezogenen Antwort nichts anfangen können.

Etwa zum Eingabefeld MTU: „Stellen Sie MTU (Maximum Transmission Unit) ein, um die Datenpaketgröße für die Übertragung über das VPN zu begrenzen.“ Prima. Oder doch nicht: Was begrenze ich damit? Verbindungsabbrüche wenn die Pakete zu groß werden oder Dateien, von denen ich fürchte, dass ein Einbrecher sie kopieren könnte? Was sind sinnvolle Zahlen? Wie sehen denn Fehler durch über- oder unterschreiten aus? Kann es sein, dass deswegen Verbindungen nicht zustande kommen? Vor dem Begrenzen wären die meisten Anwender froh, wenn es überhaupt erst einmal liefe. Der Anwender kann nun weitersuchen, etwa bei Wikipedia: https://de.wikipedia.org/wiki/Maximum_Transmission_Unit. Von der Bedienoberfläche direkt ins Engineering. Es ist nicht besser als müsse man an der Tankstelle plötzlich die Viskosität eines Schmieröls selbst errechnen. … wäre das zum Autofahren nötig, hätten wir kein Abgasproblem – dann würde ohnehin kaum jemand fahren.

Kürzen wir das mal ab: PPTP gilt heute als einfach zu knacken und damit als veraltet. Es bleiben OpenVPN und L2TP übrig, bei denen sich die Akademiker uneins sind, welches führt. Bei Microsoft Windows ist L2TP an Bord und OpenVPN müsste nachgerüstet werden. Es bleibt damit L2TP. Nun muss man – wie bei vielen Diensten in Netzwerken – Clients und Server aufeinander abstimmen.

Eigentlich braucht man nur

  • Serveradresse
  • Benutzername
  • Passwort
  • Schlüssel (eine lange Zeichenkette, letzten Endes ein zweites Passwort).

auf beiden Seiten – also Diskstation und zugreifender Rechner – zu hinterlegen.

Und eine weitere Abkürzung: mit Windows 10 ist es nicht möglich einen Zugriff per L2TP ohne externe Werkzeuge einzurichten. Bei OpenVPN auch nicht – da sind dann aber wenigstens die Mittel dazu Open Source und (verhältnismäßig) passabel bedienbar.

Und wenn es nicht klappt? Der L2TP-Irrgarten – ohne letzendliche Lösung!

Dann gibt es eine gewaltige Rundreise! Und Hürden, Hindernisse und Schrullen. Gehen wir mal sämtliche auffindbaren Tipps durch.

Windows

Auf Fehler am Client deutet die Fehlermeldung „Der L2TP-Verbindungsversuch ist fehlgeschlagen, da keine Sicherheitsrichtlinie für die Verbindung gefunden wurde.“ Auf der anderen Seite – im NAS – ist noch nicht einmal etwas angekommen, da steht nichts in irgendwelchen Log-Dateien etc.

In diesem Fall, muss „nur“ das NAT-Traversal in der Registry angepasst werden. Was so magisch klingt, meint:

Via Registry-Editor muss unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

ein DWORD-Wert namens AssumeUDPEncapsulationContextOnSendRule angelegt werden und dieser den Wert 2 bekommen (siehe hier: https://www.administrator.de/frage/vpn-verbindung-l2tp-ipsec-246837.html).

Windows/Synology

Länge des gemeinsamen Schlüssels: wo genau das Limit liegt, weiß ich nicht. Eine übliche Passwortlänge von 20 Zeichen klappt. Wenn man allerdings lange generierten Schlüssel mit 100 und mehr Zeichen eingibt, klappt die Verbindung nicht. Wer von beiden Partnern da etwas verliert (oder ob es gar unterwegs/im Router/einer Firewall/bei den Telekom) ist nicht klar. Wenn es aber mit primitiv kurzen Schlüsseln plötzlich klappt, dann ist man der Fehlerquelle ja recht nahe.

Verbindungsaufbau: Zwar gibt es eine ganze Menge Verfahren um eine L2TP-VPN-Verbindung zu erstellen. Dabei geht es darum , wie die Verbindungsdaten zugestellt werden – ob auch der Verbindungsaufbau abgesichert ist oder nur die aufgebaute Verbindung. Windows bietet da PPTP, L2TP mit Zertifikat, L2TP mit vorinstalliertem Schlüssel, SSTP und IKEv2, Synology hingegen L2TP/IPSec mit MS-CHAP v2 oder PAP, Ein Laie könnte da leicht auf die Idee kommen, dass die beiden wohl keine Schnittstelle haben. Um es nicht ganz so spannend zu machen, habe ich die eine Gemeinsamkeit (… mit unterschiedlichen Namen, danke den Herstellern für die Gelegenheit, auch das einmal nachzuschlagen) beidseits hervorgehoben.

Router/Synology/Windows

Auch der Transportweg spielt eine wichtige Rolle: VPN via L2TP erfordert die Freigabe der UDP-Ports 1701, 500 und 4500. Das muss mindestens auf dem Router erfolgen, kann aber bei Nutzung der Synology-Firewall auch auf dem NAS nötig sein und theoretisch auch in der Windows- bzw. der Client-Firewall. Die ersten beiden Punkte werden in einem prima Tutorial erläutert: https://www.youtube.com/watch?v=QPLP87ACaXI. Windows habe ich hier noch nie als Engpass gesehen – aber als Externer weiß man nie, was in Firmen konfiguriert ist oder Leute sich zuhause mal verstellt haben.

Synology

Einstieg

Dann hatte auch die Synology-Software zeitweilig einen Bug. Dafür gab es einen Workaround. Dazu müssen in der DSM-Software bei Dateien leicht geändert werden:

  • /etc/ppp/chap-secret:
# client server secret IP addresses
username l2tpd "password" *

Also: den Benutzernamen hier im Klartext eintragen, dann das Passwort in Hochkommata gefolgt von einem Stern

  • in der Datei /var/packages/VPNCenter/etc/l2tp/options.xl2tpd die beiden folgenden Zeilen auskommentieren:
plugin /var/packages/VPNCenter/target/lib/pppd/radius.so 
plugin /var/packages/VPNCenter/target/lib/pppd/radattr.so
  • in der Datei /volume1/@appstore/VPNCenter/scripts/l2tpd.sh die beiden folgenden Zeilen auskommentieren:
${PKG_TARGET}/scripts/radiusd.sh start 
${PKG_TARGET}/scripts/radiusd.sh stopo

Exkurs – WinSCP

Wie macht man das? Am Besten man nimmt dazu ein Werkzeug wie WinSCP, loggt sich mit diesem praktischen Zwei-Fenster-Tool ein, navigiert zu den Dateien und ändert das mal eben. Da hat man die Rechnung aber ohne die Security gemacht. Natürlich kann man sich mit dem Administrator-Account auf dem NAS einloggen. Und dann mangels Rechten nichts machen. Man stellt dann nämlich fest, dass die ganzen Dateien root gehören. Damit setzen wir hier natürlich voraus, dass WinSCP und der Aufbau einer Verbindung zu einem Server damit kein böhmisches Dorf ist. Selbst wenn nicht: hier ist Sackgasse.

Exkurs-Exkurs – Root

Welcome to Linux. Unterhalb der grafischen Web-Oberfläche schlummert ein ganzer Linux-Rechner. Technisch gesehen ist das für so einen Server aus vielen Gründen prima.

Für einfache User hingegen nicht unbedingt.

Der root-Account ist im default erst einmal deaktiviert. Damit soll verhindert werden, dass Anwender aus Bequemlichkeit dauerhaft als root angemeldet arbeiten – einfach weil mit dieser User-Rolle alles geht und der Rechner nicht dauernd widerspricht. Eine Unsitte, die man über ein Jahrzehnt bei Windows XP beobachten konnte – und die für zahlreiche Katastrophen gut war. Während hier heute die Lösung mehr oder minder ist, eine Bestätigung vom User einzufordern, hat Synology hier auf die harte Tour gesetzt: es gibt zunächst keinen root.

Soweit nachvollziehbar: viele User benötigen diese Schritte hier nie – umso verheerender wäre nun ein root-Zugriff mit einem Erst-Passwort in der Dokumentation, die ein Großteil der User nie lesen und brauchen. Trotzdem ist die Lösung jetzt vergleichbar mit dem Erlernen des Schlüsselmacher-Berufs: root ist gestrichen und muss erst erzeugt werden.

  • das Werkzeug putty herunterladen, in einem Ordner entpacken und ausführen
  • unter Hostname die lokale IP-Adresse der Diskstation eintragen
  • mit dem Admin-Account aus der Weboberfläche in putty einloggen (Passwort nach Aufforderung eingeben – es ist korrekt, dass nichts davon zu sehen ist – es klappt trotzdem)
  • danach kommt man zu einem Eingabeprompt
  • dort folgenden Befehl eingeben:
sudo su -
  • hier noch einmal das zuvor eingegebene Passwort zur Bestätigung eingeben

Exkurs-Exkurs-Exkurs – Root

Als wenn das nicht reicht: jetzt bekommt man in den meisten Fällen auch noch Belehrungen:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Hier wählt man nicht 1, 2 oder 3 aus sondern gibt das Passwort ein weiteres Mal ein.
Jetzt erscheint vor dem prompt die Bestätigung, dass man root ist. Damit hat man allerdings noch nichts für WinSCP gewonnen. Um root auch dort nutzen zu können, muss man folgenden Befehl ausführen
[Achtung – wer das nicht will, sollte den folgenden Befehl NICHT ausführen und darunter weiterlesen]:
synouser –setpw root EIN_PASSWORT
Anstelle von EIN_PASSWORT muss jetzt das gewünschte Passwort gesetzt werden. Damit hat man für root endlich ein Passwort … kann zurück, um die liegen gebliebenen Probleme vom Abschnitt Einstieg oben endlich anzugehen.

Exkurs-Exkurs-Exkurs-Exkurs – Kryptotechnik statt Passwort

Ja. Den letzten Schritt nicht ausführen. Dann benötigen wir ein Schlüsselpaar. Als root stattdessen folgende Befehle eingeben:

  1. mkdir -p /root/.ssh
  2. chmod 0700 /root/.ssh
  3. ssh-keygen -b 4096 -t rsa -f /root/.ssh/id_rsa
  4. cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys
  5. chmod 600 /root/.ssh/authorized_keys
  6. cp /root/.ssh/id_rsa /volume1/private
Danach liegen im Ordner /root/.ssh die Dateien id_rsa und id_rsa.pub. Die Datei id_rsa.pub bleibt, wo sie ist. Sie ist der Public-Teil. Die Datei id_rsa wurde hingegen auf den Client kopiert – hier in Schritt 6 mit dem Zielnamen „private“. Wenn man sich nun vorläufig mit dem Administrator-Account in WinSCP auf dem Server einloggt, kann man die Datei „private“ im Pfad /volume/ sehen und auf den Client kopieren (die Dateien in root sind nicht lesbar für den admin).
Auf dem Client muss die Datei „private“ nun noch in das benötigte Format der Programme Putty und WinSCP kopiert werden. Dafür gibt es im Putty-Paket das Werkzeug Puttygen. Dort muss die nun kopierte Datei „private“ via Drücken des Load-Knopfes geladen werden. Puttygen zeigt danach auch schon direkt an, dass die Datei konvertiert werden muss. Als Anwender muss man jetzt nur noch den Knopf „Save private key“ drücken und einen Dateinamen vergeben. Diese Schlüsseldatei muss nun beim Erstellen neuer Serververbindungen unter Authentifizierung angegeben werden und hat nun eine ähnliche Wirkung wie ein Passwort.
Wenn Alles geklappt hat, sollten die Dateien „id_rsa“ und „private“ vom Server gelöscht werden.
Bei extern erstellten Schlüsseln ist es nötig, den SSH-Service neu zu starten, damit die Schlüssel wirksam werden. Dazu folgende Befehle bei putty eingeben:
  1. synoservicectl –reload sshd
  2. synoservicectl –restart sshd
Wer will kann auch beim Erstellen des SSH-Keys (Schritt 3) ein Passwort für den Schlüssel angeben. Dann hat man das System doppelt abgesichert.

Sonst noch was?

Vielleicht zur Fehlersuche: ist ein Anmeldeversuch bis zum NAS vorgedrungen oder nicht? Also schon beim Client/bei Windows hängen geblieben? Das NAS führt hierzu eine Log-Datei, die hier …

/volume1/@appstore/VPNCenter/var/log/radius/radius.log

… zu finden ist. Wenn etwas schief geht, gibt es einen Fehlereintrag und wenn eine Anmeldung klappt einen „Anwesenheitsnachweis“. Wenn hingegen nichts zu finden ist, ist ein Anmeldeversuch über den Client oder Router nicht hinaus gekommen.

Bewertung

Na ja – unter uns Nerds kann man einfache Dinge ja dermaßen vergraben. Wo Familien auch mal auf jemanden warten, ist das das Allerletzte. Der Anteil von aufgabenfremden Tätigkeiten ist exorbitant. Zur Erinnerung: Anwender wollen Daten sicher speichern und sicher abrufen – nicht Dinge auf Kommandozeilen schreiben und grundlos kryptische Einstellungen justieren müssen. Ernsthaft vermittelbar ist nicht, warum wozu diese Untiefen gut sind. Auch der Einwand, dass man das bei Cloud-Anbietern auch mieten kann, wird durch dieses Gepfriemel nicht gerade unberechtigter. So sehr Synology, QNAP etc. auch anpreisen, dass das alles halb so wild sei, so sprechen Fälle wie dieser doch ihre ganz eigene Sprache – Adminlatein nämlich.