Server and Domain Isolation Using IPsec

1. SEC302 Server andDomain IsolationUsing IPsec Steve Riley Enterprise Security Architect Security Business and Technology Unit steve.riley@microsoft.com http://blogs.technet.com/steriley

2. Evolving network security • The vision • Endpoints protect themselves from other systems • Connections allowed only after authentication • All communications are authenticated and authorized • Host health is checked • The value proposition • Increased security for windows and corporate network overall • Increase IT efficiency and ROI on active directory management You can do much of this today!

3. 1 2 Without isolation Access granted or denied based on ACL Share access is checked 4 User is authenticated and authorized User attempts to access a file share Check network access permissions 3 User authentication occurs Local policy

4. Life without isolation • User authentication and authorization are the focus for most IT professionals • Server and domain isolation will change this!

5. The problems • All hosts on the network might not be trusted equally by all systems connected • Difficult to control who or what physically connects to the network • Unmanaged hosts present infection threat • Need to provide connectivity to outsiders but limit access • a.k.a. partners…vendors…customers… • Theft and abuse of trusted user credentials often not recognized—until it’s too late!

6. The problems • Large “internal” networks might have independent paths to the Internet • Difficult to monitor and control “the edge” anymore • External threats present somewhere on the internal network • Network attack surface is all TCP/IP ports, traffic • Packet filtering (network firewall) helps, but not when clients communicate inside it • Need defense-in-depth to include application layer network security

7. The solution • Isolate computers with IPsec • Protects all unicast traffic between trusted computers • Provides end to end security • Authenticates every packet (by default) • Can encrypt every packet (optional) • Customizable policy deployed in domain, no application changes necessary

8. Where does isolation fit? Security defense-in-depth model • Part of a security defense-in-depth approach • Logically sits between the network and the host layers Polices, procedures, and awareness Physical security Data Application Host Isolation Internal network Perimeter

9. What are the main benefits? • Reduces network attacks on isolated computers • Helps protect against internal attacks • Provides scalable authentication and encryption for all traffic • Even “unsecurable” stuff like SMB  Why IPsec? My network vendor says 802.1X can do this! Well they’re wrong. Stay tuned!

10. Solution Benefits

11. IPsec: the foundation • Create Active Directory–based IPsec policies with MMC • Use one of three authentication methods • Kerberos • Computer certificates • Preshared keys • IPsec policies delivered to clients with AD Group Policy • Available in Windows 2000, XP, 2003

12. Solution terminology • Hosts • Untrusted • Trustworthy • Trusted • Isolation groups • Foundational groups • Additional groups • Network access groups

13. Protect hosts from unmanaged machines Enforces domain membership (yay!) by requiring machine authentication All trusted machines can exchange traffic Encryption optional Can include stronger server isolation Protect high-value servers Restrict connectivity to a defined subset of certain people and hosts Still must be domain computers Encryption optional but common Isolation scenarios Domain isolation Server isolation

14. Access granted or denied based on ACL Share access is checked 6 1 Check network Access permissions (Computer acct) Check network access permissions (user) 2 5 3 4 Local policy Local policy With isolation Computer and user are authenticated and authorized User attempts to access a file share IKE negotiation begins IKE succeeds, user authN occurs

15. How does isolation work? • Uses IPsec to— • Handle the computer account authentication • Ensure data integrity • Provide encryption (if required) • Use group policy to— • Distribute the IPsec policies • Authorize the computer and user access

16. Implementation Planning

17. How do I implement isolation? • Organize computers into isolation groups, based on— • Security requirements • Data classification • Identify communication paths • Define what’s allowed, block everything else • Create policies to enforce business requirements • Identify and test a deployment strategy

18. Foundational groups • Non-IPsec groups • Untrusted systems • Default group • Exemptions • Trusted infrastructure • IPsec groups • Isolation domain • Default trusted group • Boundary • Higher risk trusted group

19. Traffic mapping—foundational • Plan all allowed data communications between foundational groups

20. Additional isolation groups • Driven by business requirements • Might not be necessary • For example— • No fallback allowedisolation group • Blocks outboundcommunications tountrusted hosts • Require encryptionisolation group • High security group • All data communicationsmust use encryption

21. Traffic mapping—additional

22. Network access groups • NAGs are used to explicitly allow or deny access to a system through the network • Names reflect function— • ANAG: allow network access group • DNAG: deny network access group • Can contain users, computers or groups • Defined in domain local groups

23. IPsec policy construction

24. Defined filter actions • Request mode • Accept inbound in the clear • Allow outbound in the clear • Secure request mode • Allow outbound in the clear • Full require mode • All unicast communications require IPsec • Require encryption mode • Only negotiates encryption

25. Selecting a deployment strategy • Build up • Policy has exemptions, but no requirements for IPsec on secure subnets • Request mode filter action is used with secure subnet filter lists • Subnets are slowly added to secure subnet filter list and tested • Deploy by group • IPsec policy defined and linked • Use groups to control application of the policy

26. IPsec policies for MSS solution

27. Isolation Scenarios

28. Isolation in action Active Directory Domain Controller (exempted) Domain Isolation Optional outbound authentication Server Isolation Un-trusted Required authentication X X Authenticating Host Firewalls Unmanaged Devices

29. Domain isolation Domaincontroller User:any type Ping succeeds others fail Client:Windows XP SP2 Untrusted ornon-IPsec capable Server: domain isolationIPsec policy Active (requires IPsec for all traffic except for ICMP)

