Transcript VPN`s – promise, pitfall, and policy

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




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



Requires




Put one type of packet inside another
Can put non IP protocols inside of IP
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




Before VPN, complicated to allow access



Assume a simple security policy
Internal IP based access management
An Intranet with site-licensed software
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




Home Network


Some client security software wants to reconfigure on the fly
Multiple tunnels can be impossible
May require address changes in order to be implemented
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 Original
IP
TCP
Header 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
Tunnel illustrated
Original Original
IP
TCP
Header 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 Original
IP
TCP
Header Header
Original
Data
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


Tunnel


Encrypts payload of the data
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 Original
IP
TCP
Header 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
Encrypted original packet
ESP
Header
Original Original
IP
TCP
Header Header
Original
Data
VPN Concentrators

Concentrator is NOT a gateway or firewall
• Many sites implement it parallel to a firewall

Specialized device



Authenticates clients



Only accepts connections from VPN peers
Handles encryption and VPN management
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


Placement


Require strongest mutual authentication
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..
