CYBR 230 Jeff Shafer University of the Pacific Virtual Private Networks (VPN)
2 Schedule This Week Mon September 4 Labor Day No class! Wed September 6 VPN Project 1 Work Fri September 8 IPv6? Project 1 Work Next Week Mon September 11 Instructor Busy No class! Wed September 13 Project 1 Due Fri September 15 TBD Secure Software Systems
3 VPN
4 Use Case 1 Site-to-Site VPN Remote Site 1 Remote Site 2 Internet Corporate LAN Remote Site 3
5 Use Case 2 Remote Access VPN User 1 User 2 Internet Corporate LAN User 3
6 VPN Design Considerations Security Addressing Routing Interoperability Performance
7
8 Wishful Thinking? Legacy Systems Security
9 VPN Design - Security Confidentiality, Integrity, Availability Best Practice if no legacy systems: IPSec with SHA2 hashing + AES encryption + Internet Key Exchange (IKE) v2 IPSec goals Verify sources of IP packets (authentication) Protect integrity and/or confidentiality of IP packets (encryption) Prevent replaying of old packets Operate at IP layer
10 IPSec Architectures Host-to-host Secure communication with single host Host-to-network (or host-to-gateway) Remote access VPN Network-to-network (or gateway-to-gateway) Site to site VPN
11 IPSec Protocol Suite Authentication Header (AH) RFC 4302 Prevents spoofing (source authentication) + protects data integrity from tampering + prevents replay attacks NO encryption (confidentiality), not recommended for VPN) Encapsulating Security Payload (ESP) RFC 4303 All features of AH, plus. Symmetric key encryption to provide confidentiality Internet Key Exchange (IKE) RFC 4306 Dynamically generates and distributes cryptographic keys for AH and ESP no more pre-shared keys
12 Encapsulating Security Payload Authentication algorithms (cryptographic hash) SHA2 (256, 512) (recommended) SHA1 MD5 (weak, not recommended / disable) Encryption algorithms AES (recommended) Blowfish (deprecated), Twofish (newer, not patent encumbered, lacks hardware acceleration) Camellia (Japanese) 3DES (not hardware accelerated, not recommended) DES (weak, not recommended, disable)
13 Transport vs Tunnel Mode Transport mode Secure communication between two endpoints Encapsulates IP payload only Tunnel mode Used for VPNs Entire original IP packet is encapsulated New packet header added ESP protection applies to entire inner IP packet, outer header is unprotected
14 Transport vs Tunnel Mode No IPSec: Ethernet IP Header TCP Header Payload IPSec, Transport Mode: Protected Ethernet IP Header IPSec Header TCP Header Payload IPSec, Tunnel Mode: Protected Ethernet IP Header (Gateway) IPSec Header IP Header (Original) TCP Header Payload
15 VPN Design - Addressing VPNs are (typically) not broadcast domains Where is broadcast used? VPN software/hardware acts as a router Thus, VPN clients should receive addresses in a new, VPN-specific subnet
16 VPN Design - Routing If I connect to site VPN, does all my traffic goes through the VPN? Advantage Simple design Or only traffic destined to the corporate network? Advantage Higher performance (potentially), company doesn t support both inbound and outbound traffic for employee ESPN.com usage
17 VPN Design - Interoperability Do you need to support legacy clients? Windows IKEv2 support in Windows 7+ Mac OS IKEv2 support in 10.11+ ios IKEv2 support in ios 8+ (config profile only) or ios 9+ (full GUI support) Android Still no native IKEv2 support as-of 2017 strongswan Android VPN client Linux varies by distribution Older operating systems quickly revert back to legacy/insecure algorithms MD5 identity algorithm, DES/3DES encryption, pre-shared key Windows example: https://technet.microsoft.com/enus/library/dd125380(v=ws.10).aspx
18 VPN Design - Performance Are your encryption / hashing algorithms hardware accelerated on gateway? (affects throughput) Do you load balance your VPN endpoints? (affects availability and scalability) Do you have to fragment frames to fit within Ethernet frame limits? Always a tunneling headache