Frage Wie härtet man einen SSH-Server?


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.


119


Ursprung


Absolute Undurchlässigkeit erfordert das Ausschalten der Box. - Thorbjørn Ravn Andersen
Was ist, wenn Sie Wake-on-LAN haben? - rebus
Das Problem wäre der LAN-Teil ... Wake-on-LAN-Pakete werden nicht weitergeleitet, so dass Sie Zugriff auf eine Maschine im LAN haben müssten, um das WOL-Paket zu senden ... - LassePoulsen
Bei der Schlüsselauthentifizierung können Sie die Chiffren auf die Chiffren beschränken, die Sie wirklich benötigen.


Antworten:


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:

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

  3. Passwort deaktivieren SSH-Zugriff:

    Öffnen /etc/ssh/sshd_config, finde die Zeile, die sagt #PasswordAuthentication yesund ändere es in PasswordAuthentication no. Starten Sie den SSH-Server-Daemon neu, um die Änderung zu übernehmen (sudo service ssh restart).

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


100



-1: Im Allgemeinen wird der Zugriff auf einzelne Nicht-Computer gewährt. Die Erstellung eines Schlüssels für jeden potenziellen Client-Computer, der mit dem Server verbunden ist, ist nicht sinnvoll. Ihre letzte Aussage ist nicht korrekt, und Sie haben nicht vorgeschlagen, eine Passphrase für die privaten Schlüssel festzulegen, die Zugriff auf / Zugang zu einem der Client-Systeme gewähren würden, um automatisch Zugriff auf den SSH-Server zu gewähren. Die SSH-Schlüsselauthentifizierung wird empfohlen, aber die privaten Schlüssel müssen ordnungsgemäß geschützt werden, und sie sollten auf individueller Basis und nicht in einer verteilten Weise wie beschrieben verwendet werden. - João Pinto
"Im Allgemeinen wird der Zugriff auf einzelne Nicht-Computer gewährt, die Erstellung eines Schlüssels für jeden potenziellen Client-Computer, der mit dem Server verbunden ist, ist unangemessen" Es gibt viele Optionen und ich denke, dass die Beschreibung, wie ein privater Schlüssel sicher auf jeden Client übertragen wird, außerhalb des Bereichs dieser Frage liegt . Ich stelle nicht alle Optionen vor, nur eine einfache, die die Leute verstehen können. "... sollte auf individueller Basis verwendet werden, nicht in einer verteilten Art und Weise wie beschrieben" Dies scheint Ihrer vorherigen Aussage zu widersprechen und ich habe nichts als verteilt beschrieben. - Asa Ayers
"unmöglich" ist vielleicht etwas übertrieben. - Thorbjørn Ravn Andersen
Deshalb sage ich "unmöglich". Niemand hat Computer so schnell, so klein, so viele oder so viel Zeit. "Stellen Sie sich einen Computer vor, der die Größe eines Sandkorns hat, der Schlüssel gegen verschlüsselte Daten testen kann. Stellen Sie sich auch vor, dass er einen Schlüssel in der Zeit testen kann, die er braucht, um ihn zu überqueren. so viele, dass, wenn du die Erde mit ihnen bedeckst, sie den ganzen Planeten bis zu einer Höhe von 1 Meter abdecken würden. Die Gruppe von Computern würde durchschnittlich einen Durchschnitt von 128 Bit in 1.000 Jahren knacken. " - Asa Ayers


Ich würde vorschlagen:

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

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

    Hinzufügen PermitRootLogin no zu deinem /etc/ssh/sshd_config.

  • Beschränken der Benutzer, die SSH zum Server können. Entweder nach Gruppen oder nur nach bestimmten Benutzern.

    Hinzufügen AllowGroups group1 group2 oder AllowUsers user1 user2 begrenzen, wer SSH zum Server kann.


67



Das AllowUsers und ZulassenGruppen Akzeptiert kein Komma , als Trennzeichen. Stellen Sie sicher, dass Sie dies nicht aus der Ferne versuchen. Ich werde dadurch immer wieder aus meinem NAS ausgeschlossen. - artless noise
Immer validieren Ihre sshd config ist korrekt, bevor Sie sshd neu starten, damit Sie sich nicht aus dem System aussperren. Sehen dieser Blog für Details - einfach ausführen sshd -T nach einer Änderung der Konfiguration vor dem Neustart des Main sshd. Ebenfalls, Lassen Sie eine SSH-Sitzung geöffnet auf der Maschine, wenn Sie die Konfiguration ändern, und schließen Sie das nicht, bis Sie die Konfiguration wie erwähnt validiert haben und vielleicht eine Test-SSH-Anmeldung durchgeführt haben. - RichVel


Andere Antworten bieten Sicherheit, aber es gibt eine Sache, die Sie dazu beitragen können, dass Ihre Protokolle leiser werden und es weniger wahrscheinlich ist, 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.


22



