Re: Best-of-breed Proxies (was Re: Proxy Firewalls ...)

[Bennett Todd <bet () rahul net>]

2003-01-30T14:13:16 Brian Hatch:
> > It used a chrooted sshd with private passwd/shadow files in the
> > chroot jail. The login shell for the users in that private passwd
> > was a teensy C program, that looked up the $LOGNAME in a private
> > config file to get a destination host, and execed an ssh client to
> > that host. This prevented all port forwardings and the like.
>
> This setup would seem to require two authentications.  First
> to the chrooted hop, then again to the internal machine.
> This means you'd not be able to use ssh identity authentication
> to the internal machine (since the key would be on the user's
> client, not on the middle man.)  It would also seem to defeat
> things like scp/sftp because the machine in the middle won't
> pass the commandline args along.

Yup. Plus it defeats port forwarding, X display forwarding, and
eveything else; it pretty well reduces the delivered service to
plain shell.

I construe this as a feature, but then I'm an aspiring BOFH.

> However I've never been able to find out what this mysterious
> proxy software was.  As an administrator, I'd love to have an
> actual SSH application proxy that could turn off features I
> don't like.

If you don't like _any_ feature except pure bare-naked shell with
no nothing forwarding, and if you want to demand multiple different
authentications from someone hoping to cross your moat, then it's
easy.

> As a user, I'd easily be able to work around those features by
> tunneling another ssh over the sanitized ssh connection.

It's impossible to make that impossible. It's impractical to make it
impractical. It is however easy to make it hard enough that doing so
is very obviously the work of someone deliberately thwarting policy;
and so if you add some monitoring sufficient to help improve the
odds you can pick up the different traffic pattern that results
(simple load monitoring on the proxy server would suffice here,
normal shell sessions don't cause significant load, an IP tunnel
would) you're nicely positioned to fire the perpetrator for cause
and begin prosecution. Oh, if you don't have a security policy that
clearly prohibits defeating security measures, endorsed by senior
management, with copies signed by each employee in their HR folder,
then there's no point in worrying about implementing tight controls,
or detection; you're purely dependant on the goodwill of your
employees anyway.

-Bennett

Attachment: _bin
Description: