Re: [fw-wiz] Best-of-breed Proxies (was Re: Proxy Firewalls ...)

From: Brian Hatch (
Date: 01/30/03

From: Brian Hatch <>
To: Bennett Todd <>
Date: Thu Jan 30 15:48:01 2003

> > tn-gw ssh
> For a gateway, I've constructed a highly restrictive ssh proxy
> setup.
> 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 was work-for-hire, and I no longer have that code and couldn't
> give it away if I did, but such a C wrapper is awfully trivial to
> write.

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.

Hmmn. Unless you have separate ssh identities for each user
(based on $LOGNAME) that are trusted for $LOGNAME on the
destination host. In which case you could pass those args
on to the second ssh command. As long as there's no second
authentication step, this could be seemless. I haven't tested
it, but it's intriguing.

I have had a rather reputable source meantion that the SSH
setup at their workplace would allow you to SSH out directly,
but that the firewall was running some ssh proxy that would
turn off port forwarding and other features. This proxy
would act as a MITM, because it would provide the same key
for each host, negotiate away any options it didn't like,
and then ssh out to the real server using your same
password. (Only worked with password auth, not identities.)
It would accept any username/password obviously because it
needed to work for everyone.

This was before the days of dsniff, but probably worked similarly.
The IS department said they had an actual ssh proxy, rather than
a plug-gw style proxy, so in theory this was not the result of
a cracker on the network doing dsniff-like games.

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. As a user, I'd easily be able to work around those
features by tunneling another ssh over the sanitized ssh
connection. It's nice to be able to limit things from the
hands of the less savvy, even though we all acknowledge that
anything can be tunneled over anything if you try hard enough.

Anyone heard of a real ssh proxy?

> > dns bind, chrooted (finally)
> djbdns --- dnscache is deal for use as a firewall DNS proxy.

DJBDNS is a much superiour product than BIND, in any incarnation.
Dnscache supports requests from your clients, tinydns servers
your data, walldns can create an effective no-maintenance
dummy server, axfrdns allows BIND-style domain xfrs, and axfr-get
can snag domains from BIND servers. You've got all the pieces
in one huge bloated BIND process compartmentalized into their
actual functional bits. It takes a while to get used to it,
but it's worth the switch.

Brian Hatch                  Mom, why does my hair
   Systems and                smell like vomit?  I'd
   Security Engineer          rather it smelled like   dad's hairy armpit.
Every message PGP signed