Alle Beiträge von Don Matteo

lebt in der Schweiz, ist System Engineer MCP bei A-Enterprise GmbH. Mitglied des UNBLOG Network. Author und Blogger zu den Themen, Linux und Open Source. Tutorials für Windows, VMware, Synology, Fortinet.

Windows Netzwerk­adapter in Registry finden

Windows Netzwerk­adapter GUID ausgeben und in der Registry finden

Windows weist jedem Netzwerk­adapter eine GUID zu, dabei verfügen alle Netzwerk­adapter, wie der Ethernet Adapter, Wireless Adapter oder die virtuellen Adapter und auch der Bluetooth Device über eine eigene GUID. Sollen Parameter an einem Netzwerk­adapter verändert werden, für die es beispielsweise keine Option in den Netzwerk Einstellungen gibt, muss man den betreffenden Netzwerk­adapter erst finden, da sie nicht unter dem physischen Adapter Typ oder der Namensbezeichnung in der Registry zu finden sind.

Eine relativ simple Methode ist die folgende Vorgehensweise. Als erstes muss die Dienste-Konsole geöffnet werden, mit den Tasten Win+R und der Eingabe services.msc

In der geöffneten Windows-Dienste-Konsole startet man den Dienst Automatische Konfiguration (verkabelt), falls dieser nicht bereits läuft.

Der nächste Schritt ist das öffnen einer Eingabeaufforderung, mit drücken der Tasten Win+Rcmd.

In der Eingabeaufforderung folgende Befehlszeile mit copy & paste einfügen und mit drücken der Enter Taste ausführen.

netsh lan show interfaces
netsh wlan show interfaces

Um die GUID der Wireless Adapter zu erhalten, muss der Dienst Automatische WLAN-Konfiguration gestartet sein.

Es erscheint die Ausgabe ähnlich wie die folgende, die Anzahl der Schnittstellen kann variieren, je nachdem welche Hardware und Software-Komponenten das System verfügt.

C:\>netsh lan show interfaces

Im System sind 4 Schnittstellen vorhanden:

    Name             : Ethernet
    Beschreibung     : Intel(R) Ethernet Connection (4) I219-V
    GUID             : a1cd571b-e351-4b07-9255-9a5ca910db88
    Physisch. Adresse: 80-E8-2C-BA-71-32
    Status           : Netzwerkkabel wurde entfernt

    Name             : OpenVPN TAP-Windows6
    Beschreibung     : TAP-Windows Adapter V9
    GUID             : 46bf86bd-82f1-4c70-af76-8c3bb253d76f
    Physisch. Adresse: 00-FF-44-FF-56-CD

C:\>netsh wlan show interfaces

Es ist 1 Schnittstelle auf dem System vorhanden:

    Name                   : WLAN
    Beschreibung           : Intel(R) Dual Band Wireless-AC 8265
    GUID                   : 7b4b5ecc-77b4-4f4e-b95a-09dcd3cba30d
    Physische Adresse      : d0:ab:d5:8c:71:1a
    Status                 : Verbunden
    SSID                   : NET0Hotspot
    BSSID                  : 08:60:6e:ca:c7:c4
    Netzwerktyp            : Infrastruktur
    Funktyp                : 802.11n
    Authentifizierung      : WPA2-Personal
    Verschlüsselung        : CCMP

Es werden wie hier alle Netzwerkadapter angezeigt, über die Namen oder Beschreibung ist der betreffende Netzwerkadapter leicht abzuleiten, dabei ist die GUID direkt unterhalb der Beschreibung.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces

Mit der nun gefundenen GUID lässt sich der entsprechende Netzwerkadapter im Registrierungs Editor finden.

SSH mit Zwei-Faktor-Authentifizierung für Debian

SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) auf Debian einrichten

Die Zwei-Faktor-Authentifizierung für den SSH Login bietet eine zusätzliche Sicherheitsebene. Bei der Zwei-Faktor-Authentifizierung wird zum Systembenutzerkennwort ein weiteres Kennwort erforderlich, ein PIN oder das sogenannte One-Time-Password (OTP), ein sechsstelliger Code der auf einem Mobilgerät angezeigt wird. Dadurch wird eine stärkere Authentifizierungsmethode für den Zugang zum Server erreicht.

