Heiko Zimmermann
SAP-Berater, System Engineer und Entwickler.

Weblog

Derzeit geistern Schlagzeilen wie: Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet durch das Internet. Und das sicher nicht zu unrecht.

Denn es gibt wirklich Handlungsbedarf. Ich betreibe einen OpenBSD Server mit Dovecot, OpenSMTPD, Hiawatha Webserver und SSH. Also musste auch ich mich mit den Auswirkungen beschäftigen. Die Ursachen liegen wohl in der Export Verschlüsselung und einer zu niedrigen Bitanzahl bei DH. Ich möchte gerne meine Erfahrungen teilen. Wenn dadurch nur ein einziger Server sicherer wird, habe ich schon etwas erreicht.

OpenBSD selbst hat in 5.7 current eine moduli, v 1.12 2015/05/22 und einige Änderungen veröffentlicht.

Dovecot

Hier sind einige Änderungen vorzunehmen, um bei TLS nur sichere Verfahren anzubieten. Die Änderungen werden in  /etc/dovecot/conf.d/10-ssl.conf vorgenommen:

ssl_dh_parameters_length = 2048  
# soll >= 2048 sein, ssl-parameters.dat wird wöchentlich automatisch neu erzeugt
# je größer, desto mehr CPU Last.

ssl_protocols = !SSLv3 !SSLv2    
# sollte bisher schon jeder verwenden

ssl_cipher_list = HIGH:!aNULL:!kEDH:!aECDH:!GOST2012256-GOST89-GOST89 \
:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!DES-CBC3-SHA

ssl_prefer_server_ciphers = yes


Wenn man High verwendet, kann man sich :!EXPORT:!MD5:!RC5 ... ersparen. Dennoch bitte unbedingt prüfen und ggf. erweitern, sofern man nicht OpenBSD verwendet ist das notwendig.

# openssl ciphers HIGH:!aNULL:!kEDH:!aECDH:!GOST2012256-GOST89-GOST89: \
!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!DES-CBC3-SHA    

Damit erhalte ich:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA256:CAMELLIA128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA

Ich empfehle auch in /etc/dovecot/conf.d/10-logging.conf das login_log_format_elements um %k zu erweitern, damit man sieht, womit sich die Clients verbinden.

login_log_format_elements = "user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k"


Schwierig ist es immer iOS Geräte zu einer vernünftigen Cipher zu bewegen. Mit der obigen ssl_cipher_list erhalte ich beim iPhone:  ECDHE-RSA-AES256-SHA (256/256 bits) und auch beim Thunderbird. Also was man sich wünscht :)

OpenSMTPD

Der Entwickler Gilles Chehade hat hierzu eine E-Mail an misc@openbsd.org gesendet:

As far as OpenSMTPD is concerned:

"The attack affects any server that supports DHE_EXPORT ciphers,
 and affects all modern web browsers." (from weakdh.org)

The default cipher-suite is "HIGH:!aNULL:!MD5" which doesn't support any
DHE_EXPORT cipher (obvious but verified with both LibreSSL and OpenSSL):

    $ openssl ciphers HIGH:!aNULL:!MD5|grep EXPORT


Eine kurze Prüfung ergibt, dass unter OpenBSD 5.7 current wirklich keine solchen Ciphers für OpenSMTPD verwendet werden. Also hier Entwarung. Im nächsten Release von OpenSMTPD soll man eigene Ciphers Lists wie bei Dovecot verwenden können. Geplantes Release Juni 2015.

Hiawatha Webserver

Ich habe mit Hugo Leisink Rücksprache gehalten, ob Hiawatha betroffen ist. Die Antwort war eindeutig: nein. Also war auch hier Hiawatha wieder, wie auch bereits bei Heartbleed, nicht betroffen. Hier wird intern mbed TLS (früheres PolarSSL) verwendet, das bisher bei sämtlichen aufgetretenen großen Sicherheitslücken nicht betroffen war. Das wird übrigens auch bei PowerDNS eingesetzt. Ein kurzer Test auf weakdh.org bestätigt das. Wichtig (/etc/hiawatha.conf) ist:

DHsize = 2048 # oder 4096, aber nicht 1024! # Default = 2048


SSH härten

Hierzu gibt es einen sehr lesenswerten Artikel . Die Änderungen setzen eine aktuelle OpenSSH Version voraus. Getestet wurde es vom Author ab der Version 6.7. Einiges davon habe ich übernommen. Meine Einstellungen sind sicher nicht perfekt, daher sollte das jeder für sich nochmal selbst abwägen und prüfen.

Ich habe einige Änderungen in der /etc/ssh/sshd_config vorgenommen:

Port 4711
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key


ServerKeyBits 4096

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, \
hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512, \
hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com, \
aes128-gcm@openssh.com, aes256-ctr,aes192-ctr,aes128-ctr

AllowUsers heiko
PermitRootLogin no

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

 

Es wird empfohlen die Moduli auszumisten und alle unter 2000 zu verwerfen. Unter OpenBSD ist es /etc/moduli und unter Linux /etc/ssh/moduli . Ausserdem muss noch eine /etc/ssh/ssh_host_ed25519_key und sollte eine neue /etc/ssh/ssh_host_rsa_key erzeugt werden.

# OpenBSD:
awk '$5 > 2000' /etc/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # make sure there is something left
mv "${HOME}/moduli" /etc/moduli

# Linux
awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # make sure there is something left
mv "${HOME}/moduli" /etc/ssh/moduli


cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null


Dann noch in der /etc/ssh/ssh_config der Clients:

Host *
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes

    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com, \
    ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa

    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com, \
    aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr


Was jetzt eventuell noch ansteht sind die Client Keys für PubkeyAuthentication:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

Die kann man mit ssh-copy-id oder per scp übertragen. Dazu braucht man dann temporär eventuell noch PasswordAuthentication yes.

Weitere Informationen findet man hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Ich weise darauf hin, dass dies als Ideen für eine eigene Umsetzung zu verstehen ist und nicht als fertige Anleitung. Es handelt sich hier um sensible Bereiche, für die jeder selbst verantwortlich ist. Ich kann keinerlei Gewähr für die Richtigkeit übernehmen.