Enabling Secure Remote Access In your environment

1. Enabling SecureRemote AccessIn your environment Steve Lamb IT Pro Security Evangelist http://blogs.technet.com/steve_lamb stephlam@microsoft.com

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

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

4. Internal Applicationsvia the Web

5. Examples • E-mail (Outlook Web Access) • File sharing (SharePoint varieties) • Custom applications • What’s in common? • Internal application • Runs on a web server • New business requirement for providing access while not attached to corpnet

6. 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, …

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

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

9. Protect the application with ISA ServerBetter application-level security • ISA Server becomes the “bastion host” • Web proxy terminates all connections • Decrypts HTTPS • Inspects content • Inspects URL (with URLScan) • Re-encrypts for delivery to web application x36dj23s 2oipn49v <a href… http://... ISA Server App DB AD

10. 404 Protect the application with ISA ServerBetter user authentication • 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 ISA Server App DB AD

11. New wizards and better HTTP rules

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

13. access-request URL 401 OWA form access-accept group attribs URL + basic creds form variables WinLogon cookie token URL + basic creds data WinLogon token data Delegation process browser RADIUS AD ISA Server IIS

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

15. URLScan specifics • URL canonicalization ..\..\cmd.exe

16. URLScan specifics • URL canonicalization %2e%2e\%2e%2e\cmd.exe

17. URLScan specifics • URL canonicalization ? %352e%352e\%352e%352e\cmd.exe

18. URLScan specifics • URL canonicalization • URL length • Content length • Content types • Permitted or blocked headers • Permitted or blocked verbs • Permitted or blocked file extensions

19. Recall the typical design…OWA example ExFE SMTP ExBE AD

20. ExFE SMTP ExBE AD New requirements, new designs • Move critical servers inside for better protection • Add ISA Server to your existing DMZ • Use these exact words! • Increase security by publishing web-based applications • Few interior FW holes • RADIUS (1812, 1813/udp) • HTTPS (443/tcp) ISA Server

21. Results • Known good content • Known good URL • Known good user • Dare I say it… trusted access?

22. Remote DesktopMechanisms

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

24. SSL VPNs Aren’t • VPNs • Appreciably simpler than other remote desktop alternatives • Any more secure than IPsec-based VPNs or HTTPS-protected access to published internal web sites Are • 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

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

26. Remote Desktop client

27. Remote desktop MMC

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

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

30. RDP packet creation Application data App App App App App App App MCSchannels wrapping/framing App stack IP TCP

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

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

33. Encryption options Configure with group policy or TS console

34. 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 fine-grained control • Probably not necessary

35. Some RDP configuration settings • End a disconnected session: 3 hours • Active session limit: 1 day • Idle session limit: 15 minutes TS Configuration | Connections |RDP-Tcp | Properties

36. TS over the web is cool Deployment • Rapidly deploy several applications to many users • Keep those applications up-to-date Bandwidth • Lowest bandwidth requirements • Ideal for dial-up scenarios Access • Works on many devices, even some non-Windows • Good for older hardware

37. Terminal Server over the web connect to web pagehttp://server/tsweb IIS withRDWC download ActiveX controlover HTTP (80/tcp)or HTTPS (443/tcp) webbrowser connect to TSover RDP (3389/tcp) TerminalServer

38. Full IP VPNs

39. Requirements for remote-access VPN

40. Important terms

41. Authentication

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

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

44. Stateful vs. stateless encryption

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

46. Your choice of protocols

47. L2TP+IPsec packet format App data IP np App data UDP L2TP PPP IP np App data IP IPsec UDP L2TP PPP IP np UDP L2TP PPP IP np App data IPsec App data

48. L2TP+IPsec client automaticallygenerates 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 Inbound Filter Source IP = Gateway IP Dest IP = My IP Address (Internet) Protocol = UDP Source port any, dest port 1701 IPSec IKE negotiation is for dest port = any, so that filter mirror for inbound port = any Allows gateway to float response port (per L2TP RFC 2661)

49. L2TP+IPsec connection is protected L2TP tunnel setup and management inside IPsec IPsec IKE negotiation, machine cert authN User authN RADIUS Establish IPsec SAs for L2TP port 1701/udp policy enforcement 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

50. Where do you put the RRAS server?