In diesem Tutorial wird gezeigt, wie der SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) abgesichert wird, für SSH Schlüsselbasierte Authentifizierung bei der SSH Keys verwendet werden.

Systemvoraussetzung

  • Debian 10 (buster), Ubuntu 20.04 (Focal Fossa), Linux Mint 20
  • Ein sudo privilegierter User Account mit $home Verzeichnis
  • Authentifizierung mittels SSH Key (publickey) ~/.ssh/authorized_keys

  Wichtig! es wird empfohlen, sich während der Konfiguration der Authentifizierungseinstellungen eine zweite Terminalsitzung offen zu halten. Auf diese Weise wird man vom System nicht ausgesperrt, wenn die Verbindung beim Testen getrennt wird, weil etwa die Konfiguration noch nicht vollständig ist.

  Im weiteren Verlauf werden wir nicht mehr root sein, sondern als Voraussetzung im Rahmen dieses Tutorials weiter nur noch sudo verwenden. Bei Debian muss möglicherweise das sudo Paket erst installiert werden.

Falls sudo nicht vorliegt, wird das sudo Paket als root installiert.

$ su -
Password:
apt install sudo

Jetzt unserem Benutzer „john“ die sudo-Berechtigungen erteilen.

$ usermod -aG sudo john

Google Authenticator PAM-Modul Installation

Um den SSH-Server für die Zwei-Faktor-Authentifizierung einzurichten, wird das Google Authenticator PAM-Modul auf dem Debian System installiert. Wir sind als nicht-root, mit john eingeloggt dieser nun Mitglied der Gruppe sudo ist.

$ sudo apt install -y libpam-google-authenticator

Führe nach der Installation des Google Authenticator den folgenden Befehl aus.

$ google-authenticator

Während der Ausführung müssen einige Fragen wie unten gezeigt beantwortet werden.

$ Do you want authentication tokens to be time-based (y/n) y
Warning: pasting the following URL into your browser exposes the OTP secret to Google:
  https://www.google.com/chart?XYZl=otpauth://totp/root@debian%3Fsecret%34YNE6ZI3XCLUQLBD862UR6NAL2A%36ixxuer%3Ddebian

Drücke y und die Enter Taste um fortzufahren. Im folgenden wird im Terminal ein QR-Code angezeigt werden.

Öffne als nächstes die Google Authenticator App auf dem Handy und scanne den QR-Code im Terminal, mit dem + unten rechts. Alternativ kann man über den Link oben den QR-Sicherheitscode im Browser öffnen.

Sobald der QR-Code gescannt ist, erscheint auf dem Handy das sechsstellige Einmalpasswort. Es dauert 30 Sekunden bis der Token ändert, mit diesem wir uns später per SSH beim Debian Server anmelden.

In der Ausgabe oben ist auch der geheime TOTP Schlüssel, den Bestätigungscode und die Notrufcodes zu sehen. Es wird empfohlen, diese für die spätere Verwendung an einem sicheren Ort aufzubewahren.

Beantworte als nächstes alle Fragen mit y um die Google Authenticator-Konfigurationsdatei wie unten gezeigt zu aktualisieren.

Do you want me to update your "/home/john/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

  Die Datei .google_authenticator im $home Verzeichnis ist für die 2FA Authentifizierung erforderlich, fehlt die Datei wird die 2FA Authentifizierung ignoriert und die Token Eingabe wird übersprungen.

SSH für die Verwendung von Google Authenticator Konfigurieren

Als nächstes muss der SSH-Server für die Verwendung von Google Authenticator konfiguriert werden, in dem wir sshd_config bearbeiten.

$ sudo vi /etc/ssh/sshd_config

Für die 2FA Authentifizierung werden folgende Zeilen benötigt.

PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
UseDNS no
AuthenticationMethods publickey,keyboard-interactive password,keyboard-interactive

