> -----Original Message-----
> From: Steve Riley (MCS) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 06, 2001 1:45 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Encryption vs. inspection.
>
[SNIP]
> The typical complaint against encrypted communications --
> whether IPSec
> transport mode or tunnels of various kinds -- is that once a
> machine is
> compromised, then the attacker has a direct invisible route into
other
> machines. This seems a reactionary stance.
Its not a stance; its a fact. IF you have a total VPN, which permits
any traffic whatsoever between two end-points, and one end-point is
compromised, then (barring any man-in-the-middle kludge which lets you
check the content in transit) any traffic injected in the compromised
end will be accepted at the other end, and you will be unable to check
that transit passively. Whether that is acceptable or not depends on
your set up, and where you place the end-points.
Jose mentions a number of ways to mitigate this; agent based IDS's and
the MITM kludge which is, as he points out, a pipe dream. More
important (imo) is that one treats data coming down that pipe as one
would data coming from any remote location (ie don't put your end of
the VPN on an internal LAN or protected network).
> If (as Jose mentions) we force strong machine-to-machine
> authentication,
> then the previous concern is moot: how can an attacker compromise a
> machine at all? Am I missing something basic here, or is it
> that simple?
> (No flames, please. :))
Well, if you have a common security policy shared between both ends of
the VPN, and that policy is enforced (ie, if you realy do trust the
other end NOT to be compromised) no problem. However, VPN's are
increasingly being used to link sites together with differing security
levels, and unfortunately, with the turnkey solutions becoming easier
and easier to implement, little thought is being given to the
implications thereof.
As for strong machine-to-machine authentication, whether that gains
you anything depends on what you use.
VPN's have their place; they prevent eavesdropping, and can aid in
authentication. However, all you're doing is extending the boundary of
your network. It still needs to be a boundary, and you still need to
watch the traffic once it gets to your end; just because it somehow
made it into your pipe doesn't mean that it should inherently be
trusted (that is, unless you fully trust the other end; in many
real-world implementations I've seen, that is far from a given.)
My $.02. . .
Henry
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
