Findet man bei Penetrationstests einen SSH-Server, so wirft man einen Blick auf die angebotene Konfiguration der Transportverschlüsselung und Authentisierung. Viele verlassen sich dabei auf die Standardkonfiguration, nicht zuletzt, weil niemand weis, welche Algorithmen und Einstellungen zu wählen sind.

Wir helfen uns bei Penetrationstests damit, indem wir bei SSH-Servern einen Abgleich der Konfiguration mit den Empfehlungen aus der Technischen Richtlinie TR-02102 Teil 4 (BSI-TR-02102-4) vornehmen. In diesem Blogpost möchte ich, wie bereits mit der TR-02102-2 geschehen, beleuchten, welche Empfehlungen die Technische Richtlinie 02102 Teil 4 gibt und wie man diese für ein OpenSSH-Server umsetzen kann.

Was ist die Richtlinie TR-02102-4?

Das ist der vierte Teil der technischen Richtlinie zu kryptografischen Verfahren und Schlüssellängen. Dieser Teil gibt Empfehlungen in Bezug auf die einzusetzenden kryptografischen Verfahren und Schlüssellängen bei SSH. Diese wird vom Bundesamt für Sicherheit in der Informationstechnik herausgegeben.

Welche Empfehlungen werden gegeben?

Es werden unter anderem Empfehlungen zu den nachfolgend aufgelisteten Themen gegeben. Es gilt jedoch zu beachten, dass

zu den einzelnen empfohlenen Verfahren auch Jahreszahlen angegeben werden. Daher sollte zudem auch mal ein Block in den Text der technischen Richtlinie geworfen werden.
Die Umsetzung der Richtlinie dazu führen kann, dass man nicht mehr Konform zu den in Kapitel 2 der TR genannten RFCs konform ist. Sofern man RFC-Konform sein muss empfiehlt die Richtlinie, beides anzubieten, jedoch vorrangig die empfohlenen Einstellungen der TR anzubieten.

Es werden für diesen Blogpost die Empfehlungen herangezogen und wiedergegeben, die mindestens bis 2020 bestand haben sollen und die technisch über das Netzwerk ohne Anmeldung beim Dienst prüfbar sind.

Protokollversion

Es wird ausschließlich SSH Protokollversion 2 empfohlen.

Schlüsselaustausch

diffie-hellman-group-exchange-sha256
rsa2048-sha256
ecdh-sha2-* (jeweils mit den Kurven nistp256, nistp384 und nistp521)

Key Re-Exchange

Nach jedem übertragenen Gigabyte oder nach einer Stunde sollte der Schlüsselaustausch erneut durchgeführt werden.

Verschlüsselungsalgorithmen

AEAD_AES_128_GCM*
AEAD_AES_256_GCM*
aes256-cbc
aes192-cbc
aes128-cbc
aes128-ctr
aes192-ctr
aes256-ctr

* AEAD heißt bei SSH laut ubuntu manpage so: aes128-gcm@openssh.com bzw aes256-gcm@openssh.com

MAC-Sicherung

Hinweis: Zum Zeitpunkt der Erstellung dieses Blogposts wird zwar durch die TR SHA1 noch bis 2018 empfohlen. Da vor wenigen Wochen jedoch SHA1-Kollisionen erzeugt wurden, nehme ich es aus der Empfehlung heraus.

hmac-sha2-256
hmac-sha2-512

Server-Authentisierung

ecdsa-sha2-[nistp256 | nistp384 | nistp521]
x509v3-ecdsa-sha2-*
pgp-sign-rsa (bis 2020)
pgp-sign-dss (bis 2022)
x509v3-rsa2048-sha256[1]

Client-Authentisierung

Es wird die Authentisierung mittels Public Key im Zusammenhang mit einem aus der Server-Authentisierung genannten Verfahren empfohlen.

Ich bin nicht konform zur Richtlinie, und jetzt?

