Frage:
Welche Methoden stehen zur Sicherung von SSH zur Verfügung?
Olivier Lalonde
2010-11-12 04:26:43 UTC
view on stackexchange narkive permalink

Welche Methoden stehen zum Sichern von SSH zur Verfügung?

http://library.linode.com/security/basics
Acht antworten:
#1
+35
Mark Davidson
2010-11-12 04:45:31 UTC
view on stackexchange narkive permalink
    • Root-Anmeldung deaktivieren - Die meisten automatisierten Angriffe konzentrieren sich auf das Root-Konto. Das Ablehnen von Anmeldungen von diesem Konto ist daher ein guter Ausgangspunkt.

    • Nur bestimmte Gruppen / Benutzer zulassen - Beschränken Sie, welche Benutzer und Gruppen SSH für das System verwenden können.

    • Begrenzung nach IP oder IP-Bereich - Eine der effektivsten Möglichkeiten, Ihr System vor SSH-Angriffen zu schützen.

    • Schlüsselbasierte Authentifizierung verwenden - Wie von Olivier beschrieben

    • Verwenden Sie fail2ban - fail2ban überwacht versuchte SSH-Anmeldungen und blockiert nach einer bestimmten Anzahl fehlgeschlagener Versuche die IP-Adresse des Angreifers für einen festgelegten Zeitraum. Dies kann eine sehr effektive Methode sein, um Angreifer zu verlangsamen.

Stellen Sie außerdem sicher, dass Sie alle neuen Sicherheitsfunktionen in sshd verwenden. Derzeit bedeutet dies "UsePrivilegeSeparation yes" und "Compression verzögert" - beide tragen zum Schutz vor Codefehlern bei.
Richten Sie es mit Port Knocking (einschließlich) ein oder ändern Sie den SSH-Port in einen anderen, nicht verwendeten, bekannten Port (kein High-Port, oder $ user kann seinen eigenen Dienst ausführen, der diesen Port überwacht und Anmeldeinformationen für privilegiertere Benutzer sammelt ). Fügen Sie eine Zwei-Faktor-Authentifizierung (oder mindestens eine Zweikanal-Authentifizierung) hinzu.
#2
+18
bstpierre
2011-10-29 02:15:35 UTC
view on stackexchange narkive permalink

Die anderen Antworten konzentrieren sich auf die Sicherung des Servers - was wichtig ist, aber auch die Clientseite verdient einen gewissen Schutz:

  • In / etc / ssh / ssh_config (oder ~ / .ssh / config) Setzen Sie StrictHostKeyChecking auf yes oder ask . Dies bietet einen gewissen Schutz vor Man-in-the-Middle-Angriffen, indem überprüft wird, ob der Server, mit dem Sie eine Verbindung herstellen, der erwartete ist.
  • Wenn Sie Ihrer DNS-Zone Einträge hinzufügen können, veröffentlichen Sie einen SSHFP-Eintrag und Setzen Sie VerifyHostKeyDNS auf yes oder ask . Der Client ruft das SSHFP vom DNS ab und überprüft den Fingerabdruck. (Beachten Sie, dass Sie immer noch anfällig sind, wenn Ihr Angreifer DNS kontrolliert.)
  • Protokollversion 2 erzwingen. setze Protokoll 2 in / etc / ssh / ssh_config - der Standardwert ist 2,1 , wodurch auf v1 zurückgegriffen werden kann, wenn v2 nicht verfügbar ist.
  • Ziehen Sie Schlüssel für die Anmeldung Passwörtern vor. Verwenden Sie ein sicheres Passwort für Ihre SSH-Schlüssel. Verwenden Sie Schlüssel mit ausreichender Länge (Anzahl der Bits).
    • Wenn Benutzer SSH-Schlüssel bereitstellen, überprüfen Sie die Kennwortstärke, indem Sie john auf den Schlüsseln ausführen.
  • Verwenden Sie ein Hardware-Token, um den Schlüssel zu entsperren, anstatt das Kennwort einzugeben (um Keylogger von &-Schulter-Surfern zu vermeiden).
  • Stellen Sie sicher, dass UseBlacklistedKeys no (dies ist die Standardeinstellung). Dies verhindert, dass Sie Schlüssel auf der schwarzen Liste verwenden, die während schwacher Debian-openssl-Pakete generiert wurden. Überprüfen Sie die Host- und Benutzerschlüssel mit ssh-vulnkeys. Auf von Debian abgeleiteten Systemen (z. B. Ubuntu) können Sie die Pakete openssh-blacklist und openssh-blacklist-extra installieren.
  • Stellen Sie sicher, dass CheckHostIP yes code ist > (Standardeinstellung). Dadurch überprüft der Client die IP des Hosts anhand bekannter_Hosts, um den Schutz vor DNS-Spoofing zu erhöhen.
  • Setzen Sie HashKnownHosts auf yes . Dies verhindert, dass Informationen aus Ihrer Datei "unknown_hosts" verloren gehen.
#3
+11
Olivier Lalonde
2010-11-12 04:31:02 UTC
view on stackexchange narkive permalink

Deaktivieren kennwortbasierter Anmeldungen

