Cool Beans

The SANS Internet Storm Center (isc.sans.org), a volunteer internet security watchdog group run by established systems security professional has recently posted about SShellPhishing, a.k.a. continued brute force login attempts. This is something I've noticed on my own server logs, recently. Well, more like all the time, since the servers haven't been up for all that long.

If you run a server and have ssh open to the world (I won't delve into the myriad other ports we fail to secure), there are some things you can do to mitigate the onslaught of break-in attempts:

• Configure your sshd to only accept public-key authentication, and create strongly-passworded ssh keys for all your client systems.
• If that is too restrictive, consider implementing a clipping-level for failed logins with tools like sshguard or swatch.
• Run ssh on a different port.
  
• Configure your ssh to work with a range of trusted IPs (this can be done through your firewall rules).
• Increase the delay time between failed logins making brute force a little less effective. This is under sshd config "AuthInteractiveFailureTimeout" in most ssh servers.
• Try to configure other services that require their own user accounts (e.g. postgres, oracle, webadmin tools) to have non-default account names. I saw a lot of postgres and "scott" login attempts recently in my logs.
• Try to have logins that are not common names or guessable. (I see "chris" in the login attempts a lot. Chris, you fail.)
  
• And of course, enforce strong passphrases for all your user accounts.

Simple measures, any combination of these (especially the first two) can make it so that it is extremely difficult for a brute-forcer to own you.

On the topic of pubkey-only authentication, at first glance this might not seem feasible. Especially if you need to hop around on new machines from undetermined different locations to get into your server. For this, it might be good to generate extra public keys and store them on a personal USB key (where presumably you also keep your PGP keys, not leaving them on your computer!). I really dig the KingMax 8GB Super Stick for this purpose, it's like a stick of Trident gum. Temporary ssh pubkeys can have their public counterpart pre-uploaded in the server's authorized_keys list, thereby enforcing pubkey authentication but not restricting you to a few accessible computers. You could then use these keys even on an untrusted system, and delete the pubkey from the server authorized_keys file at the beginning of the session, thereby invalidating them after your use. "ssh -i" + USB is your friend.

Mind your auth logs, and don't let ssh be a weak point in your system security.