it-swarm-eu.dev

Wie härtet man einen SSH-Server ab?

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 ein Community-Wiki sein. Sehen wir uns also an, was die Leute tun, um ihre Server zu sichern.

128
LassePoulsen

Stellen Sie sicher, dass die IP-Adressen des sshd-Block-Clients, die keine korrekten Anmeldeinformationen liefern " DenyHØsts ", diese Aufgabe recht effektiv ausführen können. Ich habe dies auf allen meinen Linux-Boxen installiert, die irgendwie von außen erreichbar sind.

Dies stellt sicher, dass erzwungene Angriffe auf die SSHD nicht effektiv sind. Denken Sie jedoch daran, dass Sie sich auf diese Weise selbst aussperren können, wenn Sie Ihr Passwort vergessen. Dies kann ein Problem auf einem Remoteserver sein, auf den Sie keinen Zugriff haben.

21
LassePoulsen

Verwenden Sie zur Authentifizierung öffentliche/private Schlüsselpaare anstelle von Kennwörtern.

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

    ssh-keygen

  2. Zulassen des SSH-Zugriffs mit öffentlichem Schlüssel von den zulässigen Computern aus:

    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, auf den Sie Zugriff gewähren (Sie müssen den Server eingeben) Passwort an der Eingabeaufforderung).

  3. Passwort-SSH-Zugang deaktivieren:

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

Die einzige Möglichkeit, SSH auf den Server zu übertragen, besteht darin, einen Schlüssel zu verwenden, der mit einer Zeile in ~/.ssh/authorized_keys übereinstimmt. Wenn Sie diese Methode verwenden, interessieren sich I nicht für Brute-Force-Angriffe, denn selbst wenn sie mein Passwort erraten, wird es abgelehnt. Brute-Forcen eines öffentlichen/privaten Schlüsselpaares ist unmöglich mit der heutigen Technologie.

108
Asa Ayers

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 Kennwort ermitteln musste, um einen Angriff zu erschweren.

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

  • Einschränkung der Benutzer, die SSH auf den Server ausführen können. Entweder nach Gruppe oder nur nach bestimmten Benutzern.

    Fügen Sie AllowGroups group1 group2 oder AllowUsers user1 user2 hinzu, um zu begrenzen, wer SSH auf dem Server ausführen darf.

72
Mark Davidson

Andere Antworten bieten Sicherheit, aber es gibt eine Möglichkeit, die Ihre Protokolle leiser macht und die Wahrscheinlichkeit verringert, dass Sie von Ihrem Konto ausgeschlossen werden:

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

Dies erhöht nicht die Sicherheit, bedeutet jedoch, dass alle zufälligen Internet-Scanner Ihre Protokolldateien nicht überladen.

24
Douglas Leeder

Aktivieren Sie die Zwei-Faktor-Authentifizierung mit HOTP oder TOTP . Dies ist ab 13.10 Uhr möglich.

Dies schließt die Verwendung der Authentifizierung mit öffentlichem Schlüssel anstelle der Kennwortauthentifizierung wie in einer anderen Antwort hier ein, erfordert jedoch auch den Nachweis, dass der Benutzer sein Zweitfaktorgerät zusätzlich zu seinem privaten Schlüssel 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 ihn bei der Konfiguration seiner Geräte mit zwei Faktoren unterstützt (z. B. die App Google Authenticator Android).

  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 an /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 verschiedenen Konfigurationsoptionen finden Sie in meinem Blogbeitrag vom letzten Jahr: Besser zwei Faktor SSH-Authentifizierung unter Ubunt .

23
Robie Basak

Hier ist eine einfache Möglichkeit: Installieren Sie fw (die "unkomplizierte Firewall") und verwenden Sie sie, um eingehende Verbindungen einzuschränken.

Geben Sie an einer Eingabeaufforderung Folgendes ein:

$ Sudo ufw limit OpenSSH 

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

$ Sudo aptitude install ufw 

Viele Angreifer versuchen, mithilfe Ihres SSH-Servers Passwörter zu erzwingen. Dies erlaubt nur 6 Verbindungen alle 30 Sekunden von derselben IP-Adresse.

20
mpontillo

Wenn ich zusätzliche Sicherheit haben möchte oder tief in einem Unternehmensnetzwerk auf SSH-Server zugreifen muss, richte ich mit der Anonymisierungssoftware Tor einen versteckten Dienst ein.

  1. Installieren Sie Tor und richten Sie den SSH-Server selbst ein.
  2. Stellen Sie sicher, dass sshd nur localhost hört.
  3. Öffne /etc/tor/torrc. Stellen Sie HiddenServiceDir /var/lib/tor/ssh und HiddenServicePort 22 127.0.0.1:22 ein.
  4. Schau dir var/lib/tor/ssh/hostname an. Es gibt einen Namen wie d6frsudqtx123vxf.onion. Dies ist die Adresse des versteckten Dienstes.
  5. Öffne $HOME/.ssh/config und füge 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 Host. Wenn es installiert ist, kann ich ssh myhost eingeben und SSH stellt eine Verbindung über Tor her. Der SSH-Server auf der anderen Seite öffnet seinen Port nur auf localhost. Somit kann es niemand über "normales Internet" verbinden.

12
qbi

Es gibt einen Debian-Administrationsartikel zu diesem Thema. Es behandelt die grundlegende SSH-Serverkonfiguration sowie Firewall-Regeln. Dies könnte auch für gehärtete SSH-Server von Interesse sein.

Siehe dort Artikel: Sicherer SSH-Zugang .

8
Huygens

