VPN’s – promise, pitfall, implementation and policy

1. VPN’s – promise, pitfall, implementation and policy don murdoch 757 683 4580 odu – isso dmurdoch < at > 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 2Tunneling 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 Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems to interpret the data that follows as IPSec Mod’d IP Header IPSec Header Original TCP Header Original Data

17. Tunnel illustrated Original IP Header Original TCP Header Original Data Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems to interpret the data that follows as IPSec Mod’d IP Header IPSec Header Original IP Header Original TCP Header Original Data

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 Add IPSec Header – change the “protocol field” in the IP Header, allowing Systems to interpret the data that follows as IPSec Encrypted original packet Mod’d IP Header ESP Header Original IP Header Original TCP Header Original Data

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