Upload
reagan-luna
View
18
Download
3
Embed Size (px)
DESCRIPTION
VPN’s – promise, pitfall, implementation and policy. don murdoch 757 683 4580 odu – isso dmurdoch < at > odu dot edu. Agenda. VPN’s defined Promises Pitfalls Implementations Policies. VPN’s defined. V irtual P rivate N etwork - PowerPoint PPT Presentation
Citation preview
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..