Für diejenigen, die an Sicherheit durch Dunkelheit glauben (en.wikipedia.org/wiki/Security_through_obsicurity) Es macht sehr viel Sinn, einen anderen Port zu verwenden. Ich weiß es nicht .. - LassePoulsen
Es geht nicht um Sicherheit durch Obskurität (obwohl die Dunkelheit einen marginalen positiven Effekt haben kann). Es geht darum, das Hintergrundgeräusch endloser Brute-Force-Versuche zu reduzieren. Sie können Ihre Zugriffsfehlerprotokolle nicht sinnvoll prüfen, wenn sie voll mit automatisierten Angriffen sind. fail2ban reduziert das Volumen nicht ausreichend angesichts der Anzahl der Angreifer und der Verbreitung von verteilten (Botnet) und gedrosselten Angriffen. Mit ssh auf einem ungewöhnlichen Port, du kennt Angriffe, die du in den Logs siehst, stammen von einem echten Angreifer, der an deiner Box interessiert ist. Ich kann es nur wärmstens empfehlen. - bobince
Da Sie Internet-Dienste wie Shodan für Web-zugewandte SSH-Server abfragen können, oder mit nmap und Banner-Capture macht die Änderung der Standard-Port ziemlich sinnlos. Ich würde davon abraten. - SLow Loris
Shodan greift nicht auf alle 65k-Ports zu, so dass ein Wechsel zu einem hohen Port ihn wahrscheinlich aus ihren Scans entfernt. Auch wenn Sie zu einem zufällig hohen Port wechseln, wird der Angreifer wahrscheinlich 65K TCP-Scans (sehr laut) durchführen müssen, um Ihren Dienst zu finden, um ihn anzugreifen. Bei beiden handelt es sich um Gewinne aus der Sicht der Sicherheit, daher ist der Wechsel zu einem hohen Port im Allgemeinen ein guter Plan. Eine andere Möglichkeit besteht darin, dass Sie, wenn Sie zu einem hohen Port wechseln, eine bessere Vorstellung davon haben, dass jemand, der Sie angreift, Ihre Systeme gezielt abzielt und nicht nur Hintergrundgeräusche im Internet - Rоry McCune


Machen Sie die sshd-Block-Client-IPs, die keine korrekten Anmeldeinformationen liefern konnten "DenyHØsts"Ich kann diesen Job sehr effektiv erledigen. Ich habe dies auf all meinen Linux-Boxen installiert, die irgendwie von außen 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.


21



Gibt es eine Option wie 10 fehlgeschlagene Anmeldeversuche vor dem Verbot der IP-Adresse? - sayantankhan


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

Dies schließt die Verwendung der Authentifizierung mit öffentlichem Schlüssel über die Passwortauthentifizierung wie in einer anderen Antwort hier ein, erfordert jedoch 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 das ausführen google-authenticator Befehl, der generiert ~/.google-authenticatorund hilft ihnen, ihre zwei Faktoren Geräte zu konfigurieren (z. B. die Google Authenticator Android App).

  3. Bearbeiten /etc/ssh/sshd_config und stellen:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Lauf sudo service ssh reload um deine Änderungen zu übernehmen /etc/ssh/sshd_config.

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

    @include common-auth
    

    mit:

    auth required pam_google_authenticator.so
    

Weitere Details zu verschiedenen Konfigurationsmöglichkeiten finden Sie in meinem Blog-Beitrag vom letzten Jahr: Bessere Zwei-Faktor-SSH-Authentifizierung auf Ubuntu.


21





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

Geben Sie an einer Eingabeaufforderung Folgendes ein:

$ sudo ufw limit OpenSSH 

Ob ufw ist nicht installiert, tue dies und versuche 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.


19



+1 Die Verwendung von Limit kann gut sein. Allerdings sollte ich darauf hinweisen, dass ich Probleme bei der Verwendung des integrierten Sftp-Servers festgestellt habe, da dies auch die Verbindungen einschränkt. - Mark Davidson
@Mark - guter Punkt, aber klingt das nicht wie ein schlecht geschriebener SFTP-Client? Warum würden sie sich immer wieder mit dem SSH-Port verbinden, wenn sie einfach mehr SSH-Kanäle öffnen könnten? - mpontillo


Wenn ich zusätzliche Sicherheit haben möchte oder auf SSH-Server innerhalb eines Unternehmensnetzwerkes zugreifen möchte, richte ich ein versteckter Dienst mit der Anonymisierungssoftware Tor.

  1. Installieren Sie Tor und richten Sie den SSH-Server selbst ein.
  2. Stellen Sie sicher, dass sshd nur zuhört localhost.
  3. Öffnen /etc/tor/torrc. einstellen HiddenServiceDir /var/lib/tor/ssh und HiddenServicePort 22 127.0.0.1:22.
  4. Ansehen var/lib/tor/ssh/hostname. Es gibt einen Namen wie d6frsudqtx123vxf.onion. Dies ist die Adresse des versteckten Dienstes.
  5. Öffnen $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 Rechner. Wenn es installiert ist, kann ich eintreten ssh myhost 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.


12



Sicherheit durch fortgeschrittene Dunkelheit, aber sehr interessant. - Johannes