0

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

In light of the current speculation of a new zero-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 one day?

Some links:

http://isc.sans.org/diary.html?storyid=6742

http://74.125.95.132/search?q=cache:Y41uUwkWZeEJ:www.webhostingtalk.com/showthread.php%3Fp%3D6270083

2
  • 2
    duplicated of serverfault.com/questions/37208/…
    – sucuri
    Jul 7, 2009 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, 2009 at 20:54

4 Answers 4

0

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.

0

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.

0

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.

0

It's a difficult question to answer, because it completely depends on what your dependent 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 OpenSSH machine has access to. Remove all permissions 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.

Not the answer you're looking for? Browse other questions tagged .