1. VPN’s – promise, pitfall, implementation and policy don murdoch 757 683 4580 odu – isso dmurdoch odu dot edu

2. Agenda VPN’s defined Promises Pitfalls Implementations Policies

3. 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

4. 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

5. 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

6. 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 ….

7. 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

8. 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

9. 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 … ????

10. 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

11. 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

12. 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

13. 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

14. 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!

15. 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

16. 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

17. 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

18. 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

19. ESP Encapsulating Security Protocol Provides Integrity Provides Confidentiality Transport Encrypts payload of the data Tunnel Encrypts original IP header May cause IP fragmentation

20. 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

21. 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

22. 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

23. 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

24. Example w/ Cisco VPN client

25. 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

26. 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!

27. 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?

28. 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..