Durch Ersetzen der kennwortbasierten Authentifizierung durch schlüsselbasierte Authentifizierung wird Folgendes verhindert:

  • Brute - Versuche zum Knacken von Passwörtern erzwingen.
  • Schulterangriffe: Personen, die sich hinterher schleichen, während Sie Ihr Passwort eingeben.
  • Key Logger
Wenn Sie Hardware-Token benötigen, erhalten Sie diese Vorteile. Aber der Link, auf den Sie verweisen, handelt von Softwareschlüsseln und lässt sogar die Idee offen, keine Passphrase auf dem Schlüssel zu haben - yikes! Ohne Hardware-Token erhalten ungeschützte Schlüssel oder Tastatur-Logger weiterhin Ihren Schlüssel oder Ihr Passwort, ebenso wie zeitlich gut abgestimmte Schulter-Surfer oder Brute-Force-Angriffe.
#4
+7
Aviah Laor
2010-11-12 11:10:38 UTC
view on stackexchange narkive permalink

Eine andere Sache, wenn nur wenige Personen auf SSH erlaubt sind, machen Sie bashrc eine E-Mail, wenn sich jemand bei SSH anmeldet

Wenn jemand weiß, dass Sie das tun, ist es nicht schwer, herumzukommen.`echo mv .bashrc .bashrc_old |ssh hostname` verschiebt die `.bashrc` aus dem Weg, so dass Sie dann eine interaktive Anmeldung durchführen können, ohne dass diese .bashrc` ausgeführt wird.(Für einen echten Angriff möchten Sie dies erweitern, um auch ".profile" und ".bash_profile" zu verschieben, oder eine der vielen anderen Techniken verwenden, um alles zu tun, was Sie tun müssen, ohne diese auszuführen.)
#5
+6
Magnus
2010-11-12 04:38:40 UTC
view on stackexchange narkive permalink

Zunächst sollten Sie Kennwörter nicht zulassen und die Authentifizierung nur mit RSA-Schlüsseln zulassen. Dies macht Brute-Force-Angriffe unmöglich. Leute werden es jedoch weiterhin versuchen, daher sollten Sie die Anmeldeversuche begrenzen und möglicherweise den Port ändern, um Ihre Bandbreite zu sparen. Dieser Ansatz beruht darauf, dass Sie Ihren Benutzern vertrauen, dass sie ihre privaten Schlüssel verschlüsseln und sichern.

Sie sollten die Root-Anmeldung nicht remote zulassen. Verwenden Sie su oder sudo, sobald Sie angemeldet sind.

Es kann eine gute Idee sein, zu verhindern, dass Benutzer ssh über Ihren Gateway-Server zu internen Servern tunneln. Dies kann verhindern, dass Ihre internen Server dem Internet ausgesetzt werden.

Sie sollten Version 2 von SSH verwenden.

#6
+6
Thomas Pornin
2012-11-25 08:26:32 UTC
view on stackexchange narkive permalink

Mir fällt auf, dass keine der anderen Antworten einen sehr wichtigen Punkt für die Sicherung von SSH betrifft: Schulung Ihrer Benutzer . Was auch immer Sie tun, wenn die Benutzer nicht lernen, vernünftig zu reagieren, wenn etwas faul passiert, sind Sie zum Scheitern verurteilt. Zumindest müssen Benutzer über das Geschäft mit der Verarbeitung von Serverschlüsseln informiert sein (wenn sie zum ersten Mal eine Verbindung zu einem bestimmten Server herstellen, müssen sie den Schlüsselfingerabdruck mit einer zuverlässigen Quelle überprüfen und SSH vor einem Schlüssel warnen das hat sich geändert, sie dürfen die Warnung nicht umgehen.

Technologie kann Sie nur so weit bringen; Solange ein Mensch in den Prozess involviert ist, ist das Sicherheitsbewusstsein dieses Benutzers eine harte Grenze für das Sicherheitsniveau, das Sie möglicherweise erreichen möchten.

#7
+3
nowen
2010-12-02 22:10:49 UTC
view on stackexchange narkive permalink

Auf dem Server gibt es eine neue Option, die Passphrasen für die Clientschlüssel erfordert. Ich denke, das ist eine sehr gute Idee. Sie kennen die Komplexität der Passphrase jedoch immer noch nicht und Benutzer könnten den Client möglicherweise neu kompilieren, um dies zu fälschen.

#8
+2
ewalshe
2010-11-13 05:25:25 UTC
view on stackexchange narkive permalink

Wie alle sagen: Deaktivieren Sie immer die Root-Anmeldung, ändern Sie die Standardportnummer (obwohl dies die Verwendung einiger SFTP-Clients erschweren kann) und akzeptieren Sie nur die schlüsselbasierte Authentifizierung.

Auch wenn Sie einen Schlüssel ändern Größen in sshd_config oder geben Sie eine Schlüsselbitgröße an, wenn Sie ssh-keygen ausführen. Sie sollten die von Zeit zu Zeit angegebenen Schlüsselgrößen überprüfen.

Damals, als ssh-keygen standardmäßig 1024-Bit-RSA-Schlüssel generierte, die ich verwendet habe Verwenden Sie die Option -b, um 1536-Bit-Schlüssel zu generieren. Im Laufe der Zeit änderte sich die Standardeinstellung, um 2048-Bit-Schlüssel zu generieren, und ich generierte immer noch 1536-Bit-Schlüssel.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...