Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
SSH server 0-day exploit - Suggestions to protect ourselves

In light of the current speculation of a new 0-day exploiting a remote vulnerability against OpenSSH, I'm curious to answer a couple of questions.

  • What steps do you take to mitigate this risk.

Implement hard ingress filters? I understand that at least one major hosting provider has done this.

Disable the service until risk is better understood? Can you rapidly identify running versions across your network.

  • How do you verify the extent of the risk

In-house source code eval? Do you have those skills.

Favorite security sites/feeds? How do you determine fact from rumor.

  • How does your change management system deal with these changes

Have an expedited process for emergency changes? Can you pull an eval and execute a plan in 1 day.

Some links:

share|improve this question

marked as duplicate by Zoredache, splattne Jul 8 '09 at 10:32

This question was marked as an exact duplicate of an existing question.

duplicated of… – sucuri Jul 7 '09 at 20:09
Thanks for the pointer to your question. I'm more curious about how a large enterprise deals with this situation rather than specific questions related to using ipfilter or some other technology. – dr.pooter Jul 7 '09 at 20:54

I think the most important thing to do would be to upgrade your version of OpenSSH. The other things to do as you mentioned would be to limit those who have access to the SSH service; however this should already be an implemented security practice.

share|improve this answer

In addition, you could make your servers listen on an alternate port number (high up), just to make a bit more difficult for port scanners.

share|improve this answer

It's a difficult question to answer because it completely depends on what your dependant users require.

  • Have local only users who need access from home? Shut off the service. They can manage until it's fixed.
  • Have remote users? Segment off the network, and limit the services the Open SSH machine has access to. Remove all perms for any user on that machine.

And so on. Sorry it's a vague answer, but without more requirements, this is the best you can do.

share|improve this answer

First of all, limit the potential risk by minimizing your visibility. In other words, make sure that as few services are visible and publicly accessible as possible. Do you need an ssh server accessible to the public? Or can you restrict all of your ssh access to only be available behind a VPN?

By limiting all access in such a way that it has to go through a single (or few) security choke-points, you make it significantly harder for someone to reach the box in order to exploit it.

For example, at my last job, where I was responsible for this kind of policy and the implementation of said policy, we only had one single box that with accessible via the Internet. All other access required going through the VPN. That box was the "backup access" point, and it was severely locked down with ACL's and firewall rules so that it could only be accessed from a small number of remote hosts. This gave us remote access in the event of a problem with the VPN concentrator, but limited that access to just a handful of key people.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.