30. Domain isolation Domaincontroller User:domain member Ping succeeds, others succeed over IPsec Client:Windows XP SP2 Trusted machine Server: domain isolationIPsec policy Active (requires IPsec for all traffic except for ICMP)

31. Server isolation Domaincontroller Authorization only forCLIENT1 in group policy via “Access this computerfrom network” right User:domain member Ping succeeds others fail because IKE fails Client:Windows XP SP2“CLIENT2” Trusted machine Server: server isolationIPsec policy Active (requires IPsec for all traffic except for ICMP)

32. Server isolation Domaincontroller Authorization only forCLIENT1andthis userin group policy via “Access this computerfrom network” right User:domain member Ping succeeds, other succeed over IPsec Client:Windows XP SP2“CLIENT1” Trusted machine Server: server isolationIPsec policy Active (requires IPsec for all traffic except for ICMP)

33. The Brokenness of 802.1X

34. What is 802.1X? • Port-based access control method defined by IEEE http://standards.ieee.org/getieee802/download/802.1X-2001.pdf • EAP provides mutual authentication between devices ftp://ftp.rfc-editor.org/in-notes/rfc3748.txt • Works over anything • Wired • Wireless ftp://ftp.rfc-editor.org/in-notes/rfc2549.txt http://eagle.auc.ca/~dreid

35. What do you need for 802.1X? • Network infrastructure that supports it • Switches, mostly • Clients and servers that support it • Supplicants included in Windows XP, 2003 • Download for Windows 2000

36. Why is it perfect for wireless? • The supplicant (client) and authentication server (RADIUS) generate session keys • Keys are never sent over the air • Nothing for an attacker to use to conduct impersonation or man-in-the-middle attacks • Can manage centrally with GPOs

37. Why is it useless for wired? • No GPOs—and we can’t retrofit • Worse…a fundamental protocol design flaw • 802.1X authenticates only at the start of traffic between client and switch • After the switch port opens, everything after that is assumed to be valid • These kinds of assumptions allow MITM attacks! • Does require physical access to the network

38. The attack …authenticate… …authenticate… 1.2.3.4 aa:bb:cc:dd:ee:ff drop all inbound not for me 1.2.3.4 aa:bb:cc:dd:ee:ff

39. Why does it work? • 802.1X lacks per-packet authentication • It assumes that the post-authentication traffic is valid—based on MAC and IP only • Switch has no idea what’s happened! • Attacker can communicate only over UDP • Victim would reset any TCP reply it received but didn’t send (victim sees reply to shadow)

40. The attack ACK-SYN ACK-RST RST 1.2.3.4 aa:bb:cc:dd:ee:ff ACK-SYN ACK-SYN ACK-RST ACK-RST SYN 1.2.3.4 aa:bb:cc:dd:ee:ff

41. But wait! • If the victim computer happens to run a personal firewall… …which drops unsolicited ACK-SYNs… It gets better!

42. The attack…improved ACK-SYN 1.2.3.4 aa:bb:cc:dd:ee:ff ACK-SYN ACK-SYN SYN ACK 1.2.3.4 aa:bb:cc:dd:ee:ff

43. So then • Despite what the networking vendors claim, 802.1X is inappropriate for preventing rogue access to the network • Good security mechanisms never assume that computers are playing nicely • 802.1X makes this incorrect assumption • IPsec does not • If you’re worried about bad guys flooding your network… • Then 802.1X + IPsec is the way to go • Or just disable their switch port • You are able to monitor for this, right?

44. What’s Next?

45. The main challenges • Learning curve for IPsec; fundamentally changes TCP/IP communication • May lose ability to inspect network traffic when IPsec-protected • ESP null is clear-text, but need parsers • ESP with encryption—you can’t see it! • Detailed planning and coordination required for domain isolation

46. The main challenges • Local administrator can disable IPsec or change the local dynamic policy • But…such a computer can’t connect to other trusted computers anymore • Not all domain members may be able to be protected (DC, DNS, DHCP)

47. Risks that aren’t mitigated • Trusted users disclosing high value data • Compromise of trusted credentials • Untrusted computers compromising other untrusted computers • Loss of physical security of trusted computers • Lack of compliance mechanisms for trusted computers

48. How to get started? • Download the MSS guide—read and train • Set requirements • To include isolation needs • Classify your data • Determine current state • Active Directory structure • Network topology and design • Plan initial design • Build a test environment • Test all changes before production deployment

49. How do I deploy? • Create goals for deployment • Which assets you want to protect? • Do you want to ensure more machines are managed? • What regulatory requirements do you need to comply? • Is it important to limit spread of worms/virus? • Create machine groups • Server isolation: ServerGroupA, ServerGroupB • Domain isolation: BoundaryGroup • Design IPsec policies • Document filter actions and rules that will best meet your requirements

50. How do I deploy? • Deploy in “request mode” • Use to validate policy and refine as necessary • Verify architecture can support IPsec • Use ESP-null except where privacy is required • When encrypting, reduce CPU load with hardware • Start small, protect a number of servers and gradually increase your managed domain • Don’t forget a roll-back plan! • Establish interoperability plan • Many operating systems capable of IPsec • Policy and credential distribution requires planning • Devices and machines that cannot use IPsec can be “exempted” in policy