Transcript Enabling secure remote access

Enabling Secure
Remote Access
In your environment
Steve Lamb
IT Pro Security Evangelist
http://blogs.technet.com/steve_lamb
[email protected]
Our time today
Solving the access vs. security dilemma
Understanding the three methods
External access to internal web-based applications
Providing users with “desktop over HTTPS” capabilities
Building full IP-based virtual private networks
When to choose which?
The dilemma: access or security
More users require more access from more places
Increase in mobile workers and where they come from
(homes, hotels, airports, hotspots)
Wireless access is everywhere now
No longer just “employee” access: business partners,
customers
But we can’t compromise security
Remote access increases security risks
Unmanaged PCs and devices
Unpatched and unprotected devices
Difficult and expensive to implement current solutions
High prices
Difficult to deploy client side software
Ugh! How do we do this?
Internal Applications
via the Web
Examples
What’s in common?
Internal application
Runs on a web server
New business requirement for providing access
while not attached to corpnet
E-mail (Outlook Web Access)
File sharing (SharePoint varieties)
Custom applications
Security issues
HTTPS is the transport
Provides the necessary privacy for protecting
confidential information in transit over the Internet
But what about checking the content?
Intrusion detection (if you still do this)
Validating conformance to information dissemination
policies—email, documents, …
Typical design
Good:  performance
Isolates access based on
location
Protects internal network
Bad:  security
Tunnel through outside
firewall: no inspection
Many holes in inside firewall
for authentication
Anonymous initial
connections
App
App
AD
DB
Improving security
Security goals
Inspect SSL traffic
Maintain wire privacy
Enforce conformance to HTML/HTTP
Block misuse of the protocol
Allow only known URL construction
Block URL-borne attacks
Optionally
Pre-authenticate incoming connections
Protect the application with ISA Server
Better application-level security
ISA Server becomes the
“bastion host”
<a
x36dj23s
http://...
href…
2oipn49v
ISA
Server
App
DB
AD
Web proxy terminates all
connections
Decrypts HTTPS
Inspects content
Inspects URL (with
URLScan)
Re-encrypts for delivery to
web application
Protect the application with ISA Server
Better user authentication
404
ISA
Server
App
DB
AD
Easy authentication to
Active Directory
Pre-authenticate
communications
ISA Server queries user for
credentials
Verifies against AD
Embeds in HTTP headers to
application server
Requires FP1
New wizards and better HTTP rules
AuthN delegation requirements
Authenticate at the perimeter
Choice of domain membership or RADIUS
Client to ISA Server: basic or forms-based
authentication
ISA Server presents form and generates cookie
Separate timeouts for public and private computers
OWA form included; can copy and reuse code for your
own forms-based applications
ISA Server to web server: basic
Won’t work with client certificates
ISA Server has no access to client’s private key
Delegation process
401 URL
OWA form
URL + basic creds
form variables
access-request
access-accept
group attribs
RADIUS
browser
WinLogon
cookie
AD
ISA Server
data
token
URL +
basic creds
data
WinLogon
token
IIS
URLScan 2.5
Policy-based URL evaluation
Define what’s allowed; drop everything else
Just like you do in your firewall (right?)
Helps protect from attacks that—
Request unusual actions
Have a large number of characters
Are encoded using an alternate character set
Can be used in conjunction with SSL inspection to
detect attacks over SSL
Yes, the script-kiddie warez do this now, too
URLScan specifics
URL canonicalization
..\..\cmd.exe
URLScan specifics
URL canonicalization
%2e%2e\%2e%2e\cmd.exe
URLScan specifics
URL canonicalization
%352e%352e\%352e%352e\cmd.exe
?
URLScan specifics
URL canonicalization
URL length
Content length
Content types
Permitted or blocked headers
Permitted or blocked verbs
Permitted or blocked file extensions
Recall the typical design…OWA example
ExFE
SMTP
ExBE
AD
New requirements, new designs
Move critical servers
inside for better
protection
Add ISA Server to your
existing DMZ
ISA
Server
ExFE
SMTP
ExBE
AD
Use these exact words!
Increase security by
publishing web-based
applications
Few interior FW holes
RADIUS (1812,
1813/udp)
HTTPS (443/tcp)
Results
Known good content
Known good URL
Known good user
Dare I say it… trusted access? 
Remote Desktop
Mechanisms
A useful “middle ground”
If Users require more access than is possible
through standard web browser and web
server
But Full IP VPNs might be too expensive or
too complex or provide too much access
Then Consider technologies that display a
desktop remotely, probably over HTTPS
SSL VPNs
Aren’t
Are
VPNs
Appreciably simpler than other remote
desktop alternatives
Any more secure than IPsec-based VPNs
or HTTPS-protected access to published
internal web sites
Poorly-named glomming on a trend
A “remote desktop in a browser”
Accessed via web-based front ends
Running proprietary protocols that
require some ActiveX or Java add-on
Why not call it what it is?
It’s just remote desktop or remote display
Certainly not a new idea
Apparently not as sexy as “SSL VPN”
Two products can do this for you now
Terminal Server—basic remote desktop display
Citrix Metaframe—more flexible preconfigured remote
desktops and application groupings
Remote Desktop client
Remote desktop MMC
RDP in detail
Based on T-120 family of protocols
Multipoint Communications Service (MCS) (T.122,125)
Channel assignment, priority levels, data segmentation
Generic Conference Control (GCC)
Manages channels and session connections, controls resources
Extends core T.Share functionality
Two drivers
wdtshare.sys—UI, compression, encryption, framing
tdtcp.sys—package RDP onto TCP
Permits up to 64,000 data transmission channels
Current version uses one channel for keyboard/mouse
activity and display output
RDP in detail
Operates independent of network and transport
protocols
Bandwidth preservation
Compression
Caching in RAM and to disk (up to 10 MB for bitmaps)
Supports Network Load Balancing
RDP packet creation
App
App
AppApplication
App dataApp
MCS
channels
App
IP
TCP
stack
wrapping/framing
App
App
Server 2003 enhancements
Can connect to real console in admin mode
Group policy control of various options
…profile paths…wallpaper…encryption…
WMI provider for scripted TS configuration
ADSI provider for access to per-user TS profiles
TS Manager reduces automatic server
enumeration
Can limit users to a single session
Security enhancements
Follows standard Windows paradigms better
Remote Desktop Users (RDU) security group
contains IDs of allowed users
Most people allow “Everyone”
Permits controlling through group policy
Can also use Security Policy Editor to grant
permissions
128-bit RC4 (“high”) now the default
Software Restriction Policies can limit the
programs users are allowed to run
Encryption options
FIPS
compliant
High
Client
compatible
Low
Use Federal Information Processing
Standards 140-1 and 140-2
algorithms in both directions
If already configured in the system’s
policy, you can’t change it here
128-bit RC4 in both directions
Use whatever the client can support
56-bit encryption from client to
server; cleartext from server to client
Configure with group policy or TS console
Securing Terminal Server
Typical layered approach
Physical security of the server computer
Secure configuration of the operating system
Secure configuration of Terminal Server
Proper security of the network path
“Locking down Windows Server 2003 Terminal
Server sessions”—registry settings for finegrained control
Probably not necessary
Some RDP configuration settings
TS Configuration | Connections |
RDP-Tcp | Properties
End a disconnected session: 3 hours
Active session limit: 1 day
Idle session limit: 15 minutes
TS over the web is cool
Deployment
Bandwidth
Access
Rapidly deploy several applications to
many users
Keep those applications up-to-date
Lowest bandwidth requirements
Ideal for dial-up scenarios
Works on many devices, even some
non-Windows
Good for older hardware
Terminal Server over the web
connect to web page
http://server/tsweb
IIS with
RDWC
web
browser
download ActiveX control
over HTTP (80/tcp)
or HTTPS (443/tcp)
connect to TS
over RDP (3389/tcp)
Terminal
Server
Full IP VPNs
Requirements for remote-access VPN
User
authentication
Address
management
Data
encryption
Key
management
Restrict network access only to
authorized users
Provide auditing and accounting
records
Assign client computer’s address on
private network
Provide address separation
Encrypt user’s data over Internet
Keep confidential information
private
Generate/refresh encryption keys for
client and server
Important terms
Authentication Proof that all parties in a transaction
are who they say they are
Privacy Only the parties entitled to see the
transaction are able to see it
Integrity Guarantees that information hasn’t
been altered or corrupted enroute
Non-repudiation Mutual, binding confirmation that a
transaction occurred—the digital
analog of a signed contract
Authorization Ability to determine what privileges
a user has after authentication
Authentication
What you
know
What you
have
What you
are
Static passwords
One-time passwords (OTP)
Requires possession of a physical object
Cryptographic calculators
Public key smartcards
Supported for IPsec, SSL/TLS, EAP
Authenticates the person
Fingerprint analysis
Retinal scan
Speech pattern recognition
Not based on a device or knowledge
which can be transferred
Supported for EAP
Authorization
Reasons to care about authorization
Untrusted users on internal net (vendors, contractors)
Need for different treatment of classes of users
Machine certificates are not enough
Makes authorization difficult
Guest has the same privileges as Administrator
Issue addressed in L2TP+IPsec
IPsec machine certificates provide integrity protection
and encryption
L2TP provides user authentication
LDAP/RADIUS provide authorization
Privacy
What good is it to authenticate and then have
data sent in the clear?
Privacy achieved through encryption
Implies need for authentication and key management,
protected ciphersuite negotiation
L2TP+IPsec provides for tunnel authentication, key
management, and protected ciphersuite negotiation
EAP-TLS (PPTP) provides key management, mutual
authentication and protected ciphersuite negotiation
MS-CHAP v2 provides key management, mutual
authentication for PPTP; encryption is MPPE
Physical security does not ensure privacy
Are telco WANs really more secure than IP?
Stateful vs. stateless encryption
Stateful
Stateless
Ability to decrypt a packet depends on
previous packet(s)
If previous packet(s) were lost, you also
lose current packet
If packets are sent out of order can result
in loss where there was none
Result is poor performance on lossy
networks (like the Internet)
Ability to decrypt a packet does not
depend on previous packet(s)
Method of choice for use over the Internet
IPsec and MPPE are stateless
Integrity protection
What good is it to authenticate and then have
your connection hijacked?
Want mutual authentication to ensure against
rogue servers
Need per-packet integrity protection
L2TP+IPsec provides for integrity protection on all data
and control packets
PPTP v2 (with MS-CHAP v2) offers per-packet integrity
protection
Your choice of protocols
PPTP
Authenticates human
Assigns IP address to remote computer
Encrypts session with MPPE (128-bit RC4)
Requires good passwords to be secure
MS-CHAPv2 ciphers based on password
Works over NAT
L2TP+IPsec
L2TP
Authenticates human
Assigns IP address to remote computer
IPsec ESP transport mode
Mutually authenticates computer and server with
digital certificates or preshared keys
Encrypts session with 3DES
Works over NAT finally
L2TP+IPsec packet format
App data
IP
np
UDP
L2TP
PPP
IP
np
IP
IPsec
UDP
L2TP
PPP
App data
App data
IP
np
App data
IP
sec
L2TP+IPsec client automatically
generates IPsec security rule
Windows L2TP always uses UDP
source port 1701, dest port 1701
Outbound Filter
Source IP = My IP address (Internet)
Dest IP = Gateway IP
Protocol = UDP
Source port 1701, dest port any
IPSec IKE negotiation is for
dest port = any, so that filter
mirror for inbound port = any
Inbound Filter
Source IP = Gateway IP
Dest IP = My IP Address (Internet)
Protocol = UDP
Source port any, dest port 1701
Allows gateway to float
response port (per L2TP
RFC 2661)
L2TP+IPsec connection is protected
L2TP
IPsec
tunnel
IKE negotiation,
setup and
management
machine cert
inside
authN
IPsec
Establish IPsec SAs for
L2TP port 1701/udp
User authN
policy
enforcement
RADIUS
AD DC
No traffic gets in until:
IPsec SAs are established—strong security based on mutual certificate trust
User authenticated in L2TP—all protected by IPSec. PPP could use CHAP,
MS-CHAP (userid/password), EAP (smartcard or token card); RADIUS client
in gateway permits single sign-on for Active Directory user accounts
User access control policy OK—RRAS server, IAS, and AD
Where do you put the RRAS server?
How about on the firewall?
How RRAS+ISA secures client connections
Broad protocol support
PPTP and L2TP/IPSec
IPSec NAT traversal (NAT-T) for connectivity across any
network
Authentication
Active Directory uses existing Windows accounts,
supports PKI for two factor authentication
RADIUS uses non-Windows accounts databases with
standards-based integration
SecurID provides strong, two-factor authentication
using tokens and RSA authentication servers
All inbound and outbound traffic is inspected by
ISA Server’s protocol filters
How RRAS+ISA controls network access
Multi-network support
Control which portions of your network are accessible
from remote locations
Application layer firewall
Inspects all traffic to and from remote clients
Ensures conformance to protocol specifications
Network quarantine
Perform security checks on client before it’s allowed
access to the internal network
Provide mechanism for out-of-date clients to update
themselves
Network access quarantine
Client script checks whether client meets
corporate security policies
Personal firewall enabled?
Latest virus definitions used?
Required patches installed?
Routing table updates disabled?
Password-protected screen saver enabled?
If checks succeed, client gets full access
If checks fail client gets disconnected after
timeout period
VPN quarantine process (1)
RRAS+ISA assigns client to
quarantined VPN clients
network, allowing access to
limited resources
Internal
network
Quarantine
resources
RRAS+ISA assigns client
to VPN clients network,
providing access to
internal network
Script on client
computer checks
configuration settings



