Home / server / Questions / 37312
In Process
dr.pooter
Asked: 2009-07-08 12:02:36 +0800 CST

OpenSSH vulnerability [duplicate]

  • 772

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

security

4 Answers

  1. 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

  2. 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

  3. 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.

    • 0

  4. 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