Wie härtet man einen SSH-Server?

119

Welche Maßnahmen kann / sollte ich ergreifen, um sicherzustellen, dass die Sicherheit rund um meinen SSH-Server absolut undurchlässig ist?

Dies wird von Anfang an Community-Wiki sein, also lasst uns sehen, was die Leute tun, um ihre Server zu sichern.

    
LassePoulsen 30.01.2015, 17:27

13 Antworten

21

Machen Sie die IP-Adressen des sshd-Block-Clients, die keine korrekten Anmeldeinformationen liefern konnten " DenyHØsts " kann diese Aufgabe sehr effektiv erledigen. Ich habe dies auf all meinen Linux-Boxen installiert, die irgendwie von der großen Außenseite erreichbar sind.

Dadurch wird sichergestellt, dass Force-Angriffe auf die SSHD nicht effektiv sind, aber denken Sie daran (!), damit Sie sich am Ende selbst sperren können, wenn Sie Ihr Passwort vergessen. Dies kann ein Problem auf einem Remote-Server sein, auf den Sie keinen Zugriff haben.

    
LassePoulsen 10.06.2016, 23:17
100

Verwenden Sie öffentliche / private Schlüsselpaare für die Authentifizierung anstelle von Kennwörtern.

  1. Erstellen Sie einen Passphrasen-geschützten SSH-Schlüssel für jeden Computer, der auf den Server zugreifen muss:

    ssh-keygen

  2. Erlaube öffentlichen Schlüssel-SSH-Zugriff von den erlaubten Computern:

    Kopieren Sie den Inhalt von ~/.ssh/id_rsa.pub von jedem Computer in einzelne Zeilen von ~/.ssh/authorized_keys auf dem Server, oder führen Sie ssh-copy-id [server IP address] auf jedem Computer aus, dem Sie Zugriff gewähren (Sie müssen das Serverpasswort im Eingabeaufforderung).

  3. Passwort deaktivieren SSH-Zugriff:

    Öffnen Sie /etc/ssh/sshd_config , suchen Sie die Zeile #PasswordAuthentication yes und ändern Sie sie in PasswordAuthentication no . Starten Sie den SSH-Server-Daemon neu, um die Änderung zu übernehmen ( sudo service ssh restart ).

Nun besteht die einzige Möglichkeit, SSH auf dem Server zu verwenden, darin, einen Schlüssel zu verwenden, der einer Zeile in ~/.ssh/authorized_keys entspricht. Mit dieser Methode kümmern sich ich nicht um Brute-Force-Angriffe, denn selbst wenn sie mein Passwort erraten, werden sie zurückgewiesen. Brute-Forcing eines öffentlichen / privaten Schlüsselpaares ist unmöglich mit der heutigen Technologie.

    
Evan Kroske 08.06.2016 02:31
67

Ich würde vorschlagen:

  • Verwenden Sie fail2ban , um Brute-Force-Anmeldeversuche zu verhindern.

  • Deaktivieren der Anmeldung als root über SSH. Dies bedeutet, dass ein Angreifer sowohl den Benutzernamen als auch das Passwort herausfinden muss, was einen Angriff schwieriger macht.

    Fügen Sie PermitRootLogin no zu Ihrem /etc/ssh/sshd_config hinzu.

  • Begrenzung der Benutzer, die SSH zum Server haben können. Entweder nach Gruppen oder nur nach bestimmten Benutzern.

    Fügen Sie AllowGroups group1 group2 oder AllowUsers user1 user2 hinzu, um einzuschränken, wer SSH an den Server senden kann.

Mark Davidson 08.06.2016 02:07
22

Andere Antworten bieten Sicherheit, aber Sie können eine Sache tun, die Ihre Protokolle leiser macht und es weniger wahrscheinlich macht, dass Sie aus Ihrem Konto ausgeschlossen werden:

Verschieben Sie den Server von Port 22 zu einem anderen. Entweder an Ihrem Gateway oder auf dem Server.

Es erhöht nicht die Sicherheit, aber bedeutet, dass alle zufälligen Internet-Scanner Ihre Log-Dateien nicht überladen.

    
Douglas Leeder 08.06.2016 02:15
21

Aktivieren Sie die Zwei-Faktor-Authentifizierung mit HOTP oder TOTP . Dies ist ab 13.10 verfügbar.

Dies beinhaltet die Verwendung der Authentifizierung mit öffentlichem Schlüssel über die Passwortauthentifizierung wie in einer anderen Antwort hier, erfordert aber auch, dass der Benutzer beweist, dass er zusätzlich zu seinem privaten Schlüssel sein zweites Faktor-Gerät besitzt.