Die geänderte SSH-Dienst Konfiguration übernehmen.

$ sudo systemctl restart sshd

SSH Schlüsselbasierte Authentifizierung

Insbesondere Linux-Systemadministratoren sollten statt Passwörter SSH-Keys als Authentifizierungsmethode verwenden, wie es in obiger sshd_config konfiguriert ist. Eine Anleitung für die SSH-Public-Key-Authentifizierung gibt es hier. In unserem Beispiel soll der User john sich mit SSH-Key und 2FA anmelden.

Als nächstes müssen die PAM-Regeln für den SSH-Dienst in der Datei /etc/pam.d/sshd definiert werden.

$ sudo vi /etc/pam.d/sshd

Die Zeile @include common-auth mit # auskommentieren und nachfolgend zwei PAM-Regeln hinzufügen.

# Standard Un*x authentication.
#@include common-auth
auth  required  pam_google_authenticator.so nullok
auth  required  pam_permit.so

  Das Wort nullok am Ende der Zeile teilt PAM mit, dass diese Authentifizierungsmethode optional ist. Dadurch können sich Benutzer ohne OATH-TOTP-Token weiterhin mit nur dem SSH-Key anmelden. Sobald alle Benutzer über ein OATH-TOTP-Token verfügen, kann man nullok aus dieser Zeile entfernen, um 2FA obligatorisch zu machen. Die zweite Zeile mit pam_permit.so ist erforderlich, um die Authentifizierung zu ermöglichen, auch wenn ein Benutzer kein 2FA-Token verwendet.

Bei der Anmeldung benötigt jede Methode ein SUCCESS, um die Authentifizierung zu ermöglichen. Wenn ein Benutzer das 2FA-Authentifizierungstool nicht verwendet, gibt die Verwendung der Option nullok ein IGNORE für die interaktive Tastaturauthentifizierung zurück. pam_permit.so gibt dann SUCCESS zurück und ermöglicht die Fortsetzung der Authentifizierung.

SSH Login mit Zwei-Faktor-Authentifizierung Testen

Der SSH-Server ist jetzt mit Zwei-Faktor-Authentifizierung konfiguriert, damit ist nun die Gelegenheit gekommen es mit john zu testen.

$ ssh -v john@10.0.0.7
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
debug1: Server accepts key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
Verification code:

Troubleshooting

Gibt es Fehler bei der Authentifizierung mit 2FA, kann für des PAM-Modul die debug Funktion aktiviert werden.

auth required pam_google_authenticator.so debug nullok

Anschliessend öffnet man die Logdatei auth.log

$ sudo less /var/log/auth.log

Mit debug werden Fehler in der Authentifizierung rasch erkannt.

Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: shared secret in "/home/john/.google_authenticator" processed
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: Invalid verification code for john
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: "/home/john/.google_authenticator" written
Oct 22 17:59:32 debian sshd[3938]: Failed password for john from 10.0.0.8 port 55673 ssh2

Hier versuchte john sich ohne SSH-Key zu Authentifizieren.

  Existiert im user home ~/.google_authenticator, so erwartet der Google Authenticator ein SUCCESS von der SSH-Key (publickey) Authentifizierungsmethode.

Wichtig ist eine korrekte Zeit, damit die TOTP-Token synchron sind, bei grösserer Abweichung kann es zu abgelaufenen OATH-TOTP-Token kommen. Der NTP-Dienst sollte daher auf dem Server entsprechend eingerichtet und konfiguriert sein, für eine präzise Zeitsynchronisation. Das Tutorial zu Linux Systemzeit Synchronisation mit Network Time Protocol (NTP) gibt es hier.

Zum Schluss

Gratulation! Du hast eben den SSH-Server mit Zwei-Faktor-Authentifizierung für Debian oder Ubuntu erfolgreich eingerichtet. Wir hoffen, wir konnten die nötigen Grundlagen Kenntnisse vermitteln, um den SSH-Server mit Google Authenticator zu schützen.

Weblinks

GitHub google/google-authenticator-libpam