Härten von OpenSSH unter Ubuntu 18.04

Der Autor wählte die Electronic Frontier Foundation Inc, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

Einführung

Linux-Server werden oft über SSH aus der Ferne verwaltet, indem eine Verbindung mit einem OpenSSH-Server hergestellt wird. Das ist die SSH-Serversoftware, die in Ubuntu, Debian, CentOS, FreeBSD und den meisten anderen Linux/BSD-basierten Systemen verwendet wird.

OpenSSH-Server ist die Serverseite von SSH, auch als SSH-Daemon oder sshd bekannt. Sie können über den OpenSSH-Client - den Befehl ssh - eine Verbindung zu einem OpenSSH-Server herstellen. Weitere Informationen über das Client-Server-Modell von SSH finden Sie in SSH-Grundlagen: Arbeiten mit SSH-Servern, Clients und Schlüsseln. Eine gute Sicherung Ihres OpenSSH-Servers ist sehr wichtig, da er als Eingangstür oder Zugang zu Ihrem Server fungiert.

In diesem Tutorial härten Sie Ihren OpenSSH-Server durch verschiedene Konfigurationsoptionen, damit der Remotezugriff auf Ihren Server so sicher wie möglich ist.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

• Einen Ubuntu 18.04-Server, der gemäß der Ersteinrichtung eines Servers unter Ubuntu 18.04 eingerichtet wurde, einschließlich eines sudo non-root users.

Sobald Sie diese zur Verfügung haben, melden Sie sich zunächst als non-root user auf Ihrem Server an.

Schritt 1 — Allgemeines Härten

In diesem ersten Schritt implementieren Sie einige anfängliche Härtungskonfigurationen, um die allgemeine Sicherheit Ihres SSH-Servers zu verbessern.

Die für Ihren eigenen Server am besten geeignete Härtungskonfiguration hängt stark von Ihrem eigenen Gefahrenmodell und Ihrer Risikoschwelle ab. Die in diesem Schritt verwendete Konfiguration ist jedoch eine generell sichere Konfiguration, die für die Mehrheit der Server geeignet ist.

Viele der von Ihnen implementierten Härtungskonfigurationen für OpenSSH verwenden die standardmäßige Konfigurationsdatei des OpenSSH-Servers, die sich unter /etc/ssh/sshd_config befindet. Bevor Sie mit diesem Tutorial fortfahren, empfiehlt sich ein Backup Ihrer vorhandenen Konfigurationsdatei, damit Sie sie in dem unwahrscheinlichen Fall, dass etwas schiefgeht, wiederherstellen können.

Nehmen Sie mit dem folgenden Befehl ein Backup der Datei vor:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Dadurch wird eine Sicherungskopie der Datei unter /etc/ssh/sshd_config.bak. gespeichert.

Bevor Sie Ihre Konfigurationsdatei bearbeiten, können Sie die aktuell festgelegten Optionen überprüfen. Dazu führen Sie folgenden Befehl aus:

sudo sshd -T

Dadurch wird OpenSSH-Server im erweiterten Testmodus ausgeführt, was die vollständige Konfigurationsdatei validiert und die effektiven Konfigurationswerte ausgibt.

Sie können die Konfigurationsdatei nun mit Ihrem bevorzugten Texteditor öffnen, um mit der Implementierung der anfänglichen Härtungsmaßnahmen zu beginnen:

sudo nano /etc/ssh/sshd_config

