On Wed, 6 Jun 2001, Paul D. Robertson wrote:
> I'm interested in where you think I missed the boat- even after the
> editor had at it, it still represents my position, though it's not a
> complete representation due to space/audience limitations.
i think you forget about some things, like i noted in my original post to
the list on this topic. agent based intrusion detection on the systems,
decent security schemes on the target servers including keeping up to
date, firewalls at the host level, etc), all of this seems to have been
overlooked in your article.
you correctly note that many people look at VPNs and crypto tunnels as a
silver bullet, and in combination with the last silver bullet (the
firewall) total security is achieved. a laugable position, but one that
(as you correctly have identified) is pervasive.
that's probably just my distast of middle management showing, though.
> Tunnels can't be used to force strong authentication, only to carry it.
sure they can. SSL, IPSec, etc .. all of those can force client side
authentication, not simply setup procedures.
in the case of IPSec, node to gateway, node to node tunnels can force very
strong client authentication at the *packet* level. the listening
application should be doing screening at its own layer.
SSL and TLS can also force client side authentication at the setup level,
but not at the packet level.
you seem to forget this. you seem to think that its an open ended pipe.
> 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.
a decent scheme can significantly reduce the risk of a malicious
application impersonating the client, through various combinations of
authentication.
an actually axent has a product for their VPN client that monitors
external access to the machine aside from the other endpoint of the VPN.
so, to the best of my knowledge, but that's a start. that's been a concern
of mine back in my consuting days, and the axent product was worth looking
at for me.
as for other aplications hijacking the tunnel, or use of it, you seem
again to forget the use of firewalls *after* the traffic has emerged from
the other endpoint of the tunnel.
> VPNs are sold as security solutions when in reality they're trust
> boundary weakeners- if you understand their limitations, then
> deploying them isn't as much of an issue as if you don't understand
> that key point and go happily extending trust to every employee and
> business partner's own private networks with their own weak and weaker
> trust boundaries.
you seem to be presenting a VPN as this pipe that will allow anything in
on either end. while a poorly configure VPN can indeed do this, and
protect the content form external inspection as you note, even a modestly
correctly configured one isn't just a funnel to suck traffic in and shove
it down the pipe to the corporation, through the firewall.
i will grant you that you're poiting out considerations often overlooked
when people decide to implement VPNs, but, like i said, i think you
overlooked a number of things.
anyhow, hope this clarifies my take on things,
____________________________
jose nazario [EMAIL PROTECTED]
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
