Absicherung von SSH

  • Ich stoße immer wieder auf "Empfehlungen" den SSH Port zu ändern, um so die Sicherheit zu erhöhen. Dies ist in meinen Augen völliger Quatsch. Es erhöht vielleicht den Aufwand der Suche für Angreifer. Da dies aber Bots machen, ist der Aufwand minimal höher. Daher würde ich gerne wissen wie der Rest hier den Dienst absichert. Und vielleicht hilft dies dem Einen oder Anderen auch ;)


    Bei mir sieht die sshd_config wie folgt aus (nur Änderungen):

    Shell-Script
    1. Protocol 2LoginGraceTime 30s
    2. PermitRootLogin prohibit-password
    3. PasswordAuthentication no
    4. PermitEmptyPasswords no
    5. Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
    6. Macs hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com
    7. HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
    8. KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256


    Login ist nur mittels Key möglich. Dies mag vielleicht auf Sharedhosting Servern mit vielen Nutzern ungünstig sein. Wobei die Generierung eines Keys auch kein Hexenwerk mehr ist. Bei z.B. Windows Nutzern können die Tools von PuTTy verwendet werden. Anleitungen gibt es hier: Windows+PuTTy, Linux+ssh-keygen


    Ich habe zudem als schwach geltende Verschlüsselungen abgeschaltet. Bei meinen Tests konnten sowohl PuTTy, der Linux Client (OpenSSH 7.4) und der SSH Client auf meinem Smartphone sich ohne Probleme verbinden. Ältere Versionen aus Kompatibilitätsgründen anzugeben macht für mich daher kein Sinn. Testen kann man seinen Dienst hier: SSH Check


    Interessant dabei ist, dass ich seit der Umstellung hauptsächlich solche Meldungen bekomme:

    Shell-Script
    1. Jul 2 12:54:09 ironman sshd[31047]: Unable to negotiate with 121.134.227.185 port 39172: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

    Dies sind Verschlüsselungen, welche aufgrund von SHA-1 als unsicher bzw. veraltet gelten.


    Des Weiteren wird SSH dann per fail2ban und einzelnen firewalld Regeln gesichert. Hier bin ich gerade dabei ein Lösung mit Integration von abuseipdb.com zu konfigurieren. Was sehr gut hilft ist eine regelmäßige Ausgabe von

    Shell-Script
    1. zgrep -h "Ban " /var/log/fail2ban.log* | awk '{print $NF}' | awk -F\. '{print $1"."$2"."}' | sort | uniq -c | sort -rn | head

    Subnetze, aus denen sehr viele "Angriffe" kamen, habe ich so permanent per Firewall Regel ausgesperrt. Meistens waren es asiatische IPs :rolleyes:

  • Generell senkt das Ändern des Ports (auf einen eher exotischen) das "Grundrauschen" schon ganz massiv. Das seh ich auch im Alltag recht einfach, Centos zb. hat das login ja so konfiguriert dass es die fehlgeschlagenen Logins anzeigt nach einem erfolgreichen Login. Da steht bei einem Server mit Port 22 schnell mal was von mehreren Tausend. Bei Servern mit Alternativport meistens gar nichts. Das fällt mir seit Jahren so auf. Also dürfte es mit dem Portscannen nicht so weit her sein bei den Robotern.


    Also ja, gebe Dir recht, ganz allgemein kann man über den Sicherheitsgewinn des Portwechsels durchaus streiten. Aber es bringt in jedem Fall schonmal viel weniger Login bzw. Auth Prozesse. Also ich fühl mich defnitiv wohler damit.

  • Es gibt meiner Meinung nach nur ein falsches Gefühl vor Sicherheit. Ja, es reduziert die Anzahl an Versuche. Dies erreicht man aber auch mit restriktiven fail2ban Regeln. Und ist der Port einmal bekannt geworden, verhindert es auch keine weiteren Loginversuche.


    Gefährlich wird es meiner Meinung nach, wenn man ein unprivilegierten Port (> 1024) nutzt. Unprivilegierte Ports können von jedem Nutzer genutzt werden. Ein mögliches Szenario wäre, dass über eine Lücke bei einem Nutzer (sei es ein Systemnutzer oder Endkunde) Schadcode eingeschleust wird. Anschließend stört der Angreifer den SSH Dienst oder lauscht sogar darauf. Im Worst Case werden dann sensible Daten abgegriffen oder gar root Berechtigungen erlangt.