Wie kann die SSH-Sicherheit (weiter) gewährleistet werden?

Führen Sie so viele Schadensbegrenzungen wie möglich durch.

Ihr Ziel ist es, eine Vielzahl potenzieller Angreifer zu zwingen, mehr Aufwand, Ressourcen, Computerzeit (und damit Stromrechnung) und vor allem "qualifizierte" (seltene oder knappe und daher wertvolle) Personenstunden aufzuwenden. Kein Schutz wirkt gegen jede Bedrohung. Nicht jede Bedrohung kann geschützt werden, während sie im Internet verbleibt.

Eine große Anzahl von Bedrohungen (Skript-Kiddies und Angreifer mit geringen Fähigkeiten oder geringen Ressourcen) kann jedoch fast immer durch eine umfassende Verteidigung abgewehrt werden – viele Schichten guter, solider Sicherheit, von denen jede – theoretisch – ausreichen sollte viele Bedrohungen alleine besiegen. Wenn also die iptables-Regeln Ihres Systems jemanden versehentlich hereinlassen, hält die SSHD-Zertifikatsauthentifizierung ihn davon ab. Wenn Ihr SSHD-Dienst einen Fehler aufweist, verhindert Ihr VPN, dass jemand ihn sieht. Wenn sowohl Ihr VPN als auch Ihre SSHD gleichzeitig einen Fehler aufweisen, hindern Ihre Firewall-Regeln die meisten IP-Adressen weltweit daran, dies auch nur zu versuchen, sodass nur Einheimische und große Botnets versuchen können, die Schwachstellen auszunutzen, die Sie patchen schnellstmöglich.

Also, ich sage es noch einmal, setzen Sie so viele Abschwächungen auf so vielen Ebenen wie möglich ein. Sie können nicht im Voraus wissen, welche unentdeckte Schwachstellen aufweisen und in welcher Reihenfolge diese ausgenutzt werden.

• Stellen Sie sicher, dass Sie nur SSH v2 zulassen

  • sshd_config

    • Protokoll 2

• Bleiben Sie auf dem Laufenden

• Verwenden Sie Ihre iptables, um NUR die IP-Adressen oder -Bereiche zuzulassen, die Sie tatsächlich verwenden

• Richten Sie Ihr SSH so ein, dass der Zugriff NUR über ein Zertifikat und nicht über Benutzername/Passwort erlaubt ist, gemäß der Ubuntu-Hilfeseite SSH/OpenSSH/Konfigurierungsseite

  • sshd_config

    • PubkeyAuthentication ja

    • PasswortAuthentifizierungsnummer

  • Wenn Sie ein verschlüsseltes Home-Verzeichnis verwenden

    • AuthorizedKeysFile /etc/ssh/%u/authorized_keys

  • Wenn nicht, kann die normale Einstellung für Home-Verzeichnisse funktionieren

    • AuthorizedKeysFile %h/.ssh/authorized_keys

    • Stellen Sie sicher, dass keine übermäßigen Berechtigungen vorhanden sind.

      • chmod 700 ~/.ssh

      • chmod 600 ~/.ssh/authorized_keys

      • chmod go-w ~

  • Und richten Sie ein so starkes Zertifikat wie möglich ein. Das Generieren von Schlüsseln wird auf der SSH/OpenSSH/Keys-Seite der Ubuntu-Hilfeseite behandelt

    • Ich würde mit einem 4096-Bit-RSA-Schlüssel oder einem ed25519-Schlüssel mit einer langen, starken Passphrase beginnen. Stellen Sie sicher, dass Sie ihn lokal generieren, geben Sie eine lange, starke Passphrase ein, wenn Sie dazu aufgefordert werden, verwenden Sie -o, um das neue OpenSSH 6.5-Schlüsselformat sicherzustellen, und stellen Sie sicher, dass der Server niemals etwas anderes als den öffentlichen Schlüssel hat.

      • ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519

      • ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa

      • Um die Länge eines vorhandenen Schlüssels zu überprüfen, verwenden Sie ssh-keygen -e -f mykeyfile

  • Beschränken Sie die Schlüssel in der Datei "authorized_keys" nach Möglichkeit auf eine bestimmte IP-Adresse oder einen Satz von Hostnamen

    • from="192.168.1.2" ssh-rsa ABCDE...012 [email protected]

    • from="*.test.test,!BadPC.test.test" ssh-ed25519ABCDE...012 [email protected]

  • Wenn Sie OpenSSH 6.8 oder höher verwenden, können Sie autorisierte Schlüssel auch in sshd_config

    auf bestimmte Typen beschränken
    • PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

• Verwenden Sie fail2ban, um Brute-Force-Versuche mühsamer zu machen (d. h. dafür zu sorgen, dass sie ein Botnet statt nur einer Maschine verwenden, oder dass sie viel Zeit in Anspruch nehmen)

  • Das Einrichten von Zertifikaten (Schlüsseln) ist besser, wenn Sie fragen, was Sie zuerst tun sollen

• Reduzieren Sie Ihre Kulanzzeit für die Anmeldung

  • Wenn Sie Zertifikate verwenden, haben Sie die Möglichkeit, es VIEL herunterzudrehen, es sei denn, Sie verwenden sehr, sehr langsame Verbindungen

    • LoginGraceTime 8

  • Ansonsten, naja, wie schnell tippst du?

    • LoginGraceTime 20