Das ist erstmal nicht schlimm, solange keine Ciphers eingesetzt werden, die bereits als gebrochen oder verwundbar gelten. Eine schlechte Verschlüsselung ist erst mal noch besser, als keine Verschlüsselung, jedoch sollte man sich nicht in falscher Sicherheit wiegen und die Empfehlungen umsetzen. Ich habe das weiter unten mal für den Openssh-Server gemacht.

Was bedeutet die Umsetzung im Hinblick auf kompatibilität?

Tja das ist schwierig zu sagen, denn hierzu gibt es kaum recherchierbare Informationen. Es bleibt also im Einzelfall vor der Produktivsetzung zu prüfen, ob durch das serverseitige Umsetzen der Richtlinie die Kompatibilität einzelner Clients gefährdet wird.

Umsetzung bei einem OpenSSH-Server

Ich habe mir ein Debian-System hergenommen und habe die Standard-SSH-Server-Konfiguration angepasst. Mit der Anpassung sollen die Empfehlungen weitestgehend umgesetzt werden. Es wird aber auch z. B. die Kompression deaktiviert, was explizit nicht in den Empfehlungen steht.

Konfiguration

Folgende Konfiguration habe ich gewählt:

Port 22
ListenAddress 0.0.0.0
Protocol 2
#Schluesselaustausch
KexAlgorithms  diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
#Verschluesselung
Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes256-cbc,aes192-cbc,aes128-cbc,aes128-ctr,aes192-ctr,aes256-ctr
#Re-Keying
RekeyLimit 1G 1H
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Logging
SyslogFacility AUTH
LogLevel INFO
#Authentfizierung
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes
#Hostkey
HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-$
#Hostkeys
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding no
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Wie sieht das übers Netzwerk aus?

Geprüft habe ich sowohl die Standard–Konfiguration, als auch meine Anpassung mit dem Nmap NSE-Script „ssh2-enum-algos“.
Standardmäßig erhalte ich ohne die Anpassungen beim Test folgende, nicht richtlinienkonforme Konfiguration:

nmap –script=ssh2-enum-algos –p22 localhost

Starting Nmap 7.32 ( https://nmap.org ) at 2017-03-20 12:54 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000045s latency).
Other addresses for localhost (not scanned): ::1
PORT   STATE SERVICE
22/tcp open  ssh

| ssh2-enum-algos:
|   kex_algorithms: (6)
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group14-sha1
|   server_host_key_algorithms: (5)
|       ssh-rsa
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp256
|       ssh-ed25519
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|       aes128-gcm@openssh.com
|       aes256-gcm@openssh.com
|   mac_algorithms: (10)
|       umac-64-etm@openssh.com
|       umac-128-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512-etm@openssh.com
|       hmac-sha1-etm@openssh.com
|       umac-64@openssh.com
|       umac-128@openssh.com
|       hmac-sha2-256
|       hmac-sha2-512
|       hmac-sha1
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com

 

nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

Nachher:

nmap –script=ssh2-enum-algos –p22 localhost
Starting Nmap 7.32 ( https://nmap.org ) at 2017-03-20 14:42 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000080s latency).
Other addresses for localhost (not scanned): ::1
PORT   STATE SERVICE
22/tcp open  ssh
| ssh2-enum-algos:
|   kex_algorithms: (4)
|       diffie-hellman-group-exchange-sha256
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|   server_host_key_algorithms: (4)
|       ssh-rsa
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp256
|   encryption_algorithms: (8)
|       aes128-gcm@openssh.com
|       aes256-gcm@openssh.com
|       aes256-cbc
|       aes192-cbc
|       aes128-cbc
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|   mac_algorithms: (4)
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512-etm@openssh.com
|       hmac-sha2-256
|       hmac-sha2-512
|   compression_algorithms: (1)
|_      none

Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds

Diese Konfiguration erhebt keinen Anspruch auf Korrektheit oder Vollständigkeit und gibt nur eine Möglichkeit wieder.
/SB

[1] Davon ausgehend, dass das Zertifikat mit mindestens 2048 bit Länge erstellt wurde.

SSH-Server Konfiguration – Technische Richtlinie TR-02102-4 des BSI