On 7 Jun 2001, at 18:11, Paul D. Robertson wrote:
> On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > > 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
>
> It's not, hence the words "or via the corporate firewall."
If it's not, then the VPN is not a relevant part of the risk
scenario you're presenting. If the vulnerability is in allowing
machines on the trusted network to browse the web, then that's all
that's needed to define the scenario.
> > [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.]
>
> Right, the difference is that you're dealing with store and forward
> intrustion versus real-time intrusion in that case.
If the VPN tunnel cuts off all other access -- as it does in the
clients I've deployed -- then the VPN case is *also* strictly store-
and-forward. THAT is whay I called this case "analogous". Again,
I'm trying to grasp what features of your scenario are relevant, and
what are not.
> .... If said laptop is only used to directly dial the corporate
> network, it's a signifcantly lower risk than if it's plugging into
> Ethernet jacks in hotel rooms.
You've lost me here. (a) Running a modem pool securely has always
seemed to me like *more* of a security challenge than a VPN, not
less, and (b) I can write any such policy I like, but how do I
monitor compliance, short of assigning each mobile user a chaperone?
> Again, if you go with application access, then that works on the
> local net as well, making it easier to place less trust on internal
> clients as well.
I suppose that if I only ever had clients and servers, I could put
all of each class in a separate subnet/VLAN and filter/NIDS/firewall
them at the router connection. That doesn't play very well in a peer-
to-peer world, does it?
[Perhaps this is an argument for segmenting the internal network by
function and deploying NIDS at the segment boundaries, as a defense
in depth. I've no argument with that! -- *except* that we've
wandered even *further* from talking about any special vulnerability
that VPNs bring to the mix.]
David Gillett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
