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
User is authenticated
and authorized
Dept Group
1
Check network
access permissions
3
Local
policy
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?
Security defense-in-depth model
Part of a security
defense-in-depth
approach
Logically sits
between the
network and the
host layers
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.1X 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
Share access is
checked
Computer and user
are authenticated
and authorized
Dept Group
Check network
Check network
access permissions
Access permissions
(user)
(Computer acct)
5
3
Local
Local
policy
policy
1
IKE negotiation
begins
2
4
IKE succeeds,
user authN occurs
IKE
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 all allowed data communications between
foundational groups
ID
From
To
Bidirectional
IPsec
Fallback
Encrypt
1
ID
Ex
Yes
No
No
No
2
ID
BO
Yes
Yes
No
No
3
ID
UN
No
Yes
Yes
No
4
BO
EX
Yes
Yes
Yes
No
5
BO
UN
No
Yes
Yes
No
6
UN
BO
No
No
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
Yes
No
Yes
10
EN
NF
Yes
Yes
No
Yes
11
EN
BO
No
Yes
No
Yes
12
NF
ID
Yes
Yes
No
No
13
NF
EX
Yes
No
No
No
14
NF
BO
Yes
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
IPsec
Policy
Key Exchange
Methods (IKE)
Rules
Authentication
Methods
Kerberos
Filter
List
Action
Certificates
Security Methods
Encryption
Filters
Pre-Shared
Keys
Key
Lifetimes
Hashing
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
Domain
Isolation
Un-trusted
X
Optional
outbound
authentication
X
Unmanaged
Devices
(exempted)
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 SP2
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 SP2
“CLIENT2”
Trusted machine
Ping succeeds
others fail
because IKE fails
Authorization only for
CLIENT1 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 SP2
“CLIENT1”
Trusted machine
Ping succeeds,
other succeed
over IPsec
Authorization only for
CLIENT1 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.1X
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
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
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.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
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.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)
The attack
ACK-SYN
ACK-RST
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.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?
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: ServerGroupA, ServerGroupB
Domain isolation: BoundaryGroup
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 “SecureNet” 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
SecureNet
X
X
Clients, Servers,
Home LANs,
Trustworthy Labs
(240,000)
ACL Controlled
Internet Servers
Business Partners
Extranet
(1,800)
U1
B
Boundary
Machines
(5,000)
U2
U3
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
CorpNet)
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/100mb 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