Everyone is writing about the Debian & derivatives SSH issue.

[Update: For the sake of accuracy I did an s/32k/196k/ in a couple of places.]

I don’t think it can be written about enough, the more exposure the better. When I first saw the headlines I thought, “oh, probably just anther ones of those things where a heat-death-of-the-universe problem has become a 1-million-years problem” – ho ho! How wrong was I? It really is very serious. If you generated an SSH key on a Debian/etc machine while the bug was in place your private key is one of only 32k possible keys (for each key type for each key size, i.e. 32k possible 2048 bit RSA keys, etc. So for 1024, 2048, and 4096 bit DSA & RSA keys that’s 196608 possible keys [Update: oops, DSA keys can only be 1024 bits!]) This means that if someone knows a machine you log into and your username it’ll take them no more than 196k attempts to log in to the system as you (and probably less, since the Metasploit page linked to above claims most keys are generated by proceses with low PIds.) That’s a tiny number of attempts in the brute-forcing world.

Some of us have brute-force blocks on our gateways and servers, this is great up to a point. For example a typical set-up is to start blocking all traffic from an IP if it hits port 22 more than 10 ten times in 30 seconds. I do the this on my server.

This is only good so-far though. First, if yo aren’t in a hurry configure your brute-force script to try every 10 seconds. I doubt most firewall setups go as far as to notice that sort of thing.

Second, this is a bonanza for botnet owners! If yo have a modestly sized botnet (say, 32k nodes) yo just give each bot a set of keys, a list of common logins, and the Internet. Actually, you’ll probably do pretty well just testing the entire internet with ‘root@’. (AFAIC you should never permit remote root login anyway – but I suspect many servers do and they make it “secure” by permitting only key-based ath, heh heh.)

What I wold be doing right this moment if I was an admin:

1. Block SSH at the gateway! (Ouch!) And all other SSL protected servers.
2. Check your server keys, replace if needed. This could take a long time where re-signing for public keys is required.
3. Move all users .ssh directories to something like .ssh_suspect
4. Inform users, probably by phone. (They’ll probably call you when they loose SSH.)
5. Start scanning all .ssh_suspect directories for blacklisted keys, remove them, inform the users, reinstate SSH with good keys restored.
6. Continue mopping up the mess– probably mostly a case of chasing up server certificate re-signing and informing/handling users.

I’m not an admin and not an SSH expert, so that scheme is vague and probably needs further tightening. It surely must be better than doing nothing though. You probably need to audit all your logs too, especially auth and firewall. Essentially the security of all your systems is suspect until you are certain that all logins prior to the lock-down were kosher (probably requiring a lot of back-n-forthing with users.)

I haven’t even sat down and contemplated the full extent of this yet.

The fact that we could even have got into the situation is insane. Peer review?
How cold someone clueless enough to cluelessly mess with the PRNG in security
code even be permitted to make such a change?! It beggars belief.

Of course, anyone even vaguely interested in security has probably already reached the cynical point of believing that there isn’t any security. Awareness is key.