[VPN] Application timeouts over VPN...HELP!

Ryan Malayter rmalayter at bai.org
Wed Apr 9 13:36:40 EDT 2003


From: Alex Pankratov [mailto:alex at cipherica.com] 
>can you explain why *exactly* it's 
>a "bad security" ? Especially given 
>that the TCP connection in question 
>is IPsec'ed in first place.

If the tunnel is left open, and the engineer's workstation is online and
idle, the workstation becomes a vector for compromising the security of
the encrypted traffic.

If the workstation is unmanned, and the screen is accidentally left
unlocked, someone could walk up and compromise the shared secret key by
looking at the Ipsec cleint settings. Or someone could walk up and hack
the OS (many prviliege-elevation hacks on Windows NT/2000/XP and other
OS require console access), or use a debugging tool to dump the memory
and find the shared secrets or session keys. 

These attacks could be nearly as harmful as if the tunnel was down,
since a remote-control backdoor or whatever could be installed, which
could later be used compromise encrypted traffic. However, if these
attacks are made while the VPN is up, then devices on the other end of
the VPN connection become ready and easy targets of opportunity for the
attacker. (There are usually loose - if any - Firewall rules applied to
a VPN connection, so remote-compromise attacks would be much easier).

Now, if all devices at the endpoints of the VPN are physically secure,
and properly firewalled, then you don't have to worry too much about
idle tunnels being a security risk.

<flame_bait>
If fact, I'd go so far as to say strong encryption is basically
redundant on a VPN. Even on a VPN with lowly single-DES encryption,
hacking the endpoint workstations or servers (either remotely or
physically) is likely to be an easier attack than breaking the VPN
encryption.
</flame_bait>

Regards,
	-ryan-



More information about the VPN mailing list