VPN’s – promise, pitfall,

implementation and policy

don murdoch757 683 4580odu – issodmurdoch < at > odu dot edu

Agenda VPN’s defined Promises Pitfalls Implementations Policies

VPN’s defined Virtual Private Network Ensures private, secure communication between hosts over an insecure medium using “tunneling”

Usually between geographically separate locations

Connecting computer is logically directly connected to a network –has a local address that it uses to communicate through the tunel

Tunneling defined Encapsulation

Put one type of packet inside another Can put non IP protocols inside of IP

Requires Consistent rules on each side Both parties must be aware of tunnel for it to work

Tables to keep track of the conversation Not a panacea

Traffic patterns can be observed even through the data is likely to be protected

Back to defining VPN’s Commonly use standardized, well respected encryption to secure communications

Two main types of VPNs – Remote-Access from a client system

Site-to-Site – between two networks

VPN advantages Control remote access through one perimeter device

• Close off other avenues of remote access • Devices all obey the same rules• Single access point allows for activate / deactivate accounts

• Provide high quality logging of remote access activity

• Plug other holes

Avoid excess provisioning costs Of dedicated lines, not devices ….

Promises Originally designed as inexpensive alternative WAN over leased lines Variety of existing insecure channels exist such as the commodity Internet

Now mostly used to securely connect computers and remote sites over the internet

Convenient (somewhat) Can now communicate securely over insecure protocols and channels

Promises – an example Example – it *may* simplify security

Assume a simple security policy Internal IP based access management An Intranet with site-licensed software

Before VPN, complicated to allow access Train all employees to use SSH tunnel Provide a tunnel support server

After VPN, employees can be offsite and connect VPN client is assign an internal IP address Minimal impact on Intranet servers rules

Pitfalls Not always easy to use

Some client security software wants to reconfigure on the fly

Multiple tunnels can be impossible May require address changes in order to be implemented

Home Network ISP’s avoid static IP address and some don’t allow VPN traffic

Overall support Client installs can be challenging Name lookups can be difficult Mapping to a share or app server requires … ????

Falling in more pits Expectations of users – the term “VPN” means different things to different people

Frequently Frustrating Troubleshooting

Interoperability with other Networks/VPNs can be problematic

Small performance overhead VPN client bound by network rules

Quagmire Local network is now subject to any security issues on the remote client

Microsoft’s source code believed to be stolen by a game developer w/ a remote control Trojan …

• Enticed to install a game demo• Trojan alerts controller when on Internet• Trojan takes actions while user connected via VPN

• Trojan reports back to controller

The Quicksand of Split Tunneling

Some VPN’s allow clients to send “secured” data to the VPN gateway while allowing general network access

Danger is that this process setups two paths – one to the Commodity Internet and the other to the site

Access rules often defined on client as a “network access list”, exposing private site data and configuration

Implementations Point to Point Tunneling Protocol

• Data encapsulated into a PPP packets, then GRE packets sent along.

• Channel for data and for control

IPSec (discussed next) Secure Shell

• Interactive login w/ port forwarding capability

Secure Socket Layer VPN Layer 2 Tunneling Protocol

IPSec Common & preferred connection method today

Can add authentication and / or confidentiality to the traffic or both

Coexists w/ current IP implementations and infrastructure components such as routers, analysis tools, etc.

Can be very complicated to troubleshoot It’s very nature is designed to prevent eavesdropping!

Tunnel and Transport Tunnel

Encapsulates each of the original packet inside another packet

Transport Adds an IPSec header to the original packet

Allows for detecting errors or changes in transit

Does not have to automatically encrypt data

Insures authenticity of the source

Transport illustrated

Original IP

Header

Original TCP

Header

Original Data

Mod’d IP

Header

Original TCP

Header

Original Data

IPSecHeader

Add IPSec Header – change the “protocol field” in the IP Header, allowingSystems to interpret the data that follows as IPSec

Tunnel illustrated

Original IP

Header

Original TCP

Header

Original Data

Mod’d IP

Header

Original TCP

Header

Original Data

IPSecHeader

Add IPSec Header – change the “protocol field” in the IP Header, allowingSystems to interpret the data that follows as IPSec

Original IP

Header

AH Authentication Header protocol

Offers Authenticity and Integrity w/o encryption

Uses cryptographic hash to verify each packet

Covers entire packet and will not survive NAT

If any part of original message changes, it will be detected

Prevents IP Spoofing and transmission errors

ESP Encapsulating Security Protocol

Provides Integrity Provides Confidentiality

Transport Encrypts payload of the data

Tunnel Encrypts original IP header

May cause IP fragmentation

Most likely implementation ESP builds tunnel Split tunneling not possible Shared secret “password”, hopefully a certificate

Connect to concentrator Get private IP on the network Get all access (often dangerous) Little to no Internet access over the VPN

Most likely (illustrated)

Original IP

Header

Original TCP

Header

Original Data

Mod’d IP

Header Original TCP

Header

Original Data

ESPHeader

Add IPSec Header – change the “protocol field” in the IP Header, allowingSystems to interpret the data that follows as IPSec

Original IP

Header

Encrypted original packet

VPN Concentrators Concentrator is NOT a gateway or firewall

• Many sites implement it parallel to a firewall

Specialized device Only accepts connections from VPN peers Handles encryption and VPN management

Authenticates clients Against local database or through RADIUS or TACACS+

RADIUS / TACACS+ can (and should) defer to a centralized LDAP directory

Enforces VPN security policies

Concentrator connections Steps

Establish username / password / access restrictions (IP, encryption, Time, source …)

Install client software if necessary•Win2000 has VPN client software

User defines “VPN Connection” to the site

Makes connection Now can ONLY talk to the site

Example w/ Cisco VPN client

Implementation Issues Additive to remote access procedure and policy Require strongest mutual authentication

Placement Just where to these devices go?

System Appliance, Firewall integration, software

Policies part one Like every year, APA audits different things

Missing a “VPN” specific policy w/ rules

Wrote a VPN policy Wrote a specific access form w/ clear statements, authorized signature

Needed to change it almost immediately!

Policies part two Can anyone install the client? Where can anyone use the client from? Do you allow home users on their own personal (non CoVA) PC’s to connect?

What are the minimum client security requirements?

Who supports what? Who handles the investigation should an incident occur?

Who monitors connections and when?

A few more issues … Do you allow connections back out to the Internet w/o a proxy? Or at all?

Do you intend on providing “access groups” or provide general access?

Remember – this is a known, sanctioned back door into the network from anywhere..