MSG308 Secure Access to Exchange from the Internet

1. MSG308Secure Access to Exchangefrom the Internet Steve Riley Microsoft Corporation

2. FAQs • Exchange? • On the Internet?? • Are you out of your #!%@&$ mind???

3. It’s topical • Design alternatives • VPNs • OWA • RPC—native and over HTTP • Recommended design • To DMZ or not to DMZ…that is the question

4. This session… • Is about— • Securing Internet access to an Exchange installation • Isn’t about— • General Exchange security

5. VPNs

6. The usual choice • VPN clients in all versions of Windows • Yes, PPTP can be made secure • L2TP+IPsec is the future • Technology is well-understood • Needs an IT staff, though • More work than most small and medium organizations want to deal with

7. Technical problems • Won’t work in some public locations • VPN protocols blocked • IPSec vs. NAT • But see SEC406, 3:15 Thurs, Ballroom A 3-4! • Packet fragmentation • IKE • IPSec NAT-T

8. Technical problems • Default gateway modifications • All traffic goes to VPN tunnel • No access to local network • Split-tunneling often disallowed • This is a good thing! • VPNs are useful to connect remote clients to corporate networks • Less useful when connecting from corporate network to some ASP

9. Outlook Web Access

10. Universal availability • Browsers are everywhere • Familiar interface • OWA 2003 is almost just like Outlook

11. Security issues • HTTPS is the transport • Intrusion detection? • Conformance to email policy? • OWA 2000 has no session timeout • Fixed in OWA 2003 • Forms authentication—cookie for session

12. Typical design • Good • Separates protocol from message store • Network protection • Bad • Tunnel through outside firewall: no inspection • Many holes in inside firewall for authentication • Anonymous initial connections to OWA OWA ExBE AD

13. Improving OWA security • Security goals • Inspect SSL traffic • Maintain wire privacy • Enforce conformance to HTML/HTTP • Allow only known URL construction • Block URL-borne attacks • Optionally • Pre-authenticate incoming connections

14. Protect OWA with ISA Server • ISA Server becomes the “bastion host” • Web proxy terminates all connections • Decrypts HTTPS • Inspects content • Inspects URL (with URLScan) • Re-encrypts for delivery to OWA <a href… http://... x36dj23s 2oipn49v ISA Server OWA Exchange AD

15. 404 Protect OWA with ISA Server • Easy authentication to Active Directory • Pre-authenticate communications • ISA Server queries user for credentials • Verifies against AD • Embeds in HTTP headers to OWA • Avoids second prompt! • Requires FP1 ISA Server OWA Exchange AD

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

17. Exchange RPCon the Internet

18. RPC on the Internet?

19. Business case • Many users require full Outlook • Third-party plugins • Mailbox synchronization • Client-side rules • Complete address book • VPNs are too costly if this is the only requirement

20. Design choices • Run it naked • Assign the RPC ports • Use RPC over HTTP • Publish with ISA Server

21. 4402/tcp 135/tcp RPC connection setup Portmapper responds with the port and closes the connection Client accesses application over learned port Client asks, “What port is associated with my UUID?” Client connects to portmapper on server (port 135/tcp) Client knows UUID of service it wants {12341234-1111…} 4402/tcp RPC client (Outlook) RPC server (Exchange) Server matches UUID to the current port… RPC services grab random high ports when they start, server maintains table

22. Design choices • Run it naked • Assign the RPC ports • Use RPC over HTTP • Publish with ISA Server

23. RPC naked on the net • Good • Easy to build! • Bad • Easy to compromise! • Firewall must permit all traffic on all high ports • Firewall can’t tell what’s Exchange and what isn’t • No protection against RPCDump, for instance Exchange

24. Potential RPC attacks • Reconnaissance • NETSTAT • RPCDump • DoS against portmapper • Privilege escalation or other specific service attacks

25. Design choices • Run it naked • Assign the RPC ports • Use RPC over HTTP • Publish with ISA Server

26. Registry keys • Need to set fixed port numbers for • Information Service • Directory Service • System Attendant • See KB 148732 • Best to use ports just above 5000

27. Fixed RPC ports • Good • Still easy to build • Limited open ports on firewall • 135/tcp + 3 high ports • Bad • Still easy to compromise • Doesn’t stop any of the previous attacks • Firewall still can’t tell what’s Exchange and what isn’t • Scaleable? Exchange

28. Design choices • Run it naked • Assign the RPC ports • Use RPC over HTTP • Publish with ISA Server

29. New in Exchange 2003 • Result of high customer demand • Useful • All firewalls allow 80/tcp and 443/tcp • Enables access from any location • No special firewall setup required

30. But is it secure? • Look back at the last slide… • Not necessarily positive attributes • Simply running RPC over HTTP doesn’t solve all the problems • No protocol awareness in firewall • No pre-authenticated connections • No inspection if HTTPS • Is secure from RPC-borne attacks • Until attack tools have HTTP wrappers…

