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