Zusammenfassung:

  1. sudo apt-get install libpam-google-authenticator

  2. Lassen Sie jeden Benutzer den Befehl google-authenticator ausführen, der ~/.google-authenticator generiert und ihnen hilft, ihre zwei Faktor-Geräte zu konfigurieren (z. B. die Google Authenticator Android App).

  3. Bearbeite /etc/ssh/sshd_config und setze:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Führen Sie sudo service ssh reload aus, um Ihre Änderungen in /etc/ssh/sshd_config zu übernehmen.

  5. Bearbeiten Sie /etc/pam.d/sshd und ersetzen Sie die Zeile:

    @include common-auth
    

    mit:

    auth required pam_google_authenticator.so
    

Weitere Details zu den verschiedenen Konfigurationsoptionen finden Sie in meinem Blogpost aus dem letzten Jahr: Bessere Zwei-Faktor-SSH-Authentifizierung auf Ubuntu .

    
Robie Basak 23.05.2017 00:29
19

Hier ist eine einfache Sache: Installieren Sie ufw (die "unkomplizierte Firewall") und verwenden Sie sie, um eingehende Verbindungen zu bewerten.

Geben Sie an einer Eingabeaufforderung Folgendes ein:

$ sudo ufw limit OpenSSH 

Wenn ufw nicht installiert ist, führen Sie dies aus und versuchen Sie es erneut:

$ sudo aptitude install ufw 

Viele Angreifer werden versuchen, Ihren SSH-Server zu verwenden, um Passwörter zu erzwingen. Dies ermöglicht nur 6 Verbindungen alle 30 Sekunden von der gleichen IP-Adresse.

    
mpontillo 15.08.2010 00:45
12

Wenn ich zusätzliche Sicherheit haben möchte oder auf SSH-Server innerhalb eines Unternehmensnetzwerkes zugreifen möchte, habe ich einen versteckt Service mit der Anonymisierungssoftware Tor .

  1. Installieren Sie Tor und richten Sie den SSH-Server selbst ein.
  2. Stellen Sie sicher, dass sshd nur auf localhost hört.
  3. Öffnen Sie /etc/tor/torrc . Setzen Sie HiddenServiceDir /var/lib/tor/ssh und HiddenServicePort 22 127.0.0.1:22 .
  4. Schauen Sie sich var/lib/tor/ssh/hostname an. Es gibt einen Namen wie d6frsudqtx123vxf.onion . Dies ist die Adresse des versteckten Dienstes.
  5. Öffnen Sie $HOME/.ssh/config und fügen Sie einige Zeilen hinzu:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Außerdem brauche ich Tor auf meinem lokalen Rechner. Wenn es installiert ist, kann ich ssh myhost eingeben und SSH öffnet eine Verbindung über Tor. Der SSH-Server auf der anderen Seite öffnet seinen Port nur auf localhost. Also kann niemand es über "normales Internet" verbinden.

    
qbi 08.06.2016 02:10
8

Zu diesem Thema gibt es einen Debian-Administrationsartikel. Es behandelt grundlegende SSH-Server-Konfiguration und auch Firewall-Regeln. Dies könnte auch für einen SSH-Server interessant sein.

Siehe dort Artikel: SSH-Zugang sicher halten .

    
Huygens 12.10.2010 00:35
6

