Wer ein NAS einsetzt, will darauf oft nicht nur aus dem lokalen Netz zugreifen, sondern von überall aus. Spätestens ab diesem Moment muß man sich auch mit Fragen der Sicherheit auseinandersetzen. Auf die Kommunikation im LAN gehe ich im folgenden nicht ein.
Bevor man Hand an sein System legt, empfehle ich, sich den gesamten Text hier durchzulesen. Dann hat man einen Überblick, weiß was man will, kann weitere Quellen hinzuziehen und sich einen genauen Plan machen.
Um ein solches System (basierend auf DSM 6) abzusichern, kann man SSH einsetzen. Das Prinzip: Auf der Speicherstation läuft ein SSH-Daemon (sshd), über den die Kommunikation abgewickelt wird. Diese Kommunikation findet über einen TCP-IP-Port statt, typischerweise 22.
Für den Filetransfer kann dann SCP verwendet werden, unter Windows gibt es dazu den sehr schön gemachten WinSCP-Client.
Um den Administratorzugang über HTTP/HTTPS abzusichern, verwendet man praktischerweise die 2-Faktor-Authentifizierung.
Hat man dann also einen Administrationszugang und einen Zugang für den Filezugriff, ist man auf der sicheren Seite. Naja, soweit man bei Computern sicher sein kann. Es empfiehlt sich, dafür zu sorgen, daß man immer ein Hintertürchen hat, falls man sich einmal durch eine ungeschickte sshd_config oder ähnliches ausgesperrt hat. Ich gebe hier auch nur einen Überblick darüber, wie man an die Sache herangehen kann. Es gibt hier kein Kochrezept, das man ohne eigenes Nachdenken einfach abkupfert. Wer das trotzdem so auffaßt, sollte sich an die eigene Nase fassen, wenn er damit Schiffbruch erleidet.
Der Einsatz von SSH wird erst richtig sicher, wenn man ein Schlüsselpaar verwendet und das Login per Paßwort vollständig untersagt. Davor schrecken viele Anwender zurück, weil sie vielleicht das Prinzip nicht genau verstehen oder weil sie die Handhabung als zu kompliziert einschätzen.
Dazu kann ich nur sagen: Es ist weniger kompliziert, als man denkt, und wem Sicherheit zu kompliziert ist, der darf sich nicht wundern, wenn er seine Untätigkeit und Denkfaulheit am Ende teuer bezahlt.
Vorab aber noch ein Wort zu den und an die Digital Na(t)ives: Hören Sie sich doch einmal im Bekanntenkreis um, wer einen Paßwortsafe oder eine andere sichere, dateibasierte Methode benutzt, um seine Zugänge zu Systemen zu verwalten (und nicht irgendwelche abgegriffenen Freßzettel und Moleskin-Büchlein). Es sind verschwindend wenige, jedenfalls in meinem Umfeld. Es gibt Leute, die haben eine Word-Datei, in die sie ihre Paßwörter hineinschreiben, und diese Datei ist natürlich unverschlüsselt. Und planmäßig gesichert wird sie auch nicht. Im sichersten Fall ist sie nur auf einem PC vorhanden, doch wenn man den nicht gerade unter dem Arm herumschleppt, ist die Datei meistens nicht verfügbar, wenn man sie eigentlich braucht. Das hat dann prompt zur Folge, daß das fehlende Paßwort bei nächster Gelegenheit so geändert wird, daß man die Datei nicht mehr braucht.
Meine Empfehlung war damals, als ich diesen Artikel geschrieben habe:
In diesem Programm kann man erstens alle Informationen unterbringen, und das sehr übersichtlich, selbst Bilddateien kann man einstellen, z. B. Screenshots, aber zweitens kann man das Programm anweisen, die verwendete Datei mit den Zugangsdaten zu verschlüsseln. Somit hat man in Form einer Keynote-Datei einen Paßwort-Safe, in dem man auch andere wertvolle Informationen ablegen kann, und das Programm Keynote-NF, mit dem man diese Datei lesen und bearbeiten kann, ist innerhalb weniger Minuten auf jedem Windows-Recher installiert, auf dem man es vielleicht einmal braucht.
Und was auch toll ist: Es läßt sich mit Hilfe von Wine auch unter Linux verwenden!
Dieser Absatz hier ist ein Nachtrag, angefertigt am 27. Nov. 2020: Heute würde ich das Programm
empfehlen, denn es läuft unter vielen Betriebssystemen, Sie können es sogar auf dem (Android-) Handy nutzen und brauchen unter Linux kein Wine: Es läuft nativ unter Linux.
Wer dennoch eine Word-Datei oder so etwas verwenden will, kann das tun, wenn er sie in einem verschlüsselten File ablegt. Die Software Cryptomator kann so etwas und kostet nichts, wenngleich der Autor gerne Spenden entgegennimmt und die auch bekommen sollte, wenn man sein Programm gut findet:
DynDNS = DDNS
Auf der Synology-Diskstation geht ohne Quickconnect und DynDNS gar nichts, wenn man einen Zugang von extern sinnvoll konfigurieren will. Wenn man im Zusammenhang mit einem SSH-Zugang keine feste, öffentliche IP benutzen kann, benötigt man einen DynDNS-Dienst. Unkompliziert und zuverlässig geht das über Synology.
Zunächst sollte man jedoch QuickConnect konfigurieren.
Anschließend muß man im Control Panel (ich beziehe mich im folgenden immer auf die englische Nomenklatur) das Applet External Access öffnen. Die erste Seite mit dem Reiter DDNS dient dem Hinzufügen eines DynDNS-Dienstes.
Anschließend hat man eine Zeile, in der der sogenannte Hostname in Form einer voll qualifizierten URL angezeigt wird: <hostname>.synology.me.
Diese URL muß verwendet werden, wenn man Zugang per SSH erhalten will.
Schlüsselpaar
Ohne im Detail zu erläutern, wie asymmetrische Verschlüsselung funktioniert, gebe ich das Prinzip der Authentifizierungsmethode an:
- Man erzeugt auf der entfernten (englisch remote) Maschine, von der aus man sich einloggen will, ein Schlüsselpaar, bestehend aus einem privaten Schlüssel, den man niemals preisgibt und niemals verschickt, und einem öffentlichen Schlüssel, den man jederzeit jedermann übergeben kann.
- Dem Server, auf dem man sich einloggen will, übergibt man seinen öffentlichen Schlüssel.
- Der Software, die auf dem Client läuft, von dem aus man sich anmelden will, übergibt man seinen privaten Schlüssel, der normalerweise in einer Datei auf dem Client gespeichert ist. Dieser private Schlüssel sollte immer (!) mit einem Paßwort gesichert sein, so daß niemand, der unrechtmäßig an diesen privaten Schlüssel kam, diesen verwenden kann. Kurz gesagt, der private Schlüssel ist nur funktionsfähig zusammen mit seinem Paßwort, das man beim Erzeugen des Schlüssels frei wählen kann. (In diesem Zusammenhang ist auch in der Regel von der passphrase die Rede, nicht von einem password.)
- Beim Start der Anmeldung übergibt man als erstes seinen Benutzernamen. Die Diskstation kennt den öffentlichen Schlüssel, der zu diesem Benutzernamen gehört. Da die Gegenstelle den privaten Schlüssel des Schlüsselpaars hat, können sich beide darauf einigen, daß die beteiligten Schlüssel und der Benutzername zusammenpassen.
- Die Verbindung wird hergestellt.
Benutzernamen
Man sollte keine Benutzernamen wie root, admin oder administrator verwenden. Viel besser ist es, z. B. auf random.org zu gehen, um sich dort ein Paßwort erzeugen zu lassen wie z. B.
8kYMZUwq
Solcherlei Paßwörter (Ja, es heißt Paßwörter, nicht Paßworte!) lassen sich hervorragend als Benutzernamen verwenden, denn auf einen solchen Benutzernamen kommt sobald niemand.
Kurzüberblick
- Erzeugen eines Schlüsselpaars auf dem Client
- Vorbereiten des Anwenderkontos und der SSH-Konfiguration auf der Diskstation
- Übertragen des öffentlichen Schlüssels auf die Diskstation
- Einrichten eines Zugangs mit Putty auf dem Client
- Einrichten eines Zugangs mit WinSCP auf dem Client
1. Erzeugen eines Schlüsselpaars auf dem Client
Laden Sie puttygen herunter:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Speichern Sie den öffentlichen Schlüssel, geben Sie ein Paßwort ein für den privaten Schlüssel und speichern Sie anschließend auch den privaten Schlüssel.
Wenn Sie dieses Schlüsselpaar z. B. auf einem USB-Stick ablegen, sollten Sie darüber nachdenken, diese Daten zu verschlüsseln. Es gibt viele Möglichkeiten, das zu tun, eine sehr praktische ist, wie oben schon gesagt, der Einsatz von Cryptomator:
2. Vorbereiten des Anwenderkontos und der SSH-Konfiguration auf der Diskstation
Die global für den SSH-Daemon wirksame Datei
/etc/ssh/sshd_config
muß folgende Einträge enthalten:
# Dieser Eintrag ist erforderlich:
PubkeyAuthentication yes
# Dieser auch:
AuthorizedKeysFile .ssh/authorized_keys
# Hiermit wird das Login mittels Paßwort verboten,
# so daß man sich nur noch mit dem Schlüssel
# authentifizieren kann:
PasswordAuthentication no
Einige Dinge werden wirksam, wenn man den sshd neu startet, aber insbesondere das Verbot, sich per Paßwort zu authentifizieren, greift erst nach einem Reboot, da hierbei mehrere Dienste beteiligt sind. Nach meinen Erfahrungen ziehe ich Reboots der Diskstation reinen Neustarts des SSH-Daemons vor!
Wenn man auf Nummer Sicher gehen will, läßt man den Eintrag
PasswordAuthentication noerst einmal weg bzw. auf
PasswordAuthentication yesDann kann man erst einmal in Ruhe prüfen, ob das Login mit dem Schlüssel gelingt. Hat das geklappt und hat das verwendete Konto die Rechte, die man sich vorstellt, kann man die Paßwortauthentifizierung deaktivieren und kommt nach einem Reboot nur noch per Schlüsselauthentifizierung auf das System. Auf jeden Fall, was die SSH angeht! Der HTTP/HTTPS-Zugang ist davon nicht betroffen!
Darüberhinaus müssen folgende Rechte gesetzt werden:
$ chmod 755 /var/services/homes/<username>
Im Home-Verzeichnis muß das Verzeichnis .ssh und darin die Datei authorized_keys angelegt werden. Die Zugriffsrechte müssen angepaßt werden:
$ mkdir ~/.ssh $ chmod 0700 ~/.ssh $ touch ~/.ssh/authorized_keys $ chown -R <username> ~/.ssh $ chmod 0600 ~/.ssh/authorized_keys
In die Datei authorized_keys wird dann der öffentliche Schlüssel des Clients geschrieben.
3. Übertragen des öffentlichen Schlüssels auf die Diskstation
Man loggt sich auf der Diskstation mit einer SSH-Shell ein und öffnet die Datei authorized_keys mit einem Editor, mit dem man sich auskennt. Dann kopiert man den Schlüssel dort hinein.
Das gelingt nur, indem man in puttygen den Schlüssel aus dem Anzeigefenster kopiert! Nachträgliches Kopieren aus einer Schlüsseldatei hat für mich noch nicht funktioniert! Und zwar völlig unabhängig vom verwendeten Editor!!!
Im vi muß man dazu in den Insert-Mode und mit einem Rechtsklick fallen die Daten dann aus der Zwischenablage in die Datei, die man anschließend mit wq auf die Platte schreibt.
Es dürfen im vi keine Zeilenumbrüche zu sehen sein, wenn das doch der Fall ist, wird die Authentisierung fehlschlagen!
Kurze Bemerkung zu Puttygen: Man kann auch nachträglich einen Schlüssel in Puttygen laden, damit man Zugriff auf die Darstellung des Schlüssels im Anzeigefenster erhält. Ein Rechtsklick in dieses Fenster erlaubt auch ein schnelles select all und copy, um den Schlüssel korrekt auf ein unixoides System zu übertragen:
Nach dem Einfügen des Schlüssels sollte man sofort testen, ob das Login mit diesem Schlüssel auch funktioniert. Sollte das nicht der Fall sein, könnte es daran liegen, daß Zeilenumbrüche im Schlüssel vorkommen, die nachträglich von einem Editor eingefügt wurden oder daß man zuviele Daten mit markiert und kopiert hat oder auch zuwenig Daten beim Copy & Paste erfaßt hat.
Wenn man z. B. mit WinSCP Zugang zum entsprechenden Anwenderverzeichnis hat, kann man die Datei mit dem öffentlichen Schlüssel auch direkt dorthin kopieren und in die authorized_keys einfügen.
4. Einrichten eines Zugangs mit Putty auf dem Client
In Putty richtet man sich eine Session ein, in deren SSH-Sektion das File mit dem privaten Schlüssel eingetragen ist.
Über Putty läßt sich auch ein Zugriff auf Rechner im entfernten Netz weiterleiten. Putty fungiert dann mit seiner SSH-Shell wie ein Tunnel-Gateway, d. h., man routet seine RDP-Anfrage über das lokal laufende Putty und die offene SSH-Shell in das entfernte Netz, in dem die Diskstation läuft, die Pakete, die man dort hineinschickt, werden über die entsprechende Konfiguration des Putty-Tunnels auf eine lokale Maschine weitergeleitet. Hierzu müssen in der /etc/ssh/sshd_config zwei Variablen auf yes gesetzt werden:
AllowTcpForwarding yes GatewayPorts yes
(Auf keinen Fall PermitTunnel auf yes setzen, damit sperrt man sich u. U. aus.)
5. Einrichten eines Zugangs mit WinSCP auf dem Client
Im Host-Verwaltungstool gibt man als file protocol SCP an. Der host name sollte der sein, den man in der DDNS-Konfiguration auf der Diskstation eingetragen hat, also etwas wie
winterwunderland.synology.me
Der Port sollte 22 lauten, falls man nicht einen anderen Port für die SSH konfiguriert hat. User name ist klar, password kann frei bleiben, weil es sowieso nicht verwendet wird.
In Erweitert… muß man nur unter SSH -> Authentication den Pfad zum private key file eintragen. Der ganze Rest kann bleiben, wie er ist.
Man kann natürlich WinSCP auch durch einen bereits konfigurierten und geöffneten Putty-Tunnel jagen, aber WinSCP kann das ja von sich aus. In der Regel wird man das nicht benötigen, denke ich.
Kolloquia 