Monthly Archives: December 2016

Authentisierung, Authentifizierung, Autorisierung

Die o. g. drei Begriffe werden oft unsauber verwendet, daher versuche ich hier, kurz und knapp darzustellen, was sie bedeuten:

  1. Authentisierung: Ich behaupte, eine bestimmte Person zu sein und lege zum Beweis etwas vor bzw. lasse mich nach einer Legitimation fragen.
  2. Authentifizierung: Am Ende dieses Prozesses steht die Feststellung, ob die unter 1. gemachte Behauptung als wahr akzeptiert wird oder nicht.
  3. Autorisierung: Ein Abgleich meiner Identit├Ąt mit hinterlegten Rollen oder Zugriffsrechten f├╝hrt dazu, da├č ich bestimmte Dinge darf und andere nicht.

Die Punkte 1. und 2. kann man auch so darstellen: Als Benutzer authentisiere ich mich an (gegen├╝ber) dem System dadurch, da├č ich meinen (Login-) Namen angebe und mein Pa├čwort oder einen Schl├╝ssel ├╝bergebe, woraufhin das System mich auf Grund dieser vorgelegten Daten authentifiziert (oder auch nicht).

Nach Abschlu├č der Authentifizierung gilt der Benutzer im System als authentisch oder auch autorisiert: Die erfolgreiche Authentifizierung f├╝hrt zur Autorisierung.

In diesem Zusammenhang ist der Begriff System schon weit gefa├čt, aber auch der Begriff des Benutzers kann erweitert werden: Z. B. k├Ânnen auch Ger├Ąte authentifiziert werden, man denke an Wahlcomputer, deren Identit├Ąt sichergestellt sein mu├č, bevor ihre Daten in ein ├╝bergeordnetes System eingespeist werden.

Angels├Ąchsischer Sprachraum

Microsoft schreibt:

  • Authentication is the verification of the credentials of the connection attempt. This process consists of sending the credentials from the remote access client to the remote access server in an either plaintext or encrypted form by using an authentication protocol.
  • Authorization is the verification that the connection attempt is allowed. Authorization occurs after successful authentication.

Demnach entspricht die
authentication der Authentisierung
und die
authorization der Authentifizierung.

Nachtrag

Es gibt tats├Ąchlich Leute, die ernsthaft behaupten, authentifizieren sei ein beliebter Fehler, die richtige Schreibweise [sic] w├Ąre dagegen authentisieren. Unglaublich, und das auf einer Website, die sich korrekturen.de nennt.

Absichern eines Synology-DSM-NAS per SSH

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 ein 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:

Keynote NF

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!

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:

https://cryptomator.org/de/

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:

  1. 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.
  2. Dem Server, auf dem man sich einloggen will, ├╝bergibt man seinen ├Âffentlichen Schl├╝ssel.
  3. 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.)
  4. 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.
  5. 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

  1. Erzeugen eines Schl├╝sselpaars auf dem Client
  2. Vorbereiten des Anwenderkontos und der SSH-Konfiguration auf der Diskstation
  3. ├ťbertragen des ├Âffentlichen Schl├╝ssels auf die Diskstation
  4. Einrichten eines Zugangs mit Putty auf dem Client
  5. 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:

https://cryptomator.org/de/

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 no

erst einmal weg bzw. auf

PasswordAuthentication yes

Dann 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.