• Kontrollieren Sie Ihre Cipher Suite-Auswahl mit Informationen von Mozilla.org Security/Guidelines/OpenSSH

  • Da es Ihr Server ist und nur Sie hineinkommen, können Sie eine sehr, sehr enge Gruppierung auswählen, sodass nur die modernsten Clients zugelassen werden. Vielleicht

  • Hostschlüssel /etc/ssh/ssh_host_rsa_key

    • sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

      • oder

      • Hostschlüssel /etc/ssh/ssh_host_ed25519_key

      • sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

    • stimmen offensichtlich genau mit Ihren HostKey-Dateinamen überein!

      • oder beides (am meisten bevorzugt zuerst)

      • alle dsa-Schlüssel vollständig entfernen; sie sind auf erbärmliche 1024 Bit für SSH festgesetzt

  • Verwenden Sie ssh -Q-Anweisungen, um festzustellen, was Ihr System für die Cipher-Suite-Optionen unterstützt

  • KexAlgorithms [email protected]

  • Chiffren [email protected], [email protected], [email protected]

  • MACs [email protected]

  • Oder welche konkreten Entscheidungen Sie sich am sichersten fühlen

  • Und halten Sie sich mit der Literatur auf dem Laufenden; Wenn etwas, das Sie ausgewählt haben, einen Fehler aufweist, wählen Sie etwas, das zu diesem Zeitpunkt keine bekannten Fehler aufweist.

• Verwenden Sie Ihre iptables (oder Firewall) mit Blocklisten von I-blocklist

• Verwenden Sie Ihre iptables (oder Firewall) mit geografischen oder ISP-basierten IP-Listen; Eine solche Quelle für geografische Listen ist maxmind.com

• Wechseln Sie zu einem Port im dynamischen (ephemeren) Portbereich von 49152 bis 65535 gemäß RFC6335

  • Und nur an die erforderlichen IP-Adressen binden

• Blockieren Sie alle anderen Ports auf diesem Server über iptables; Die Chancen stehen gut, dass Sie von VIELEN Angriffen getroffen werden

  • Härten Sie insbesondere Ihre MySQL-Datenbank ab, falls vorhanden - ich sehe viele MySQL- (und SQL Server-) Angriffe auf mein IDS, und ich habe nie einen von beiden ausgeführt oder einen der beiden Ports geöffnet. Setzen Sie sie auf nur lokale, nicht routbare IPs usw., lange Passwörter, deaktivieren Sie sie usw.

  • Deaktivieren Sie insbesondere alle Webserver, stellen Sie sie nur auf lokale, nicht routbare IPs ein usw.

• Verwenden Sie Port Knocking gemäß der Ubuntu-Hilfeseite oder einem DigitalOcean-Artikel

• Begrenzen Sie neue Verbindungsversuche gemäß dieser Antwort auf die ServerFault-Frage „Hunderte von fehlgeschlagenen SSH-Anmeldungen“

iptables -A INPUT -p tcp --dport 22 -m updated --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m updated --set --name SSH --rsource -j ACCEPT

• Erwägen Sie die Verwendung von Chroot gemäß der Debian-Dokumentation „OpenSSH SFTP chroot() with ChrootDirectory“

• Stellen Sie sicher, dass rhosts mit der Option sshd_config

  deaktiviert ist

  • IgnoreRhosts ja

  • RhostsRSA-Authentifizierungsnummer

  • RhostsAuthentifizierungsnummer

• Fügen Sie dem nicht privilegierten Prozess der Vorauthentifizierung weitere Einschränkungen hinzu

  • PrivilegeSeparation-Sandbox verwenden

• Wenn Sie Weiterleitung oder Tunneling nicht verwenden, deaktivieren Sie es in sshd_config

  • X11Weiterleitungsnr

  • AllowTcpForwarding nein

  • GatewayPorts Nr.

  • PermitTunnel Nr.

• Verhindern Sie andere unsichere Einstellungen in Verzeichnissen oder Berechtigungen

  • StrictModes ja

  • Und dann deine Berechtigungen und Einstellungen durchgehen, bis es wieder funktioniert :)

• Hostbasierte Authentifizierung deaktivieren

  • Hostbasierte Authentifizierung nein

• Beachten Sie, dass die alte ServerKeyBits-Anweisung sshd_config gemäß dieser Serverfault-Antwort auf „OpenSSH-Daemon ignoriert ServerKeyBits-Direktive“ nicht mehr anwendbar ist, da Sie SSH v1 von vornherein nicht zulassen.

• Root in sshd_config nicht zulassen

  • RootLogin-Nr. zulassen

• Erlauben Sie nicht, dass andere Benutzer - vielleicht Service-Benutzer eines Pakets, das Sie installieren - andere Optionen haben

  • PermitUserEnvironment Nr.

• Installieren Sie eine separate, umfassende Firewall wie pfSense oder einen Ubiquiti Edgerouter Lite zwischen diesem Computer und der Außenwelt.

  • Verwenden Sie dann das integrierte VPN ZUSATZ ZU Ihre gehärtete SSH-Anmeldung

  • Auch mit zertifikatsbasierten Anmeldungen, nicht benutzernamen-/passwortbasierten Anmeldungen

  • Wenn Sie OpenVPN verwenden

    • Stellen Sie sicher, dass Sie auch einen --tls-auth "ta.key" Pre-Shared Key verwenden

    • Und wählen Sie bessere Verschlüsselungen als die Standardeinstellung

  • Und verwenden Sie auch auf dieser Ebene die oben erwähnten Sperrlisten

Wie DeerHunter erwähnt hat, kann das Ändern von ssh- und/oder iptables- und/oder anderen Firewall-Einstellungen ohne andere Möglichkeit dazu führen, dass keine SSH-Verbindung möglich ist.

Bitte schön:

• SSH-Schlüssel generieren + mit Passwort schützen
• Nur bestimmten Benutzern die Anmeldung erlauben (AllowUsers)
• Zulassen von bestimmter IP [email protected]
• Standardport ändern
• Firewallregeln erstellen
• und als letztes installiere fail2ban.