Bei der Bearbeitung Ihrer Konfigurationsdatei können standardmäßig einige Optionen mit einem einzelnen Hash-Zeichen (#) am Anfang der Zeile auskommentiert werden. Um diese Optionen zu bearbeiten oder die kommentierte Option anerkennen zu lassen, müssen Sie sie unkommentieren, indem Sie das Hash entfernen.

Deaktivieren Sie zunächst die Anmeldung über SSH als root-Benutzer durch Festlegen der folgenden Option:

PermitRootLogin no

Das ist sehr vorteilhaft, da es einen potenziellen Angreifer daran hindert, sich direkt als root anzumelden. Das unterstützt zudem gute betriebliche Sicherheitspraktiken wie das Operieren als nicht privilegierter Benutzer und die Verwendung von sudo, um Berechtigungen nur dann auszuweiten, wenn es unbedingt erforderlich ist.

Als Nächstes können Sie die maximale Anzahl der Authentifizierungsversuche für eine bestimmte Anmeldesitzung begrenzen, indem Sie Folgendes konfigurieren:

MaxAuthTries 3

Für die meisten Einstellungen ist ein Standardwert von 3 akzeptabel. Sie können diesen jedoch je nach Ihrer eigenen Risikoschwelle höher oder niedriger festlegen.

Bei Bedarf können Sie auch eine reduzierte Anmeldefrist festlegen. Das ist die Zeitspanne, in der ein Benutzer die Authentifizierung abschließen muss, nachdem er sich mit Ihrem SSH-Server verbunden hat:

LoginGraceTime 20

Die Konfigurationsdatei gibt diesen Wert in Sekunden an.

Eine Einstellung auf einen niedrigeren Wert hilft, bestimmte Denial-of-Service-Angriffe zu verhindern, bei denen mehrere Authentifizierungssitzungen für einen längeren Zeitraum offen gehalten werden.

Wenn Sie SSH-Schlüssel für die Authentifizierung konfiguriert haben anstatt Passwörter zu verwenden, deaktivieren Sie die SSH-Passwortauthentifizierung, um zu verhindern, dass geleakte Benutzerpasswörter einem Angreifer ermöglichen, sich anzumelden:

PasswordAuthentication no

Als eine weitere Härtungsmaßnahme in Bezug auf Passwörter können Sie bei Bedarf auch die Authentifizierung mit leeren Passwörtern deaktivieren. Dadurch wird die Anmeldung verhindert, wenn das Passwort eines Benutzers auf einen blanken oder leeren Wert gesetzt ist:

PermitEmptyPasswords no

In den meisten Anwendungsfällen wird SSH mit der Authentifizierung mit öffentlichen Schlüsseln als die einzige in Gebrauch befindliche Authentifizierungsmethode konfiguriert. Jedoch unterstützt OpenSSH-Server auch viele andere Authentifizierungsmethoden, von denen einige standardmäßig aktiviert sind. Wenn diese nicht erforderlich sind, können Sie sie deaktivieren, um die Angriffsoberfläche Ihres SSH-Servers weiter zu reduzieren:

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Wenn Sie mehr über einige der in SSH verfügbaren zusätzlichen Authentifizierungsmethoden erfahren möchten, stehen Ihnen diese Ressourcen zur Verfügung:

• Challenge-Response-Authentifizierung
• Kerberos-Authentifizierung
• GSSAPI-Authentifizierung

X11-Forwarding ermöglicht die Anzeige von entfernten grafischen Anwendungen über eine SSH-Verbindung, was jedoch selten in der Praxis verwendet wird. Es wird empfohlen, diese zu deaktivieren, wenn sie auf Ihrem Server nicht benötigt wird:

X11Forwarding no

OpenSSH-Server ermöglicht es Verbindungsclients, benutzerdefinierte Umgebungsvariablen zu übergeben, d. h. einen $PATH festzulegen oder Terminaleinstellungen zu konfigurieren. Wie das X11-Forwarding werden diese jedoch generell nicht verwendet, sodass sie in den meisten Fällen deaktiviert werden können:

PermitUserEnvironment no

Wenn Sie diese Option konfigurieren möchten, sollten Sie dabei sicherstellen, alle Referenzen zu AcceptEnv auszukommentieren, indem Sie am Anfang der Zeile ein Hash (#) hinzufügen.

Als Nächstes können Sie verschiedene sonstige Optionen bezüglich Tunneling und Forwarding deaktivieren, wenn Sie diese nicht auf Ihrem Server verwenden:

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Schließlich können Sie das standardmäßig aktivierte ausführliche SSH-Banner deaktivieren, da es verschiedene Informationen zu Ihrem System anzeigt, darunter die Betriebssystemversion:

DebianBanner no

Beachten Sie, dass diese Option wahrscheinlich nicht in der Konfigurationsdatei vorhanden ist, sodass Sie sie möglicherweise manuell hinzufügen müssen. Speichern und schließen Sie die Datei, sobald Sie fertig sind.

Validieren Sie nun die Syntax Ihrer neuen Konfiguration, indem Sie sshd im Testmodus ausführen:

sudo sshd -t

Wenn Ihre Konfigurationsdatei eine gültige Syntax hat, gibt es keine Ausgabe. Im Falle eines Syntaxfehlers gibt es eine Ausgabe, die das Problem beschreibt.

Wenn Sie mit Ihrer Konfigurationsdatei zufrieden sind, können Sie sshd neu laden, um die neuen Einstellungen anzuwenden:

sudo service sshd reload

In diesem Schritt haben Sie eine allgemeine Härtung der Konfigurationsdatei Ihres OpenSSH-Servers vorgenommen. Als Nächstes implementieren Sie eine Zulassungsliste für IP-Adressen, um weiter zu beschränken, wer sich bei Ihrem Server anmelden kann.

Schritt 2 — Implementieren einer IP-Adressen-Zulassungsliste

Sie können IP-Adressen-Zulassungslisten verwenden, um die Benutzer zu beschränken, die berechtigt sind, sich bei Ihrem Server auf Bais der einzelnen IP-Adressen anzumelden. In diesem Schritt konfigurieren Sie eine IP-Zulassungsliste für Ihren OpenSSH-Server.

In vielen Fällen melden Sie sich nur von einer kleinen Anzahl bekannter, vertrauenswürdiger IP-Adressen auf Ihrem Server an. Beispiele sind Ihre private Internetverbindung, eine gemeinschaftliche VPN-Anwendung oder eine statische Jump Box oder ein statischer Bastion Host in einer Datenzentrale.

Durch die Implementierung einer IP-Adressen-Zulassungsliste können Sie sicherstellen, dass sich Personen nur über eine der vorab zugelassenen IP-Adressen anmelden. Dadurch wird das Risiko eines unerwünschten Zugriffs in dem Fall, dass Ihre privaten Schlüssel und/oder Passwörter geleaked wurden, erheblich reduziert.

Sie können die IP-Adresse identifizieren, mit der Sie sich derzeit mit Ihrem Server verbinden, indem Sie den Befehl w verwenden:

w

Sie sehen eine Ausgabe, die der folgenden ähnelt:

Output
 14:11:48 up 2 days, 12:25,  1 user,  load average: 0.00, 0.00, 0.00
         USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
your_username     pts/0    203.0.113.1     12:24    1.00s  0.20s  0.00s w

Finden Sie Ihr Benutzerkonto in der Liste und notieren Sie sich die IP-Adresse der Verbindung. Hier verwenden wir die Beispiel-IP 203.0.113.1

Um mit der Implementierung Ihrer IP-Adressen-Zulassungsliste zu beginnen, öffnen Sie die Konfigurationsdatei des OpenSSH-Servers mit Ihrem bevorzugten Texteditor:

sudo nano /etc/ssh/sshd_config

Sie können IP-Adressen-Zulassungslisten mit der Konfigurationsanweisung AllowUsers implementieren, die Benutzerauthentifizierungen auf Basis des Benutzernamens und/oder der IP-Adresse beschränkt.

Ihre eigenen Systemeinstellungen und -anforderungen bestimmen, welche spezifische Konfiguration am besten geeignet ist. Die folgenden Beispiele helfen Ihnen dabei, die am besten geeignete zu identifizieren:

• Beschränken aller Benutzer auf eine bestimmte IP-Adresse:

AllowUsers *@203.0.113.1

• Beschränken aller Benutzer auf einen bestimmten IP-Adressbereich mit der Classless Inter-Domain Routing-Notation:

AllowUsers *@203.0.113.0/24

• Beschränken aller Benutzer auf einen bestimmten IP-Adressbereich (mit Wildcards):

AllowUsers *@203.0.113.*

• Beschränken aller Benutzer auf mehrere spezifische IP-Adressen und -bereiche:

AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1

• Deaktivieren aller Benutzer mit Ausnahme von benannten Benutzern von bestimmten IP-Adressen:

AllowUsers sammy@203.0.113.1 alex@203.0.113.2<^>

• Beschränken eines bestimmten Benutzers auf eine bestimmte IP-Adresse, während es allen anderen Benutzern weiterhin erlaubt ist, sich ohne Beschränkungen anzumelden:

Match User ashley
  AllowUsers ashley@203.0.113.1

Wenn Sie Ihre Konfiguration abgeschlossen haben, fügen Sie sie unten in Ihre OpenSSH-Server-Konfigurationsdatei ein:

AllowUsers *@203.0.113.1

Speichern und schließen Sie die Datei. Anschließend testen Sie Ihre Konfigurationssyntax:

sudo sshd -t

Wenn keine Fehler gemeldet werden, können Sie OpenSSH-Server neu laden, um Ihre Konfiguration anzuwenden:

sudo service sshd reload

In diesem Schritt haben Sie eine IP-Adressen-Zulassungsliste auf Ihrem OpenSSH-Server implementiert. Als Nächstes beschränken Sie die Shell eines Benutzers, um die Befehle, die er verwenden darf, einzugrenzen.

Schritt 3 — Beschränken der Shell eines Benutzers

In diesem Schritt sehen Sie sich die verschiedenen Optionen zur Beschränkung der Shell eines SSH-Benutzers an.

Neben dem Remote-Shell-Zugriff eignet sich SSH auch hervorragend für die Übertragung von Dateien und anderen Daten, z. B. über SFTP. Es kann jedoch sein, dass Sie Benutzern nicht immer vollständigen Shell-Zugriff gewähren möchten, wenn sie nur in der Lage sein müssen, Datenübertragungen durchzuführen.

Es gibt mehrere Konfigurationen im OpenSSH-Server, mit denen Sie die Shell-Umgebung für bestimmte Benutzer beschränken können. In dieser Anleitung werden wird diese zum Beispiel verwenden, um Nur-SFTP-Benutzer zu erstellen.

Zunächst können Sie die Shell /usr/sbin/nologin verwenden, um interaktive Anmeldungen für bestimmte Benutzerkonten zu deaktivieren, während nicht-interaktive Sitzungen wie Dateiübertragungen, Tunneling usw. weiterhin funktionieren können.

Um einen neuen Benutzer mit der nologin-Shell zu erstellen, verwenden Sie folgenden Befehl:

sudo adduser --shell /usr/sbin/nologin alex

Alternativ können Sie die Shell eines vorhandenen Benutzers zu nologin ändern:

sudo usermod --shell /usr/sbin/nologin sammy

Wenn Sie dann versuchen, sich interaktiv als einen dieser Benutzer anzumelden, wird die Anfrage abgelehnt:

sudo su alex

Sie sehen eine Ausgabe mit einer Meldung, die der folgenden ähnelt:

Output
This account is currently not available.

Trotz der Ablehnungsmeldung zu interaktiven Anmeldungen werden andere Aktionen wie Dateiübertragungen weiterhin zugelassen.

Als Nächstes sollten Sie die Verwendung der nologin-Shell mit einigen zusätzlichen Konfigurationsoptionen kombinieren, um die entsprechenden Benutzerkonten weiter zu beschränken.

Öffnen Sie zunächst die Konfigurationsdatei des OpenSSH-Servers in Ihrem bevorzugten Texteditor:

sudo nano /etc/ssh/sshd_config

Es gibt zwei Konfigurationsoptionen, die Sie gemeinsam implementieren können, um ein streng beschränktes Nur-SFTP-Benutzerkonto zu erstellen: ForceCommand internal-sftp und ChrootDirectory.

Die Option ForceCommand innerhalb OpenSSH-Server zwingt einen Benutzer, einen bestimmten Befehl bei der Anmeldung auszuführen. Das kann für bestimmte Machine-to-Machine-Kommunikationen nützlich sein, oder um ein bestimmtes Programm zwangsweise zu starten.

In diesem Fall ist der Befehl internal-sftp jedoch besonders nützlich. Dabei handelt es sich um eine spezielle Funktion des OpenSSH-Servers, die an Ort und Stelle einen grundlegenden SFTP-Daemon startet, der keine unterstützenden Systemdateien oder Konfiguration benötigt.

Idealerweise kombinieren Sie diese mit der Option ChrootDirectory, die das erkannte Root-Verzeichnis für einen bestimmten Benutzer aufhebt bzw. ändert, wodurch dieser im Wesentlichen auf ein bestimmtes Verzeichnis im System beschränkt wird.

Fügen Sie dazu den folgenden Konfigurationsabschnitt in Ihre OpenSSH-Server-Konfigurationsdatei ein:

Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /home/alex/

Speichern und schließen Sie Ihre Konfigurationsdatei, und testen Sie die Konfiguration erneut:

sudo sshd -t

Wenn es keine Fehler gibt, können Sie dann Ihre Konfiguration anwenden:

sudo service sshd reload

Dadurch wurde eine robuste Konfiguration für den Benutzer alex erstellt, bei der interaktive Anmeldungen deaktiviert sind, und alle SFTP-Aktivitäten sind auf das Stammverzeichnis des Benutzers beschränkt. Aus der Perspektive des Benutzers ist das Verzeichnis des Systems - d. h. / - ihr Stammverzeichnis. Er ist nicht in der Lage, das Dateisystem nach oben zu durchlaufen, um auf andere Bereiche zuzugreifen.

Sie haben die nologin-Shell für einen Benutzer implementiert und dann eine Konfiguration erstellt, um den SFTP-Zugriff auf ein bestimmtes Verzeichnis zu beschränken.

Schritt 4 — Erweiterte Härtung

In diesem abschließenden Schritt implementieren Sie verschiedene zusätzliche Härtungsmaßnahmen, um den Zugriff auf Ihren SSH-Server so sicher wie möglich zu machen.

Eine weniger bekannte Funktion des OpenSSH-Servers ist die Fähigkeit, Beschränkungen auf einer Pro-Schlüssel-Basis aufzuerlegen. Das sind Beschränkungen, die nur für bestimmte öffentliche Schlüssel gelten, die in der Datei .ssh/authorized_keys vorhanden sind. Das ist besonders nützlich, um den Zugriff bei Machine-to-Machine-Sitzungen zu kontrollieren und um auch Nicht-Sudo-Benutzern zu ermöglichen, die Beschränkungen für das eigene Benutzerkonto zu kontrollieren.

Sie können die meisten dieser Beschränkungen auf System- oder Benutzerebene anwenden. Es ist jedoch immer noch von Vorteil, sie auch auf der Schlüsselebene zu implementieren, um eine tief greifende Abwehr und eine zusätzliche Ausfallsicherheit im Falle versehentlicher systemweiter Konfigurationsfehler zu gewährleisten.

Öffnen Sie zunächst Ihre .ssh/authorized_keys-Datei in Ihrem bevorzugten Texteditor:

nano ~/.ssh/authorized_keys

Nach dem Öffnen Ihrer authorized_keys-Datei sehen Sie, dass jede Zeile einen öffentlichen SSH-Schlüssel enthält, der höchstwahrscheinlich mit etwas Ähnlichem wie ssh-rsa AAAB... beginnt. Weitere Konfigurationsoptionen können am Anfang der Zeile hinzugefügt werden; diese gelten nur für erfolgreiche Authentifizierungen mit diesem bestimmten öffentlichen Schlüssel.

Folgende Beschränkungsoptionen stehen zur Verfügung:

• no-agent-forwarding: Deaktivieren des SSH-Agent-Forwardings.
• no-port-forwarding: Deaktivieren des Port-Forwardings.
• no-pty: Deaktivieren der Fähigkeit, einen tty zuzuweisen (d. h. eine Shell zu starten).
• no-user-rc: Verhindern der Ausführung der Datei ~/.ssh/rc.
• no-X11-forwarding: Deaktivieren des X11-Display-Forwardings.

Sie können diese anwenden, um bestimmte SSH-Funktionen für bestimmte Schlüssel zu deaktivieren. Um zum Beispiel Agent-Forwarding und X11-Forwarding für einen Schlüssel zu deaktivieren, verwenden Sie die folgende Konfiguration:

no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...

Standardmäßig arbeiten diese Konfigurationen nach der Methode „standardmäßig zulassen, ausnahmsweise blockieren“. Es ist jedoch auch möglich, „standardmäßig blockieren, ausnahmsweise zulassen“ zu verwenden, was zur Gewährleistung der Sicherheit generell vorzuziehen ist.

Hierzu können Sie die Option restrict verwenden, die implizit alle SSH-Funktionen für den spezifischen Schlüssel ablehnt und verlangt, dass diese nur dort neu aktiviert werden, wo sie unbedingt erforderlich sind. Sie können Funktionen mit denselben zuvor in dieser Anleitung beschriebenen Konfigurationsoptionen neu aktivieren, jedoch ohne das Präfix no-.

Um z. B. alle SSH-Funktionen außer das X11-Display-Forwarding für einen bestimmten Schlüssel zu deaktivieren, können Sie die folgende Konfiguration verwenden:

restrict,X11-forwarding ssh-rsa AAAB...

Ziehen Sie auch die Verwendung der Option command in Betracht, die der in Schritt 3 beschriebenen Option ForceCommand sehr ähnelt. Sie bietet keinen direkten Vorteil, wenn Sie bereits ForceCommand nutzen, dient aber als eine gute tief greifende Abwehr für den unwahrscheinlichen Fall, dass die Hauptkonfigurationsdatei des OpenSSH-Servers überschrieben, bearbeitet etc. wird.

Um beispielsweise Benutzer, die sich über einen bestimmten Schlüssel authentifizieren, zu zwingen, bei der Anmeldung einen bestimmten Befehl auszuführen, können Sie die folgende Konfiguration hinzufügen:

command="top" ssh-rsa AAAB...

Um schließlich die in Schritt 3 erstellten Pro-Schlüssel-Beschränkungen für den Nur-SFTP-Benutzer optimal zu nutzen, können Sie die folgende Konfiguration verwenden:

restrict,command="false" ssh-rsa AAAB...

Die Option restrict deaktiviert jeden interaktiven Zugriff. Die Option command="false" fungiert als zweite Verteidigungslinie für den Fall, dass die Option ForceCommand oder die nologin-Shell fehlschlagen sollten.

Speichern und schließen Sie die Datei, um die Konfiguration anzuwenden. Diese wird sofort für alle neuen Anmeldungen wirksam. Daher müssen Sie OpenSSH nicht manuell neu laden.

In diesem abschließenden Schritt haben Sie einige zusätzliche erweiterte Härtungsmaßnahmen für OpenSSH-Server implementiert, indem Sie die benutzerdefinierten Optionen in Ihrer .ssh/authorized_keys Datei verwendet haben.

Zusammenfassung

In diesem Artikel haben Sie die Konfiguration Ihres OpenSSH-Servers geprüft und verschiedene Härtungsmaßnahmen implementiert, um Ihren Server zu sichern.

Dadurch wurde die Angriffsfläche Ihres Servers insgesamt verringert, indem nicht genutzte Funktionen deaktiviert und der Zugriff bestimmter Benutzer gesperrt wurde.

Konsultieren Sie bei Bedarf auch die manuellen Seiten für OpenSSH-Server und die zugehörige Konfigurationsdatei, um mögliche weitere Optimierungen zu finden, die Sie eventuell vornehmen möchten.