Einleitung
Voraussetzungen
Einrichtung von google-authenticator auf dem Zweitgerät
Einrichtung von google-authenticator auf dem Server
Bermerkungen zu verschlüsselten Daten
Referenzen
Einleitung
Alle, die auf Börsen unterwegs sind, wissen das zusätzliche Sicherheitsfeature 2FA zu schätzen. Diese Methode stellt eine zusätzliche Hürde für die Übernahme eines Accounts dar, da ein simples Abfangen/Erraten/Erhacken des Login-Passworts für diesen Zweck nicht mehr ausreicht. Essenziell hierfür ist, dass die nutzerseitige 2FA-generierende Software auf einem Zweitgerät läuft.
Ein paar Definitionen und Erklärungen:
- 2FA: Two-Factor-Authentication.
- Server: Z.B. Börse mit Webinterface fürs Login oder ein Raspi mit ssh-Zugang per Konsole.
- Account: Z.B. Nutzeraccount bei einer Börse oder direkt auf einem Server.
- Erstgerät:
- Das Gerät mit welchem man den normalen Login-Vorgang durchführt.
- In der Regel ein PC.
- Zweitgerät:
- Das Gerät, welches die 2FA-Token für den Login-Vorgang generiert.
- In der Regel ein Smartphone.
- Zweitgerät MUSS UNGLEICH Erstgerät sein damit das Prinzip greift.
- 2FA-Masterkey:
- Die Seed für die Erzeugen der 2FA-Token.
- Besteht in der Regel aus einem kryptischen String.
- Dieser liegt auf dem Server und auf dem Zweitgerät.
- Es handelt sich hierbei um symmetrische Kryptographie (zumindest wenn man oath-tool nutzt: https://www.nongnu.org/oath-toolkit/), es ist aber nicht ausgeschlossen, dass es andere Methoden gibt.
- 2FA-Token:
- In der Regel eine sechstellige Zahl, welche sich alle 30 Sekunden ändert.
- Diese Zahl hängt deterministisch vom 2FA-Masterkey und der aktuellen Zeit ab.
- Wird beim Login am Server zusätzlich zum Passwort eingegeben.
- Voraussetzung für einen erfolgreichen Login ist, dass die Uhren auf Server und Zweitgerät korrekt synchronisiert sind.
- Wer Zugriff auf die Hardware des Servers hat, hat somit auch Zugriff auf den Masterkey.
- Verification Code (VC): Muss einmalig zur Aktivierung von 2FA auf dem Server eingegeben werden, siehe weiter unten.
Z.B. ist so die Übernahme eines Accounts nur per Login-Passwort nicht mehr möglich! Wer seine Passwörter mal irgendwo hat rumliegen lassen oder wem diese wie auch immer gestohlen wurden, ist per 2FA trotzdem noch geschützt. Wer einen Keylogger u.ä. auf seinem Rechner laufen hat, ist durch 2FA sicherer, denn der Angreifer müsste zusätzlich das 2FA-Token abfangen um selbst, vor dem eigentlich Accountbesitzer, den Login durchzuführen. Ist natürlich auch der 2FA-Masterkey dem Angreifer bekannt, ist der Account für den eigentlichen Besitzer verloren.
Wer nun einen Server aufsetzt, welcher direkt mit dem Internet kommuniziert, wird oft auch einen SSH-Zugang offenhalten, damit man Zugriff auf den Server hat, wenn die Hardware selbst eine halbe Welt entfernt ist. Das mag der Fall sein, wenn man z.B. selbst auf Reisen ist, oder wenn man den Server in der Cloud laufen hat.
Voraussetzungen
In diesem Howto verwende ich einen Raspberry Pi. Welche Generation, d.h. ob 1, 2, 3 oder 4 ist relativ egal, wichtig ist nur, dass ihr die richtige Raspbian-Version für die gegebene Hardware nutzt. Getestet habe ich das auf einem 1er- und einem 3er-Raspi. Für eine Basisinstallation verweise ich auf:
https://bitcointalksearch.org/topic/howto-adressen-monitoring-5202173
Und dort im Besonderen auf die zwei Punkte "Vorbereitung der SD-Karte" (https://bitcointalksearch.org/topic/howto-adressen-monitoring-5202173#post_vorbereitung_sd) und "Konfiguration des Raspi" (https://bitcointalksearch.org/topic/howto-adressen-monitoring-5202173#post_konfiguration_raspi).
Einrichtung von google-authenticator auf dem Zweitgerät
Ihr benötigt die google-authenticator-App aus dem entsprechenden Playstore um diese auf z.B. eurem Smartphone zu installieren. Diese gibt es für Android auf jeden Fall (https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=de) und auch für iPhones sollte diese zur Verfügung stehen.
Einrichtung von google-authenticator auf dem Server
Per ssh verbinden wir uns mit dem Server:
Code:
und installieren den google-authenticator:
Code:
sudo apt-get install libpam-google-authenticator
Dann editieren wir die erste ssh-Konfigurationsdatei:
Code:
sudo nano /etc/pam.d/sshd
und fügen folgende Zeile unten in der Datei ein:
Code:
auth required pam_google_authenticator.so
Wir speichern die Datei via Strg+x. Nun editieren wir die zweite ssh-Konfigurationsdatei:
Code:
sudo nano /etc/ssh/sshd_config
In dieser Datei befindet sich folgende Zeile:
Code:
ChallengeResponseAuthentication no
und dort ändern wir das "no" zu "yes":
Code:
ChallengeResponseAuthentication yes
Wir speichern die Datai via Strg+x. Dann rufen wir google-authenticator auf (OHNE sudo!):
Code:
google-authenticator
Und bestätigen jeweils immer mit ja bzw. yes. Dies erzeugt einen QR-Code in der Konsole, welcher mit dem Smartphone und der google-authenticator-App abphotographiert werden kann. Die App erzeugt nun entsprechende 2FA-Token. Wie das aussieht könnt ihr hier sehen:
https://ryanerickson.com/add-two-factor-aut/
Direkt unter dem QR-Code befindet sich der 2FA-Masterkey ("new secret key") und wiederum direkt darunter der sogenannte "verification code" (VC). Den 2FA-Masterkey braucht ihr euch nicht merken oder notieren. Wichtig ist aber der VC für die weitere Installation!
GANZ WICHTIG!!! JA NICHT AUSLOGGEN!!! DIESE VERBINDUNG IMMER OFFEN LASSEN BIS 2FA AUCH WIRKLICH FUNKTIONIERT.
Zusätzlich wurde der Ordner
Code:
/home/thorsten/.google_authenticator
erzeugt, welcher die 2FA-Konfiguration für Nutzer thorsten enthält. Wird dieser gelöscht, geht auch diese Konfiguration verloren (siehe auch weiter unten).
Nun starten wir den ssh-Dienst neu:
Code:
sudo systemctl stop ssh
sudo systemctl start ssh
sudo systemctl start ssh
Zum Aktivieren und Testen von 2FA öffnen wir eine neue Konsole und versuchen uns am Server anzumelden:
Code:
- Ein erstes Passwort wird abgefragt: Gebt hier den VC ein. Wenn nicht der korrekte VC eingegeben wird, dann kann man Einrichtung von google-authenticator auf dem Server gleich nochmal durchexerzieren.
- Ein zweites Passwort wird abgefragt: Dies ist nun das Nutzerpasswort von euch bzw. hier im Beispiel von thorsten.
- Ein Verification Code wird abgefragt: Hierbei handelt es sich um das 2FA-Token, welches vom Zweitgerät alle 30 Sekunden neu generiert wird.
Wenn das geklappt hat, einfach ausloggen und nochmal das Ganze:
Code:
Bei Passwort diesmal das Nutzerpasswort eingeben, dann kommt auch gleich die Token-Abfrage.
Falls 2FA nicht klappt, dann macht die Änderungen in
Code:
/etc/pam.d/sshd
und
Code:
sudo nano /etc/ssh/sshd_config
rückgängig. In ersterer Datei reicht das Auskommentieren der neuen Zeile:
Code:
#auth required pam_google_authenticator.so
In zweiterer Datei schlicht "yes" wieder durch "no" austauschen. Zusätzlich muss der Ordner:
Code:
/home/thorsten/.google_authenticator
gelöscht werden. Last but not least den ssh-Dienst wieder neu starten:
Code:
sudo systemctl stop ssh
sudo systemctl start ssh
sudo systemctl start ssh
Es kann nun zur Fehlersuche wieder von vorne bei Einrichtung von google-authenticator auf dem Server begonnen werden. Wenn alle Stricke reissen, dann könnt ihr die Dateien bei Nutzung eines Raspis auch direkt auf der SD-Karte editieren, wenn diese in einem PC gemountet ist, anstatt das System vollständig neu aufzusetzen.
Bemerkungen zu verschlüsselten Daten
Im Folgenden gehe ich davon aus, dass dem Angreifer das Nutzerpasswort sowie der 2FA-Masterkey unbekannt ist.
Für einen erfolgreichen ssh-Login mit 2FA muss der Ordner:
Code:
/home/thorsten/.google_authenticator
entschlüsselt vorliegen. D.h. bei direktem Zugriff auf die Hardware und bei unverschlüsseltem Homeverzeichnis könnte ein Angreifer beliebige Informationen aus diesem auslesen. Ist jedoch das Homeverzeichnis verschlüsselt, dann kann das System nicht auf die 2FA-Konfiguration zugreifen. Ein Henne-Ei-Problem.
Eine ziemlich unhandliche Lösung wäre, dass der Adim des Servers immer dafür sorgt, dass das Homeverzeichnis während des laufenden Betriebs entschlüsselt vorliegt. Wie schon erwähnt, ist das Homeverzeichnis verschlüsselt, z.B. durch Nutzung von ecryptfs (https://wiki.ubuntuusers.de/ecryptfs/), so ist kein erfolgreicher Login bei aktiviertem 2FA möglich, da das System nicht an die 2FA-Konfiguration kommt! Ist 2FA beim Neustart des Servers deaktiviert so kann man sich normal per ssh auf dem Server einloggen und das Homeverzeichnis wird bei aktiviertem ecryptfs entschlüsselt. Nun aktiviert man 2FA. Sollte nun ein Angreifer Zugriff auf die Hardware des Servers bekommen, so kann er nicht die Daten im Homeverzeichnis der SD-Karte auslesen, da beim Ausschalten/Steckerziehen das entschlüsselte Homeverzeichnis mit der 2FA-Konfiguration sowie die anderen Daten im Homeverzeichnis verloren gehen (zumindest gehe ich davon aus). Zugriff ist per ssh auch unterbunden, da der Angreifer das Nutzerpasswort und die notwendigen 2FA-Tokens nicht kennt. Wird der Server jedoch abgeschaltet, so muss der Admin vor einem Neustart jedesmal dafür sorgen, dass 2FA deaktiviert ist. Und dies geht nur, wenn er dies durch manuelles Mounten und Editieren der SD-Karte am PC macht (/etc/pam.d/sshd und /etc/ssh/sshd_config).
Referenzen
https://ryanerickson.com/add-two-factor-aut/
https://wiki.archlinux.org/index.php/Google_Authenticator