31. What’s the big deal? • Knowing a port number or a UUID doesn’t mean you know the intent • What do the following tell you: • 80/tcp • 49494/tcp • {23947829-3857-2983-9838293069843927} • They are application identifiers • That’s all! well-known port for HTTP random (fixed?) port for Exchange well-known UUID for Exchange

32. So what’s it good for? • RPC over HTTP is no more, and no less, secure than fixed-port RPC • So use it: • If your business case requires it • You are comfortable with the risk • It’s another option for customers who are satisfied with its operation

33. Design choices • Run it naked • Assign the RPC ports • Use RPC over HTTP • Publish with ISA Server

34. ISA Server • More than just a proxy • True application-aware content-filtering firewall • Exchange RPC • SMTP • H.323 • FTP • DNS • POP3/IMAP4

35. Exchange RPC filter • Intimately aware of— • How Exchange RPC connections establish • What the proper protocol format is • Allows only Exchange RPC UUIDs • Enforces client authentication • Can optionally enforce encryption • Requires Feature Pack 1 • Supports new mail notification

36. Published RPC interfaces {99E64010-B032-11D0-97A4-00C04FD6551D}: "Store admin (1)" {89742ACE-A9ED-11CF-9C0C-08002BE7AE86}: "Store admin (2)" {A4F1DB00-CA47-1067-B31E-00DD010662DA}: "Store admin (3)" {A4F1DB00-CA47-1067-B31F-00DD010662DA}: "Store EMSMDB" {9E8EE830-4459-11CE-979B-00AA005FFEBE}: "MTA" {1A190310-BB9C-11CD-90F8-00AA00466520}: "Database" {F5CC5A18-4264-101A-8C59-08002B2F8426}: "Directory NSP" {F5CC5A7C-4264-101A-8C59-08002B2F8426}: "Directory XDS" {F5CC59B4-4264-101A-8C59-08002B2F8426}: "Directory DRS" {38A94E72-A9BC-11D2-8FAF-00C04fA378FF}: "MTA 'QAdmin'" {0E4A0156-DD5D-11D2-8C2F-00C04FB6BCDE}: "Information Store (1)" {1453C42C-0FA6-11D2-A910-00C04F990F3B}: "Information Store (2)" {10F24E8E-0FA6-11D2-A910-00C04F990F3B}: "Information Store (3)" {1544F5E0-613C-11D1-93DF-00C04FD7BD09}: "Directory RFR" {F930C514-1215-11D3-99A5-00A0C9B61B04}: "System Attendant Cluster" {83D72BF0-0D89-11CE-B13F-00AA003BAC6C}: "System Attendant Private" {469D6EC0-0D87-11CE-B13F-00AA003BAC6C}: "System Attendant Public Interface"

37. Filter operation • Client connects to filter’s “portmapper” • Runs as part of filter • Responds only to requests for Exchange RPC • ISA Server returns filter’s Exchange RPC port numbers • Client makes new connection ISA Server Exchange AD

38. Filter operation • ISA Server connects to Exchange’s portmapper • Exchange returns port numbers • ISA Server makes new connection ISA Server Exchange AD

39. Filter operation • Client logs on to Exchange • Exchange proxies logon to Active Directory • Need “No RFR Service” key to make this happen: KB 302914 • Filter watches for approval • Filter checks whether encryption is on, if required • Client mailbox opens ISA Server Exchange AD

40. Protects from RPC attacks Yes! • Reconnaissance? • NETSTAT shows only 135/tcp • RPCDump simply fails • DoS against portmapper? • Known attacks fail • Successful attack leaves Exchange protected • Service attacks? • No reconnaissance info available • ISA Server-to-Exchange connections fail unless prior client-to-ISA Server connection is correctly formatted Yes! Yes!

41. Results • Known good connection • Known good encryption (optional) • Known good user • Dare I say it… trusted access? 

42. Recommended design

43. Recall the typical design ExFE SMTP ExBE AD

44. ExFE SMTP ISA Server ExBE AD New requirements, new designs • Move critical servers inside for better protection • Add ISA Server to your existing DMZ • Increase security by publishing: • Exchange RPC • OWA over HTTPS • SMTP (content filter)

45. Next Steps • Consider your risk— • What do you have? • What are you comfortable with? • Consider the way attacks are evolving • Ports mean nothing • Attacks look like legitimate traffic • Evaluate and deploy ISA Server for all current and future Exchange installations

46. Community Resources • Community Resources http://www.microsoft.com/communities/default.mspx • Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ • Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx • User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

47. Suggested Reading And Resources The tools you need to put technology to work! TITLE Available Microsoft® Exchange Server 2003 Administrator's Companion: 0-7356-1979-4 9/24/03 Active Directory® for Microsoft® Windows® Server 2003 Technical Reference: 0-7356-1577-2 Today • Microsoft Press books are 20% off at the TechEd Bookstore • Also buy any TWO Microsoft Press booksand get a FREE T-Shirt

48. evaluations

49. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.