Mein Ansatz zur SSH-Härtung ist ... komplex. Die folgenden Punkte beziehen sich auf die Art und Weise, wie ich es tue, von der äußersten Grenze meines Netzwerks zu den Servern selbst.

  1. Border-Level-Filterung des Datenverkehrs durch IDS / IPS mit bekannten Service-Scannern und Signaturen in der Blockliste. Das erreiche ich mit Snort über meine Border-Firewall (das ist mein Ansatz, ein pfSense Gerät). Manchmal kann ich das aber nicht, zB mit meinen VPSes.

  2. Firewall / Netzwerkfilterung der SSH-Ports. Ich erlaube explizit nur bestimmten Systemen, auf meine SSH-Server zuzugreifen. Dies geschieht entweder über eine pfSense-Firewall an der Grenze meines Netzwerks oder die Firewalls auf jedem Server werden explizit konfiguriert. Es gibt Fälle, in denen ich dies nicht tun kann (was fast nie der Fall ist, außer in privaten Pen-Testing- oder Sicherheitstestumgebungen, in denen Firewalls nicht helfen, Dinge zu testen).

  3. In Verbindung mit meinem pfSense oder einer Grenz-Firewall, die das interne Netzwerk NAT-basiert und sich vom Internet und den Systemen trennt, VPN-Only Access to Servers . Ich brauche VPN in meine Netzwerke, um zu den Servern zu gelangen, da es keine Ports im Internet gibt. Dies funktioniert definitiv nicht für alle meine VPSes, aber in Verbindung mit # 2 kann ich ein VPS als "Gateway" durch VPN in diesen Server setzen und dann erlauben, dass es IPs zu den anderen Boxen gibt. Auf diese Weise weiß ich genau, was SSH kann oder nicht - meine eine Box ist das VPN. (Oder, in meinem Heimnetzwerk hinter pfSense, meine VPN-Verbindung, und ich bin die einzige mit VPN-Zugang).

  4. Wo # 3 nicht möglich ist, fail2ban, das nach 4 fehlgeschlagenen Versuchen blockiert wird und die IPs für eine Stunde oder länger blockieren ist ein angemessener Schutz gegen Leute, die ständig mit Bruteforcing angreifen - nur block em an der Firewall automatisch mit fail2ban und meh. Die Konfiguration von fail2ban ist jedoch eine Qual ...

  5. Port-Verschleierung durch Ändern des SSH-Ports. Allerdings das ist KEINE gute Idee, auch ohne zusätzliche Sicherheitsmaßnahmen auszukommen - das Mantra von " Sicherheit durch Obscurity "wurde bereits in vielen Fällen widerlegt und bestritten. Ich habe dies in Verbindung mit IDS / IPS und Netzwerkfilterung gemacht, aber es ist immer noch eine SEHR schlechte Sache, es alleine zu tun.

  6. OBLIGATORISCHE Zwei-Faktor-Authentifizierung über die Zwei-Faktor-Authentifizierungslösungen von Duo Security . Jeder einzelne Auf meinen SSH-Servern ist Duo so konfiguriert, dass, um überhaupt hineinzukommen, 2FA-Prompts passieren und ich jeden Zugriff bestätigen muss. (Dies ist die ultimative hilfreiche Funktion - denn selbst wenn jemand meine Passphrase hat oder einbricht, kommt er nicht an den Duo PAM Plugins vorbei). Dies ist einer der größten Schutzmechanismen auf meinen SSH-Servern vor unberechtigtem Zugriff - jeder Benutzer muss sich an einen konfigurierten Benutzer in Duo binden, und da ich einen restriktiven Satz habe, können keine neuen Benutzer im System registriert werden.

Meine zwei Cent zur Sicherung von SSH. Oder zumindest meine Gedanken zur Annäherung.

    
Thomas W. 10.06.2016 23:14
1

Sie können die FreeOTP App von RedHat aus testen, anstatt Google Authenticator zu verwenden. Manchmal, wenn Sie die App aktualisieren, sperren sie Sie aus! ; -)

Wenn Sie andere Hardwaretokens wie ein Yubikey oder eToken PASS oder NG verwenden möchten oder wenn Sie viele Benutzer oder viele Server haben, möchten Sie vielleicht ein OpenSource Zwei-Faktor-Authentifizierungs-Backend verwenden.

In letzter Zeit schrieb ich einen Howto dazu .

    
cornelinux 08.06.2016 02:12
0

Ich habe kürzlich ein kleines Tutorial geschrieben. Im Grunde müssen Sie PKI verwenden und mein Tutorial zeigt auch, wie Sie die Zwei-Faktor-Authentifizierung für noch mehr Sicherheit nutzen können. Selbst wenn Sie keines dieser Dinge verwenden, gibt es auch einige Leckerbissen über die Sicherung des Servers, indem schwache Cipher Suites und andere Grundlagen entfernt werden. Pfandrecht

    
01000101 19.05.2015 15:52
0

Bei einer großen Anzahl von Benutzern / Zertifikaten sollte die LDAP-Integration berücksichtigt werden. Große Organisationen verwenden LDAP als Repository für Benutzeranmeldeinformationen und Zertifikate, die auf Ausweisen oder Fobs gespeichert sind, unabhängig davon, ob die Zertifikate zur Authentifizierung oder zum Signieren von E-Mails verwendet werden. Beispiele hierfür sind openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Computer und Gruppen können auch in LDAP verwaltet werden, wodurch eine zentrale Verwaltung der Anmeldeinformationen ermöglicht wird. Auf diese Weise können Help Desks eine zentrale Anlaufstelle für große Bevölkerungsgruppen bieten.

Hier ist ein Link zur CentOS-Integration: Pfandrecht

    
weller1 29.04.2016 15:50
0

Sie können auch basierend auf dem Ursprungsland mithilfe der geoIP-Datenbank blockieren.

Grundsätzlich, wenn Sie in den USA leben, gibt es keinen Grund für jemanden in Russland, sich mit Ihrem SSH zu verbinden, damit diese automatisch blockiert werden.

Das Skript finden Sie hier: Pfandrecht

Sie können auch iptables-Befehle hinzufügen (die ich für meine Tröpfchen gemacht habe), um den gesamten Verkehr von diesen IPs automatisch zu löschen.

    
Michael A Mike 10.08.2017 07:09

Tags und Links