Client computer
connects
Script sends “success”
notification to RRAS+ISA
VPN quarantine process (2)
RRAS+ISA assigns client to
quarantined VPN clients
network, allowing access to
limited resources
Quarantine
resources
RRAS+ISA will
disconnect client
after timeout expires
Script on client
computer checks
configuration settings

Client can update
from quarantine
resources
Client computer
connects
Script does not send
“success” notification
to RRAS+ISA
Quarantine architecture
Quarantine
Internet
RAS client
CM profile
• Runs customizable
post connect script
• Script runs RQC
notifier with “results
string”
RRAS+ISA
Listener
• RQS receives notifier
“results string”
• Compares results to
possible results
• Removes time-out if
response received but
client out of date
• Removes quarantine filter
if client up to date
IAS
Server
Quarantine VSAs
• Timer limits time
window to receive
notify before auto
disconnect
• Q-filter sets
temporary route
filter to quarantine
access
So What to Do Now?
Resources
Everything about VPN and RRAS
http://www.microsoft.com/vpn
ISA Server info and deployment guides
http://www.microsoft.com/isaserver
Terminal Server
http://www.microsoft.com/terminalserver
Now available!
Order online:
http://www.awprofessional.
com/title/0321336437
Use promo code
JJSR6437
Thanks to Steve Riley
[email protected]
who wrote this presentation
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
How Microsoft
Does VPN
Current state of RAS at Microsoft
Two-factor authentication for VPN
Client placed in quarantine upon connecting
Security checks performed while in quarantine
Additional usability and security checks run
outside of quarantine as part of the connection
Three types of connection options:
Direct dial
Microsoft-contracted 3rd-party ISP
VPN over the Internet (this is >85% of use)
All connections end with a VPN session
RAS service—quick facts
User base: ~55,000 Microsoft employees and
~25,000 contract employees worldwide
Average of 45,000 unique RAS users per month
worldwide
Remote access devices globally
95 VPN servers, 17 RADIUS servers
18 standalone Cisco dial devices, 51 dial modules on
shared Cisco network device
Typical weekly RAS connections
Total direct dial
Total VPN
Total RAS over Internet
Average connection duration (min.)
~193,233
11,268
173,532
10,759
134
Special implications of VPN
Most use of VPN comes from unsecured networks
Verifying the identity of VPN users requires a
higher bar
The higher bandwidth enabled by broadband also
increase effectiveness of brute force attacks
Servicing the security needs of a remotely located
client brings additional challenges
The RAS security threats
Malicious users
Unpatched vulnerabilities and weak configurations
expose valid network credentials
Home users’ machines are frequently attacked
Remote network access secured only by passwords
Unauthorized activity with valid credentials is difficult to
detect and prevent
Malicious software
Unmanaged and infected remote devices put corporate
resources at risk
Viruses, trojans, worms
Always-on broadband Internet access heightens
exposure
Addressing the security threats
threat
Malicious
users
Malicious
software
requirement
Two-factor
authentication
Enforce remote
system security
configuration
solution
Smartcards for
RAS logon
Connection
Manager and RAS
Quarantine
Strengthening identity with smartcards
Smart card chip added to
existing building access
cards
Remote access policy (RAP)
deployed on VPN/RADIUS
infrastructure
Uses existing self-hosted
PKI for digital certificate
management
Centralized card
management team formed
to manage card creation,
distribution, and support
Securing the RAS client
Infrastructure components
Windows 2003 RRAS server (~400-600 ports
configured per server)
RQS on RRAS server
Internet Authentication Services (IAS)
Responsible for authentication and policy setting
Can apply different policies based on back end rules (this is
how exceptions are granted)
Connection Manager Administration Kit (CMAK)
ISA Server 2004
Client side components
Custom connection created with CMAK
Security scanning scripts—”Secure Remote User” (SRU)
Why ISA Server 2004?
Packet size limitation with RADIUS that limits the
size of the filter list
Microsoft needs more servers in the quarantine
network then the limit allows for:
DCs
SRU Servers
DNS
Management of filter lists is easier with ISA Server
2004 then using IAS filters
Connection Manager
Provides mechanism to manage phone book
entries for service
Enables entry points for actions executed during
connection experience
Pre-initialize
Pre-connect
Post-connect
Pre-tunnel
Post-tunnel
SRU runs in various places during the connection
Secure Remote User (SRU)
Designed and developed by Microsoft IT
Enterprise Application Services (EAS)
Performs critical security checks
Windows Firewall on
Internet Connection Sharing off
Patch management
Anti-virus using Computer Associates eTrust
Operating system version compliance
Very flexible, self updating and gathers metrics
from the users perspective
RAS Infrastructure
Custom
automated
reporting
User session
data transfers,
regional
IAS / RADIUS
servers
Active Directory,
User groups,
Global catalog
Domain
controller
SQL Server
central database store
Lightweight Directory
Access Protocol (LDAP)
authorization Secure
Remote Procedure Call
(RPC) domain
authentication
IAS proxy server
RADIUS authorization
Microsoft user
account
authentication
EAP-TLS security
authentication
(smart card)
r a te
rpo
ft co undary
o
s
o
ro
Mic work b
net
Corporate
network
resources
IAS / RADIUS
server
Direct dial
Cisco router
Internet
Routing and
Remote Access
VPN server
Telephone
service
MS-CHAP v2
authentication
ISP
VPN tunnel over
broadband connection VPN tunnel
over ISP
using EAP-TLS
connection
using
VPN tunnel
EAP-TLS
over dial-up
connection
Analog / ISDN
dial connection
through ISP
Analog / ISDN
dial connection
Legend
data transfer path
authentication transfer path
physical dial connections
Modem
CHAP
authentication
Remote
client
Smart
card
The user experience
Average connect experience worldwide is under
two minutes
Failed security check results in opportunity to
remediate
Microsoft IT design decision
Incorrect smartcard PIN results in quick
notification
Since PIN unlocks card, decision is made locally
Five incorrect PIN entries will lock the smartard; takes a
help desk call to unlock
Lessons we learned
Manage change—minimize overlaps
Deploy smartcards first
Then Connection Manager and security scanning second
Provide internal and external sites where users can obtain
security tools
Consider analog dial-up users when designing security
scripts
Communicate and set user expectations clearly
The solution is only as good as the components
Monitor and measure each required element
Don’t wait until using RAS to bring machine into
compliance—encourage proactive security practices