On 6 Jun 2001, at 20:41, Paul D. Robertson wrote:
> On Thu, 7 Jun 2001, Ben Nagy wrote:
>
> > > Nothing on the market currently prevents a malicious client
> > > from being the
> > > source of authentication, and that's the biggest tunnel issue
> > > out there--
> > > the "Microsoft source code out the window" stuff.
> >
> > I take it you're talking about Joe Luser VPN'ing in to work when his PC is
> > already r00ted by some trojan, or similar circumstances? I've seen at least
>
> It's true not just of VPN tunnels, but yes, that is probably the
> predominantly hanging vector.
>
> > one client (Cisco - the old SafeNet one) that can chop off all other traffic
> > if a VPN connection is up. That doesn't prevent time-bombs, but it does
>
> I proposed this as a fix at an NISSC panel discussion on VPNs I
> particpated in back in '98. Back then I think it was potentially valid-
> but now-a-days I'm thinking it's actually less useful than it would
> appear...
>
> The problem is that everyone seems to _require_ HTTP/HTTPS access these
> days, so there's your trojan's control vector happily provided either
> directly, or via the corporate firewall.
And this is different from an on-site user, visiting the web
through the corporate firewall, exactly HOW? i.e. I do not see how
this risk is exacerbated if the client connection comes across a VPN
tunnel rather than just a length of Cat5.
[Consider also the case of the travelling employee who, after a
stint on the road, plugs his laptop into the internal net. No amount
of filtering at the tunnel endpoint is going to address this
analogous real-world case where a machine is sometimes connected to
the internal net, and sometimes not.]
David Gillett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
