dmz security policy - ssh through jump server

dmz security policy - ssh through jump server

Secure Home | Search | About
 Networking Firewalls    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
dmz security policy - ssh through jump server inetquestion 07-28-2008
Posted by inetquestion on July 28, 2008, 10:25 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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

Posted by Ansgar -59cobalt- Wiechers on July 29, 2008, 9:29 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> 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

Similar ThreadsPosted
CheckPoint Policy Server - do I need aditional license? November 16, 2004, 1:27 pm
WatchGuard FireBox v60 - Security Policy June 20, 2005, 12:19 pm
Access Lists Vs Security Policy Tabs September 1, 2006, 1:50 am
Symantec Client Security 3.0 - Firewall Policy Update Failed April 28, 2006, 10:43 am
Cisco Security Manager, how does the policy manager handle precedence? September 18, 2007, 12:34 pm
Server security September 12, 2005, 11:30 pm
Security Sanity Check - Email server in DMZ or VPN Access November 23, 2004, 7:21 pm
NIS 2005 - Outlook 2000 & DNS Server "Security Alert" April 20, 2005, 7:06 am
Norton Internet Security 2004 Firewall & WinXP Pro VPN Server June 21, 2005, 9:28 pm
Firewall Policy Mgt? June 14, 2006, 4:18 pm

The site map in XML format XML site map

Contact Us | Privacy Policy