"John P. Rouillard" <rouilj @
terminus .
cs .
umb .
edu> wrote:
> Sadly, this sort of attack seems to be able to be used on just about
> any firewall system out there that allows connection level access. I
> think a twist on the same mechanism would work across most application
> level gatways (telnet would be a trivial example).
Yes, one could envisage such an approach with any application gateway or
proxy mechanism that does not require further authentication on outbound
connexions. I remember Marcus Ranum talking about this possibility on
the list a while back: the alternative being real authentication (eg
SecurId) for every outbound connexion as well as every inbound; the TIS
Toolkit has hooks for this, I think.
Taking the particular case of SOCKS..
On Sat, 26 Mar 1994, Eric Murray wrote:
> Perhaps the next version of socks should provide some sort of
> encrypted token exchange to allow only 'approved' clients to connect, even
> from inside your bastion host...
I assume you mean so that only approved client _programs_ can connect
out? (of course you already have control over which client _hosts_
can do so)
Well, it needn't be quite as simple as described, in that each site's
SOCKS library is different, having knowledge of the particular
configuration. Of course, it's probably not hard to guess a site's
default SOCKS proxy host. Configuring your site's SOCKS to use
non-default client route configuration file locations and a non-standard
SOCKS port will also help. But yes: adding a further site-specific
exchange might make things a shade harder too.
With care, an arbitrary smuggled-in SOCKSed client would not work in
your environment. No: a cleverer attack would be to use the genuine
clients that a site already had, with all the knowledge already in them.
Which brings us back to SecurID on each outgoing connexions -- and break
it to your users that they can't have Mosaic!
I.
--
Ian Dunkin <imd1707 @
ggr .
co .
uk>
--
Follow-Ups:
References:
|
|
