dmz security policy - ssh through jump server - Firewalls

This is a discussion on dmz security policy - ssh through jump server - Firewalls ; A couple of fellow computer geeks and I were discussing some proposed changes to how people/processes access servers within the DMZ. The proposed solution involved routing all SSH access through a set of jump box servers. From there you could ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: dmz security policy - ssh through jump server

  1. dmz security policy - ssh through jump server

    A couple of fellow computer geeks and I were discussing some proposed
    changes to how people/processes access servers within the DMZ. The
    proposed solution involved routing all SSH access through a set of
    jump box servers. From there you could then ssh wherever you need to
    go. These servers also allow you to tunnel your traffic through to a
    server on the inside. They also allow you to setup ssh key pairs so
    that you do not have to enter a username/password during each hop. My
    initial concern is that this new policy is going to break many of the
    existing processes which are working with direct ssh access to all the
    target hosts. They assured me that any commands I run today will work
    when going through the new jump boxes.

    My overall response to this change wasn't very positive. Are there
    flaws in how the implementation is being proposed. Essentially they
    left it up to each user to work out for themselves how to manage
    setting up the ssh tunnels. From what I have seen so far most people
    are hard coding these tunnels to specific ports. For a small set of
    tests/users this probably works well. However what happens when you
    end up with different groups of users who clobber each others attempts
    to setup the ssh tunnels or a set of scripts run by the same user step
    on each others port lock due to overruns in the run times, etc?
    Granted you could solve this problem with code, but it seems like a
    hack to me...

    Back to the original point of this post, what is the added security to
    this approach? Now you have one box (or a set) to go through...what
    did this buy you? If I can do all the same actions I once could what
    added security is being employed? Since most of the processes we are
    talking about here use services accounts to operate none of them are
    tied to an individual. I agree with the approach for individual
    users, but for automated processes it doesn't make sense.
    suggestions?


    -Inet

  2. Re: dmz security policy - ssh through jump server

    inetquestion wrote:
    > A couple of fellow computer geeks and I were discussing some proposed
    > changes to how people/processes access servers within the DMZ. The
    > proposed solution involved routing all SSH access through a set of
    > jump box servers. From there you could then ssh wherever you need to
    > go. These servers also allow you to tunnel your traffic through to a
    > server on the inside. They also allow you to setup ssh key pairs so
    > that you do not have to enter a username/password during each hop. My
    > initial concern is that this new policy is going to break many of the
    > existing processes which are working with direct ssh access to all the
    > target hosts. They assured me that any commands I run today will work
    > when going through the new jump boxes.
    >
    > My overall response to this change wasn't very positive. Are there
    > flaws in how the implementation is being proposed. Essentially they
    > left it up to each user to work out for themselves how to manage
    > setting up the ssh tunnels. From what I have seen so far most people
    > are hard coding these tunnels to specific ports. For a small set of
    > tests/users this probably works well. However what happens when you
    > end up with different groups of users who clobber each others attempts
    > to setup the ssh tunnels or a set of scripts run by the same user step
    > on each others port lock due to overruns in the run times, etc?
    > Granted you could solve this problem with code, but it seems like a
    > hack to me...
    >
    > Back to the original point of this post, what is the added security to
    > this approach? Now you have one box (or a set) to go through...what
    > did this buy you? If I can do all the same actions I once could what
    > added security is being employed? Since most of the processes we are
    > talking about here use services accounts to operate none of them are
    > tied to an individual. I agree with the approach for individual
    > users, but for automated processes it doesn't make sense.
    > suggestions?


    Frankly, I don't see any real benefits with this approach, but at least
    two issues. First, you have additional maintenance overhead, because
    then you'll have to maintain the users not only on the target hosts, but
    also on each jump-box. Second, users will have to deposit private keys
    on several hosts instead of just having one private key on their
    workstation.

    What benefits are you/your colleagues expecting from the jump-box setup?

    cu
    59cobalt
    --
    "If a software developer ever believes a rootkit is a necessary part of
    their architecture they should go back and re-architect their solution."
    --Mark Russinovich

+ Reply to Thread