Domain and Server Isolation Using IPsec Jesper M

Domain and Server Isolation Using IPsec Jesper M. Johansson Senior Security Strategist Security Technology Unit jesperjo@microsoft. com http: //blogs. technet. com/jesper_johansson

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!

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

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

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!

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

Security Lessons From The Physical World Traffic lights control traffic flow Buffer overflows are unheard of Malicious hosts easily quarantined

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

Where does isolation fit? Part of a security defense-in-depth approach Logically sits between the network and the host layers Security defense-in-depth model Data Application Host Isolation Internal network Perimeter Physical security People, Policies, and Process

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. 1 X can do this! Well they’re wrong. Stay tuned!

Solution Benefits

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

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

Isolation scenarios Domain isolation 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 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

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

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

Implementation Planning

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

Foundational groups Non-IPsec groups Untrusted systems Default group Exemptions Trusted infrastructure Isolation Domain IPsec groups Isolation domain Default trusted group Boundary Higher risk trusted group Boundary Isolation Group Untrusted All systems Systems

Traffic mapping—foundational Plan allowed data communications between foundational groups ID From To Bidirectional IPsec Fallback Encrypt 1 ID Ex Yes No No No 2 ID BO Yes No No 3 ID UN No Yes No 4 BO EX Yes Yes No 5 BO UN No Yes No 6 UN BO No No 7 UN EX Yes No No No

Additional isolation groups Driven by business requirements Might not be necessary For example— No fallback allowed isolation group Blocks outbound communications to untrusted hosts Require encryption isolation group High security group All data communications must use encryption Isolation Domain Encryption Isolation Group No fallback Isolation Group Boundary Isolation Group Untrusted systems

Traffic mapping—additional ID From To Bidirectional IPsec Fallback Encrypt 8 EN EX Yes No No No 9 EN ID Yes No Yes 10 EN NF Yes No Yes 11 EN BO No Yes 12 NF ID Yes No No 13 NF EX Yes No No No 14 NF BO Yes No No

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

IPsec policy construction

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

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

Isolation Scenarios

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

Domain isolation Domain controller User: any type Client: Untrusted or non-IPsec capable Ping succeeds others fail Server: domain isolation IPsec policy Active (requires IPsec for all traffic except for ICMP)

Domain isolation Domain controller User: domain member Client: Windows XP SP 2 Trusted machine Ping succeeds, others succeed over IPsec Server: domain isolation IPsec policy Active (requires IPsec for all traffic except for ICMP)

Server isolation Domain controller User: domain member Client: Windows XP SP 2 “CLIENT 2” Trusted machine Ping succeeds others fail because IKE fails Authorization only for CLIENT 1 in group policy via “Access this computer from network” right Server: server isolation IPsec policy Active (requires IPsec for all traffic except for ICMP)

Server isolation Domain controller User: domain member Client: Windows XP SP 2 “CLIENT 1” Trusted machine Ping succeeds, other succeed over IPsec Authorization only for CLIENT 1 and this user in group policy via “Access this computer from network” right Server: server isolation IPsec policy Active (requires IPsec for all traffic except for ICMP)

The Brokenness of 802. 1 X

What is 802. 1 X? Port-based access control method defined by IEEE http: //standards. ieee. org/getieee 802/download/802. 1 X-2001. pdf EAP provides mutual authentication between devices ftp: //ftp. rfc-editor. org/in-notes/rfc 3748. txt Works over anything Wired Wireless

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

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

Why is it useless for wired? No GPOs—and we can’t retrofit Worse…a fundamental protocol design flaw 802. 1 X 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

The attack …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

Why does it work? 802. 1 X 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)

The attack ACK-SYN ACK-RST 1. 2. 3. 4 aa: bb: cc: dd: ee: ff ACK-SYN ACK-RST SYN 1. 2. 3. 4 aa: bb: cc: dd: ee: ff

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

The attack…improved ACK-SYN 1. 2. 3. 4 aa: bb: cc: dd: ee: ff ACK-SYN ACK SYN 1. 2. 3. 4 aa: bb: cc: dd: ee: ff

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

What’s Next?

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

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)

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

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

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: Server. Group. A, Server. Group. B Domain isolation: Boundary. Group Design IPsec policies Document filter actions and rules that will best meet your requirements

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

Customer deployments Remote access/VPN is very common IPsec server isolation is very popular Financial services (top 5 American banks, top 2 Canadian banks) Government (at all domestic and international levels) Education (multiple universities with >30, 000 students, inner-city public school systems) Health care, retail, manufacturing, high tech… Majority of AD deployments use IPsec for secure DC-to-DC communication Satisfies regulatory requirements for Sarbanes-Oxley, HIPAA, … Domain isolation attracting interest of large orgs Largest non-Microsoft deployment is >350, 000 nodes Used extensively within Microsoft

Customer case studies DC-to-DC replication Domain isolation of library Isolate branches from headquarters ? 350, 000 domainisolated nodes Protect source code

Microsoft IT Requirement 1: protect high-value intellectual property and meet compliance requirements Solution Source code repositories restricted by server isolation Authentication with certificates and machine groups in Active Directory Two levels of authorization—at the network and at the application Results Only Windows developers can see and connect to source code servers Meets Sarbanes Oxley Act requirements for protecting data of material impact to shareholders

Microsoft IT Requirement 2: protect managed hosts from worm attacks and unauthorized access Solution A “Secure. Net” that uses Active Directory and IPsec Requires Kerberos for authentication Requires certificates for home VPN users Results IPsec is fully deployed on Corpnet for over 12 months ~250, 000 domain-joined systems using IPsec worldwide Increase of domain-joined systems of 45% from start of implementation 75% of all network traffic globally is IPsec protected 293 helpdesk calls per month (compared to ~500 for Outlook)

Microsoft IT implementation Microsoft Corporate Network Secure. Net X X Clients, Servers, Home LANs, Trustworthy Labs (240, 000) ACL Controlled Internet Servers Business Partners Extranet (1, 800) U 1 B Boundary Machines (5, 000) U 2 U 3 Labs Pocket PC MAC 75, 000 XBox 2, 000 18, 000 D H C P D N S W I N S D C I A S Untrustworthy Infrastructure (500) Permitted Infrastructure External Exclusions DTaps (no connectivity to Corp. Net)

Preparing for Network Access Protection Deploy domain isolation to become familiar with IPsec concepts NAP will provide a richer enforcement mechanism, while adding to server and domain isolation Plan and model to add health authentication and other compliance enforcement mechanisms network access protection provides More guidance available during Longhorn beta

IPsec roadmap Server 2003, Windows XP “Longhorn” and beyond Isolation by domain or server • Authentication of machine, but no health check Extensible isolation • User and machine credentials • Health certificates Windows firewall integration • Authenticated bypass capability Overhead offload • 10/100 mb NIC—lower CPU Firewall integration • Windows filtering platform Improved administration • One-size-fits-all policy Extensible performance • Gig-E offload for lower CPU

Learn more Server and domain isolation using IPsec and Group Policy http: //go. microsoft. com/fwlink/? linkid=33947 Microsoft IT experiences with domain isolation http: //www. microsoft. com/technet/itsolutions/ msit/security/IPsecdomisolwp. mspx IPsec resources http: //www. microsoft. com/ipsec

For more information Jesper and Steve finally wrote a book! Order online: http: //www. protectyourwindowsnetwork com jesperjo@microsoft. com