Possible SSH 0-day vulnerability? And a couple of semi-helpful iptables tips.

Update 07/08/2009: This is starting to sound less and less like a 0-day and more like a single administrative error or lapse. Either way it's a warning; don't be lax with your SSH access. SSH is for the most part secure, but there's always the chance that it can be exploited.

Update 07/07/2009: SANS is also as vexed with the lack of info on this issue as everyone else I've contacted.  They're a great place to watch for more data as it becomes available.  If anything new happens I'll also update here, but I'll probably get it from SANS myself.



I'm sorta loathe to report this, since I don't have anything to substantiate it other than rumors flying on web hosting bulliten boards and Twitter, but there is word of a 0-day SSH vulnerability floating around.

Translated Rumor

Translated Rumor Source

I have no more information on this than that, other than hearing that several hosts are locking down SSH also.

So I've been running around tonight locking down my visible servers.

This is actually good practice for the most part.  SSH is a powerful service, so any vulnerability to it tends to get magnified in importance very quickly, and also as information on the vulnerability spreads attacks multiply quickly.

The fix is simple; block SSH access to untrusted IPs.  At this juncture even if it upsets your clients, you might want to until more information trickles out about the status of this vulnerability.

If you want an easy way to create and test some new iptables rules, you can do what I do (no warranties, etc).

1. do an 'iptables-save > ~root/tmp_iptables'


2. edit ~root/tmp_iptables and add the following lines before the line that says COMMIT.  Substituting the IPs and hostnames I have added for your own of course.
   -A INPUT -s 10.0.0.1 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s my.devlab.ca -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP



3. do a 'cat ~root/tmp_iptables | iptables-restore' and cross your fingers

If things have gone horribly wrong, and I have led you down a terrible path, cutting off your SSH access, you can either console in and re-do that same process, but taking out the SSH rules, or you can have your service provider console in, or reboot the box.   The nifty thing about this method is that it's not a permanent change to your server.  It will only last until your next reboot, unless you have some process that automatically saves any iptables rules you put into place.