VPN’s – promise, pitfall, implementation and policy don murdoch odu – isso dmurdoch 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 IPSec Header Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems 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 IPSec Header Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems 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 ESP Header Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems 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..