Mein Ansatz zur SSH-Härtung ist ... komplex. Die folgenden Punkte beziehen sich darauf, wie ich es mache, von der äußersten Kante meines Netzwerks (meiner Netzwerke) bis zu den Servern selbst.

  1. Border-Level-Filterung des Datenverkehrs durch IDS/IPS mit bekannten Service-Scannern und Signaturen in der Blocklist. Ich erreiche dies mit Snort über meine Border-Firewall mein Ansatz, eine pfSense-Appliance). Manchmal kann ich das jedoch nicht, wie bei meinen VPS.

  2. Firewall-/Netzwerkfilterung der SSH-Ports. Ich erlaube ausdrücklich nur bestimmten Systemen, auf meine SSH-Server zuzugreifen. Dies geschieht entweder über eine pfSense-Firewall an der Grenze meines Netzwerks oder über die explizit konfigurierten Firewalls auf jedem Server. Es gibt Fälle, in denen dies nicht möglich ist (was fast nie der Fall ist, außer in privaten Test- oder Sicherheitstestlabors, in denen Firewalls nicht helfen, Dinge zu testen).

  3. In Verbindung mit meinem pfSense oder einer Border-Firewall, die das interne Netzwerk nutzt und vom Internet und den Systemen trennt, Nur-VPN-Zugriff auf Server . Ich muss ein VPN in mein Netzwerk, um zu den Servern zu gelangen, da es keine mit dem Internet verbundenen Ports gibt. Dies funktioniert definitiv nicht für alle meine VPS, aber in Verbindung mit Nr. 2 kann ich einen VPS zum "Gateway" machen, indem ich einen VPN-Zugang zu diesem Server herstelle und dann dessen IPs zu den anderen Boxen zulasse. Auf diese Weise weiß ich genau, was SSH kann oder nicht - meine einzige Box ist das VPN. (Oder in meinem Heimnetzwerk hinter pfSense meine VPN-Verbindung, und ich bin der einzige mit VPN-Zugang).

  4. Wo # 3 nicht machbar ist, ist fail2ban, das so konfiguriert ist, dass es nach 4 fehlgeschlagenen Versuchen blockiert und die IPs für eine Stunde oder länger blockiert , ein angemessener Schutz gegen Menschen, der ständig besteht mit bruteforcing angreifen - einfach an der firewall automatisch mit fail2ban blocken und meh. Die Konfiguration von fail2ban ist allerdings ein Problem ...

  5. Verschleierung der Ports durch Ändern des SSH-Ports. Dies ist NICHT empfehlenswert, um auch auf zusätzliche Sicherheitsmaßnahmen zu verzichten - Das Mantra "Sicherheit durch Dunkelheit" wurde bereits in vielen Fällen widerlegt und umstritten. Ich habe dies in Verbindung mit IDS/IPS und Netzwerkfilterung getan, aber es ist immer noch eine SEHR schlechte Sache, die ich alleine machen kann.

  6. OBLIGATORISCHE Two-Factor-Authentifizierung über Two-Factor-Authentifizierungslösungen von Duo Security Auf jedem einzelnen meiner SSH-Server ist Duo konfiguriert darauf, so dass, um überhaupt einzusteigen, 2FA-Eingabeaufforderungen auftreten, und ich muss jeden Zugriff bestätigen. (Dies ist die ultimative hilfreiche Funktion. 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 unbefugtem Zugriff. Jede Benutzeranmeldung MUSS an einen konfigurierten Benutzer in Duo gebunden werden. Da ich einen restriktiven Satz habe, können keine neuen Benutzer im System registriert werden.

Meine zwei Cent für die Sicherung von SSH. Oder zumindest meine Gedanken zur Annäherung.

6
Thomas Ward

Möglicherweise möchten Sie die FreeOTP-App von RedHat auschecken, anstatt Google Authenticator zu verwenden. Manchmal werden Sie beim Aktualisieren der App gesperrt! ;-)

Wenn Sie andere Hardware-Token wie einen Yubikey oder einen eToken PASS oder NG verwenden möchten oder wenn Sie viele Benutzer oder viele Server haben, möchten Sie möglicherweise ein OpenSource-Backend für die Zwei-Faktor-Authentifizierung verwenden.

In letzter Zeit habe ich ein Howto dazu geschrieben .

1
cornelinux

Berücksichtigen Sie bei einer großen Anzahl von Benutzern/Zertifikaten die LDAP-Integration. Große Organisationen verwenden LDAP als Repository für Benutzeranmeldeinformationen und Zertifikate, die auf Ausweisen oder Anhängern 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, was eine zentrale Verwaltung der Anmeldeinformationen ermöglicht. Auf diese Weise erhalten Helpdesks eine zentrale Anlaufstelle für die Bewältigung großer Bevölkerungsgruppen.

Hier ist ein Link zur centOS-Integration: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

0
weller1

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

Wenn Sie in den USA leben, gibt es für jemanden in Russland keinen Grund, sich mit Ihrem SSH zu verbinden, sodass er automatisch gesperrt wird.

Das Skript finden Sie hier: https://www.axllent.org/docs/view/ssh-geoip/

Sie können ihm auch iptables-Befehle hinzufügen (ich habe das für meine Droplets getan), um den gesamten Datenverkehr von/zu diesen IPs automatisch zu löschen.

0
Michael A Mike

Ich habe kürzlich ein kleines Tutorial dazu geschrieben. Grundsätzlich müssen Sie PKI verwenden, und mein Tutorial zeigt auch, wie Sie die Zwei-Faktor-Authentifizierung für noch mehr Sicherheit verwenden. Selbst wenn Sie keines dieser Dinge verwenden, gibt es auch einige Kleinigkeiten zum Sichern des Servers durch Entfernen schwacher Chiffresuiten und anderer Grundlagen. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

0
01000101