Things become complicated with this issue.

I recently posted some warning about the Debian SSH / SSL vulnerability, even before Heise had a clue People now start to get hyperactive, which leads to a confusing amount of blacklists and guides on the Web.

For our Debian systems, I performed the following steps. Please note that the blacklist packages currently only check 1024bit and 2048bit keys.

• Update your SSH installation on all machines, in order to get “ssh-vulnkey” for free. The SSH server will reject all vulnerable keys from this point, so make sure that you keep some shell open. Use the following command to scan the complete disc for vulnerable SSH keys:
  find / \( -name "*_dsa*" -o -name "*_rsa*" \) -type f -exec ssh-vulnkey '{}' \; 2> /dev/null|grep COMPROMISED
• Install the Debian OpenSSL blacklist package from the Debian Wiki. You can then check the disc for vulnerable SSL keys with a similar command:
  find / -name "*.pem" -type f -exec openssl-vulnkey '{}' \; 2> /dev/null|grep COMPROMISED
  This step can get a little bit annoying, since the openssl package asks for the passphrase of encrypted PEM files.

Since this afternoon, the internal Hetzner DNS servers seem to have a problem. You can connect, but get no answer. This is tricky since all basic services rely on DNS during their operation. Think of the reverse lookup during SSL negotation or the host name HELO check in the mail server.

For this night, OpenDNS saved me. The response times “feel” pretty fast, and I couldn’t find any problems reports from users regarding their advertisement and blocking policy.

However, the automated redirection features of OpenDNS for Web browsers might confuse your daemons:

frodo:~# ping foo
PING foo.nclmail.de (208.69.34.132) 56(84) bytes of data.
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=1 ttl=56 time=21.2 ms
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=2 ttl=56 time=20.3 ms
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=3 ttl=56 time=20.5 ms


I recommend to have the usual safe guards of DNS configuration – a valid search mydomain1, mydomain2, ... string in resolv.conf and static entries for localhost and all critical infrastructure machines in your /etc/hosts file.

The Debian security team announced a vulnerability in the OpenSSL package, reasoned by a Debian-specific change of the original sources. It leads to a predictable number generator, which makes the key space for generated private keys (for SSL certificates or SSH key-based authentication) extremely small.

As the authors noted, this is extremely nasty. It influences not only all Debian installations since 2006, but also all derived distributions such as Ubuntu or Knoppix. Whenever one of your applications is offering SSL-based security (mail server, web server, SSH server, OpenVPN, imap server, pop3 server, subversion, …), it could be vulnerable. If you got your SSL certificates from a provider such as GoDaddy or Verisign, they might be also vulnerable, even though you are not using Debian.

A wiki page tries to summarize the needed steps for all relevant packages.

I am currently investigating the already published scanner tools from MetaSploit. The page also contains a good explanation of the attacks nature.

[Update]

Save your time. Debian already provides a package with all possible weak keys, and a tool to compare this database with the keys on your system (“ssh-vulnkeys -a”). So just update your Debian as usual, and inform your users about the new SSH host keys.

Hagen had the best comment on that: