Re: SSH-Security-Check a la ssllabs.com/ssltest

Hi Sven.

Sven Velt - 17.12.19, 14:50:07 CET:
> Da ich aktuell recht viel an meinen SSH-Servern und -Clients
> rumschraube, bin ich auf https://sshcheck.com/ gestoßen. Ist mal ganz
> interessant zu sehen, wie (insbesondere ältere) SSH-Daemons so
> bewertet werden. Aber auch, dass an aktuellen eben auch noch
> optimiert werden kann.

Macht das etwas anderes als ssh-audit, paketiert unter dem gleichen
Namen in Debian? Das ist übrigens Python :)

Da ist auf meinen Servern alles grün :)

> Außer einem (nicht mehr ganz aktuellen) Ruby-Monster hab ich leider
> bisher nichts auf der Command-Line gefunden, so dass man das geschickt
> selbst machen könnte. Falls da jemand was kennt, her damit ;)

Hmm?

> Wer, auf der anderen Seite, Tipps zum weiteren Absichern für's SSH
> (Server und Client) braucht:
>
> - https://stribika.github.io/2015/01/04/secure-secure-shell.html
> - https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-> Shell
> - und natürlich https://blog.fefe.de/?ts=aa52d8da :D

In dem FEFE Blog Link finde ich beim Drüberfliegen nur Blabla über andere
Themen.

Das andere habe ich mir gerade nicht im Detail angeschaut. Ich verwende:

https://bettercrypto.org/

und für Apache, Nginx und bald auch Dovecot auch (kann es schon, habe
ich aber noch nicht umgesetzt, da ich seinerzeit das alte Fairphone
nicht aussperren wollte):

https://ssl-config.mozilla.org/

https://observatory.mozilla.org

Letzteres ist heftig streng, deutlich strenger als das Qualys-Zeug.
Meine Haupt-Webseite und die meisten anderen Domains haben jedoch A+.
Mit Wordpress aus Devuan Beowulf aka Debian Buster bekam ich das jedoch
nicht hin. Das kommt nicht mit Content-Security-Policy (CSP) klar oder
ich kam nicht damit klar, weil ich das extrem komplex finde.

Ansonsten haut auch Lynis einige Tipps raus – wovon ich aber längst
nicht alles umgesetzt hab. Einen fand ich aber gut: Auf meinen SSH-
Servern ist eine Verbindung nur als Benutzer aus einer bestimmten Gruppe
möglich. Da muss dann allerdings auch Root drin stehen, sonst darf der
auch nicht.

Achja, und SSHGuard oder Fail2Ban, wobei Fail2Ban wohl deutlich flexibler
ist. Ich hab noch SSHGuard am Start, funktioniert aber, obwohl es
sollte, mit Dovecot nicht – wo ich laut Protokoll immer wieder Leute
oder Skripte habe, die es versuchen. Und Apache mit mod-evasive.

Achja, Clients habe ich auch gesichert, und dann insbesondere für die
Arbeit Ausnahmen geschaffen, weil SSH-Server nicht aktuell genug waren.
:)

> Apropos Command-Line (und SSL), hier noch eine Alternative zu
> ssllabs.com/ssltest/ → https://testssl.sh/

Das gibt es natürlich auch noch.

Ciao,

-- 
Martin

--
Mailing-Liste der Linux User Schwabach (LUSC) e.V.
Vor und beim Posten bitte
?http://lusc.de/List-Netiquette < und
?http://lusc.de/List-Howto < beachten. Danke!