SANS Security 505.4 Windows Firewalls, IPSec, Wireless & VPN's

Copyright 02010, The SANS Institute. All rights reserved.
The entire contents of this i

publication are the property of the SANS Institute.
IMPORTANT-READ CAREFULLY:
This Courseware License Agreement ("CLA") is a legal agreement between you (either
an individual or a single entity; henceforth User) and the SANS Institute for the personal,
non-transferable use of this courseware. User agrees that the CLA is the complete and
exclusive statement of agreement between The SANS Institute and you and that this CLA
supersedes any oral or written proposal, agreement or other communication relating to
the subject matter of this CLA. If any provision of this CLA is declared unenforceable in
any jurisdiction, then such provision shall be deemed to be severable from this CLA and /-
.
shall not affect the remainder thereof. An amendment or addendum to this CLA may
accompany this courseware. BY ACCEPTING THIS COURSEWARE YOU AGREE TO
BE BOUND BY THE TERMS OF THIS CLA. IF YOU DO NOT AGREE YOU MAY
RETURN IT TO THE SANS INSTITUTE FOR A FULL REFUND, IF APPLICABLE.
The SANS Institute hereby grants User a non-exclusive license to use the material
contained in this courseware subject to the terms of this agreement. User may not copy,
reproduce, re-publish, distribute, display, modify or create derivative works based upon
all or any portion of this publication in any medium whether printed, electronic or I
otherwise, for any purpose without the express written consent of the SANS Institute. 1
Additionally, user may not sell, rent, lease, trade, or otherwise transfer the courseware in
any way, shape, or form without the express written consent of the SANS Institute.
The SANS Institute reserves the right to terminate the above lease at any time. Upon
termination of the lease, user is obligated to return all materials covered by the lease
within a reasonable amount of time.
V2010__0125
i
i
I-
i
i-
Windows Firewall, IPSec, Wireless and VPNs
www.sans.org 02010
2 IPSec. RADIUS. Wireless. and VPNs
SANS Institute
IPSec, RADIUS, Wireless, and VPNs 3
06
All reasonable and good faith efforts have been exerted to verify that the information in this
document is accurate and up-to-date. However, new software releases, new developments, new
discoveries of security holes, new publications hom Microsoft or others, etc. can obviate at any
time the accuracy of the information presented herein.
Neither the SANS Institute nor GIAC provide any warranty or guarantee of the accuracy or
usefulness for any purpose of the information in this document. Neither the SANS Institute,
GIAC nor the author(s) of this document can be held liable for any damages, direct or indirect,
financial or otherwise, under any theory of liability, resulting from the use of or reliance upon the
information presented in this document at any time.
This document is copyrighted (2010) and is the exclusive property of the SANS Institute
(www.sans.org). Reproductions of this document in any number, in any form, in whole or in part,
is expressly forbidden without prior written authorization.
Microsoft, MS-DOS, MS, Windows, Windows NT, Windows 2000, Windows XP, Windows
Server 2003, Windows Server 2008, Windows 7, SSTP, NPS, NAP, Active Directory, Internet
Information Server, IIS, VBScript, IAS, and RRAS are either registered trademarks or trademarks
of Microsoft Corporation in the United States and/or other countries. Fortezza is a registered
trademark of the National Security Agency. Netscape Navigator is a product and trademark of
Netscape Corporation. The Intel@PRO/lOO S Network Adapter is a product and trademark of the
Intel Corporation. Pluto's moon, Charon, was named after the wife of the astronomer who
discovered it. Charon orbits Pluto every 6.4 days, always showing the same face to Pluto, just as
our own moon always shows the same face to us despite its orbit. What are the odds of two
moons doing this in one solar system? The odds must be astronomical. Apache is a product and
trademark of the Apache Software Foundation.
Other product and company names mentioned herein may be the trademarks of their respective
owners.
The legal consequences of any actions discussed in this document are unknown. No lawyers or
legal experts participated in the writing of any part of this document. Readers are advised to
consult with their attorney before implementing any of the suggestions in this document.
SANS Institute
4 IPSec, RADIUS, Wireless. and VPNs
co
Network security is something produced by a community. Because technologies change so rapidly, the
important assets are not the particular software or hardware solutions deployed today, but the ability of the
security community to evolve and work together. It is part of the mission of the SANS Institute to facilitate
this. This manual is a community document in that it was written with reliance upon the prior work of
others and is updated regularly with the input of the security community members who use it. That means
you.
If you find a significant error of fact or an important omission which would clearly add value to the
document, please e-mail the contact listed below. If your suggestion is incorporated, we would be pleased
to list your name as a contributor.
Document Contact: Jason Fossen (Jason@EnclaveConsulting.com)

Document Version: 18.0
Last Modified: 6-Oct-2009
Contributors:
Jason Fossen (www.EnclaveConsu1ting.com): author.
William Dixon (www.microsoft.com):generous sharing of IPSec irnplementdtion deldils.
Anonymous (www.rsasecurity.corn): whoever wrote RSA's Cryptography FAQ -- thank you!
P. Reuter (CSC): IPSec interoperability information.
Jeff Nieusma (Storageway): IPSec and NAT clarifications.
Tina Bird (www.counterpane.com): technical review and NAT clarifications for IKE's UDP port.
Carla Wendt (www.sans.org): RFC number correction and other factoidal doo-dads.
Jeffrey Basista (SEI): ESP transport mode vs. NAT, and Windows 2003 IPSec issues.
Bryce Alexander (Vanguard): 802.1X authentication of wireless devices with IAS.
Chris Weber (Foundstone): interesting factoids and good surfing tips.
Dustin Decker (Dude): corrections to document references.
Sean McDermott (Talbots): correct location of ipseccmd.exe for X P .
David Perez (Human): lots-0-updates!
Bryan Simon (Human): MD5 command line options and other updates.
Tim Legge (Human): correction to IKE statement.
SANS Institute
IPSec. RADIUS. Wireless. and VPNs 5
Table of Contents ................................................................................................................ 5

Websites. Utilities. Articles and Advisories Mentioned in The Course ............................. 7
Recommended Reading ...................................................................................................... 8
What To Expect ................................................................................................................ 10
Firewall And IPSec Tools ................................................................................................. 13
Windows Firewall with Advanced Security ..................................................................... 19
Windows Firewall: Network Profiles ............................................................................... 21
Network Profile: Firewall Default Settings ...................................................................... 23
Managing Firewall Rules .................................................................................................. 26
Today's Agenda ................................................................................................................. 30
Overview of IPSec ............................................................................................................ 31
IPSec Scenarios and Uses ................................................................................................. 37
IPSec Protocols ................................................................................................................. 41
Internet Key Exchange (IKE) ........................................................................................... 43
Authentication Header (AH) ............................................................................................. 50
Encapsulating Security Payload (ESP) ............................................................................. 52
Default IPSec Settings ...................................................................................................... 54
Phase I: Main Mode Advanced Options ........................................................................... 56
Phase 11: Quick Mode Advanced Options ........................................................................ 59
Authentication Options ..................................................................................................... 61
Connection Security Rules ................................................................................................ 68
Windows Firewall (Windows XP/2003) ........................................................................... 77
IPSec Policies On Windows 2000/XP/2003 ..................................................................... 80
Phase I Settings ................................................................................................................. 85
Phase I1 Settings................................................................................................................ 88
IP Filter Lists ..................................................................................................................... 89
Filter Actions .................................................................................................................... 93
Authentication Methods .................................................................................................... 98
Tunnel Settings and Connection Type ............................................................................ 102
Today's Agenda ............................................................................................................... 104
GPO Assignment of IPSec and Firewall Policies ........................................................... 105
Scripting IPSec And Firewall Policies ............................................................................ 108
Today's Agenda ............................................................................................................... 120
Routing and Remote Access Service (RRAS) ................................................................ 121
RRAS Installation and Tools .......................................................................................... 126
Remote Access Policies = RADIUS Policies ................................................................. 130
Constraints Tab: Authentication Methods ..................................................................... 138
EAP-TLS and Smart Card Support................................................................................. 141
Constraints Tab: Tiineouts and Port Types .................................................................... 144
Settings Tab: Encryption................................................................................................ 146
Settings Tab: IP Filters and IP Settings .......................................................................... 148
RRAS Packet Filtering and NAT .................................................................................... 150
RRAS/RADIUS Account Lockout ................................................................................. 159
SANS Institute
Secure Socket Tunneling Protocol (SSTP) ..................................................................... 161

How To Set Up A Host-to-Router VPN ......................................................................... 165
How To Set Up A Router-to-Router VPN ...................................................................... 170
Creating Pre-Configured VPN Connectoids ................................................................... 176
Today's Agenda ............................................................................................................... 183
RADIUS Integration ....................................................................................................... 184
Network Policy Server (NPS) = Microsoft RADIUS ..................................................... 186
Logging Remote Access (RRAS and NPS) .................................................................... 189
802.1 1 Wireless Concepts Refresher .............................................................................. 195
Wireless AP Configuration For EAP .............................................................................. 201
RADIUS Server Configuration For EAP ........................................................................ 203
Wireless Client Configuration Through GPOs ............................................................... 208
Wireless Security Best Practices ..................................................................................... 211
Congratulations! .............................................................................................................. 216
Appendix A: L2TP Dynamic IPSec Policies .................................................................. 217
Appendix B: PPTPv2 ..That Other VPN Protocol ....................................................... 220
Appendix C: Checklists ................................................................................................. 224
SANS Institute
RFC Searchable Library http://www .rfc-editor.org

IPSec IETF Charter h t t p : / / w w w . i e t f . o r g / h t m l . c h a m
PPP IETF Charter html
http://www.ietf.org/html.charters/pppext-charter.
L2TP IETF Charter ht~://www.ietf.or~/html.charters/l2t~ext-charter.html
1 Cain & Abel 1 http://www.oxid.it
iC Ce S
When a KB-number is referenced in the course, e.g., KB188806, this refers to a
Microsoft KnowledgeBase or TechNet article. These articles can be found either in one's
TechNet subscription CD-ROMs or at http://search.microsoft.com.
When a MS-number is referenced in the course, e.g., MS98-003, this refers to a

Microsoft Security Advisory Bulletin. These bulletins can be found at
http://www.microsoft.com/security/.
s S
AD = Active Directory (ntds.dit)
AH = Authentication Header (IPSec authentication)
DC = Domain Controller (dcpromo.exe)
ESP = Encapsulating Security Payload (1PSec encryption)
Filter = An IPSec selector which triggers IPSec driver actions.
Filter Action = An IPSec Policy component which defines AH and ESP settings.
GPO = Group Policy Object
IPSec = Internet Protocol Security (RFC 2401)
IPSec Policy = A complex object composed of Rules, Filters and Filter Actions.
MMC = Microsoft Management Console (mrnc.exe)
OU = Organizational Unit (subdivision of a domain)
RRAS/Connection Policy = Policy which controls remote access.
Rule = An IPSec Policy component which governs IPSec usage.
SA = Security Association (collection of IPSec session parameters)
SADB = Security Association Database (database of SAs on a host)
Selector = An IPSec filter which triggers IPSec driver actions.
Snap-In = MMC snap-in tool (e.g., AD Users and Computers)
SPD = Security Policy Database (database of IPSec policies)
SPI = Security Parameter Index (index of IPSec SAs)
Transport Mode = An IPSec mode which secures a packet's payload.
Tunnel Mode = An IPSec mode which encapsulates and protects entire packets.
WFAS = Windows Firewall with Advanced Security
-
SANS Institute
8 IPSec, RADIUS, Wireless, and VPNs
IPSec: The New Security Standard for the Internet, Intranets, and Virtual Private
Networks, N. Doraswamy and D. Harkins (Prentice Hall: 2003).
IPSec RFCs, read in this order: RFCs 2401,2402,2406 and 2409.
elevant Requests for Comments (

RFC 1661: The Point-to-Point Protocol (PPP)
RFC 1828: IP Authentication using Keyed MD5
RFC 1829: The ESP DES-CBC Transform
RFC 2085: HMAC-MD5 IP Authentication with Replay Prevention
RFC 2104: HMAC: Keyed-Hashing for Message Authentication
RFC 2284: PPP Extensible Authentication Protocol (EAP)
RFC 2401: Security Architecture for the Internet Protocol
RFC 2402: IP Authentication Header (AH)
RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2406: IP Encapsulating Security Payload (ESP)
RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408: Internet Security Association & Key Management Protocol(1SAKMP)
RFC 2409: The Internet Key Exchange (IKE)
RFC 241 1: IP Security Document Roadmap
RFC 2412: The OAKLEY Key Determination Protocol
RFC 245 1: The ESP CBC-Mode Cipher Algorithm
RFC 2637: The Point-to-Point Tunneling Protocol (PPTP)
RFC 2661: Layer Two Tunneling Protocol (L2TP)
RFC 2716: EAP-TLS
RFC 2759: MS-CHAPV~
The SKEME public key authentication protocol is described in "SKEME: A Versatile

Secure Key Exchange Mechanism for the Internet", by Hugo Krawczyk, IEEE
Proceedings of the 1996 Symposium on Network and Distributed Systems Security,
1996.
ubleshooting in Windows 2000

KB259335: Basic L2TP/IPSec Troubleshooting in Windows 2000
KB253489: How to Install a Certificate for Use with IPSec
KB23 1881: How to Install a Public Key Certification Authority
KB249125: Using Certificates for Windows 2000 and Cisco 1 0 s
KB248750: Description of IPSec Policy Created for L2TPAPSec
KB258261: Disabling IPSec Policy Used with L2TP
Kl3254728: IPSec Does Not Secure Kerberos Traffic Between DCs
SANS Institute
KB233256: How to Enable IPSec Traffic Through a Firewall

KB252735: How to Configure IPSec Tunneling in Windows 2000
KB254949: Client-to-DC and DC-to-DC IPSec Support
KB248694: Configuring IPSec to Handle (Un)Trusted Domain Authentication
KB240262: Configure a L2TP/IPSec Connection Using a Pre-Shared Key
KB247231: Event ID 201 11, Error 792 or Error 781
KB254257: IPSec Off-Load for Intel PROA00 S Adapters
KB227523: IPSec and IP-to-IP Tunnels Do Not Work with RIP and OSPF
KB276360: Excess Padding May Cause IPSec Packet Loss with Third-party
SANS Institute
This seminar will explain how to use the Windows Firewall, IPSec and RADIUS for
secure communications, including for VPNs and wireless.
The Windows Firewall with Advanced Security (WFAS) found in Windows Vista/2008/7
and later is fully stateful, application-aware, provides both egress and ingress filtering,
and is manageable from both the command-line (NETSH.EXE) and via Group Policy.
IPSec is the industry standard for securing network communications. It provides

transparent authentication and encryption of packets without modification of applications
or services, and requires no end-user training! IPSec can also be used for VPNs, but that
is certainly not its sole purpose.
The VPN router on Windows Server is the Routing and Remote Access Service (RRAS).
RRAS is what authenticates users, enforces remote access policies, logs connection data,
and routes or bridges client packets onto the LAN. 802.11 wireless access points also
provide encrypted network access. The RADIUS service is the Network Policy Server
(NPS) role. NPS can be use for RRAS VPNs, wireless, and many other networking
technologies. NPS is what regulates user access through the VPN and wireless networks.
his course yo
Understand and configure the Windows Firewall.
Encrypt and authenticate all packets transmitted among your critical servers and
workstations with IPSec.
SANS Institute
i
Automatically deploy IPSec policies and firewall filters throughout your
enterprise with Group Policy and Active Directory.
Install RRAS as a VPN router.
Use Microsoft's RADIUS server, Network Policy Server (NPS), to authenticate
and log remote access connections to RRAS.
Configure RRAS connection policies to control authentication methods,
encryption strengths, time/day restrictions, and even per-user packet filtering.
Deploy a client-to-router VPN for remote user access over the Internet.
Deploy a router-to-router VPN for transparent connectivity between networks
over the Internet with a secure channel.
Use NPS for enforcing secure wireless policies.
is av le?
No. Microsoft's firewall and proxy server for Windows Server, Threat Management
Gateway (TMG), uses RRAS for its routing and VPN support. TMG implements its own
packet filtering and NAT, but in many respects it still sits on top of RRAS, not replaces
RRAS. TMG was previously known as Internet Security and Acceleration Server (ISA
Server).
re so s
A pure hardware solution will provide the best performance, but there are other factors to
consider:
There are inexpensive IPSec-offload network adapter cards for Windows that will
make the box a hybrid hardware/software solution for IPSec and VPNs. These
cards offload the CPU-intensive work of encryption and hashing from the
operating system and mainboard CPU, and multiple cards can be installed in dual-
or quad-processor VPN gateways for maximum throughput.
True end-to-end security requires IPSec/VPN support on user's desktops, on the

file servers, database servers, e-mail servers, etc. It's not good enough to support
IPSec on just the routedgateways if you want 100% end-to-end data protection.
IPSec can be used for many other purposes besides VPNs.
A Windows VPN solution has administrative benefits that may not be available
with a VPN hardware appliance. For example, a Windows Server VPN gateway
will be tightly integrated with Active Directory for user authentication and policy
enforcement, and you can use Group Policy and the scriptability of Windows to
manage the gateway itself. If a company has already invested in a Windows
network, then Windows-savvy administrators already exist and they will face a
gentler learning curve.
Performance is never considered apart from price. If you only have a 45 Mbps T3
connection to the Internet, do you really need a $20,000 VPN appliance that can
SANS institute
handle thousands of tunnels with an aggregate bandwidth of 300 Mbps? If you

switch from VPNs to thin clients for your remote access solution, what are you
going to do with that appliance? The hardware and licenses invested in your
Windows VPN gateway, on the other hand, can be re-purposed later for other uses
because the hardware and OS are generic. A load-balanced array of three dual-
Xeon Windows VPN gateways at $3300 each will outperform a single $10,000
VPN appliance (and provide better fault tolerance too).
TP, L2TP or SST

simply use IPSec in tunnel mode?
Pure IPSec "tunnel mode" currently lacks features necessary for a variety of VPN
scenarios, e.g., it lacks user authentication, has no dynamic IP assignment for remote
hosts, an inability to encapsulate other protocols besides TCP/IP, etc.. When IPSec is
combined with L2TP, however, these limitations are overcome. L2TP does not in any
way weaken the security provided by IPSec. All L2TP-related data is encrypted by IPSec
before it leaves the computer.
The IPSec IETF working group will soon overcome these limitations of IPSec tunnel
mode, but their solutions have not been finalized (http://www.ietf.org/html.charters/ipsra-
charter.htm1). In the meantime, L2TP is also an industry-standard IETF protocol; its
other most important vendor being Cisco Systems.
SANS Institute
There are a variety of tools for managing the Windows Firewall and IPSec.
IP Security Monirnr
IP SecuriQPolicies on Loa1Computer
IP Security Policies on Acbve Directory
ce is
Starting with Windows Vista, the primary tool for managing IPSec is also the MMC
snap-in for managing the firewall: Windows Firewall with Advanced Security.
Specifically, it is the Connection Security Rules container in that snap-in, as well as the
IPSec Settings tab in the properties of the snap-in itself.
IP Security Monitor is an MMC snap-in which can be used to view IPSec statistical data
and session information on local or remote Windows XP or later systems (not 2000). It
can display hostnames instead of IP addresses, if desired, and supports a query feature
that helps to determine which IPSec rule would govern certain types of traffic. It is a
CUI version of the data that can be acquired with "ipseccmd.exe show all".
SANS Institute
I P Security Monitor 1s; 192 168 111 113 192 168 111 111 Kerberos 3DES SHAl Mediurn(2)
ations
Negotiation Policies
Security Associations
In Windows Vista and later, some of this snap-in's functionality has been added to the
Monitoring > Security Associations container in the Windows Firewall with Advanced
Security snap-in too.
The primary IPSec configuration tool for Windows 2000/XP/2003 is the "IP Security
Policy Management" MMC snap-in. It is available on newer operating systems as well
even though it is no longer primary for them. This utility can be used to do the
following:
Configure local IPSec Policies in a computer's registry.

Assign local IPSec Policies from a computer's registry.
Configure IPSec Policies in Active Directory.
Create, edit and delete IPSec Filters, Filter Actions, and other IPSec options.
Check IPSec Policy integrity.
Restore the built-in Policies to their default settings.
Import/export Policies f r odto files.
The IP Security Policies snap-in must be installed by hand. It is not in the Administrative
Tools folder. When installed, the snap-in can be used to manage IPSec Policies stored
either in Active Directory or on the local machine.
Checking Policy integrity will verify that the Filters and Filter Actions linked to the
Policy are valid, that the locally cached Policy matches the Policy stored with Group
Policy, and that the internal structure of the IPSec Policy is consistent. You can also
exporthmport Policies for backup purposes. For either, right-click on the "IP Security
Policies" snap-in and select All Tasks.
SANS Institute
IPSec, RADIUS. Wireless. and VPNs 15
1 I
If !
To install the IP Security Policies snap-in, enter "mmc.exe" at the Run line > Console
menu > Add/Remove Snap-in > Add button > select IP Security Policy Management >
Add button > select desired IPSec Policies to manage > Finish > Close > OK. The snap-
in can manage IPSec Policies in the registry of local or remote computers, or Policies
stored in Active Directory in the local or remote Windows domains. Save the MMC as
"IPSec Snap-Ins".
NETSH.EXE is a command-line utility for managing network adapters, protocols and

some network services such as RRAS, WINS, DHCP, and, on Windows Serve 2003,
IPSec. NETSH.EXE is one of the most important new command-line tools from
Microsoft. Search on the tool's name in Windows XP/2003 Help for more information,
and note that it does support the "-r" switch to operate against remote systems.
For a taste of what NETSH.EXE can do for you, try these commands one at a time:
netsh.exe int ip show address

netsh-exe int ip set ?
netsh.exe diag qui
netsh.exe diag show OS /v
netsh.exe int ip show offload
The last command above will show the IPSec-offload characteristics (if any) of your
network adapter card. These network interface cards have on-board processors for
handling some of the CPU work of doing IPSec. On Windows Server 2003 you can also
manage your IPSec settings with NETSH.EXE. This will be discussed later in the
manual along with 1PSECPOL.EXE (2000) and 1PSECCMD.EXE (XP).
Some configuration settings can only be changed through NETSH.EXE; for example, to
support NAT for dial-in or VPN clients going through the RRAS box to access the
Internet, you must configure the "Internal" virtual interface in RRAS to support NAT
with NETSH.EXE. This is necessary with Windows 2000, but not Windows 2003
(KE33 10888). The command is "netsh routing ip nat add interface internal private".
- SANS Institute
iagnostic Tool
The IPSec Diagnostic Tool is a free Microsoft download which can examine the IPSec
service, driver, current associations, event log entries, NAP client configuration, and
other IPSec-related settings to help troubleshoot IPSec problems. When run, it examines
these settings and produces a report to help guide the administrator in the troubleshooting
process. The tool works on Windows XP/2003/Vista/2008 and later. To find the
download, do a Google search on "site:microsoft.com ipsec diagnostic tool download".
NETD1AG.EXE is one of the Support Tools that is found on the Windows CD-ROM in
the \Support\Tools folder or downloaded from Microsoft's website.
The NETDIAG.EXE command-line utility is a comprehensive networking diagnostic

tool. It performs a series of in-depth tests against protocols, adapters and some network
services to help troubleshoot networking problems. One of the tests it can perform is for
IPSec.
In general, NETDIAG.EXE is better than 1PSECMON.EXE for troubleshooting and

understanding IPSec on Windows 2000; on Windows XP, use 1PSECCMD.EXE; on
Windows Server 2003 and later, use NETSH.EXE. The following commands will run
SANS Institute
tests against IPSec on the local Windows 2000 computer and output operational statistics
that are more detailed than those from 1PSECMON.EXE:
netdiag /test:ipsec /v
netdiag /test:ipsec /debug
The /v switch only shows Phase I offers, while /debug will show both Phase I and Phase
I1 offers. The /v switch shows packet statistics, while /debug does not. Expect to become
very familiar with the output of this tool if you plan to work with IPSec extensively on
Windows 2000. On Windows XP, use 1PSECCMD.EXE instead, and on Windows
Server 2003 use NETSH.EXE.
Cum*ent Phase I SBs:

SB 8 1
P o l i c y Id: C68B4686C-5422-4D2C-?B73-A5Cl3CBI4B96>
Cuivent Oahley S t a t e : MainMode Key ButhoPized
SPC : 169.254.222.222. D e s t : 169.254.111.111
I d e n t i t y P r o t e c t i o n : No. PRF : 0
PFS : No, Enciyption : 3DES, Hash : SHAI
B u t h e n t i c a t i o n : RSB Signature, G P O U ~ : Medium < 2 >
Quickmodes pea MainMode : 1- Lifetime Seconds : 28800
Curpent Phase 2 SAs:

SA # I
Filtek. N a m e : No Name
P o l i c y Name :
F i l t e p Id: C689B6D72-294A-499F-B5FD-36B85fiDD@Y33>
P o l i c y Id: C@17470fi9-61BB-4ElF-8L334-D9310D60D6B7>
SPC Bddi. : 169.254.222.222 S i x Mask : 255 -255 -255 -255
Dest Rddp : 169.254.111.111 Dest Mask : 255.255.255.255
Tunnel add^ : 0.0.0.0 Src Po1.t : 0 Dest Popt : 80
Protocol : 6 TunnelFilteP: No
Flays : Outbound
OpePation : Enciyption Lifetime Seconds : 900. ](Bytes : 100000
I n t e y a i t y : SHRI C o n f i d e n t i a l i t y : 3DES
1
1PSECCMD.EXE only works on Windows XP and installs with the XP Support Tools.
Similar to IPSECPOL.EXE, this is a tool that can be used to configure virtually every
IPSec option from the command line. It is also used instead of NETDIAG.EXE on XP
when viewing IPSec statistics and session information. On Windows Server 2003,
though, the features of this tool have been moved into NETSH.EXE, and it's likely that
future XP Service Packs will do the same to NETSH.EXE on XP too.
)
1PSECPOL.EXE is a Windows Resource Kit command-line utility which provides most
of the functionality of the IP Security Management MMC snap-in. It can be used to
manage Filters, Filter Actions, IKE Phase I negotiations, and other features. (You can
also download the tool for free as a part of 1ISLOCK.EXE package from Microsoft.)
Importantly, 1PSECPOL.EXE can set temporary IPSec Policies that are cleared after
rebooting or restarting the IPSec Policy Agent service.
SANS Institute
A later section will discuss 1PSECPOL.EXE in detail. Its command-line options are
somewhat complex.
E (2000 Only)
1PSECMON.EXE is a GUI tool which displays information about IPSec activity on the
local computer (KE3231587, KE3256284). It comes bundled with the operating system.
The refresh interval is configurable, but nothing else. 1PSECMON.EXEdisplays the
following information about outbound SAs:
Security Association details: IP addresses, ports, covering IPSec Policy.
IPSec statistics: bytes sent/received, invalid packets, key additions.
ISAKMP/Oakley (Phase I) statistics: madquick modes, soft SAs, failures.
IPSec Driver Enabled: ordoff. Indicates whether a Policy has been assigned.
___I__ ~ _I__
. . . !-
I/
. .-
.............. .......... .- ......
. . . . .. . .,, : I
,, . ~ . ,*._,.
I ..I,
. . ,,,. ...... i
I ' , . . ,. ,r. , , I
, .I..
1 ' I
I
I <. :I::: ,,.. > I
" I
' 1 .
!...;.. .
. . . . . . . . .......
....
. ,./,,.
______ ..----._l--.l----
. . . . . . . . . . . . . . . .
(!. ,
....
I
Even I
You can log IPSec information to the System log in Event Viewer when troubleshooting.
To audit IKE negotiations, enable "Audit Logon Events" in the computer's audit policy.
To audit IPSec Policy changes, enable "Audit Policy Changes'' as well. IPSec driver
event data can be audited once per hour by setting the DiagnosticMode value to 1 under
HKEY-LOCAL__MACHINE\System\CurrentControlSet\Services\IPSEC\.
SANS Institute
The original version of Windows XP had a built-in firewall called the Internet
Connection Firewall (ICF). Service Pack 2 for XP drastically improved the ICF and it
was renamed to the Windows Firewall (WF). Starting with Windows Vista, the firewall
was again enhanced and this time not-so-eloquently renamed to Windows Firewall with
Advanced Security (WFAS). Importantly, the IPSec driver in Vista and later is tightly
integrated with WFAS, and IPSec is primarily managed through the WFAS snap-in.
File and Printer Siiaring (Echo Request - I

ReemoTe Assistaxe Domain, Pubkc
two':: Orscovery (SSDP-ifi) hietwor.c Disco'very Donrain, Public
Netwoik Discovery Domain, Puhirc
WFAS is built into the operating system, stateful, easy to configure, supported by
Microsoft, can be managed through Group Policy or custom scripts (NETSH.EXE), and
works with all types of interfaces (LAN cards, 802.11 wireless, dial-up connections, VPN
tunnels, etc.). WFAS also is compatible with the Internet Connection Sharing service,
SANS institute
provides good ASCII text logging in W3C Extended format, and can easily be configured
'
to permit access to services on the host itself or to another machine behind it on the LAN,
such as to an HTTP or FTP server. The WF in XP-SP2 had only meager egress filtering,
but WFAS filters both inbound and outbound traffic with equal facility.
On the bad side, though, WFAS lacks the sophisticated intrusion detection capabilities of
some other popular personal firewalls, doesn't work on Windows 2000/XP/2003, and
there's no built-in support for automatic upload of log data to a central server. The
flexibility of WFAS also comes with an administrative price: complexity. A large part of
that complexity comes from having different rules for different network profiles.
It's important to understand that WFAS is not just for laptop and home use. The firewall
is supposed to be enabled on all machines, both workstations and servers, whether they
are "safe" inside the corporate LAN or outside on the Internet. Defense in depth means
you no longer have just a perimeter firewall, you are performing filtering on every single
computer under your control! To make this possible, however, you must be able to 1)
manage the firewall across the enterprise and 2) provide filtering exceptions for remote
administration, troubleshooting, backups, monitoring and other necessary
communications (while blocking the rest). IPSec actually makes this easier because you
can make firewalling exceptions but only for traffic secured with IPSec.
SANS Institute
When a Windows Vista or later computer is connected to a network, that network will be
categorized as a public, private or domain network (Microsoft sometimes calls these
categories "network location types" or "network profiles"). A domain network can be
used to access domain controllers for the computer's Active Directory. A private network
is a trusted network that does not have domain controllers, e.g., a home or small office
network. A public network is everything else, such as airports and coffee shops with
Internet access.
Dircoietyof other ccmputeriand devices will be limited and

the use of the ncW orb by s o m e programsmay be restricted
u Private
Thsallo .is you tc seeccmpiiteissnd deuices,while nraiing
your computer dacoieiablc
SANS Institute
You can see and edit the category of the network to which you are currently attached by
going to Control Panel > Network and Sharing Center > Customize. The computer will
remember your settings the next time you connect to that network. If a domain controller
is reachable, the domain category will be automatically assigned.
The Windows Firewall can have different sets of rules for each network category, and
will switch the rulesets automatically as the computer is disconnected and reconnected to
different networks. And if you have multiple network interfaces with different profile
assignments, then different sets of firewall rules will be applied simultaneously according
to each interface's profile. Rules for the public network are generally the most strict,
while rules for the domain network are the least strict.
iscovery Section
In the Network and Sharing Center applet there is a section at the bottom named "Sharing
and Discovery". This section is actually for managing the firewall in a user-friendly way.
When, for example, file sharing is enabled or disabled, certain firewall rules are
automatically modified to allow or block the sharing. File sharing might be enabled for
private profile networks, but disabled for public networks. Exactly what these firewall
rule changes are we'll see in a moment.
,
olicy Control Over Profiles
Note that you have Group Policy control over network profiles and their defaults. Inside
a GPO, navigate to Computer Configuration > Policies > Security Settings > Network
List Manager Policies, and here you can determine whether users can change the profile
type for a given network and what the default profile should be for new networks.
A nelwork location identifies the $pe of natviorl that a computer 15

connected to and sutornabcally sets the appropriatsflrIvrall ssaings for
that location
Locabon vpe
/'
,Not conflgured
User permissions
user man change location
User cannot change location
SANS Institute
vs .
There are different default settings for the different network location types. To edit these
per-network defaults, right-click the WFAS snap-in > Properties > choose the appropriate
tab: Domain, Private or Public.
For each profile, you can enable/disable the firewall, blocWallow inbound or outbound
connections, configure logging options, and spec@ whether the user is notified when a
SANS institute
program is prevented from receiving inbound connections (giving administrative users

the opportunity to allow them in for that program).
__
,- . " . _ _ _ . _ _ I . .
7
I: customize Setrhg; tor [he Dcmain Profile
For inbound connections, if the option is set to "Block All Connections" then all inbound
connections are blocked even if there is a rule which would normally allow it, while the
"Block (Default)" option blocks only those inbound connections for which there isn't a
rule to allow them.
Logging is written to an ASCII text file (pf irewall .l o g ) in W3C Extended format.
Note that all dropped packets are logged, if those packets are logged at all, but only the
initial packet in a successful connection is recorded in order to avoid killing performance
by logging all the permitted packets that follow. The maximum log size is 32MB.
S A N S Institute
: f ~ i m eFormat: coca1
#Fields: date time action protocol s r c - i p dst-ip sr-c-port dst-port s i z e rcpflags tcpsyn tcpack tcpain Zcmptype
2004-08-12 22:51:30 DROP TCP 10.7.7.7 10.4.iT.77 31747 1145 628 AP 4275647614 4059211188 16251 - - .. R E C E I V E
, 7 10.1.77.77 34747 1145 1500 AP 4275646202 4Q592112BB IS251
' 7 10.4.77.77 347"7 1145 I460 AP 4275ci49GC.2 4059211268 16251
-- -- -- RECEIVE
.7 10.4.77.77 34717 1145 140 AP 4275654230 4059211288 1625i

. 3 10.255.255.255 137 137 78 ------- RECEIVE
- -.*
RECEIVE
RECEIVE
, 3 10.255.255.255 137 137 78 ---- -- RECEIVE

. 5 m.25s.255.255 1 3 7 137 7s -------
-------
RECEIVE
. 3 10.?55.255.255 137 137 70 RECEIVE
. 7 10.-.77.77 3S056 1157 A 0 R 3285151261 0 0 ---
.7 10.4.77.77 35065 1160 40 R 2406377338 0 0
2004-08-11 23:08:54 DROP UDP 10.4.3.3 10.255.255.255 137 137 73 - -- ---- ---
RECEIV€
RECEIVE
RECEIVE
SANS Institute
ec
- Only Secure Connections
- Users and Computers
ce
- Network Profile
- Interface Type
- First Match Wins (No)

- Best Match Wins (Yes)
- What is "best"?
WFAS performs both ingress and egress filtering. Connections are regulated by the rules
in the Inbound Rules and Outbound Rules containers in the WFAS snap-in. To create a
new rule, right-click the Inbound/Outbound Rules container > New Rule. To edit a rule,
simply double-click it.
The property sheet of each rule has the follow tabs and options:
General: Allow or block, or allow only if secured with IPSec, and allow with
IPSec to a particular user or computer (Users and Computers tab) even if there is
another rule that would otherwise block the connection.
Programs and Services: The exact program binary or background service(s) to

which the rule applies.
Users and Computers: If only IPSec-secured connections are allowed (General

tab) and if the IPSec authentication protocol can identify the exact user or
computer account of the peer (such as Kerberos or certificate), then computer and
user accounts can be selected from Active Directory (not the local accounts
database or the workgroup) in order to limit connections to/from just those
particular users or computers. L
Protocols and Ports: Select any protocol, including IPv6, or any port(s), i
including dynamically-assigned RPC and NAT ("Edge Traversal") ports, or any
SANS Institute
IPSec. RADIUS, Wireless, and VPNs 27
ICMP protocol, including custom ICMP type and code numbers, to which the rule
applies.
Scope: Limit the source and/or destination IP address(es) to which the rule
applies, including DHCP-assigned WINS, DNS, DHCP and default gateway
addresses.
Advanced: Specify the network location profile(s) and the types of network
interfaces (wireless, VPN/dial-up, physical NIC) to which the rule applies, as well
as whether an Internet-accessible IP address should try to be obtained (inbound
rules only) for the sake of publishing a service to the Internet without the aid of a
NAT-ing device in front of the computer.
eri es
With a large number of firewall rules to sift through, it can be difficult to focus on just
the rules which are relevant to you. Notice that you can right-click the Inbound Rules or
Outbound Rules containers and filter by profile, enabled state, or grouping. This is very
useful when, for example, you want to see only the enabled rules for the public profile.
Ce ace es
Each interface is assigned a network profile type when it connects to a live network. You
can have different rules for different profiles, hence, different rules for different
interfaces on a multi-homed machine simultaneously. But notice on the Advanced tab
that you can also apply different rules to different types of interfaces based on their
media: LAN, wireless, and remote access (VPN and dial-up).
Note that a "secure connection'' is traffic signed using IPSec Authentication Header (AH)
or Encapsulating Security Payload (ESP) with the encryption disabled, while a "secure
connection with encryption required" is traffic both signed and encrypted using IPSec
ESP with the encryption enabled.
If an IPSec-secured connection is only for particular users or computers (as defined on

the Users and Computers tab), then the IPSec channel must be authenticated with either
Kerberos or a certificate, and those users and computers must exist in Active Directory.
SANS Institute
The IPSec settings are configured using the Connection Security Rules container in the
WFAS snap-in. If an appropriate IPSec Connection Security Rule is not created for a
firewall rule that requires it, the firewall rule will not allow the traffic. The default IPSec
settings used can be seen by right-clicking the WFAS snap-in > Properties > IPSec
Settings tab.
rograrn Exceptions
Another way for a user with administrative rights to add an inbound rule is to simply
launch a program which attempts to listen on a new port number. This action causes a
dialog box to appear which alerts the user to the attempted port binding. In the
screenshot below, netcat was run to make it listen on TCP port 7890 and connect an in-
coming session to a new instance of CMD.EXE (“nc .exe -L -p 7890 -e
cmd .exe”). Maybe the user did this knowingly and deliberately, or maybe the system
has been compromised and a back door is being opened.
Windows Firewall has blocked this program from accepting incoming network connections. If
you unblock this program, it v ~ i lbe
l unblocked on all prlvate nehvorks that you connect to. mt
are the risks of iinblockino a orocrdm?
Name: nc.exe
eublisher: Unknown
Path: D:\sources\nc. exe
Network jocatton: Private nebwork
VJIiai are nehilork lacation@
The dialog box gives the user two choices:
Keep Blocking: Don’t allow the program to acquire a listening port. Train your
users to choose this option when there is any doubt.
Unblock: Create inbound rules for this program to permit it to listen on the port it
is currently requesting and on any other port it may request in the future.
If you don’t want this dialog box to ever appear, right-click the WFAS snap-in > select
the tab for the relevant network profile > Customize button for settings > select No to ,
display a notification (default is Yes). For non-technical users, this is perhaps the best
thing to do.
Keep in mind that you should limit the IP addresses of the other machines which you
allow to connect to you as much as possible. This is done on the Scope tab in the
SANS Institute
properties of the inbound rule. At a minimum, don't set the remote IP addresses on the
Scope tab to 'Any IP Address".
Firewall rules are not processed from top-to-bottom in the order shown in the snap-in.
The Windows Firewall does not follow the "First Match Wins" metarule, it follows the
"Best Match Wins" metamle. Now, the exact criteria for making one rule better than
another is not fully documented, but informal sources indicate that rules are processed
roughly in this order:
1. Rules that allow/block traffic for particular services.

2. Rules that allow traffic from particular computer sets.
3. Rules that allow traffic only if it is IPSec secured (AH or ESP).
4. Rules that block traffic, inbound or outbound.
5. Rules that allow traffic, inbound or outbound, with or without IPSec.
6. Default behavior for the active network profile (allow or block).
SANS Institute
30 IPSec. RADIUS. Wireless, and VPNs
Let's now talk about how Microsoft has implemented IPSec in Windows and walk
through the process, mouseclick by mouseclick, of creating IPSec policies.
SANS Institute
Internet Protocol Security (IPSec) is a suite of protocols used for the authentication,
integrity-checking, encryption, and encapsulation of TCP/IP packets.
IPSec security is implemented at the Network layer in the four-layer DoD protocol model
associated with TCP/IP. This seemingly simple fact has drastic benefits!
I Commands and data used by I Pretty Good Privacy I

services and applications, e.g., (PGP) enciyption of
HTTP, SMTP, FTP, NNTP, etc. files and e-mail
TCP and UDP port numbers, Secure Sockets Layer
sequence and acknowledgement (SSL), Transport
An important point to understand is this: as authenticatiodencryption features are

implemented at a lower and lower level in the protocol stack, these features become more
transparent to users and more compatible with a wider range of applications and services.
Users do not have to be trained to use IPSec-compatible applications because all their
applications are already IPSec-compatible, even if the original application developers
SANS Institute
have never even heard the word "IPSec" before. Services and daemons do not have to be
replaced with IPSec-compatible versions because they are already compatible straight off
the CD-ROM. In short, if a piece of software sends IP packets over the wire, you can use
IPSec to invisibly secure those packets. (Including ping? Yes, including ping packets.)
That is the real shortcoming of doing encryption/authentication at the Application and

Transport layers. PGP, SSH and Stunnel have to be installed separately, for example, and
users have to be trained and reminded to use them. TLS only works with applications
and services specifically designed to support TLS, but at least it is more transparent than
PGP because it is at the Transport layer instead of the Application layer. On the other
hand, IPSec is invisible to users, does not have to be separately installed, and is
compatible with all applications and services that communicates via IP.
As the table above shows, only hardware-based cryptographic devices provide security at
a lower level than IPSec. But, in this case, you have to purchase special crypto-
hardware! IPSec is compatible with any off-the-shelf hardware which is capable of using
IP, including ethernet, token ring, FDDI, wireless, modems, serial lines and infrared. In
sum, IPSec is both independent of the underlying hardware and invisible to the upper-
level protocols and applications above it -- that is why IPSec has become the standard.
Threats
IPSec is needed because the standard Internet Protocols --IP, ICMP, UDP, TCP, etc.-- do
not provide security for themselves. In fact, these protocols are inherently insecure and
archaic. They were never designed for security in the first place. They are wonderfully-
designed fossils of the DARPA-net era which, through the accident of technological
evolution, have been pressed into service to make an information economy.
IPSec can help to prevent attackers from causing harm when attackers try to:
Use a port scanner to discover active TCP and UDP ports (reconnaissance).
Spoof source IP addresses (denial-of-service and other attacks).
Capture, modify and resend packets (replay attacks).
Impersonate hosts (man-in-the-middle attacks).
Extract confidential information from captured packets (attacks against privacy).
Connect to any open TCP port if the computer is directly accessible from the
Internet, even if you wish some ports were only available to your LAN users.
IPSec standards are defined by Internet Engineering Task Force (IETF) Requests for
Comments (RFCs). IPSec itself is not owned by any one vendor, and certainly not
owned by Microsoft.
IPSec has become the de facto standard for securing TCP/IP traffic and doing Virtual
Private Networking over the Internet.
SANS Institute
There are many RFCs related to IPSec; the most important ones are at the front of this
courseware. The following are the core RFCs and should be read in this order:
RFC 2401 : Security Architecture for the internet Protocol
RFC 2402: IP Authentication Header (AH)
RFC 2406: iP Encapsulating Security Payload (ESP)
FWC 2409: The Internet Key Exchange (IKE)
ec o S
There are numerous benefits of IPSec for network security:
utual Authentication equired. Unlike SSL, both IPSec peers must

authenticate to each first before an IPSec session can be established between
them. Windows supports Kerberos, certificate, and pre-shared key authentication
methods for IPSec. Kerberos is enabled automatically when a computer joins the
domain, an Enterprise CA can distribute certificates automatically through Group
Policy auto-enrollment, and pre-shared keys can be configured through Group
Policy as well.
ES Encryption. The payload of a packet (or the entire packet

itself when tunneled) can be strongly encrypted for privacy. Windows supports
both AES 128/192/256-bit and the older 3DES 168-bit in Cipher Block Chaining
(CBC) mode for IPSec data encryption.
hecking. Packets can be checked to verify that they have not been
accidentally damaged or deliberately modified during transit. Windows can use
MD5 or SHA-1 for integrity-checking, as required by the RFCs.
Static tering. Though IPSec is mainly known for authentication and

encryption, it is also designed for static packet filtering. Because IPSec drivers
are typically implemented at a low layer in the protocol stack, the filtering is
effective even against attacks on the protocol stack itself. However, note that this
filtering is not stateful or dynamic, like a true firewall, it is only for doing fixed
("static") filtering of packets based on port, IP addresses and protocol ID number.
lications and Services. Because security is implemented at

the Network layer, IPSec is transparent to applications, services and end users.
Applications and services do not have to be upgraded or patched to make tGem
IPSec-compatible. Legacy applications can be used and they too will benefit
from IPSec because they will be completely unaware of IPSec's operation or
existence. You do not have to look for an "IPSec Inside!" sticker on your new
software to verifl that it will work with IPSec. IPSec works with all iP packet
types except for broadcast and multicast packets.
ser . Users do not have to be trained to use IPSec. In

fact, users don't even need to be aware that IPSec has been enabled on their
SANS Institute
computers. This is one of the most important benefits of IPSec. Without this
"user transparency" IPSec would be undeployable on desktops because of its
complexity.
anagement. Users do not have to be trained because IPSec can

be centrally managed through Group Policy. Each OU or site could have a
different set of IPSec policies applied to the computers in it. This feature is what
enables IPSec on Windows to relatively easily scale out to thousands of machines.
Remote Command-Line anagement. The IPSec driver is 100% manageable

from the command line with 1PSECPOL.EXE (2000), IPSECCMDEXE (XP) or
NETSH.EXE (2003). These tools work against both local and remote systems.
Windows Firewall Integration. The XP-SP2/2003-SP1 Windows Firewall has a

Group Policy management option named "Allow Authenticated IPSec Bypass"
which permits unsolicited in-bound connections if they are secured with IPSec.
You can limit which remote computers are permitted through the firewall by
defining a custom group of computer accounts and only allowing the IPSec-
bypass feature for that group, e.g., for remote management and backup computers.
When an IPSec policy is assigned, the Windows Firewall automatically allows in-
coming UDP 500 and 4500 packets for the sake of IPSec session establishment.
ardware Accelerators. IPSec cryptographic operations can be off-

loaded to smart network adapter cards. These IPSec-enabled network cards
possess cryptographic processors to perform the CPU-intensive work of
authenticating, integrity-checking, and encrypting packets on behalf of the
operating system. Example IPSec off-load cards include 3Com's Etherlink 3XP
and the Intel PRO/100 S. (See KB254257 concerning the Intel cards and fine-
tuning AH+ESP mode.) Also, some SSL accelerator cards can assist with main
mode negotiations as well if the cards support CryptoAPI. Each IPSec security
association consumes about 5KB of memory and a single high-end server can
support over ten thousand associations. A dataflow using IPSec ESP requires
about 1-3% more bandwidth than the same transfer in cleartext.
User Rights Integration (Windows Server 2003 and later). When using either
Kerberos or certificate-to-computer-account-mapping authentication, Windows
Server 2003 will enforce the "Access This Computer From The Network" and
"Deny Access To This Computer From The Network" user rights against remote
computers (2000 or later) when they initiate in-bound IPSec connections to it.
Hence, you can limit by group membership which computers are permitted to
open in-bound IPSec connections and then block all non-IPSec connections to the
port or service you are trying to secure.
Firewall, NAT and IDS Compatibility. When used by servers which must
communicate through a firewall, e.g., webservers and database servers, IPSec
simplifies the firewall design because the vagaries of the protocols used do not
SANS Institute
have to be predicted and managed. The servers can additionally be required to

communicate over IPSec, thus providing defense in depth beyond the security
provided by the firewall. Using AH or ESP with no encryption enabled will
reduce the overhead of using IPSec because of the lack of encryption processing,
and the cleartext packets can be examined by network Intrusion Detection
Systems (IDS). Finally, the NAT-T extension permits IPSec sessions through
firewalls, proxy servers and other devices that perform Network Address
Translation (NAT).
nteroperable. Because IPSec is an IETF standard, it is not owned by any single

vendor. Hence, different vendors can create interoperable IPSecNPN products.
For example, PGP Desktop Security 7.0.3 and later can use PGP's IPSec client
(PGPnet) to connect from a non-Windows client to a Windows server over IPSec
(www.pgp.com). Also, there are a variety of Cisco Systems products which
interoperate with Windows IPSec; this should not be too surprising since Cisco
helped Microsoft write their IPSec code (www.cisco.com). And note that the
Windows PKI can be configured to support Cisco's Simple Certificate Enrollment
Protocol (SCEP); to do this, see the help for the CEPSETUP.EXE utility from the
Windows Server Resource Kit CD-ROM (\apps\cep folder). Finally, the
FreeS/WAN IPSec client for Linux is mostly interoperable with Windows
(www.freeswan.org) and so is OpenBSD's i sa kmpd (www.openbsd.org).
Extensible. IPSec was designed to be extensible and flexible. For example, as

new ciphers and key lengths become desired, IPSec can be extended to support
them while maintaining backwards compatibility.
v6 Support. IPSec was designed with IPv6 in mind. The version of IP in

widespread use today is version 4. IPv6 is the next generation of IP, with 128-bit
addresses, extensible headers, and a number of new features for a heavily
networked world. Windows supports IPv6 natively as well.
ort. Virtual Private Networking is the ability

of a remote user or router on the Internet to connect to the corporate LAN through
an encrypted secure channel. This encrypted channel will encapsulate or "tunnel"
entire packets during transit. VPNs reduce long-distance charges while providing
very secure remote access. While VPNs can be implemented with other protocols
besides IPSec (for example, PPTP does not use IPSec) IPSec has become the
industry-standard solution for VPNs. The preferred VPN protocol on Windows is
L2TP, and L2TP uses IPSec for its security.
). IPSec and NLB are compatible and can be

used together to create a load-balanced and fault-tolerant farm of VPN gateways
(maximum of 32 gateways in the farm). With DNS round robin, multiple farms
can be used for even greater scalability. For configuration steps, see KB820752
and KB323437, as well as the help menu in the Network Load Balancing
Manager in the Administrative Tools folder.
SANS Institute
backs to the s Implementation of I

There are a few important drawbacks to using IPSec on Windows:
A Windows IPSecNPN will not have the same throughput as a hardware-only

IPSecNPN solution, even if IPSec-enabled network adapter cards are used. If
your organization is not already using Windows, or if you must support a very
large number of simultaneous VPN clients, then a hardware solution may be more
cost-effective.
Windows only supports enough of IPSec tunnel mode for bare RFC compliance,
and Microsoft doesn't really want you to use tunnel mode for anything other than
gateway-to-gateway connections either (~1325273 5). There are valid reasons for
this (discussed later) but the tunnel mode limitations in Windows can be
disappointing.
With the possible exception of Cisco devices, Microsoft is not particularly

concerned about interoperability with non-Windows IPSec peers. Some degree of
interoperability is currently possible with various flavors of
UNIX/Linux/Solaris/etc.,but the next Service Pack could easily change all this.
The only way you can know if it'll work is to set it up and see what happens.
Microsoft stores "pre-shared keys" for IPSec authentication in cleartext in the

registry. If the key can be read by an adversary, the adversary can open his or her
own IPSec sessions with one's systems. However, capture of this key does not
enable an adversary to decrypt anyone else's sessions because the pre-shared key
is only used for authentication, not data encryption. These data are stored in
subkeys under H~M\Software\Policies\Microsoft\M7indows\IPSec~olicy\*.
Transparency to application-layer software is not always ideal. Unlike SSL/TLS,

the details of an IPSec session are usually not (easily) available to applications if
those applications wish to confirm the existence or details of the IPSec session,
such as cipher suite or peer credentials, before proceeding with critical actions.
Services and client applications are at the mercy of the operating system and the
administrators who manage it.
Like other implementations of IPSec, flooding of UDP port 500 or 4500 can
prevent a victim host from establishing new IPSec sessions with other hosts.
UDP 500 and 4500 are the ports used for IPSec Internet Key Exchange (I=)
negotiations.
SANS Institute
i
i IPSec, RADIUS, Wireless, and VPNs 37
IPSec is a powerful and versatile protocol. A few examples of its uses can illustrate.
ices e
There are many tools and services one would like to use --especially for remote
administration-- but cannot because of their security weaknesses, e.g., they transmit
cleartext passwords. But if servers were configured to require an authenticated IPSec
session before allowing connections to these dangerous ports, and if 3DES encryption
were required for all the traffic, then these dangerous tools and services might be made
secure enough to use, perhaps even on bastion hosts in the firewall's DMZ. The
following is a sampling of the applications many administrators would like to use, or
services they would like to enable on their servers, but cannot because of security
worries, yet IPSec might make them secure enough:
FTP
TELNET
SNMP
SYSLOG
RADIUS and LDAP authentication
RPC-based applications (like most MMC snap-ins)
Microsoft File and Print Sharing (SMBKIFS)
Terminal Services (remote administration mode)
VNC Remote Control (http://www.uk.research.att.com/vnc/)
SANS Institute
Symantec pcAnywhere (http://www.symantec.com/pcanywhere/)

And the list goes on for all those protocols, services and tools which would have
been nice to run on servers in the DMZ, but were too dangerous even when
protected by the firewall.
Wireless networks can be securely bound together with IPSec. Authentication will limit
communication channels to just those systems participating in the domain or PKI, and
encryption can provide privacy. And you don't have to require IPSec for all wireless
communications either; you could rely upon the security enhancements of 802.1 l i for the
most part, then require IPSec in addition whenever connecting to critical servers through
the wireless link. If you do wish to use IPSec for all wireless traffic, install a wireless
card that can run in Access Point mode in a Windows router, then configure the clients to
use IPSec tunnel mode to forward all packets destined to the LAN to the wireless router
instead. The Windows box will decrypt the IPSec packets and route/bridge the original
packets onto the LAN. If your hardware Access Point vendor's box supports IPSec
natively, then all the better! (And if one needs to push out IPSec digital certificates, one
might as well push out certificates for 802.1X EAP-TLS authentication too.)
Farm
Many websites are composed of a farm of webservers which act as front-ends to
middleware servers which themselves communicate with multiple back-end databases (in
a "three-tier'' design). IPSec could be used to authenticate and integrity-check (but not
encrypt) all communications among the servers and databases, then block everything else
fiom the Internet and DMZ. A farm of webservers is also often a part of an isolated
domain in the DMZ to provide for administration and content management. The domain
controllers for this domain would be on a separate DMZ segment, and IPSec would be
used to armor the communications between DCs and the webservers. Authentication
protects the vital communications links between these servers, but without the overhead
of encryption. Encryption isn't needed here because the threat of packet-sniffing is
relatively small.
Critical Data Flows And Sensitive referring IPSec)

Defense "in depth" means providing multiple redundant layers of security. At many
sites, if an attacker can penetrate the firewall, there are no other barriers between the
attacker and critical internal servers. Exclusive reliance upon the firewall creates a single
point of failure. IPSec can help to provide in-depth security for sensitive internal servers
and workstations; for example:
Domain controllers could replicate using IPSec,

Databases could synchronize securely over IPSec,
The workstations of the security administrators could require IPSec for all
communications because the boxes they manage would too as well,
The fileserver with the R&D source code might always require IPSec,
SANS Institute
The computers of a certain OU might be isolated from all other machines by their
secret authentication keys and packet filtering rules,
The computer OUs for corporate executives, HR and legal staff might always
attempt to negotiate IPSec encryption, but fall back down to cleartext when
required,
And, in general, IPSec can help to defend a network against its own "trusted
insiders" who are, in fact, according to the FBI, behind the majority of network
security breaches which cause measurable financial harm.
For example, at the time of this writing, Microsoft's corporate network comprises 18
domains in six forests with cross-forest trusts and over 200,000 managed and unmanaged
hosts. Yet approximately 70% of the internal traffic at Microsoft uses IPSec ESP (with
no encryption enabled) to help protect the managed boxes from the unmanaged ones.
(ESP is used instead of AH since ESP supports NAT-T and AH doesn't.) ESP with
encryption is enabled on an as-needed basis through Group Policy on critical servers.
Very importantly, notice that in many of the examples above that IPSec is not required
from the other computer, IPSec is merely preferred. This means a system can be
configured to attempt to negotiate IPSec whenever a new inbound or outbound
connection is being established, but, if the other computer cannot or will not authenticate
with IPSec, the system will fall back to unsecured communications automatically, thus
permitting the connection like normal. Hence, you do not always have to require IPSec
when configuring a system, you can configure that system to merely prefer IPSec but be
willing to talk to non-IPSec-capable machines as necessary. And you can either require
or prefer IPSec on a case-by-case basis depending on the IP addresses, protocols or ports
being used.
Imagine if all your workstations and servers (or a large subset of them) required IPSec
mutual authentication prior to any communication whatsoever. This would be similar to
a VLAN, but instead of using switches, you're using IPSec. Only domain-joined
computers would have the necessary kerberos tickets or certificates to be able to
authenticate to other domain members, and all (most) systems would be configured
through Group Policy to require mutual IPSec authentication. If an unauthorized
computer attempted to open a TCP or UDP connection with a domain member, the
connection would fail because of the inability of the rogue computer to authenticate with
IPSec first.
1
You may have SMTP relays, websites, file servers, etc. to which you wish to give a
partner network limited access. However, the partner company is not a part of one's
forest and/or does not use Windows systems. Windows IPSec connections can be
authenticated with digital certificates. These certificates can be distributed to hosts in
other forests or to non-Windows systems. In short, the use of IPSec is not restricted to
those within one's own organization or Active Directory forest.
SANS Institute
or
When roaming users need to gain access to the LAN while on the road, IPSec can be used
with L2TP to provide encrypted and authenticated client-to-router VPN tunnels. The
client can now communicate with other hosts on the LAN just as though he or she were
physically connected.
If all the users in a branch office need access to the main office, the two offices can be r
connected over the Internet with router-to-router IPSec. The routers perform all the
encryption and authentication transparently for the users. The solution is secure,
relatively easy to set up, and saves on long-distance leased lines. From the perspective of
the two LANs, there just appears to be another "segment" connecting them. But that
"segment" is actually an encrypted VPN tunnel through the Internet.
SANS Institute
i IPSec, RADIUS, Wireless, and VPNs 41
IPSec is a suite of protocols. The three main protocols are Internet Key Exchange (IKE),
IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP).
The following table summarizes the purposes of IPSec's core protocols.
IKE Securely negotiate IPSec communication parameters and

cryptographic keys between peers. Parameters include
authentication methods, ciphers, key lengths, sequence numbers,
time-to-live counters, IPSec session ID numbers, modes, etc..
AH Provides authentication of packet source, data integrity, and
protection against replay attacks. Does not provide encryption.
ESP Provides data encryption, authentication of packet source, data
integrity, and protection against replay attacks.
The most important distinction between AH and ESP is that ESP provides data
encryption and AH does not. You must use ESP when you want privacy.
The second most important distinction between AH and ESP is that AH authenticates the
IP layer of the packet and higher, while ESP only authenticates the transport layer and
S A N S Institute
higher. This means that changes to the IP layer of the packet are detected by AH but not
by ESP.
Keep in mind, though, that both AH and ESP can be used simultaneously. Hence, a
single packet can use ESP to encrypt its Transport layer and higher, while using AH to
authenticate and integrity-check the entire packet (except the physical layer of course).
SANS Institute
IKE (RFC 2409) is a general-purpose protocol for negotiating communication parameters

and cryptographic keys on behalf of other protocols like IPSec, RIPv2, OSPF, etc.. IKE
negotiation is the first thing that occurs between two peers when they wish to
communicate over IPSec. IKE is how two " eers" --IPSec-enabled hosts, servers
or routers-- agree on how to secure their communications before secure communications
can begin.
will use IKE negotiation, a document called a "

" will define what IKE will negotiate for the protocol and how IKE
will negotiate it. RFC 2407 is IPSec's DO1 document for IKE.
42C
The end result o ion for IPSec, as defined in IPSec's DOI, is a data
structure called 'I. A SA is a set of parameters and
cryptographic keys used by a peer to manage an IPSec session with another IPSec peer.
Every bi-directional IPSec session a host/router is party to will correspond to two SAs on
that host/router: one for securing out-going packets to the other peer, and one for
securing in-coming packets from that other peer. An SA is one-way, so two are required
on each peer for bi-directional communications.
SANS Institute
44 IPSec. RADIUS, Wireless. and VPNs
An SA is what maintains the context or "state" of an IPSec session. The information and
keys in an SA enable the IPSec driver on a peer to successfully encrypt, decrypt,
authenticate, and verify the integrity of IPSec packets.
An IPSec-enabled host or router will keep all of its SAs in its own "Security Association
Database (SADB)". Each SA in a peer's SADB database is identified by a unique
number called a "SecurityParameters Index (SPI)". One SPI for each SA in the
SADB. (Ouch! Now the acronym soup begins to get thick! But I promise I will only
mention the important ones.)
Communicating peers will include the SPI numbers of the SAs controlling their IPSec
communications in the headers of the packets they exchange. This fact is important for
understanding how IPSec operates.
IKE negotiations are carried out using a more abstract n alled the
Internet Security Association and Key Management . IKE is an
implementation of ISAKMP, Le., IKE speaks a dialect of ISAKMP.
IKE is less abstract/general than ISAKMP, but IKE can still be used to negotiate SAs for
protocols other than IPSec; a DO1 document is used to lay out the details of how IKE
negotiates for other protocols, hence, a DO1 will also specifjr some ISAKMP parameters,
since many IKE parameters are just features of ISAKMP.
This can be confusing, but just keep in mind that ISAKMP is the more abstract or
general-purpose, while IKE is an implementation of it. IKE-for-IPSec is an
implementation of generic IKE. This course only concerns IKE-for-IPSec. The purpose
of ISAKMP-IKE, in any case, is just to negotiate cryptographic keys and session
parameters between the peers.
ISAKMP-IKE negotiations occur over UDP port 500 (but if NAT-T has been engaged,
ISAKMP-IKE switches over to UDP 4500).
After configuring IPSec on your computer (discussed later), open Network Monitor and
capture the ISAKMP packets.
SANS Institute
13 4.616638 LOCAL D-LIBKF7B386 ISAKMP Elajor Version: 1 &nor V e r s ~ o n : 0 Length: 1 8 4 -1
r t : ISkJTsIP, (500); D s t Port: ISAKIIP ( 5 0 0 ) ; Length = 9 0 0 ( 0 x 3
ISAVllP: Responder cookie = 00 00 0 0 0 0 0 0 00 00 00

ISAIUIP: B e x t payload = S e c u r i t y A s s o c i a t i o n
ISUllP- Major v e r s i o n = 1 ( 0 x 1 )
ISAKNP: l l i n o r v e r s i o n = 0 (0x0)
ISMIP: E x c h a n g e t y p e = I d e n t i t y Protection
+ISPXIP. Flags summary = 0 (0x01
ISAKIIP: llessage ID = 0 ( 0 x 0 1
ases
ISAJSMP-IKE negotiations occur in two Phases: Phase I and Phase 11. The end result of
each Phase is a separate SA, hence, we make a distinction between Phase 1 SAs and
Phase I1 SAs. An IPSec session with a remote peer will require two SAs on each peer.
gotiates an SA for ISAKMP-IKE itself (a "Main Mode IKE SA").

egotiates an SA for IPSec proper (a "Quick Mode IPSec SA").
The SA negotiated in Phase I is separate from and prior to the IPSec SA produced during
Phase 11. Importantly, the IPSec SA from Phase I1 relies upon the SA negotiated in Phase
I for its security. The real important key exchange occurs in Phase I for the ISAKMP-
IKE SA. The IPSec SAs negotiated in Phase I1 derive their security from the Phase I SA.
ote: Strictly speaking, both Phases are carried out by IKE, but in different
-- "modes" (see below).
ase I negotiation are:

ipher (DES, 3DES), hash (MD5, SHAl), authentication
method (Kerberos, certificate, preshared key), and Diffie-Hellman "group". This
is for the authentication phase only, not the bulk encryption of user data.
e- ge: the DH technique is used to
derive an identical secret "master key" on each peer using the group information
negotiated.
SANS Institute
3. Authenticate peer: The master key from the prior step is used to HMAC and
encrypt an authentication sequence, whose details were just negotiated.
4. Create the ISA SA: with the above credentials and master key, the
end-product we want is a set of Phase I SA parameters.
Two IPSec peers will first create a single ISAKMP-IKE SA from the Phase I negotiation,
then use that single Phase I SA to negotiate one or more IPSec SAs using one or more
Phase I1 negotiations. Over time, many IPSec SAs may come and go, but the ISAKMP-
IKE SA between the two peers will remain. A single ISAKMP-IKE SA can be used to
spawn many IPSec SAs.
Even when there are no active IPSec SAs between two peers, there may still be an
ISAKMP-IKE SA between them. If a new IPSec SA is needed, the existing ISAKMP-
IKE SA will be used to carry out a Phase I1 negotiation to produce the needed IPSec SA.
If a new IPSec is needed, but there is no ISAKMP-IKE SA between the peers, a Phase I
negotiation will occur to define the ISAKMP-IKE SA first, and then the Phase I1
negotiations can occur to produce the needed IPSec SAs.
Phase I1 Negotiation Steps

In outline, the steps of a Phase I1 negotiation are:
1. Negotiate policy: IPSec protocol (AH, ESP), cipher (DES, 3DES), and hash
(MD5, SHA1). This is for the user's data, not the authentication sequence.
2. Key generation: The master key from Phase I is used to derive a new key for
this IPSec SA. Optionally, IKE can perform another DH exchange to create an
entirely new key for Perfect Forward Secrecy and greater security. Rekey
intervals are defined.
3. Create IPSec SA: The above parameters and keys are combined to form a new
SA in the SADB with a unique SPI number. The information is now available for
the IPSec Driver.
When an SA needs to be renegotiated, perhaps because its lifetime has expired or an error
has occurred, usually this means the IPSec SA needs a new Phase I1 negotiation, but it
can also mean that a new Phase I ISAKMP-IKE negotiation is required. Because IPSec
SAs rely upon ISAKMP-IKE SAs, when an ISAKMP-IKE SA is deleted all the IPSec
SAs that depend on it are deleted as well.
You can see what SAs are currently active on your Windows box by installing the
NETDIAG.EXE utility from the \Support\Tools folder on the Windows Server CD-ROM.
Once installed, open a command-prompt window and execute "netdiag /test:ipsec /v".
current pilase z sns:
b e connand completed successfully I
SANS Institute
The above screenshot shows no SAs have been negotiated. The screenshot below
shows a single Phase I SA and a single Phase II SA.
C u r r e n t P h a s e ISRs:
SR # I
P o l i c y I d : C68B4686C-5422-4D2C-9R73-A5Cl3CBl4B96?
C u r r e n t Oakley S t a t e : MainMode Key Authoi*ized
Si-c : 169.254.222.222. Dest : 169.254.111.111
I d e n t i t y P r o t e c t i o n : No, PRF : 0
PFS : No- E n c r y p t i o n : DES, Hash : SHAI
R u t h e n t i c a t i o n : RSR Signatu1.e. G ~ o u p: Lou <I>
Quickmodes p e r MainMode : I , L i f e t i m e Seconds : 28800
C u r r e n t P h a s e 2 SRs:
P i l t e r Name : No Name
P o l i c y Name :
F i l t e r I d : C689R6D72-294R-499F-BSFD-36B85ADD0933>
P o l i c y Id: C017470R9-6IRB-4ElF-8034-D9310D60D6R7>
S r c Rddr : 169.254.222.222 S r c Mask : 255.255.255.255
D e s t Rddr : 169.254.111.111 D e s t Mask : 255.255.255.255
T u n n e l Rddr : 0 . 0 . 0 . 0 Src Port : 0 D e s t Port : 0
Protocol : 6 T u n n e l F i l t e i - : No
F l a g s : Outbound
O p e r a t i o n : Enci-yption L i f e t i m e Seconds : 900, XBytes : 100000
I n t e g r i t y : MD5 C o n f i d e n t i a l i t y : DES
blie command c o m p l e t e d s u c c e s s f u l l y
1
es
The Phase I negotiation can occur in either "main mode" or "aggressive mode". The end
result of the modes is the same (an ISAKMP-IKE SA) but their details differ (main mode
is more secure, but slower). Phase I1 negotiations always occur in "quick mode".
The important thing to remember is that "maidaggressive mode" is often used

synonymously with "Phase I" and "IKE negotiations"; while "quick mode" is often used
synonymously with "Phase 11" and "IPSec negotiations".
Phase I MaidAggressive Mode Negotiates "IKE SA"

Phase I1 Quick Mode Negotiates "IPSec SA"
IKE borrows these modes from the k' key-exchange protocol (RFC 2412), so
you will sometimes also see them r as "OAIUEY modes" or "OAIUEY
negotiations". IKE also borrows from the S protocol for public key authentication
(see Recommended Reading above concerning SKEME).
!
On Windows you can enable logging of IKE negotiations to a text file for analysis and
troubleshooting. Do this now so that the log will have data later on. You enable logging
by creating a REG-DWORD value in the registry named EnableLogging set equal to 1 in
HKLM\System\CurrentControlSet\Services\PolicyAgent\Oakley key (KB257225). Log
entries will be written to %SystemRoot%\debug\oakley.log. The log is overwritten
whenever the IPSec Policy Agent service is restarted.
SANS Institute
~ e s i ~ m e(get): 5k. = 0 x 0 0 0 0 0 0 0 0 f r o m 1 6 9 . 2 5 4 . 1 1 1 . 1 1 1
ISAKMP Header: (vl.0), l e n = 1 0 3
I - C O O K I E 3ec09009fZd5a5b4
K-COOKIE O 0 0 0 Q Q O ~ ~ # O O O ~ ~ ~
exchange : oak1 e y mi n Mode
flags: 0
n e x t p a y l o a d : SA
message I D : 001300000
D e t e r m i nesourceAddr sock 1 0 5 5
. .
F i 1t e r t o tn a t c t-i : 5 r c 1 59.2 5 4 .111.111.0 os t 1 69.2 5 4 2 2 2 2 2 2 0 .
f in d ( i psec) : 017470a9-61ab-4e1f-3034d9310d60d6a7
c r e a t e d new SA 2 3 a f 7 0
Responding w i t h new SA 2 3 a f 7 0
p r o c e s s i n g pay1 oad SA
R e c e i v e d Phase 1 d rat is form 1
E n c r y p t i o n ~ l DESg CEC(1)
Hash A l g SHA(Z)
o a k l e y Group 1
A U t h Method KSA s i n a t u r e w i t h c e r t i f i c a t e s ( 3 )
1
L i f e t y p e i n secon s
L i f e d u r a t i o n o f 28800
find(isakmp3: 00000Q00-0Q00-QQ00-0~0~0Q0~0~~00000
Oak1 e P o l icyA11 oc: 0023E3E3
i'
SAOak e y p o l i c y : 0QZ3B130
~ t i a s e1 SA accepted: t r a n s f o r m = l
SA - O a k l e y p r o p o s a l a c c e p t e d
ISAJSMP is a complex protocol. It supports multiple payload types, multiple

authentication methods, multiple key-exchange methods, multiple "modes", and
negotiates SAs by proposing sets of acceptable cryptographic algorithms in ranked order
of preference. Hence, despite the large number of hash/cipher/key-length combinations,
two IPSec peers can negotiate the highest security supported by both sides in common.
Note: For the sake of RFC compliance, it is possible to configure RRAS servers
to use a "preshared key" (a passphrase) for IKE Phase I negotiations (KB240262).
(Apparently there's been some debate about this.) The preshared key
authentication discussed later is for Phase I1 negotiations.
One of the most im t cryptographic techniques used by IPSec is the

Hellrnan-MerMe ( ey exchange. DH is a method for two parties to
shared secret key over an insecure channel like the Internet, but without ever sending that
secret key itself over the channel-- not even in an encrypted format.
The parties must first agree which "group" to use. A group is a set of numbers used to
control the DH exchange, consisting of a large prime number and second smaller number.
The numbers can be transmitted between the peers in the clear without risk of
compromising the secret key generated with them. Vanilla DH is susceptible to a man-
in-the-middle attack, though, if an attacker can intercept the transmissions between the
SANS Institute
IPSec. RADIUS. Wireless, and VPNs 49
peers; the attacker can simply create two independent DH-encrypted channels with each
of the peers, then ferry and/or modify the data they exchange. To combat this, IPSec
authenticates the peers using Kerberos, a passphrase, or machine certificates.
The important thing to know when configuring DH is that different "groups" have
different security strengths. In general, choose the group with the largest prime number if
security is the most important consideration. The relevant property sheets mark the DH
groups as "Low" (768-bit), "Medium" (1024-bit) or "High" (2048-bit). However,
Windows 2000/XP requires an upgrade to support 2048-bit DH keys (KB8 18043) and all
the versions, Windows 2003 included, must have a registry value added to enable 2048-
bit support:
Hive: HKEY LOCAL MACHINE

Key: \SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
Value Name: NegotiateDH2048
Value Type: REG-DWORD
Value Data: 1 (1 to enable support, 0 to disable)
In Windows Vista and later, the DH exchange can also be performed using Elliptic Curve
Cryptography (ECC) for ECDH. Vista supports DH group 19, which is ECC using a
256-bit random curve group, and also DH group 20, which is ECC using a 384-bit
random curve group.
SANS institute
Authentication Header (AH) is the IPSec protocol which provides integrity and
authentication, but not encryption (RFC 2402). AH can operate in either "transport
mode" or "tunnel mode".
In transport mode, AH authenticates the entire packet at and above the IP layer, except
for a few fields in the IP layer which change during transit, e.g., time to live, type of
service, etc. (these fields are zeroed out during signature construction and verification).
The AH layer itself comes directly after the IP layer and just before the TCP/UDP
transport layer. Despite the AH header's location in the middle of the packet, the entire
packet is still authenticated.
I IP I AH I TCP/UDP I PayloadData I
AH can be combined with ESP. In this case, the ESP data is treated no differently than
any other type of data, and the AH header again comes after IP and before ESP.
1 IP I AH I ESP (see below for ESP)
In the AH header is the "Authentication Data" field. This field contains the authenticated
hash of the packet. The hash will either be HMAC-MDS or HMAC-SHA1. The
encryption key used in the Hashed Message Authentication Code (HMAC) is negotiated
when the Phase I1 SA is constructed. An AC hash can only be calculated and
SANS Institute
checked if both parties possess a shared secret key; this key is appended to the packet
data before the packet+key is hashed with MDS/SHAl.
Interestingly, the hash value produced, whether with HMAC-MD5 or HMAC-SHAI, is

truncated to 96 bits (down from 128 bits with MD5 and down from 160 bits with SHA1).
This weakens the authentication a bit, but also helps to thwart brute-force searches for the
shared secret key.
4.917070 D-LIlEP7E386 LOCAL TCP .A.. S . , len: 6 5 5 0 7 , seq. 3288870299-3288935806,

D-LIEEF7B386 TCP
IP: DOD I n t e r n e t . P r o t o c o l
AH: S e c u r i c y P a r a m e t e r s hide:: = 3608476033 ( O x D 7 1 4 P 9 8 1 )

AH: S e q u e n c e Numher = 3 i 0 x 3 )
AH. A u t h e n t i c a t i o n D a t a . N U e r o f data b y t e s r e m a i n i n g = 1 2 iOx000C)
G T C P : .AP . . . , l e n : 6 5 5 1 5 , seq: 673680755-673746270, aclr.3288870300, w i n : 1 7 5 2 0 , src: 1 5 7 7 dst: 3389
I / 1 -'I
~ 0 0 0 0 0 0 0 0 00 80 C 8 P 7 E 3 86 00 00 8 6 1 2 8B 6 8 08 0 0 45 00 .G%snh..&rijO.B.
noooonzo
00000030 06 29 OD 3 D 2 8 27
00000040 8 D 7 3 C 4 0 8 2D 9C 50 1 8 44 70 9 1 B6 00 00 0 3 00 is4-iPtDprdl.. Y.
100000050 00 OB 06 BO 00 00 00 00 00 . . - h a . . .. .
e
e, the entire original packet is placed behind the AH header and a new IP
header is fabricated and placed in front of the AH header. In this case, the entire original
packet is authenticated as well as the non-changing fields of the new IP header. The new
IP header can have a different destination address than the original. This new destination
IP address is called the "tunnel endpoint", but it is not necessarily the final destination of
the original packet. The tunnel endpoint is likely to be an IPSec-enabled router.
I IP (new) I AH I IP (original) I TCP/UDP I Payload Data

Because of the lack of encryption, AH tunnel mode is rarely used.
AH is protocol number 5 1.
SANS Institute
IP I ESP I TCPlUDP I Payload Data I Trailer '1 I Trailer 2
IP ESP IP TCPl Payload Trailer *i Trailer 2

(new) (original) u ~ pData
Encapsulating Security Payload (ESP) is the core IPSec protocol which provides
integrity, authentication and encryption. It too can operate in either "transport mode" or
"tunnel mode".
ESP can be used alone or in conjunction with AH (as in the screenshot below).
ESP Transport
ESP uses both a header and a trailer. In transport mode, the ESP header is inserted just
after the IP layer and before any transport layer protocols such as UDP or TCP. The ESP
trailer has two parts, and both are appended to the very end.
I IP I ESP I TCP/UDP I Payload Data I ESPTrailer 1 I ESPTrailer2 I

The layers in gray are encrypted with 56-bit DES or 168-bit 3DES in CBC mode.
Encrypted layers include everything in between the ESP header and the second ESP
trailer at the very end. The DES/3DES key was generated when the Phase I1 SA was
established.
The second ESP trailer at the very end contains the Authentication Data field for the
HMAC-MD5 or HMAC-SHA1 hash of the packet. Importantly, however, the scope of
the authentication is smaller with ESP than in AH. In AH, the entire packet is
authenticated, including the front IP layer (but not the datalink layer). In ESP, by
contrast, the packet is authenticated except the front IP and the last ESP trailer.
SANS institute
e
In tunnel mode, the entire original packet is placed after the ESP header and a new IP
header is fabricated and placed in front of the ESP header. In tunnel mode, the entire
original packet is both encrypted and authenticated. However, the new fabricated IP
header is still not authenticated. AH can be used simultaneously with ESP in order to
authenticate the front IP header.
I lP(iiew) I ESP I IP(origina1) I TCP/UDP I Payload I ESP 1 I ESP2 I

ESP tunnel mode is commonly used for Virtual Private Networking (VPN). Windows
uses L2TP with ESP in transport mode, not tunnel mode.
ESP is protocol number 50.
I 41
d2
6.429244
6. 429244
LOCAL
L 0GAL
D - L II,IKF 7E 386
D -L IImF 7E 3 8 6
ESP
ESP
ESP D a t a
ESP D a t a
@Frame: E a s e frame p r o p e r t i e r
@ETHERIJET: ETYPE = 0::0800 : P r o t o c o l = I P : DUD I n t e r n e t Protocol
G I P : I D = OxC65S; P r o t o = 0x33; L e n : 96
~00000010 0 0 60 C6 58 40 00 80 33 1P 08 0i- 01 01 04 0i. 05 . k@.C3l'OElX)tm

00000020
00000n30
00000040
00000050
000 00 060
s
AH cannot encrypt data, but ESP can.
AH authenticates the entire packet, including the IP layer. ESP only authenticates
data above the IP layer.
Both AH and ESP can be used in either transport or tunnel mode.
AH and ESP can be combined in the same packet.
SANS Institute
When a firewall rule or a connection security rule uses IPSec, but an IPSec option is set
to YJse Default (Recommended)", what is this default and how can the defaults be I
changed?
SANS Institute
The default settings come from the IPSec Settings tab on the property sheet of the WFAS
snap-in itself (right-click WFAS snap-in > Properties > IPSec Setting tab). This tab also
allows you to globally exempt ICMP traffic from IPSec rules.
When you click the Customize button, you'll see the dialog box shown in the slide. The
defaults are as follows:
hase
Diffie-Hellman-Merkle: Group 2 (1024-bit prime)
Encryption: 128-bit AES is tried first (primary), then 168-bit 3DES (secondary)
Hashing: SHA- 1
Key Lifetime (Minutes): 480 Minutes
Key Lifetime (Sessions): 0 Sessions (hence, only minutes decides).
efaults for "Secure Connection"

Protocol: ESP is tried first (primary), then AH is tried (secondary)
Encryption: Disabled for ESP.
Hashing: SHA- 1
Key Lifetimes: 60 Minutes or 100000 KB, whichever comes first.
Authentication: Kerberos (Computer Only)
efaults for "Secure Connection with Encryption":

Protocol: ESP
Encryption: 128-bit AES is tried first (primary), then 168-bit 3DES (secondary)
Hashing: SHA- 1
Key Lifetimes: 60 minutes or 100000 KB, whichever comes first.
Authentication: Kerberos (Computer Only)
And when we select the "Advanced" options instead, what do we get? Let's take a look!
0 Recommended (IPSec: General): Use Performance Monitor to track CPU utilization

and packet throughput after implementing IPSec or after increasing the security settings
of your IPSec policies. In general, tailor your IPSec settings to your likely adversaries
and your overall security posture, i.e., don't needlessly kill the performance of your
network.
0 Recommended (IPSec: General): Purchase IPSec-offload network adapter cards to

dramatically improve the performance of IPSec. Faster CPUs and multi-processor
motherboards will also alleviate the stress of using IPSec on servers and VPN gateways.
If an SSL accelerator card supports the CNG/CryptoAPI interface, then some models can
be used to accelerate main mode negotiations as well.
SANS Institute
The Phase I master key secures the exchange of keys negotiated in Phase 11. The master
key is ultimately protected using the Diffie-Hellman exchange which occurs in Phase I.
The most important option here is the key exchange algorithm. A Diffie-Hellman
"group" determines the length of the prime numbers used during DH exchanges in Phase
I. The larger the prime number, the more secure the encryption. DH Group 1 uses a 768-
bit prime number, Group 2 (the default) uses a 1024-bit prime, and Group 14 provides
2048 bits. Elliptic Curve DH is more secure than the original DH even though the bit-
sizes are smaller, e.g., 256 and 384 bits.
Two peers must support a common key exchange method in order to communicate. Note
that Elliptic Curve DH is only supported in Windows Vista and later by default, but
Microsoft may release updates to Windows XP/2003. DH Group 2 is the default because
it has the widest compatibility with Windows and non-Windows peers, and is also very
secure.
Windows 7/2008-R2 and later include a checkbox to YJse Diffie-Hellman for enhanced
security". If this box is checked, DH is always used instead of AuthIP-derived keys.
AuthIP is an IPSec enhancement first introduced with Vista. It's use is negotiated
automatically. If AuthIP is used, then, by default, a Kerberos-derived or NTLM-derived
encryption key is used instead of a key derived from DH. AuthIP key derivation is faster
than DH, but less secure.
SANS Institute
i
i
One of the golden rules of cryptography is to avoid using the same key for too long or to
encrypt too much data. How long is too long? How much is too much? That depends on
your adversaries, but in this dialog box you can specify your key lifetime in minutes
and/or sessions. If you configure both, whichever maximum is hit first (minutes or
sessions) will cause a rekeying and then both counters will be reset. Keep in mind that
the keys referenced here are for securing the IKE channel itself, not all the gigabytes of
data to follow. Those keys are negotiated in Phase I1 and have their own lifetime
parameters.
What kind of key has a time to live here? If you edit one of the security methods on the
left-hand side, you can choose the ciphedkey type as well as the hashing algorithm.
Depending on the time-value of your data and the resources of your adversaries, choose
the cipher and key size which is adequate for your needs, but avoid choosing the highest
security levels simply because they're stronger -- they will also slow down your
computers unnecessarily. For widest compatibility, consider using 3DES instead of AES.
AES is only supported by default in Windows Vista and later, but Microsoft may release
an update for Windows XP/2003.
Note that a Windows 2000 peer must have the High Encryption Pack (HEP) installed in
order to support 3DES. The HEP is included with Service Pack 2 and later, and it is built
into Windows XP and later by default. If a peer lacks High Encryption support, but
3DES is required, the IPSec session will fail.
For the hashing algorithm, always choose SHA-1 or better. Never choose MD5.
1
Perfect Forward Secrecy (PFS) for IPSec means that a new DH exchange is performed
whenever a new symmetric key needs to be created. PFS is disabled by default. PFS can
be enabled for either Phase I or Phase I1 keys independently using the NETSH.EXE
command-line tool. In Windows 2000/XP/2003 there was a GUI checkbox for PFS, but
in Windows Vista and later this GUI element was removed, hence, the necessity of using
NETSH.EXE to enable it. Only very high security environments will be required to
enable PFS.
ry (IPSec: Phase I): For Phase I settings, always set the Diffie-Hellman
group to Medium(2) or higher.
hase I): In both Phase I and Phase 11, remove any offers from
the list you are not willing to accept, don't just move them to the bottom.
ecommended (IPSec: Phase I): In very high security environments, enable Master
Key Perfect Forward Secrecy for Phase I. It is more important to enable PFS in Phase II
however. Keep in mind that PFS issues are a common cause of incompatibilities
between different vendors' implementations of IPSec.
SANS Institute
0 Recommended (IPSec: Phase I): In Phase I , rekey and reauthenticate on the basis
of minutes of time transpired, not on the number of sessions (set sessions to zero). The
rate of new sessions can be unpredictable and is not the relevant factor. As a rule of
thumb, no more than 1OOMB of data should be secured with a single key. Hence,
estimate how many minutes it typically takes for the computer(s) under consideration to
transmit 100MB of data, then rekey before that number of minutes. If in doubt, change
the number of minutes to 120 and set the number of sessions to zero. This also has the
advantage of reducing the number of stale security associations a peer must hold in
memory (about 5KB per session). Main mode rekeying has a relatively small impact on
performance.
0 Recommended (IPSec: Phase I): Require 3DES encryption or better in both Phase I
and Phase II whenever possible. Don't forget that Windows 2000 requires Service Pack
2 or later in order to support 3DES. Regular DES encryption is fine for low security
environments where the intent is to only thwart casual eavesdropping.
0 Recommended (IPSec: Phase I): In both Phase I and Phase II, always use SHA-1 or
better. Never use MD5.
SANS Institute
The left-hand side of this dialog box is for AH by itself or for ESP with the payload
encryption disabled. The right-hand side is only for ESP with encryption enabled. These
are the settings used by firewall rules and connection security rules that specify a "secure
connection" (left side) or "secure connection with encryption" (right side).
If you check the box at the top labeled "Require encryption for all connection security
rules that use these settings" then the left-hand side of the dialog box becomes grayed
out: you can no longer use AH or ESP with no encryption. Connection rules don't
specify Phase II/Quick Mode settings, they pull these settings from here.
Very importantly, ESP can traverse devices like routers and firewalls that perform
Network Address Translation (NAT) without the IPSec integrity checks failing. Because
NAT is so widely used, ESP is preferred over AH in all cases, even when encryption for
ESP is disabled. Hence, unless you have specific reason for doing so, don't use AH.
If you edit one of the integrity-only methods on the left-hand side, you can choose the
algorithm (AH or ESP with encryption disabled), the hashing algorithm (SHA-1 or
MD5), and the key lifetimes. As before, SHA-1 is less efficient but more secure than
MD5.
SANS Institute
If you edit one of the methods on the right-hand side that use ESP payload encryption,
you can choose whether to use ESP by itself or ESPt-AH, the encryption algorithm,
hashing method, and key lifetimes. Remember that AES is not supported out-of-the-box
by versions of Windows prior to Vista, and Windows 2000 requires at least Service Pack
2 to even support 168-bit 3DES.
AES Cipher Block Chaining (AES-CBC) is a mode of AES encryption in which each
block of plaintext is XOR-ed with the previous block of ciphertext, making the overall
message more difficult to crack. AES-CBC requires Vista or later. AES Galois Counter
Mode (AES-GCM) is a mode of AES which is faster than CBC mode. Galois Message
Authentication Code (GMAC) is the use of GCM for signing and integrity-checking only.
Note that GCM/GMAC requires Vistat-SP 1 or later.
est Practices
andatory (IPSec: Phase 11): If you want 3DES support in Windows 2000, install
Service Pack 2 or later. Windows XP and later supports 3DES by default. To balance
compatibility and security, choose 3DES encryption. To maximize security, choose AES-
256, but remember that this (currently) only compatible with Windows Vista and later.
Recommended (IPSec: Phase 11): In both Phase I and Phase II, always use SHA-1
or better. Never use MD5.
Recommended (IPSec: Phase I): Key lifetime should be 60 minutes (or less) and
1OOMB (or less). Smaller numbers are more secure, but less efficient. The defaults are
fine for most environments.
SANS Institute
i
The authentication methods supported by an IPSec Policy control how the computer
and/or user authenticates to the other peer during Phase I negotiations. Note that in
Windows 2000/XP/2003 only the computer can authenticate, not the user, but in
Windows Vista and later the user can authenticate via IPSec too.
Multiple authentication methods can be enabled simultaneously. There are three

authentication methods available in Windows 2000/XP/2003 :
Kerberos (Computer)
Certificate (Computer)
Preshared Key
In Windows Vista and later, you can also authenticate using:
Kerberos (User)
Certificate (User)
Health Certificate (Computer)
NTLMv2 (User)
NTLMv2 (Computer)
The authentication methods are attempted in the order shown on the property sheet, from
top to bottom. The first method acceptable to both peers is used. If two peers do not
have at least one common authentication method, the authentication will fail. Once a
SANS institute
mutually agreed-upon method fails, the next method in the list is not attempted in
Windows 2000/XP/2003, but Windows Vista and later can be configured to try a second
time using a different authentication protocol.
In Windows 2000/XP/2003, for example, if a remote peer is configured with both

Kerberos and certificate authentication, in that order, and the RRAS server is configured
with both Kerberos and certificate authentication in that order, and both sides have
mutually-acceptable certificates, then authentication will still fail because the remote peer
cannot reach the domain controller for Kerberos. But Windows Vista and later, on the
other hand, can be configured to try a second time, and, in fact, if both computers are
Vista or later, each peer can use a different authentication method (as long as it is
supported by the other peer, even though it is not that peer's first choice).
ut hent icat ion

Every Windows computer in the domain has a computer account in Active Directory.
The computer uses this account to authenticate to the domain when it starts up. This
same account can be used with IPSec Kerberos authentication. In Windows Vista and
later, the user can also use hidher account in AD for Kerberos authentication of IPSec.
Keep in mind that for Kerberos authentication to work, the IPSec peers must be in the
same or trusted domains, and each peer must be able to contact a domain controller.
Hence, Kerberos authentication is really not appropriate for remote access scenarios.
Peers can be mutually authenticated with their machine certificates. To be successfully

authenticated, the issuer of each computer's certificate must be trusted by the other IPSec
peer, and that is all that is required. It is not the case that an IPSec peer must have a copy
of the other peer's certificate beforehand, or know any of the details of the certificate's
credentials. No one-to-one or many-to-one mapping occurs. Computer certificates are
not mapped to computer accounts in Active Directory by default. The purpose of
certificate authentication is, in part, to authenticate with peers in foreign domains or that
can't be domain members.
The certificate can be issued by a Microsoft, Netscape, Entrust, VeriSign or any other
CA. There are no special requirements for the X.509~3certificate itself other than the
standard validity and integrity checks.
A Windows peer must have the certificate of the issuing Certification Authority (CA) of
its own IPSec certificate and the other peer's certificate in its personal Trusted Root CA
Store. This is the "personal store'' of the computer itself, not the human sitting at it. Use
Group Policy to distribute trusted CA certificates automatically (as discussed in the PKI
seminar).
A Windows computer can obtain an IPSec certificate through auto-enrollment from a

Windows Enterprise CA. An alternative is to manually request and install the certificate
SANS Institute
IPSec. RADIUS, Wireless. and VPNs 63
with the Certificates snap-in or the Certificate Services Website. Manual installation
requires administrative rights at the system.
Certificate authentication is appropriate when the other peer does not support Kerberos,
domain controllers cannot be accessed for Kerberos authentication, the other host is not
in a trusted domain, or L2TP is in use.
evocation Checking
The IPSec Driver does not perform certificate revocation checking by default. A
certificate is "revoked" if it is on the list of revoked certificates its issuing CA publishes.
A certificate might be revoked if its private key (or the private key of the CA) have been
compromised. Hence, for maximum security, you should enable certificate revocation
checking by setting the following registry value, but beware of performance penalties and
hassles caused by configuration mistakes:

Key: \SYSTEM\Curre~tControlSet\Services\PolicyAgent\Oakley
Value Name: StrongCrlCheck
Value Type: REG DWORD
Value Data: I or 5(select "Hex" as the Radix)
1: Normal CRL checking in which the check fails only if

a CRL is successfully obtained and the certificate is on it.
2: Strong CRL checking in which any error whatsoever in

the download or processing of the CRL returns a failure,
including finding that the certificate is on the CRL.
A certificate will include a CFU Distribution Point (CDP) field which lists the URLs
where the certificate's CRL can be obtained. The IPSec peer performing the revocation
checking must be able to access one or more of these URLs.
I1
eC CCeSS
IPSec supports certificate-based authentication. A special type of certificate is called a
"health certificate". A health certificate is issued to a computer only after that computer
has passed a variety of security health tests, e.g., confirrnation of a running virus scanner,
a personal firewall is engaged, recent patches applied, etc. Health certificates are a part
of the much larger system of servers, protocols and procedures that comprise Microsoft's
Network Access Protection (NAP) scheme (see http://www.microsoft.com/nap/).
Windows Vista and later can be configured to only accept health certificates for IPSec
authentication, thus limiting the set of communicating computers to those which have
passed a minimal health checkup. However, be aware that this capability requires at least
one server running Windows Server 2008 and quite a bit of planning and configuration of
Group Policy, RADIUS, PKI, Active Directory, etc.
SANS Institute
64 IPSec. RADIUS.Wireless. and VPNs
The "preshared key" is actually just a passphrase. The passphrase is protected during
Phase I1 negotiation by the master key derived in Phase I. However, the passphrase is
stored unencrypted in the IPSec Policy in both Active Directory and in the local registry.
The registry stores the passphrase in a value named l'ipsecData'' in a key under
HKLM\SOFTWARE\Policies\l\/licrosoft\Windows\IPSec\Policy\Local\ipsecNFA {xxxxxx
,where the ''xxx'~number is the GUID for the IPSec policy
xx-xxxx-xxxx-xxxx-~xxxxxxxx}
object itself. The permissions on these keys allow the local Users group read access.
Important: If an adversary obtains a certificate or knows the preshared key, this

only permits the adversary to open his or her own IPSec channel to your peer.
The adversary cannot decrypt other captured sessions with this information
because the Diffie-Hellrnan-Merkle exchange with each session is unique.
Support for preshared key authentication is included only for RFC compliance, for testing
purposes, or when security is not an issue (KB240262). Kerberos or certificate
authentication should always be used on production servers instead.
uthent icate
Authenticated IP (AuthIP) is an enhanced version of Internet Key Exchange (IKE) for
IPSec. AuthIP has the following benefits over regular IKE:
Authentication of the user, instead of the user's computer, using Kerberos,

NTLMv2, a user certificate, or a Network Access Protection health certificate.
The user authentication can be performed alone or after the user's computer first
authenticates itself to the target (dual authentication).
Multiple authentication attempts with different authentication protocols.
A different authentication protocol can be used by each IPSec peer when

negotiating a session, e.g., a client might use Kerberos and the server might use a
certificate.
Only Windows Vista and later supports AuthIP. When communicating with Windows
Server 2003 and earlier peers, IPSec on Windows Vista and later will automatically
downgrade to regular IKE for backwards compatibility.
uthentication
If you mark both authentication choices as "optional", authentication will no longer be
required. This would permit untrusted computers to open their own IPSec channels to
your machines and makes man-in-the-middle attacks more likely. Never choose this
option unless you are forced to do so by your planning constraints.
SANS Institute
If neither authentication choice is marked as "optional", then both authentication events

are mandatory. You can use this feature, for example, to first force authentication of the
peer's computer using a certificate, then force the user sitting at that computer to
authenticate with Kerberos. If either the remote computer or user lacks the Log On Over
The Network right, the IPSec channel can be blocked.
The first authentication method might safely be marked as "optional" if you intend to rely
solely on the second method. This would be done, for example, when you wish to only
authenticate users, not computers, because IPSec user authentication can only be enabled
in the second authentication attempt, not the first one.
If you select a user-based authentication method in the second choice, any other methods
on the second-choice list must be user-based as well. If you choose a computer-based
method in the second-choice list, all the other methods in that list must be computer-
based too. In short, you cannot mix user- and computer-based authentication methods in
the second-choice list, it is all of one or the other.
If you select pre-shared key authentication as the first method, you cannot have a second
authentication attempt of any type. This is so, in part, to maintain backwards
compatibility.
The following screenshot shows the first authentication method options.
SANS Institute
The next screenshot shows the second authentication method choices, but remember that
if you choose pre-shared key authentication as the first choice, you cannot add a second
choice. Note that only the second authentication choices include user-based
authentication methods.
llote You cannct use both user credentials and computer credentials in the
second authentication nieihcds IISI
In Windows 7/2008-R2 and later, you can specify the signing algorithm used with
certificate-based authentication. RSA is the default, very widely used, and backwards
compatible, while the Elliptic Curve Digital Signature Algorithm (ECDSA) is newer,
faster, more secure, but also not as widely used or as backwards compatible. Only
Windows 7/2008-R2 and later support ECDSA for IPSec.
Because the foregoing pages describe the default IPSec settings, these will be the settings
used whenever a firewall rule is marked to require a secure connection. But what if you
need to use something other than the defaults on a particular server or OU of laptops?
ry (IPSec: Authentication): Do not use preshared key authentication if you

can help it. The "keys" are stored in the registry in cleartext. However, don't be surprised
when preshared keys are necessary to interoperatewith other vendors' products. The
compromise of a preshared key does not enable one's adversaries to decrypt other
captured lPSec sessions.
0 Recommended (IPSec: Authentication): In general, intranet peers should use

Kerberos, and only Kerberos, while external Internet peers should use only certificate
SANS Institute
authentication. RRAS VPN servers will need to be configured with both certificate and
Kerberos authentication methods. If you can only support having a single-authentication
method, then choose certificate.
0 Recommended (IPSec: Authentication): When both certificate and Kerberos

authentication are configured, make certificate authentication the first method in the list,
Kerberos second. This satisfies a number of design scenarios and avoids problems.
0 Recommended (IPSec: Authentication): Enable certificate revocation checking only

in very high security environments. It will slow authentication and adds another step
which can fail. Set StrongCrlCheck = 1 for a compromise between security and stability.
Recommended (IPSec: Authentication): Use computer auto-enrollment with a

Windows Enterprise CA to simplify the distribution of certificates. Use the Certificate
Services Website (http://servername/certsrv/)for distribution to foreign-domain or
external peers on the Internet.
SANS Institute
The firewall rules allow/block packets, and sometimes packets must be secured with
IPSec or else they'll be blocked. But it's the Connection Security Rules which specify
which IP addresses, protocols and port numbers should trigger the negotiation of IPSec.
In order to use IPSec, each peer must have a Connection Security Rule which indicates
that certain packets exchanged with the other peer must use IPSec.
Remember, though, that a Connection Security Rule does not by itself allow traffic
through the Windows Firewall. There must still be a firewall rule enabled to allow the
traffic through aft.. it has been decrypted or otherwise processed by IPSec. I
If a firewall rule permits a certain type of traffic but does not require IPSec for those
packets, then that traffic is permitted whether or not it is secured with IPSec. If a firewall
rule permits a certain type of traffic but only if it is secured with IPSec, then there must
be a Connection Security Rule which successfully negotiates IPSec before the firewall
examines that traffic.
The firewall must be enabled for the network profile which is active in order for any
Connection Security Rules to become active too. The inbound and outbound defaults can
both be set to Allow in the firewall if you wish to use IPSec but do not wish to perform
any packet filtering (perhaps only for the Domain profile).
An inbound or outbound firewall rule which requires a secure connection will not by
itself, in the absence of a Connection Security Rule, trigger an IPSec negotiation between
SANS Institute
the peers. At least one Connection Security Rule must be configured on each peer before
IPSec will function on that peer.
ec s
There is a built-in wizard to help you create Connection Security Rules. The wizard will
ask you why you are creating the rule and then will prompt you for the necessary
information. However, once a rule is created, you can always go back to its properties to
edit its settings, and these property sheet tabs are the same no matter what type of rule
you create with the wizard, hence, let's focus on editing the rule after its been created.
To create a Connection Security Rule, open the Windows Firewall snap-in > right-click
Connection Security Rules > New Rule > follow the wizard's questions.
The default IPSec options in the properties of the Windows Firewall snap-in will be used
by Connection Security Rules when those rules do not specify those options explicitly,
Le., when an option in a Connection Security Rule is set to "Default", the value is taken
from the options configured on the IPSec tab of the properties of the Windows Firewall
snap-in. To see what options are actually being used, open Windows Firewall >
Monitoring > Connection Security Rules. (Note: Sometimes when you click "Default" in
the IPSec tab of the Windows Firewall properties, the change doesn't stick after clicking
OK, so you'll need to choose a particular option in that tab instead.)
Let's discuss each of the tabs in the property sheet of a Connection Security Rule. Simply
right-click the rule and select Properties.
The Computers tab is for defining the endpoints or peers of the IPSec connection to
which this rule applies. If a connection attempt matches the information on the
Computers tab, then the Connection Security Rule is triggered for IPSec negotiations.
The information on the other tabs do not apply or have any effect if the two endpoints
under scrutiny do not match the endpoints defined on the Computers tab.
SANS Institute
When you click Add or Edit, you can specify a single IP address or a set of IP addresses
by range, subnet mask or CIDR notation (IPv4 or IPv6). You can also specify IP
addresses which may change dynamically and do not need to be hard-coded into the
IPSec policy. In this case, you specify endpoints as being your DNS, WINS or DHCP
servers, whatever they are at the moment, or your current local subnet, as defined by your
current IP address and subnet mask. These dynamic options are especially nice for
roaming laptops.
SANS Institute
60 s
The Protocols and Ports tab exists only on Windows 7/2008-R2 and later. This tab is
missing on Vista/2008. On this tab you can refine the Connection Security Rule so that it
is only triggered by a particular protocol and port number combination (instead of just IP
addresses, like in Vista/2008).
The Authentication tab provides the exact same options as found in the default IPSec
settings, except that these authentication options apply to just this one rule. Please take
careful note of the option named "DONot Authenticate". Why is this an option? This is
how you exempt certain endpoints from the necessity of using IPSec at all. Remember
that Connection Security Rules take precedence over your default IPSec settings.
SANS institute
vanced Ta
The Advanced tab has familiar options for choosing network profiles and interface types
(LAN, remote access and wireless), but the IPSec tunneling options are different.
SANS Institute
i
i
eC
IPSec tunneling is very similar to Virtual Private Networking (VPN). In fact, many
organizations use IPSec tunnels as their VPNs and there is a widespread misconception
that "IPSec tunnel" and "IPSec VPN" are synonymous terms. Strictly speaking, though,
an IPSec VPN does not have to use IPSec in tunnel mode (think of L2TP IPSec VPNs)
and you can use IPSec in tunnel mode between two endpoints in a way that few people
would consider to be a VPN. If you do wish to set up a VPN with Windows, though, you
shouldn't use IPSec in tunnel mode, you should use L2TP with IPSec in transport mode
or SSTP (or PPTP).
As discussed earlier, IPSec can operate in either transport mode or tunnel mode. In
tunnel mode, the original packet is encapsulated behind a new IP header (among other
changes) and the new front IP header does not have to have the same source and
destination IP addresses as the original header (now encapsulated inside the new IPSec
packet). In fact, the IP addresses are usually different. Usually the tunnel endpoints are
gateway devices, and these gateways might be using IPv6 internally and IPv4 on their
Internet interfaces.
Since the tunnel endpoint IP addresses are normally different from the IP addresses of the
hosts communicating, what are the IP addresses of the endpoints? On the Advanced tab,
clicking the Tunneling button and enter these IP addresses. These will be the IP
addresses of the outer-most IP header created for the sake of IPSec.
SANS institute
74 IPSec, RADIUS. Wireless. and VPNs
When would you use such a feature instead of a full VPN? Rarely. You might have a
non-Windows IPSec gateway or server that doesn't support L2TP, but normally you'll
either use regular transport mode IPSec or a true VPN like L2TP or SSTP.
The."Apply authorization" checkbox is to limit which computers and users are permitted
to tunnel through the present device. These computers and users are configured by going
to the properties of the Windows Firewall snap-in > IPSec Settings tab > IPSec Tunnel
Authorization section > Advanced > Customize button.
The "Exempt IPSec protected connections'' checkbox will cause the computer to not
pump any packets through the tunnel which have already been secured with IPSec by
virtue of a different Connection Security Rule. If you want all matching packets to go
through the tunnel, don't check this box.
rder of Filter
The order of the Connection Security Rules in the dialog box does not matter. If any of
the rules match a packet, then that rule will be triggered. However, a single IPSec policy
can contain multiple Connection Security Rules, and each rule will have its own defined
endpoints, profiles and interface types. An inbound or outbound packet may match two
different rules, and these rules may have conflicting actions. The ambiguity is resolved
by the way the IPSec driver matches packets against rules. All the filters from all the
rules in the policy are arranged in order from most specific to least specific when
processed by the IPSec driver. (This is similar to the behavior of a router matching
packets against its route table.) Each filter is assigned a weight value, and of the filters
which match a given packet, that filter with the highest weight value (i.e., the most
specific filter) is the one which will be matched.
You can see all the filters being enforced by the IPSec driver using the IP Security
Monitor MMC snap-in. In the snap-in, navigate to the Quick Mode > Specific Filters
container and sort the lines on the Weight column in descending order. From top to
bottom, this is the order in which packets are compared against loaded filters; the first
filter which matches a packet is the one that wins, and the action associated with that
filter is what determines what the IPSec driver will do with that packet.
+.E!l&l
__ ' -1aj XI
._
_I_ ---
_I Coma e Root v - 1 :y;oI I Action { Direction 1 Weight 1-1
~ri8 IP secur ty
lonitor Ferrnit Inbound 34603269
EJ @ GIMANTIS 443 TCP Permit Inbound 34603269
80 TCP Permit Inbound 34603269 ,
El Any TCP Permit Outbound 34603266
8 34603266
Any TCP Permit Outbound
Any TCP Permit Outbound 34603266
Any TCP Permit Outbound 34603266
Any Any Block Inbound 34603009
Any Block Inbound 34603009 I
SANS Institute
IPSec. RADIUS, Wireless, and VPNs 75
Note that if a packet matches two filters because they both specify a range of IP addresses
in which the packet falls, the range defined with the greater number of subnet mask bits is
the filter which will win. Also, tunnel mode filters always take precedence over transport
mode filters.
However, it is still possible for two filters in two different rules to be equally specific.
When this occurs, the filter associated with the more restrictive action is the filter (and
rule) which takes precedence; for example, two rules with equally specific filters might
select the same packet, but the rule which blocks that packet takes precedence over the
rule which only encrypts it, because blocking is more restrictive than encrypting.
If you received a CD-ROM with this courseware, then the IPSec folder on the CD will
contain a file named IPSec-Order-of-Specificity.csv which lists the relative weightings
of the various criteria that a packet can match (highest weight at the top, smallest weight
at the bottom). Double-click this file to open it in Excel.
S
Some exemptions are built into the IPSec driver by default which causes the driver to
simply ignore certain types of traffic, such as broadcast and multicast; however, a registry
value can be set (NoDefaultExempt) which changes this behavior (KB8 11832,
KB8 10207). Windows 2000 requires SP 1 or later to enable this registry value, and note
that SP4 and later changes this to a value of 1. Windows X P supports the value by
default, but SP2 will automatically change it to 1. Windows Server 2003 and later
support the value by default and it is set to 3 by default (create the value to change it to
something else).

Key: \SY STEM\Cune%ControlSet\Services\IPSEC
Value Name: NoDefaultExempt
Value Data: 0, 1 , 2 or 3 (depending on operating system)
Windows 2000: 0 or 1 possible with SP 1, 0 by default, 1 by default with SP4.

Windows XP: 0 or 1 possible, 0 by default, 1 by default with SP2.
2003 and Later: 0, 1 , 2 or 3 possible, 3 by default.
Value 0: Multicast, broadcast, RSVP, Kerberos and IKE are exempt.

Value 1: Multicast, broadcast and IKE are exempt.
Value 2: RSVP, Kerberos and IKE are exempt.
Value 3: Only IKE is exempt.
Note that Windows 2000/XP cannot be configured to not exempt broadcast or multicast
traffic. And IKE can never be made not exempt too. If you wish to block IKE, it must be
done with a firewall or some other filtering capability.
SANS Institute
It is mandatory to set this value to 1 on 2000/XP and either 1 or 3 on Windows Server

2003 and later. This importance is highlighted by Microsoft’s decision to set these values
automatically with Service Packs despite the interoperability problems that may arise.
The problem is that attackers can send malicious packets with any source port they wish,
including the well-known port for Kerberos (UDP/TCP 88). Any defender relying on
IPSec packet filtering could be compromised with this trick (perhaps using FPIPE.EXE
fiom http://www.foundstone.com). It is also possible to send malicious broadcast
packets, hence, the value should be set to 3 on Windows Server 2003 and later.
Once these more-secure values are set, keep in mind that your IPSec policies will have to
take into account these once-exempted protocols when you wish to maintain functionality
(KB254949, KB253 169).
Best Practices
17 Mandatory (IPSec): Set the NoDefaultExempt registry value to 1 on Windows
2000/XP and to 1 or 3 on Windows Server 2003 and later (KB811832). These values are
set automatically with SP4 for Windows 2000, SP2 for XP, and is set to 3 on Windows
Server 2003 and later by default. This value determines, among other things, whether
Kerberos traffic is exempt from IPSec filters.
17 Recommended (IPSec): Ideally, your physical network topology should reflect the
security requirements of the hosts on each segment. Each segment will have a different
IP subnet number, and endpoints can then be keyed to these subnets. This will have
other security benefits related to switches, routers and internal firewalls.
17 Recommended (IPSec): Disable NetBlOS when possible. Remember that IPSec

does not apply to broadcast traffic, including NetBlOS broadcast traffic, and a lot of
reconnaissance information can be sniffed from NetBlOS broadcasts. This
recommendation is especially important if you intend to use IPSec to secure your
wireless communications.
17 Recommended (IPSec): Be careful when assigning IPSec policies to infrastructure

servers such as DNS, WINS, and DHCP servers. Domain controllers should also be
carefully configured to avoid obstructing their Kerberos, LDAP, SMB and RPC traffic.
Consider exempting internal ICMP traffic for the sake of PMTU discovery and network
monitoring.
SANS Institute
- Configured through Group Policy to allow remote

backup and management traffic using IPSec.
Windows XP/2003 includes a basic built-in dynamic personal firewall which is simple to
configure, but lacks the flexibility of products like BlacMCE and ZoneAlarm. However,
the “Internet Connection Firewall” has been renamed to just “Windows Firewall” and has
been significantly enhanced in Windows XP Service Pack 2 and later. If for no other
reason, make sure to apply SP2 or later to install and enable the new Windows Firewall.
A Control Panel applet is added with SP2 for configuring the Windows Firewall, and it is
customizable through Group Policy and NETSH.EXE as well.
”. . ”.. - - ”
. . .
-1
I
I- - - --i
= I
The new Windows Firewall supports the following features:
SANS Institute
Enabled by default for all interfaces after SP2 or later is applied.
Dynamic packet filtering with global rules that apply to all interfaces and per-
interface rules to define exceptions/additions to the global rules. Different rules
can be assigned to communications occurring on the local subnet versus other
communications across a router. Multicast and broadcast packets can also be
filtered.
Special rules can be defined for applications by name. If not already configured,
a new application accessing the network will cause the user to be prompted
whether to allow the application to communicate or not.
Most firewall features can be managed remotely through Group Policy or the
NETSH.EXE command-line tool.
Most firewall features can be pre-configured as a part of the unattended

installation of the operating system using an unattended installation file.
Two sets of rules can be defined: one for when the computer is in contact with its
Domain Controllers and another when it is not. For example, a laptop computer
at home is more at risk than when it is in the office behind the main perimeter
firewall, hence, two different policies could be automatically enforced. Stand-
alone computers only have one set of rules. The computer automatically detects
whether it is connected to the domain and switches its rule set on the fly.
A special shielded mode (“Don’t Allow Exceptions” option) that will drop all
unsolicited incoming traffic, even if that traffic is normally permitted. This could
be enabled through Group Policy in an emergency while, for example, viius
scanners were being updated or other patches applied for zero-day exploits.
Automatic boot-time policy to allow DNS, DHCP and Domain Controller

communications during start-up to protect the machine between the POST and the
enforcement of its regular firewall policy.
Packet logging in detailed W3C format to a textual log file.
f
# s X i a r e Y Microsoft I n t e r n e t connecrion F i r e w a l l
#Time Format: L o c a l
# F i e l d s : date t i m e a c t i o n p r o t o c o l s r c - i p d s t - i p s r c - p o r t d s t - p o r t s i z e t c p f l a g s t c p s y n tcpack t c p w i n
2001-11-02 01 :48:4 6 DROP UOP 192.168.111.111 192.168.111.113 137 137 96 - - - - - - -
2 001-11-02 02 :00:4 7 DROP UDP 192.168.111.111 192.168.111.113 500 500 264 - - - - - - -
2001-11-02 02 :00 :48 DROP UDP 192.168.111.111 192.168.111.113 500 500 264 - - - - - - -
2 001-11-02 02 :11:3 5 DROP TC P 192.168.111.113 192.168.111.111 17664 48 68 UP 571293696 2147907721 28529
2001-11-02 02:12:49 DROP UDP 192.168.111.111 192.168.111.113 137 137 96 - - - - - - -
2 001-11-02 02 :12:51 DROP UDP 192.168.111.111 192.168.111.113 137 137 96 - - - - - - -
2 001-11-02 02 :13 :28 DROP TCP 192.168.111.111 192.168.111.113 1167 21 48 5 878133181 0 16384 - - -
2 001-11-02 02 :13 :31 DROP TCP 192.168.111.111 192.168.111.113 1167 21 48 5 878133181 0 16384 - - -
2001-11-02 02 :13 :37 DROP TCP 192.168.111.111 192.168.111.113 1167 21 48 5 878133181 0 16384 - - -
SANS Institute
The XP-SP2 and later Windows Firewall can be managed through Group Policy. The
following are the types of settings manageable through Group Policy:
Prohibit use of Windows Firewall (since it’s enabled by default)

Turn Windows Firewall on with “no exceptions” to its normal policy
Allow user preference/Group Policy settings to merge
Define allowed programs by pathname
Allow dynamically assigned ports for RPC and DCOM
Allow file and printer sharing
Configure ICMP filter settings
Allow remote assistance support
Allow UPnP framework to work
Prohibit notifications to users about transmitting applications
Enable logging and set logging options
Allow authenticated IPSec to bypass normal restrictions
Define custom open ports
For troubleshooting Windows Firewall problems, see KB875357. In particular, you may
have problems with DCOM and WMI operations (KB875605).
ec ss
There is another Group Policy management option named “Allow Authenticated IPSec
Bypass” which is very important. This option permits unsolicited in-bound connections
if they are secured with IPSec. You can limit which remote computers are permitted
through the firewall by defining a custom group of computer accounts and only allowing
the IPSec-bypass feature for that group, e.g., for remote management and backup
computers. When an IPSec policy is assigned, the Windows Firewall automatically
allows in-coming UDP 500 and 4500 packets for the sake of IPSec session establishment.
SANS institute
IPSec Policy Objects ("IPSec Policies") define all the options necessary to implement
IPSec on a computer: filters, authentication methods, ciphers, key lengths, key
refreshment parameters, SA lifetimes, etc.. When an IPSec Policy is "assigned" to a
computer, that computer's IPSec settings will be configured with the Policy.
Tree 1 Favorites 1 blame I Policy Assigned I

11-7 Console Root @j Client (Respond L7nlyj No
Secure Server (Require Security) No

@Server (Request Security)
IPSec Policies are nimble in that they can be configured to secure very narrowly-defined
types of traffic. For example, a Policy might require IPSec security only for packets with
a particular source IP address, destination address, protocol type and/or destination port.
This same port- and address-sensitivity can be used for static packet filtering.
A Windows computer does not have to be a member of a domain to use IPSec. IPSec
Policies can be created and stored locally, or Policies can be distributed through Active
Directory and Group Policy.
SANS Institute
i
YO ic
Group Policy is the mechanism for IPSec Policy distribution. The flexibility of Group
Policy allows for flexible assignment of different IPSec Policies to different sets of
computers (see below). Once an IPSec Policy is defined, Group Policy can be used to
automatically push it out to systems.
The IPSec Policy Agent implements the IKE protocol. It is what retrieves, interprets and
enforces IPSec Policy on the computer. The Agent is a service listed in the Services
applet. It is implemented as part of the Local Security Authority (1sass.exe).
%iInternet Connection Sharing Provides nebmrk a,,.
Kerberos Key Distribution Center Generates session k.. Started Automabc

License Logging Service Started Automabc
Loaical Disk Manaaer Loaical Disk Manaae.,, Started Automabc
The screenshot above is from a Windows 2000 system. On Windows XP and later, this
service has been renamed to "IPSec Services".
If the computer is a member of a domain, the Policy Agent will retrieve the domain IPSec
Policy through Group Policy and write it to the registry, where it is cached. An IPSec
Policy obtained through Group Policy will overwrite any IPSec Policy stored in the
registry, no matter where the Policy originally came from in the past (another Group
Policy or a locally-created one). Cached Policy will continue to be used even if a domain
controller cannot be contacted.
If the computer is not a member of a domain, the Policy Agent will still retrieve the
assigned IPSec Policy from the registry. But, in this case, the IPSec Policies must be
created and stored in the registry on the computer by hand with an MMC snap-in or a
command-line tool for IPSec.
IPSec Policy information, whether assigned locally or through Group Policy, is stored in
the registry under the following key:
Hive: HKEY LOCALMACHINE

Key: \SOFTWAREZ\Policies\Microsoft\Windows\IPSec
SANS Institute
Cached IPSec Policy information is refreshed at startup, at the default Winlogon polling
interval, and at the interval defined in Group Policy for IPSec (discussed later).
Restarting this service will reinitialize the IPSec Driver, clears all SAs, and forces a fresh
injection of Policy into the IPSec Agent. This is a common method of troubleshooting.
It is also possible to directly inject IPSec Policies from the command-line with
1PSECPOL.EXE or 1PSECCMD.EXE (discussed later in detail).
The Agent will use the IPSec Policies it retrieves to configure the IPSec Driver. The
IPSec Driver (ipsecsys) uses the Filters and Filter Actions defined in the Policy assigned
to it to manage packet flow. The Policy Agent is the manager, while the IPSec Driver
does the actual work of handling packets.
The IPSec Driver compares outgoing packets against the Filters from the IPSec Policy to
determine whether a Filter Action should be triggered, i.e., whether AH/ESP is required.
The Driver maintains the Security Association Database (SADB). If an outgoing packet
requires AH/ESP processing, the Driver will see if the necessary SA already exists in the
SADB. If the SA does not exist, then the Driver will carry out a Phase I1 negotiation with
the target to create one. Phase I1 negotiations require a previously-completed Phase I
negotiation to establish the ISAKMP-I= SA; if this SA does not exist with the target,
the Policy Agent will conduct a Phase I negotiation for the Driver.
Incoming IPSec packets are identified by the Security Parameter Index (SPI) number in
the IPSec header. The Driver will use the incoming packet's SPI (and other information)
to look up the correct SA in the SADB in order to decrypt, authenticate and check the
integrity of the packet. If all goes well, the packet is handed off to the regular TCP/IP
driver as though it had been received from the wire in the clear. This is how transparency
to applications and services is maintained.
PSec Policy Objects

IPSec Policies are created with the 1P Security Management snap-in. Policies are stored
either in the local registry or in Active Directory, depending on the storage location
selected when the snap-in is added to a MMC.
An IPSec Policy is not active on a computer until it has been "assigned" to the computer.
Only one Policy can be assigned at a time, regardless of whether the Policy is local or has
been distributed with Group Policy (discussed later).
To create an IPSec Policy in Active Directory, right-click on the IP Security Policies On

Active Directory snap-in > Create IP Security Policy. This launches a Wizard which will
walk you through the process. (To create the snap-in, see above.) The parts of an
IPSec Policy will be described below.
SANS Institute
Cerbficabon Authority (Local)
re
/
Sec Policy, it will open it. An bject has two tabs
i
on its property sheet:
General tab = Phase I settings.
Rules tab = Phase 11 settings.
The General tab contains settings for Phase I or "Main Mode" negotiations (see below).
The Rules tab contains settings for Phase I1 negotiations (see below). These Phase I1 or
"Quick Mode" negotiations are governed by one or more Rules.
ici
There are three built-in IPSec Policies and Filter Actions that can be customized or used
as models:
Client Policy (Filter Action: Respond Only)
Server Policy (Filter Action: Request Security)
Secure Server Policy (Filter Action: Require Security)
SANS Institute
The "Client (Respond Only)" Policy will cause the computer to never use IPSec security
except when it is requested by the other host. Hence, computers with this Policy assigned
will send plaintext packets except when connecting to servers that requesthequire IPSec
security. The only Rule this Policy uses is the "Default Response" Rule, which has no
Filter or Filter Actions, but only a list of preferred AH/ESP negotiation settings with
which to respond to negotiation requests. You must assign a Policy with at least the
Default Response Rule to activate IPSec on the computer at all.
The "Server (Request Security)" Policy will cause the computer to always request IPSec
security for non-ICMP packets, but it will accept plaintext transmissions if the other host
does not support IPSec. This is the "fail open" or "fail to cleartext" Policy.
The "Secure Server (Require Security)" Policy will only send non-ICMP packets when
those packets are secured with IPSec. Hence, the other host must support IPSec or else
sessions will fail.
Tip: It is better to not use the three built-in Policies themselves. Instead, make
new Policies, even if the new Policies have the exact same settings. This will
avoid problems related to duplicate GUID numbers when backing up, restoring or
otherwise working with the Policies, especially in a multi-domain environment
(KB232817).
SANS Institute
- 5 i f f i ~ - ~ ~ l l mGroups
an
- D E S vs. 3 5 E S
The General tab of an IPSec Policy configures Phase I negotiation parameters.
]Note Do NOT rernobJe the PFS requirement1

1
The IPSec Policy Agent will check for updated Policies at the interval specified on the
General tab from Group Policy. The policy change interval should be lowered to 60
minutes so that Group Policy-assigned settings will be activated more quickly. Locally-
assigned settings take effect immediately.
SANS Institute
The Name and Description boxes can be useful for reducing administrative chaos by
describing exactly what the Policy does, what domains/OUs it is intended for, and
perhaps the name of the administrator responsible for it.
Clicking the Advanced button reveals IKE Phase I negotiation settings.
ect (Po1icy:General Tab:Advanced Button)

The Phase I master key secures the exchange of keys negotiated in Phase 11. The master
key is ultimately derived from the Diffie-Hellman exchange which occurs in Phase 1.
By default, when a new Phase I master key is needed, it is generated from the prior
master key after a specified number of minutes or sessions (as defined in the dialog box).
However, the new master key is generated using a deterministic method such that, should
one master key be compromised, subsequent keys can be compromised. This behavior is
the default because it is more efficient, but it is not more secure.
On the other hand, when "Master Key Perfect Forward Secrecy" (PFS) is enabled, a new
Phase I master key will be created from scratch with each new Phase I negotiation. This
enhances security since the loss of one master key will not entail the loss of any others.
But, again, this will not be as efficient because a complete reauthentication of the peers is
required whenever a renegotiation takes place.
Master key PFS does not have to be required on both peers: either peer can require it
from the other.
Note: Enabling master key PFS will cause the session key limits (discussed later)
to be ignored. When a new master key must be created, it resets all SAs. On the
other hand, a session key refresh limit of 1 has the same end result as enabling
master key PFS.
ase I Security s (Po1icy:General:Advanced:Methods)

To customize the Phase I negotiation, click the Methods button.
SANS Institute
i
The most important option here is the Diffie-Hellman "group". A DH group determines
the length of the prime numbers used during DH exchanges in Phase I. The larger the
prime number, the more secure the encryption. The Low( 1) group uses a 768-bit prime
number, while the Medium(2) group uses a 1024-bit prime. Two peers must support a
common DH group level in order to communicate. Even without the High Encryption
Pack installed, though, a Windows peer can support Medium(2) 1024-bit primes, so
always require this or better. Click the Edit button to change the setting unless there are
third-party peers you must interoperate with that do not support 1024-bit primes.
The DES or 3DES key here is only used to encrypt the identity of the computers or
routers communicating, not user data and not peer identities. Hence, it is not critical to
require 3DES here, but should be enabled anyway. Note that if Kerberos is the
negotiated authentication method (discussed later) then the identity of the peers is sent in
cleartext anyway. On the other hand, if 3DES is required in Phase I1 for data encryption,
then it makes sense to require it here in Phase I as well.
A Windows 2000 peer must have the High Encryption Pack installed in order to support
3DES. The HEP is included with Service Pack 2 and later, and it is built into Windows
XP and later by default. If a peer lacks High Encryption support, but 3DES is required,
the IPSec session will fail.
For the hashing algorithm, always choose SHA- 1 or better. Never use MD5.
SANS Institute
An IPSec Policy contains one or more I'RulesII on the Rules tab of an IPSec Policy.
A Rule defines authentication methods, encryption key lengths, IPSec tunnel mode
addresses, the connection types to which the Rule applies (VPN or LAN) and the
selectors which determine exactly which packets should be secured. Configuring IPSec
is largely a matter of configuring Rules.
A Rule is active if the box next to it is checked. If multiple Rules are checked, they are
not ranked in an order of preference. Instead, the "Filters" fiom each rule are prioritized
in order of specificity (see below) and all the Rules are applied simultaneously. If you
open a command-prompt window and execute " n e t d i a g / t e s t : i p s e c /debug"
you will see the sum total of these Rules as the IPSec Policy Agent understands them.
Selecting a Rule and clicking Edit will expose its property sheet.
0 Recommended (IPSec: General): In Windows 2000/XP/2003, a Policy can have

multiple Rules enabled in it. Instead of creating a single Rule with a very complex Filter
List, create multiple Rules with relatively simple Filter Lists. Give each a descriptive
name. This will give you more manageable granularity and the IPSec Policy will be
easier to understand.
SANS Institute
matches a Filter, the

packet triggers the
RuI e’s “Action”.
- This is how and when
a Rule gets enforced
by the IPSec driver.
A Rule’s IP Filter List defines which packets should trigger the Rule’s Filter Action. That
is the critically important connection between these two tabs: If a packet’s characteristics
match a Filter List in a Rule, then that Rule’s Filter Action will be applied to the packet.
SANS Institute
Only one Filter List can be activated in a Rule, even if more are available or visible in the
dialog box (notice the radiobuttons instead of checkboxes).
Note: What Microsoft calls a "Filter", all the rest of the world calls a "selector",
including the RFCs for IPSec, so, "Filter" = Selector.
You can click the Add button to create a new Filter List, but these Filter Lists actually
exist separately from any Rule. Indeed, a single Filter List can be referenced in multiple
Rules, just like a Group Policy Object can be linked to multiple OUs. Filter Lists can be
managed separately from any Rule as well, just like Group Policy Objects can be
managed separately from any OU, site or domain.
To manage Filters stored in Active Directory, right-click the "IP Security Policies On
Active Directory" snap-in > Manage IP Filter Lists and Filter Actions > Manage IP Filter
Lists tab (left-hand dialog box). Select a Filter List > Edit (right-hand dialog box).
Creating a Filter in a Filter List

An IPSec Filter List is composed of one or more "Filters". A Filter can match packets
based on any of the following criteria:
Source IP address: "my", "any", specific address, hostname, or subnet.
Destination IP address: tcmyrr, "any", specific address, hostname, or subnet.
Source port: TCP or UDP.
Destination port: TCP or UDP.
Protocol type: TCP, UDP, protocol type number, etc..
i
From the right-hand screenshot above, select a Filter > Edit (or click Add). The following
screenshots show the property sheet of a Filter in a Filter List. Select the source and/or
destination IP address(es), protocol type, and port number which this Filter should match.
SANS Institute
0 re s
If a Filter is "Mirrored", then the Filter matches packets with the Source and Destination
addresses specified plus the opposite Source and Destination addresses as well. This
includes port numbers as well. For example, if the following Filter is mirrored:
I
i Source: 191.122.13.7
Destination: 10.". *.*
then the mirror of the above would be:
Source: lo.*.*.*
Destination: 191.122.13.7
Mirroring your Filters is generally a good iwa since it simplifies Rule design.
When using NETDIAG.EXE to debug IPSec, you will see I t - - M i r r o r " after each
entry that was automatically created because a Filter was mirrored.
se
Note that there is a special Rule called the "Default Response" Rule which does not
include Filters or Filter Actions. This Rule only exists to respond to other hosts when
they requesthequire IPSec from the local machine. This Rule does not request or require
IPSec from other computers. The Default Response Rule is always included in Policies;
the only choice is whether it is activated or not. Hence, when you examine the property
sheet of the Default Response Rule you will not see the IP Filters List tab.
mended (IPSec: Filter Lists): In Windows 2000/XP/2003, try to specify only

IP addresses in Filters, not protocol types or port numbers. For IP addresses, prefer to
SANS Institute
use “Any IP Address” and subnets instead of “My IP Address” or large numbers of
individual addresses. Prefer “Any<->Subnet” Filters over “Any<->Any” Filters, especially
on laptops and Windows 2000 systems. In general, try to simplify the Filters as much as
possible to optimize performance. Another advantage of this is that you will not have to
predict or understand which protocols a client can use to access a server-- you can trust
that a//packets going between them will be secured no matter what new application or
service is installed. This is particularly important for RPC-based services. (This can also
help to avoid problems related to incompatible authentication methods.) It is feasible to
have 500 mirrored Filters in a Filter List on a high-end machine, but the fewer Filters the
better.
17 Recommended (IPSec: Filter Lists): In Windows 2000/XP/2003, mirror your Filters

whenever possible. Problems can arise if traffic is secured going in one direction (A +
B) but not in the other (A t B). Mirroring also makes complex Filter Lists easier to
understand.
17 Recommended (IPSec: Filter Lists): In Windows 2000/XP/2003, use the Name and
Description fields in a Filter List to reduce misunderstandings. Be explicit in what the
Filter List covers. Don‘t customize standard Filter Lists that have been in use a long time;
instead, create a new Filter List with your modification so that it will be clear to others that
it is different. Consider defining a collection of standardized Filter Lists in your
organization in a whitepaper or policy document, and devise a consistent naming
standard.
SANS Institute
A Filter Action is what gets triggered when a packet matches a Filter List in a Rule. The
Filter Action will be one of the following:
Permit -- Forward the packet unchanged and unsecured.
Block -- Drop the packet.
Negotiate -- Conduct a Phase I1 negotiation for AH and ESP parameters.
Each Rule can have only a single Filter Action activated.
None of the Filter Actions have precedence over any other when two Rules with identical
Filter Lists have conflicting Filter Actions. As discussed above, Filter Lists are processed
in order from most-specific to least-specific, and, when a packet matches a Filter, that
Filter's corresponding Action is triggered. Hence, use the specificity of Filter Lists to
implement an order of precedence to resolve conflicts between Filter Actions.
For example, Permit can be used in combination with Block to create a "Deny All
Except.. . I ' Policy which will Block all packets coming to/from your webserver, except
those related to HTTP on TCP port 80. To do this, create a new Policy with the
following two Rules:
SANS Institute
#2 Source IP:Any, Dest IP:Any, Protocol:Any, Block

Source Ports:Any, Dest Ports:Any, Mirrored:Yes
Because the Filter List in the Rule which Permits access to the webserver is more specific
than the one for Blocking, the Permit Rule (#1) will take precedence over the Blocking
Rule (#2). Note that AH/ESP is not used at all; this example just does packet filtering.
Creating Filter
Filter Actions can be built and managed separately from any particular Policy, just like
Filter Lists can be managed separately.
To manage Filter Actions stored in Active Directory, right-click the IP Security Policies On
Active Directory snap-in > Manage IP Filter Lists and Filter Actions > Manage Filter
Actions tab (left-hand dialog box). Select a Filter Action > Edit (right-hand dialog box).
Alternatively, a new Filter Action can be created simply by clicking the Add button on
the Filter Action tab in the Rule.
If Negotiate is the Filter Action, then one or more Security Methods will define what is
negotiated in Phase 11. A Security Method is a collection of AH/ESP settings. Each
Method constitutes an "offerf'that a peer will present to another peer during Phase I1
negotiations. Each peer will compare the offers of the other, from top to bottom, until a
mutually-acceptable collection of AH/ESP settings are found. (Hence, there is an order
of precedence here.) These settings will then be used to secure the packet(s) which
matched the Filter List which triggered the Filter Action in the first place.
While there are built-in Security Methods ("High" and "Medium"), it is always better to
define your own custom Methods so that you'll know exactly what IPSec settings your
computer is offering and accepting.
SANS Institute
!
To create a custom Security Method in a Filter Action, right-click the "IP Security Policies"
snap-in > Manage IP Filter Lists and Filter Actions > Manage Filter Actions tab > Add >
select the Negotiate Security radiobutton > Add > select Custom > Settings button >
uncheck the top box for AH > check the middle box for ESP > select SHAl for the
Integrity Algorithm > select 3DES for the encryption algorithm > check both boxes to
"Generate a new key every.. ." and set them to I00000 Kbytes (1OOMBs) and 900
seconds (15 minutes) > OK > OK > check the box for "Session key Perfect Forward
Secrecy" > General tab > set the Name to "Best ESP Only" > OK > OK > Close.
portant: 168-bit 3DES encryption is not supported in Windows 2000 unless

the High Encryption Pack or Service Pack 2 or later has been applied. If one peer
requires only 3DES and the other does not support it, the session will fail. The
default is to attempt 3DES, but then fall back to plain 56-bit DES if regular DES
is listed as an acceptable security method after 3DES on both peers. Hence, if
you want 3DES only, ensure that only 3DES is listed as an acceptable cipher -- do
not merely give it a higher preference-- and remove DES entirely.
portant: The 2048-bit DH group size is only available if the NegotiateDH2048

value under HKLM\SYSTEM\CurrentControlSet\Services\ RasMan\Parameters\
is set equal to one. Windows 2000/XP also requires a special patch (KB8 18043).
Windows Vista and later includes built-in support for 128/192/256-bit AES too.
On the property sheet of a Filter Action, the middle checkbox to "Allow u

CQ uters" will permit unsecured non-IPSec
sessions with other hosts if the other host fails to respond to IPSec negotiation requests.
Your system will attempt to negotiate IPSec if one of its Filters is triggered, but if the
other system does not support IPSec, your computer will resume cleartext norma1
communications if this box is checked. This is the "fail open" option. However, if the
other computer supports IPSec, but its negotiation policies are incompatible, then
SANS Institute
communications will fail even if this box is checked. Once IPSec Phase I negotiations
begin to proceed, then there's no going back to cleartext, even if this box is checked.
However, while pre-Vista IPSec policies can be configured to request IPSec instead of
requiring it like this, there is often a two-second delay before the initiator would give up
on negotiating IPSec and fall back to plaintext traffic. Users can find this two-second
delay annoying. With Vista and later, if IPSec is merely preferred instead of required, the
initiator sends both the plaintext traffic and the IKE requests simultaneously at the
beginning of the connection, whereupon the plaintext traffic continues unimpeded until
an IPSec session is established, if possible, and then that traffic is automatically switched
to the IPSec channel instead without interruption. This should help to avoid annoying
users.
The top checkbox to "Accept unsecured communication, but always respond using
IPSec" is more complicated. Outgoing packets from the local computer which are
covered by a Filter will trigger IPSec no matter how this checkbox is set. This checkbox
only affects how the local host will respond to incoming non-IPSec packets initiated by
others when a response would be covered by a local IPSec Filter.
If this box is not checked, the local computer will not respond in any way to
requests for services whose packets are covered by an IPSec Filter which requires
security. If this box is checked, then the local box will attempt to negotiate IPSec with
the remote host initiating contact, but if that remote host does not support IPSec,
communications will fail.
Said another way, if the checkbox is unchecked, the local host will (rudely) ignore
non-IPSec-secured packets which request responses that would have to be IPSec-secured.
If the checkbox is checked, the local host will (kindly) attempt to negotiate IPSec, but,
failing that, will terminate communications.
If a server is not configured with this option, then all clients must have their
Filters configured to initiate with IPSec, not merely to respond to requests for it. It is
generally best to check this box on intranet servers, but to leave it unchecked when the
server is attached to untrusted networks like the Internet. It is not the case that anything
normally secured will somehow become unsecured if this box checked, but you don't
want port scanning to make your server respond with IPSec requests either.
The option for "Session Key Perfect Forward Secrecy"will prevent the reuse of keying
material for generating new encryption keys for Phase I1 SAs. When a Phase I1 SA is
initially negotiated, session encryption keys are also created. As new keys are needed for
the SA over time, the new keys can be generated from the old keys. This is fast and
efficient, but if the original keys become compromised, an attacker can generate the new
keys based on them, and the later keys based on those, and so on. Perfect Forward
Secrecy (PFS) prevents this "weak link in the chain" vulnerability. With session key
PFS, all new Phase I1 SA encryption keys will be freshly negotiated. With PFS, the
SANS Institute
i
compromise of one session key will not cause the cornpromise of all subsequent session
keys. PFS is a way of limiting the damage caused by a single compromised key.
ote: Session key PFS must be enabled on both the local and remote IPSec
peers; otherwise, IPSec will fail to negotiate a Phase I1 SA (Security Methods are
not the only items that must be agreed upon by IPSec peers).
Tip: PFS details can be implemented differently by different vendors. Try

disabling session key PFS when troubleshooting interoperability with non-
Windows peers.
es ices
andatory (IPSec: Filter Actions): In Windows 2000/XP/2003, be very cautious

when choosing to "Allow unsecured communication with non-IPSec-aware computers".
This can defeat the point of using IPSec in the first place. This is the "fail open" option,
i.e., fail to cleartext. This option may be required, however, in a mixed environment
where backwards compatibility must be maintained.
andatory (IPSec: Filter Actions): In Windows 2000/XP/2003, on an intranet, it is

generally safe to enable "Accept unsecured communication, but always respond using
IPSec". However, on Internet-accessible peers, do not check this box and try to restrict
the IP addresses which are permitted to access UDP ports 500 and 4500.
Recommended (IPSec: Filter Actions): Be mindful that Filter Lists are processed in
order from most-specific to least-specific. This is what determines which Rule's Filter
Action is triggered. Use this to create "Deny All Except..." rules, but beware of the
potential complexity.
0 Recommended (IPSec: Filter Actions): As described in KB818043, 2048-bit Diffie

Hellman support requires a registry value change and, on Windows 2000/XP, the
installation of a patch. 2048-bit DH groups should be used in high security environments.
0 Paranoid (IPSec: Filter Actions): In Windows 2000/XP/2003, the most secure

settings are 3DES only, SHA-1 hashing, certificate authentication, Perfect Forward
Secrecy, no default filter exemptions, tunnel mode only, and extremely frequent rekeying.
That being said, the performance penalties and management hassles these settings will
entail would only make sense in the most paranoid of environments. You must balance
security, performance and manageability.
SANS Institute
Human Users
The authentication methods supported by an IPSec Policy control how the computer
authenticates to the other peer during Phase I1 negotiations. In Windows Vista and later,
IPSec can also be used to authenticate users.
Multiple authentication methods can be enabled simultaneously. There are three

authentication methods available:
Kerberos
Certificate
Preshared Key
SANS Institute
The authentication methods are attempted in the order shown on the property sheet, from
top to bottom. The first method acceptable to both peers is used. If two peers do not
have at least one common authentication method, the authentication will fail. Once a
mutually agreed-upon method fails, the next method in the list is not attempted. Hence, a
peer only gets one shot at authentication.
For example, if a remote peer is configured with both Kerberos and certificate
authentication, in that order, and the RRAS server is configured with both Kerberos and
certificate authentication in that order, and both sides have mutually-acceptable
certificates, then authentication will still fail because the remote peer cannot reach the
domain controller for Kerberos.
The solution is for both peers to be configured to support certificate authentication first,
Kerberos second. This is the best solution because there will likely be many internal
LAN clients that only use Kerberos and they will still be supported. If any peer has a
certificate, such as a remote or foreign-domain peer, then it will work too.
os ica
Every Windows computer has a computer account in Active Directory. The computer
uses this account to authenticate to the domain when it starts up. This same account is
used with IPSec Kerberos authentication. Importantly, this is authentication of the
computer, not the user sitting at it.
ote: The identity of the computer is not encrypted if Kerberos authentication is

used. To always hide the identity of the computer, use preshared key or
certificate authentication.
Keep in mind that for Kerberos authentication to work, the IPSec peers must be in the
same or trusted domains, and each peer must be able to contact a domain controller.
Hence, Kerberos authentication is not appropriate for remote access scenarios.
Peers can be mutually authenticated with their machine certificates. To be successfully

authenticated, the issuer of each computer's certificate must be trusted by the other IPSec
peer, and that is all that is required. It is not the case that an IPSec peer must have a copy
of the other peer's certificate beforehand, or know any of the details of the certificate's
credentials.
The certificate can be issued by a Microsoft, Netscape, Entrust, VeriSign or any other
CA. There are no special requirements for the X.509~3certificate itself other than the
standard validity and integrity checks.
ote: If you have multiple certificate authentication methods (i.e., multiple CAS
listed) then put them all in a contiguous row in the dialog box. Don't have a
SANS Institute
certificate authentication method followed by a Kerberos or pre-shared key

method, and then another certificate authentication method after that.
A Windows peer must have the certificate of the issuing Certification Authority (CA) of
its own IPSec certificate and the other peer's certificate in its personal Trusted Root CA
Store. This is the "personal store" of the computer itself, not the human sitting at it. Use
Group Policy to distribute trusted CA certificates automatically (as discussed in the PKI
seminar).
A Windows computer can obtain an IPSec certificate through auto-enrollment from a

Windows Enterprise CA. An alternative is to manually request and install the certificate
with the Certificates snap-in or the Certificate Services Website. Manual installation
requires administrative rights at the system.
Note: The Windows Resource Kit includes a utility to add support for Cisco's
Simple Certificate Enrollment Protocol (SCEP). This enables a Windows CA to
distribute IPSec certificates to Cisco routers for certificate authentication as well.
Certificate authentication is appropriate when the other peer does not support Kerberos,
domain controllers cannot be accessed for Kerberos authentication, the other host is not
in a trusted domain, or L2TP is in use. L2TP uses certificate authentication by default.
Certificate Revocation Checking

The IPSec Driver does not perform certificate revocation checking by default. A
certificate is "revoked" if it is on the list of revoked certificates its issuing CA publishes.
A certificate might be revoked if its private key (or the private key of the CA) have been
compromised. Hence, for maximum security, you should enable certificate revocation
checking by setting the following registry value, but beware of performance penalties and
hassles caused by configuration mistakes:

Key: \SYSTEM\CurrentControlSet\Services~olicyAgent\Oakley
Value Name: StrongCrlCheck
ValueType: REG DWORD
Value Data: 1 or 5(select "Hex" as the Radix)
1: Normal CRL checking in which the check fails only if

a CRL is successfully obtained and the certificate is on it.
2: Strong CRL checking in which any error whatsoever in

the download or processing of the CRL returns a failure,
including finding that the certificate is on the CRL. f
A certificate will include a CRL Distribution Point (CDP) field which lists the URLs
where the certificate's CRL can be obtained. The IPSec peer performing the revocation
checking must be able to access one or more of these URLs.
SANS Institute
ic
The "preshared key" is actually just a passphrase. The passphrase is protected during
Phase I1 negotiation by the master key derived in Phase I. However, the passphrase is
stored unencrypted in the IPSec Policy in both Active Directory and in the local registry.
The registry stores the passphrase in a value named "ipsecData" in a key under
HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA {xxxxxx
, where the "xxx"number is the GUID for the IPSec policy
xx-xxxx-xxxx-xxxx-xxxxxxxxx}
object itself. The permissions on these keys allow the local Users group read access.
mportant: If an adversary obtains a certificate or knows the preshared key, this

only permits the adversary to open his or her own IPSec channel to your peer.
The adversary cannot decrypt other captured sessions with this information
because the Diffie-Hellman exchange with each session is unique.
Support for preshared key authentication is included only for RFC compliance, for testing
purposes, or when security is not an issue. More than a few steps are required to
configure it (IU3240262). Kerberos or certificate authentication should always be used
on production servers instead.
SANS Institute
- IPSec tunnel mode. - LAN interfaces

- Only for RFC compliance. - Remote Access interfaces
Each tunnel end-point

has its own IP address.
Tunnel settings and connection types can be explained very quickly.
s (Policy:Rules:Edit:Tunnel Settings Tab)

IPSec tunnel mode is enabled by specifying a destination IP address on the Tunnel
Settings tab.
IPSec can operate in transport mode or tunnel mode. In transport mode, only part of the
packet is protected. In tunnel mode, the entire packet is encapsulated and protected. In
tunnel mode, a new IP layer is added to the front of the packet. This new IP layer
requires a destination address: the address of the IPSec peer or router that can extract the
original packet. This is the address entered on the Tunnel Settings tab.
IPSec tunnel mode is supported on Windows strictly for RFC compliance, but it is not
Microsoft's preferred solution and its configuration tools/options are very sparse. Tunnel
mode should only be used when the other peer does not support L2TP.
Tunnel Filters can only specify IP addresses, not ports or protocol types (Kl3248983).
And tunnel mode can only be used for router-to-router connections, not client-to-client or
client-to-router scenarios. Hence, it cannot be used for secure remote access for roaming
users. Again, L2TP is the intended solution.
Article Kl3252735 describes how to configure a pure IPSec router-to-router tunnel with
RRAS. Because this is not the preferred solution for tunneling packets on Windows, the
SANS Institute
steps will not be detailed here. Instead, the configuration of L2TP and PPTP will be
discussed later.
ec e (Po1icy:Rules:Edit:Connection Type Tab)

A Rule can apply to LAN interfaces, remote access (dial-up or VPN) interfaces, or both.
This is a useful feature for RRAS servers. An OU of RRAS servers providing VPN
access could have an IPSec Policy which tightly controls the packets of the remote users
(PPTP or L2TP) while still permitting full access to the RRAS servers from the LAN.
On a client, an IPSec Policy could use LAN-only Rules to enforce AH/ESP, while
permitting cleartext through dial-up connections (as an example).
SANS Institute
104 IPSec. RADIUS, Wireless, and VPNs
The wizards and graphical tools that Microsoft provides for creating individual IPSec
policies are nice, but they don't help you when you need to configure IPSec settings on
thousands of systems. Nor do they help you manage IPSec from the command line when
you need to script custom solutions. In this section we'll talk about how to push out
IPSec settings through Group Policy and the available command-line IPSec tools.
SANS Institute
How do you scale out management of IPSec and firewall policies to thousands of
computers? Group Policy of course! And for your stand-alone systems, you can write a
batch script to manage IPSec and firewall policies on them too. Not only Windows Vista
and later, but also Windows XP/2003 can have their IPSec and firewall settings managed
through Group Policy and/or custom scripts.
IPSec policies can be exported and imported. On Vista and later, the IPSec and firewall
policies are exportedimported together in one file. In Windows 2000/XP/2003, right-
click the "IP Security Policies" MMC snap-in > All Tasks > Import/Export Policies. In
Windows Vista/2008/7 and later, right-click the "Windows Firewall" snap-in >
Import/Export Policy. In either case, you are saving or restoring settings from a file.
The ability to export and import policy files is important because you'll want to test your
IPSec and firewall policies in an isolated lab first, then you'll later import them into a
GPO for pilot testing and then eventually into another GPO for production deployment.
It is also a good idea to keep snapshots of your various IPSec and firewall policies for
recovery and audit reference.
Windows Firewall settings for Vista and later are located in a GPO under Computer
Configuration > Policies > Windows Settings > Security Settings > Windows Firewall
With Advanced Security.
SANS Institute
Windows Firewall settings for Windows XP/2003 are located in a GPO under Computer
Configuration > Policies > Administrative Templates > Networks > Network
Connections > Windows Firewall.
IPSec policies for Windows 2000/XP/2003 computers are located in a GPO under
Computer Configuration > Policies > Windows Settings > Security Settings > IP Security
Policies on Active Directory.
Note that all IPSec policies created in Active Directory for Windows 2000/XP/2003 will
be visible in the GPO, but only one of these IPSec Policies can be activated or "assigned"
at a time (notice the Assigned column). It is not the case that all visible policies will be
assigned.
ultiple Policies Via GPO

Recall that GPOs are applied in the following order: local, site, domain, and OUs from
outermost to innermost (mnemonic: LSD-OU). On Windows 2000/XP/2003, the last
GPO to be applied which assigns an IPSec Policy will replace and override any other
IPSec policies earlier in the GPO precedence order. So, an IPSec policy assigned at the
OU level will supplant any IPSec policy assigned at the domain, which will replace any
IPSec policy assigned at the site, which replaces the local, and so on. IPSec policies
assigned to the site, domain or OU are not merged on Windows 2000/XP/2003: the last
IPSec policy assigned while GPOs are being processed is the one and only IPSec policy
that becomes effective. There are no conflicts because only one IPSec policy wins in the
end, i.e., the last one applied wins. And if a local IPSec policy was assigned to a
machine, this local policy will be overwritten by the IPSec policy assigned from Group
Policy too.
If you use Group Policy to push out an IPSec policy to Windows 2000/XP/2003 and also
Windows Vista or later, that policy is accepted and enforced on all operating systems.
Windows Vista and later are backwards compatible with the older IPSec policies. But,
on Windows Vista and later, any additional IPSec policies configured through WFAS are
also accepted and enforced at the same time. If there is a conflict, the older Windows
2000/XP/2003 IPSec policies are evaluated first and then the WFAS IPSec Connection
Security Rules are evaluated afterwards.
Note: On way or another, though, if a Windows Firewall rule requires certain

traffic to be secured with IPSec, it still has to be secured, but it doesn't matter
what triggered the IPSec negotiation process (an older Windows 2000/XP/2003
IPSec policy, a WFAS Connection Security Rule, or the firewall itself). And as a i
kicker, remember that dynamic mode IPSec settings are evaluated before any of
the static mode settings!
Another difference to note is that WFAS IPSec policies inherited from multiple GPOs are
all accepted, combined and enforced. In Windows 2000/XP/2003, the last IPSec policy
assigned through Group Policy is the only IPSec policy which gets enforced. This is no
SANS Institute
longer the case in Vista or later. If multiple GPOs apply to a Windows Vista box, for
example, and each GPO has different WFAS IPSec quick mode settings, then all the
applicable quick mode IPSec settings from all the inherited GPOs are combined and
enforced. If there are conflicts, then GPOs processed later will override conflicting
settings applied earlier. However, this merging of IPSec quick mode (Phase 11) settings
does not apply to the main mode (Phase I) settings. You can only have one main mode
policy, and the last GPO to assign a main mode policy is the winner (just like in
Windows 2000/XP/2003). Hence, standardize on one set of main mode configuration
settings and use them everywhere on every operating system.
e§ ices
Cl Recommended (IPSec: Group Policy): Consider assigning a Windows
i 2000/XP/2003 IPSec Policy with the Default Response Rule at the domain level through
Group Policy, then customize IPSec Policies at the OU level. Remember, the very last
IPSec Policy to be assigned on a Windows 2000/XP/2003 host, after all the Group Policy
Objects have been processed, will be the one and only effective IPSec Policy on that
host. Hence, an IPSec Policy assigned at the OU will override any IPSec Policies
assigned at the site or domain. If an OU lacks an assigned IPSec Policy, then the
Default Response Rule at the domain level will be in effect. However, even better than
using the Default Response Rule is to create a fully-configured Policy at the domain level
with all the needed exemptions. As a domain-wide default Policy, this configuration will
better permit the exemptions to function as expected and will cause fewer time-outs.
Remember, though, that on Windows Vista and later, WFAS IPSec policies are merged
across multiple GPOs.
Cl Recommended (IPSec: Group Policy): Consider creating GPOs which contain only
firewall and IPSec settings, then tightly control the permissions on the GPO and its links
to prevent other administrators from modifying them. Audit failed access too. This is
warranted by the complexity and sensitivity of firewalling and IPSec.
0 Recommended (IPSec: Group Policy): Don’t forget about portable computers when
assigning firewall and IPSec settings through Group Policy. These machines will need to
function normally when outside the LAN away from the forest. For this purpose, avoid
filters constructed around “My<->Any” or “Any<->Any” addresses; use filters tied to
specific internal subnets or particular IP addresses instead.
Cl Recommended (IPSec: Group Policy): Before deleting a GPO, unassign any IPSec
policies in it and clear any firewall policies in it. Similarly, before deleting an IPSec policy
from a GPO, unassign that IPSec policy first (or assign a different one), let this change
fully replicate through Active Directory and Group Policy, then delete the IPSec policy
afterwards (see KB234320).
SANS Institute
- 2003 and Later: NETSH.EXE
- Windows XP and Later: NETSH.EXE
- Dynamic: Injects rules until next reboot.

- Static: Creates and assigns regular policies.
Both IPSec and firewall settings can be scripted from the command line. These tools
work on local or remote systems, as long as you are a member of the local Administrators
group, and they work on both domain members and stand-alones. While Group Policy is
the primary tool for managing firewall and IPSec settings, the ability to script these
settings opens new possibilities.
There are different tools for different operating systems. For managing IPSec settings:
Windows 2000: 1PSECPOL.EXE

Windows XP: 1PSECCMD.EXE
Windows 2003/Vista/2008/7 and later: NETSH.EXE
For managing the firewall on Windows XP and later, use only NETSH.EXE. In
Windows XP/2003, the NETSH.EXE context is Itfirewalltt,while in Windows Vista and
later the context is named "advfirewalltt(execute "netsh.exe /?" to see these contexts).
The NETSH.EXE program is built into Windows 2000 and later by default, but it has
different capabilities on different OS versions.
1PSECPOL.EXE is intended for Windows 2000 only, while 1PSECCMD.EXE is for

Windows XP. The command-line switches used by the tools are almost identical. To get
the latest download URL, Google on "site:microsoft.com ipseccmd.exe download". It
was last seen as a part of the Windows X P Server Pack 2 Support Tools.
SANS Institute
ic e vs. ic e
The IPSec command-line tools operate in two modes: dynamic mode and static mode.
When used in dynamic mode, they inject new rules directly into the IPSec driver's in-
memory database of IPSec rules. Dynamic rules take effect immediately, but they do not
show up in any graphical tool, hence, they can only be managed from the command line.
When used to create static mode policies, these tools can create visible named policies
that are permanently stored in the registry or in Active Directory. Which mode is being
used depends on the command-line switches used of course.
A batch script with the desired IPSec or firewall rules could be scheduled to run every
hour. Because these tools can take a command-line argument of a remote computer,
domain member or stand-alone, this single script could configure hundreds of systems
from a central location. Even more flexibility is available when using PowerShell or
VBScript instead of plain batch files.
IPSec policies are assigned to computers, not users. However, Group Policy can be used
to define logodlogoff scripts for users. These scripts could create dynamic IPSec rules
when the user logs on, then delete these dynamic rules when the user logs off again.
Hence, you can implement per-user IPSec settings with logon scripts for users who are
local Administrators wherever they log on.
es
NETSH.EXE can be used on Windows XP and later to manage firewall settings, and on
Windows Server 2003 and later to manage IPSec settings.
On Windows Vista/2008/7 and later, for example, experiment with these commands:
To see a summary of your profile options:

netsh.exe advfirewall show allprofiles
To dump the details of every connection security rule (IPSec):

netsh-exe advfirewall consec show rule name = all
To see how to create a connection security rule (IPSec):

netsh-exe advfirewall consec add rule / ?
To dump the details of every firewall rule:

netsh.exe advfirewall firewall show rule name = all
To see how to create a firewall rule from the command line:

netsh.exe advfirewall firewall set rule / ?
The following is an example of a batch file that could be used to create a static IPSec
policy object on Windows Server 2003/2008. This policy would block all packets except
SANS Institute
-
for TCP 80/443, and it would require AH for all traffic to/from network ID 10.0.0.0 (note
that many of the lines must be wrapped).
REM * * * * * * * X * * * * * * * * * * * * x x x x * * x x * * * * x * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
REM Create The Ipsec Policy Object.
netsh.exe ipsec static add policy name=fTIIS-Server-Policy"assign=no
REM Create Filter Lists And Add Filters To Them.
netsh.exe ipsec static add filterlist name="HTTP Traffic"
netsh.exe ipsec static add filter filterlist="HTTP_Traffic"srcaddr=any
dstaddr=me description="HTTP" protocol=TCP srcport=O dstport=80
netsh.exe ipsec static add filter filterlist=IlHTTP Traffic" srcaddr=any
dstaddr=me description=IlHTTPS" protocol=TCP srcport=O dstport=443
netsh.exe ipsec static add filterlist name=llA1l-Traffic"
netsh.exe ipsec static add filter filterlist="All_Traffic"srcaddr=any
dstaddr=me description="All Traffic" protocol=any
srcport=O dstport=O
netsh.exe ipsec static add filterlist name=lgInternal-Traffic"
netsh.exe ipsec static add filter filterlist="Internal-Traffic"
srcaddr=l0.0.0.0srcmask=255.0.0.0dstaddr=me
description=IlInternal Traffic" protocol=any srcport=O dstport=O
REM Define Filter Actions.
netsh.exe ipsec static add filteraction name=flAllowfT
action=permit
netsh.exe ipsec static add filteraction name="Block" action=block
netsh.exe ipsec static add filteraction name="AH-Only" qmpfs=yes
soft=no inpass=yes action=negotiate qmsec=~~AH[MD51:100000k/1000s
AH [SHAl]: 100000k/1000s"
REM Now Create Rules In The Policy With The Actions And Filters.
netsh.exe ipsec static add rule name="Allow HTTP"
po 1 icy= IIS-S erver-Po 1 icy f i1ter1 ist= HTTP-Tr affic If
kerberos=yes filteraction=Allow
netsh.exe ipsec static add rule name="Block All"
policy= IIS-Server-Pol icyt1fi1terlist = "A11-Traf fic
kerberos=yes filteraction=Block
netsh.exe ipsec static add rule name="AH for LAN"
policy=(IIIS-Server-Pol icy" fi1terlist= ITInternal-Traf fic"
psk=tlmyPreSharedKeyT1 filteraction=AH-Only
REM Disable The Built-In Default Response Rule.
netsh.exe ipsec static set defaultrule policy="IIS-Server-Policy"
activate=no
REM Now Assign The Policy.
netsh-exe ipsec static set policy name="IIS-Server-Policy" assign=yes
1PSECCMD.EXE is a command-line tool that is almost identical to IPSECPOL.EXE,

with some important differences. 1PSECCMD.EXE only works on Windows XP, not
Windows 2000, and comes with the X P Support Tools. Dynamic policies set with
1PSECCMD.EXE survive restarts of IPSec Services and computer reboots, unlike
dynamic policies set on Windows 2000, which disappear after a restart. And
1PSECCMD.EXE supports a "query mode" which 1PSECPOL.EXE does not.
SANS Institute
1PSECCMD.EXE on Windows XP replaces NETDIAG.EXE on Windows 2000 for

viewing IPSec information from the command line. Query mode supports the following
commands for showing, respectively, IPSec filters, policies, authentication methods,
statistics, security associations (SA'S),and all of the above.
ipseccmd.exe show filters

ipseccmd.exe show policies
ipseccmd.exe show auth
ipseccmd.exe show stats
ipseccmd.exe show sas
ipseccmd.exe show all
The commands work on remote boxes too, e.g., "ipseccmd \\server show sas".
. ... .
:
I
I1 :.'?!i Ill -4 3 x
. .... .. - . .... . . . ...- .- .. . . . -.. ... .. ...- .... .. . .. .
~ : \ > i p s e c c m d . e x e \\192.168.111.113 show s a s
a i n Mode SFls
_____________________________
a i n Mode SA #I:
i From 192.168.111.113
To 192.168.111.111
P o l i c y Id : CBB41CA0B-503E-4F0B-B680-
Offel. Used :
3DES SHAI DH Gi*oup 2
Quickmode l i m i t : 0, L i f e t i m e
Ruth Used : Kei*bei*os
I n i t i a t o r c o o k i e c9f5fehc77a83436
Responder c o o k i e 3hd43fSedb7cc386
~ u i c l rMode SAs
Ltiick Mode SA E l :
1 F i l t e i . I d : <E93FFP18-4AEB-4169-Fl885-11572A79CBD8>
T p a n s p o r t F i l t et*
From 192.168.111.113
To 192.163.111.111
P r o t o c o l : 0 S r c P o r t : 0 Des P o r t : 0
Dit*ecti o n : Outbound
P o l i c y Id : <7238523F-70FR-11Dl-864C-l4A30@0@@0@Ci>
Offel. Used :
Rlso It1 : Enci-untion 3DES SHAI <24hutes/0i*ounds>
1
MySpz-279428846 Peei-Spi 1983229716

PFS : F a l s e , L i f e t i m e 100000Khytes/900seconds
I n i t i a t o i . c o o k i e c9f5fehc77a83436
Responder c o o k i e 3bd43f8edh7cc386
/The command completed s u c c e s s f u l l y .
F:\> 7
4 b
In a batch script, the following will 1) delete all dynamic Rules, 2) Block all packets to or
from the server, and 3) selectively allow only those packets to or from TCP port 80. This
would be run against a remote webserver for packet filtering. The Rules they add are
dynamic, i.e., they will not survive a reboot or restart of the IPSec Policy Agent.
ipseccmd.exe \\servername --u

ipseccmd.exe \\servername -f i o + * ]
ipseccmd.exe \\servername -f (0:80+*::TCP)
SANS Institute
To also allow HTTPS and ICMP access to the server as well, add these two lines. Now
your webserver can service SSL requests for webpages and respond to pings.
ipseccmd.exe \\servername -f (0:443+*::TCP)

ipseccmd.exe \\servername -f (O+*::ICMP)
If you have a home computer connected to the Internet 24x7 through a DSL or cable
modem line, then execute the following line to block access to your most sensitive ports
(follow the pattern to add any other ports you wish to block). This works even if your IP
address is dynamically assigned by your ISP, just execute it after you connect (or
schedule it to run every hour). To delete these Filters, execute "ipseccmd -ul'.
ipseccmd.exe -f [*=0:135:TCPl [*=0:139:TCPl [*=0:137:UDPI
Note: As these dynamic Rules are added and deleted, you can see them appear
and disappear with "netdiag.exe /test:ipsec /debug".
You can make these Rules survive reboots by creating a static Policy named "MyPol" in
the registry with Rules named "Blocker", "GoHTTP", "GoHTTPS" and "GoICMP". The
first line below unassigns and deletes any static Policy named "MyPol", and the \\server
argument has been omitted to avoid line-wrapping, but it still works on remote systems.
ipseccmd -w REG -p "MyPol" -y -0

ipseccmd -w REG -p "MyPol" -r "Blocker" -n BLOCK -x -f 0+*
ipseccmd -w REG -p "MyPol" -r "GoHTTP" -n PASS -x -f 0:80+*::TCP
ipseccmd -w REG -p "MyPol" -r "GoHTTPS" -n PASS -x -f 0:443+*: :TCP
ipseccmd -w REG -p "MyPol" -r "GoICMP" -n PASS -x -f O+*: :ICMP
The "MyPol" Policy and its Rules can be seen and edited with the graphical "IP Security
Policies" snap-in because the Policy is static. Dynamic Policies are invisible here.
Execute the following (wrapped) line to create a static Policy named "SecurePol" which
requires 3DES encryption, SHA 1 hashing, Kerberos authentication, and session key PFS
for all packets, but only between "My Address" and the 169.254.*.* subnet, and enable
the option "Accept unsecured communication but always respond using IPSec".
ipseccmd.exe -w REG -p 'I SecurePol" -r "GoESP" -n ESP [ 3DES,SHA]PFS

INPASS -a KERBEROS -x -f 0+169.254.0.0/255.255.0.0
D.EXE Phase Command-Line Switches

If no Phase I switches are specified, the computer's current IKE settings will be used. If
there are no current IKE settings, the defaults listed below will be used. None of the
switches for Phase I are required.
-1s SecurityMethod [SecurityMethod2] [SecurityMethodn]

(Optional) The -1s switch defines one or more space-separated Im security methods in
the following format:
SANS Institute
Cipher-Hash-GroupNumber
Cipher can be DES or 3DES. Hash can be MD5 or SHA. GroupNumber is 1 or 2.

Default: 3DES-SHA-2 3DES-MD5-2 DES-SHA-1 DES-MD5- 1.
-lP
(Optional) The -1p switch enables Perfect Forward Secrecy for 1K.E Phase I.
Default: PFS for Phase I is not used.
-1k number
(Optional) The -1k switch specifies the number of sessions or the number of seconds to
rekey for I J E Phase I negotiations. A Q or S is appended to the end of the number to
indicate sessions or seconds. For example, - l k 20Q will rekey after twenty sessions.
Default: no session limit, rekey after 480 minutes (28800 seconds).
se e es ( ic e)
Dynamic mode only injects Rules into the Policy Agent. These Rules do not survive
reboots. Do not mix dynamic mode switches with the switches unique to static mode.
There are a number of switches common to both modes, but there are static mode
switches that do not work in dynamic mode.
\\computername
(Optional) Computer where Policy will be written. Default: local computer.
-confir
(Optional) Prompts before writing the Policy or Rule. Can be abbreviated to -c. Only
works when writing or deleting dynamic Policy. A nice feature of this switch is that it
displays the Rule to be added or deleted in a format more user-friendly than
NETDIAG.EXE, but not as complete either. Default: no confirmation requested.
(Required) One or more IPSec Filters can be defined, each separated by a space. Each
Filter is a string in one of the following two formats, optionally surrounded by either
parentheses or square brackets:
A.B. C.Dlmaslt:port=A.B.C.Dlmask:port:protocoL
A.B. C.Dlmask:port+A.B.C.Dlmaskport:protocoL
The source IP address (A.B.C.D) is on the left-hand side of the "=" and the destination on
the right. If a "+" is used instead of "=", the Filter is mirrored.
If the entire Filter is enclosed with parentheses, the Filter has the Filter Action of Permit.
If the entire Filter is enclosed in square brackets, the Filter has the Filter Action of Block.
e: (10.2.4.0/255.255.255.0:80=122.18.0.0/255.255.0.0:25:TCP) will
Permit packets from the subnet 10.2.4.* with TCP port 80 to the subnet
SANS Institute
122.18.*.* with TCP port 25. Enclosing the same in "[ 1'' instead of "( )'I would
create a Block Filter Action instead of Permit.
The mask and port are optional. If omitted, port will match any/all ports, and mask will
be 255.255.255.255, which will match just the one IP address specified. A3.C.D can be
replaced with 0, which is identical to "My Address(es)" in the snap-in, or with *, which is
identical to "Any Address". Each octet in A.B.C.D can be replaced with * for partial IP
address matching instead of using a mask, e.g., 10.7.*.* is the same as
10.7.0.0/255.255.0.0. The same cannot be done with 0.
The protocol is optional. If omitted, any protocol is assumed. Ifprotocol is specified,

either aport must also be specified or the Filter must include "::" to hold the place of the
unspecified port in the destination. The following protocol symbols are valid: ICMP,
UDP, TCP and RAW.
Example: 0+19 1.108.* .* :445:TCP is a mirrored Filter between the local

computerk IP address(es) and 191.108.0.0/255.255.0.0 on TCP port 445.
Note: Filters of the form (*=*), (*+*), [*=*I and [*+*I appear to not work, even
though NETDIAG.EXE shows the Filters they specify. Fortunately, (O+*) and
[O+*] achieves the same result because of the mirroring.
-n FilterAction
(Optional) Permit and Block Filter Actions are defined using parentheses and square
brackets (see the -f switch). One or more AH and ESP Filter Actions are listed after the -
n switch, separated by spaces in order of preference, using one of the following three
formats:
ESP[ Cipher,AuthMethod]lRelceyPFS
AH [Hash]
AH [Hash]+ESP [Cipher,AuthMethod]
Cipher can be NONE, DES, or 3DES. AuthMethod can be NONE, MD5, or SHA. Hash
is MD5 or SHA. These items are required when AH or ESP is specified.
Relcey is optional. Rekey is the number of kilobytes or seconds to rekey, with an "S" or
"K" placed after the number to indicate. To rekey on the basis of both time and
kilobytes, separate the two numbers with a slash, e.g., 3600S/lOOOOK will rekey every
hour or every lOMB of data, whichever comes first.
,
PFS is optional. When present, it enables Perfect Forward Secrecy for Phase I1
negotiations of IPSec SAs. "Pttcan be used instead to abbreviate.
Example: -n ESP[3DES7SHA]1800S/5000KPFS AH[MD5]
Because the -n switch is optional, the default Filter Actions are:

I
!'
SANS Institute
ESP[3DES7SHA]
ESP[3DES7MD5]
ESP[DES,SHA]
ESP[DES,MDS]
-t A.B. c.
(Optional) This switch both enables IPSec tunnel mode and specifies the IP address or
hostname of the tunnel endpoint. A.B. C.D can be replaced with a Fully Qualified
Domain Name. Default: transport mode, no tunnel endpoint. Keep in mind that an IPSec
tunnel cannot use mirrored Filters, hence, two 1PSECCMD.EXE commands will be
necessary.
od2] [AuthMethodn]
(Optional) AuthMethod is one or more space-separated authentication methods in one of
the following formats:
PRESHARE:"passphrase"
KERBEROS
CERT :" CA Name"
The passphrase for preshared-key authentication and CA Name for certificate

authentication are case-sensitive. You can abbreviate the AuthMethod with the first letter
of each method, i.e., P:"passphrase", K, or C:"CA Name". Default: KERBEROS.
-U
(Optional) The -u switch will delete all IPSec Rules which are not permanent or "static",
i.e., not in the registry or Active Directory. This is very useful for testing and returning
to the default settings. Default: nothing is deleted.
e: ipseccmd-exe -u
-soft
(Optional) The -soft switch will allow "softtt Security Associations that do not use AH or
ESP protection. Default: do not allow soft SAs. (When used with IPSECCMD.EXE,
there is an associated switch (-le) which can set soft SA expiration time-outs.)
-Ian and -
(Optional) The -1an switch will mark the Policy for LAN network adapters only. The -
dialup switch will mark the Policy for dial-up adapters only. Default: the Policy will
apply to both LAN and dial-up adapters.
Static mode changes survive reboots. 1PSECCMD.EXE in static mode can create named
Rules and Policies that are stored in the registry or Active Directory. Many of the
switches in static mode are the same in dynamic mode. For the sake of clarity, all
switches valid in static mode will be listed despite the duplication.
SANS Institute
Note the different way of specifying Permit or Block Filter Actions in static mode (the -n
switch) and the switches near the end of the list. The required switches are -r, -p and -f.
\\computemame
(Optional) Computer where Policy will be written. Default: local computer. See the -w
switch for related options.
-confirm
(Optional) Prompts before writing the Policy. Can be abbreviated to -c. Only works
when writing temporaryldynamic Policy. Default: no confirmation requested.
-f FiZter IFiZtet-21 [Filter31 [FiZtern]

(Required) One or more IPSec Filters can be defined, each separated by a space. Each
Filter is a string in one of the following two formats:
A.B. C.Dlmask:port=A.B.C.Dlmaskport:protocol
A.B. C.Dlmask:port+A.B.C.Dlmaskport:protocol
The source IP address (A.B.C.D) is on the left-hand side of the 'I='' and the destination on
the right. If a "+" is used instead of "=", the Filter is mirrored.
The mask and port are optional. If omitted, port will match anylall ports, and mask will
be 255.255.255.255, which will match just the one IP address specified. A.B.C.D can be
replaced with 0, which is identical to "My Address(es)" in the snap-in, or with *, which is
identical to "Any Address". Each octet in A.B. C.D can be replaced with * for partial IP
address matching instead of using a mask, e.g., 10.7.*.*. The same cannot be done with
0.
The protocol is optional. If omitted, any protocol is assumed. Ifprotocol is specified,

either aport must also be specified or the Filter must include "::" to hold the place of the
unspecified port. The following protocol symbols are valid: ICMP, UDP, TCP and
RAW.
Example: 0+191.108.*.*:445:TCP is a mirrored Filter between the local /
computer's IP address(es) and 191.108.0.01255.255.0.0 on TCP port 445.
The name of the Filter List will be identical to the name of the Rule specified with the -r
switch. (When using IPSECCMD.EXE, there is a related switch (-lf) for Phase I Filters.)
-n FiZterAction
(Optional) One or more AH and ESP Filter Actions are listed after the -n switch,
separated by spaces in order of preference, using one of the following six formats:
ESP [Cipher4 uthMethodJRekeyPFS

AH [Hash]
i
S A N S Institute
i
AH[Hash]+ESP[Cipher,AuthMethod]
BLOCK
PASS
INPASS
Cipher can be NONE, DES, or 3DES. AuthMethod can be NONE, MD5, or SHA. Hash
is MD5 or SHA. These items are required when AH or ESP is specified.
Relcey is optional. Relcey is the number of kilobytes or seconds to rekey, with an "S" or
"K" placed after the number to indicate. To rekey on the basis of both time and
kilobytes, separate the two numbers with a slash, e.g., 3600S/10000K will rekey every
hour or every 10MB of data, whichever comes first.
PFS is optional. When present, it enables Perfect Forward Secrecy for Phase I1
negotiations of IPSec SAs. I'P'' can be used instead to abbreviate.
xample: -n ESP[3DES,SHA]1800S/5000KPFSAH[MD5] INPASS
If BLOCK is listed, then the Filter acquires a Block Filter Action. Do not use any other
options with -n if BLOCK is used.
If PASS is listed, then the Filter acquires a Permit Filter Action. Do not use any other
options with -n if PASS is used.
If INPASS is listed, then this is the same as checking the box in the GUI snap-in labeled
"Allow unsecured communication, but always respond using IPSec". This permits
inbound cleartext packets, but the host will attempt to negotiate IPSec security for all
outbound packets. You can use INPASS with AH or ESP options, without which the
default Filter Actions below will be used.
Because the -n switch is optional, the default Filter Actions are:

ESP[3DES,SHA]
ESP[3DES,MD5]
ESP[DES,SHA]
ESP[DES,MDS]
The name of the Filter Action will be identical to the name of the Rule specified with the
-r switch, but with "negpol" appended to the end, e.g., if the Rule is "goodrule" then the
Filter Action will be named "goodrule negpol".
(Optional) This switch both enables IPSec tunnel mode and specifies the IP address or
hostname of the tunnel endpoint. A. B. C.D can be replaced with a Fully Qualified
Domain Name. Default: transport mode, no tunnel endpoint. Keep in mind that an IPSec
tunnel cannot use mirrored Filters, hence, two 1PSECCMD.EXE commands will be
necessary.
SANS Institute
-a AuthMethod [AuthMethod2] [AuthMethodn]

(Optional) AuthMethod is one or more space-separated authentication methods in one of
the following formats:
PRESHARE:"passphrase"
KERBEROS
CERT:"CA Name"
The passphrase for preshared-key authentication and CA Name for certificate

authentication are case-sensitive. You can abbreviate the AuthMethod with the first letter
of each method, i.e., P:"passphrase", K, or C:"CA Name". Default: KERBEROS.
-soft
(Optional) The -soft switch will allow "soft" Security Associations that do not use AH or
ESP protection. A soft SA is different than Permit or PASS. Default: do not allow soft
SAs. (When used with IPSECCMD.EXE, there is an associated switch (-le) which can
set soft SA expiration time-outs.)
-1an and -dialup

(Optional) The -1an switch will mark the Policy for LAN network adapters only. The -
dialup switch will mark the Policy for dial-up adapters only. Default: the Policy will
apply to both LAN and dial-up adapters.
-w Type[:Location]
(Optional) Writes the Policy to storage indicated by Type[:Location].Type can be either
REG for regishy or DS for Active Directory. If the Type is REG, then Location should
not be used. If the Type is DS, then Location is the DN name of the local or remote
domain where the Policy should be written, or, if omitted, the default is the local domain.
Default: write the Policy to the local domain's Active Directory.
-p PolicyName[:PoZlIntervalJ
(Required) If PoZicyName does not exist, a new one will be created. If it does already
exist, the Rule will be added to it. Hence, it is common to create the Policy with one
command in a batch script, then add Rules to it with additional commands. PoZZIntervaZ
defines the polling interval for the Policy, specified in minutes (defaults to 180 minutes).
-r RuleName
(Required) If the RuleName does not exist, a new one will be created. If the RuleName
does already exist, it will be updated. Hence, it is common to create the Rule with one
command, then update its settings with another. Note that the Default Response Rule
will be added automatically and there appears to be no switch to disable this.
-X
(Optional) Assigns the Policy to make it active. Does not assign it in Group Policy, only
in the registry.
i
SANS Institute
-Y
(Optional) Unassigns the Policy to make it inactive. Does not unassign it in Group
Policy, only in the registry.
-0
(Optional) Deletes the policy specified by -p AND all of the Filters and Filter Actions
used in the Policy. Hence, do NOT delete a Policy with this if other Policies use the
same Filters or Filter Actions! Note: this switch will not work unless the entire command
line used to create the Policy and Rule is also specified with -0. No error message is
reported if the Policy is not deleted!
SANS Institute
IPSec provides wonderful packet encryption, but it doesn't provide everything needed for
a full Virtual Private Networking solution. IPSec needs help with problems like user
authentication, policy enforcement, RADIUS integration, logging and auditing, etc.
Microsoft's Routing and Remote Access Service (RRAS) is much more than a dial-up
service. RRAS is the server-side gateway in a Windows-based IPSec VPNs. In the
following section we can't cover every aspect of RRAS, but we will talk about its security
features as a VPN gateway.
SANS Institute
- Routes TCP/IP, IPX/SPX

and AppleTalk packets.
- VPN Gateway
- L2TP/IPSec, SSTP, PPTP
- Static and On-Demand
- Allocate IP addresses.
- RIPv2 and OSPF
- Stateful Firewall
- Load balancing.
- Dial-Up Server - log gin^ and ~ u d i ~ i n g .
- Compression.
The Routing and Remote Access Service (RRAS) is what uses IPSec to create encrypted
VPN tunnels between networks and to enable remote users to gain access to the corporate
network. RRAS is the server-side component for Virtual Private Networking (VPN) on
Windows Server, whether the VPN protocol is L2TP/IPSec, SSTP or PPTPv2.
RRAS is more than just a VPN server, however. RRAS can also do the following:
Route IP packets between multiple physical, virtual and dial-up interfaces.

Uses L2TP/IPSec, SSTP or PPTP for its VPN protocols.
Use RIPv2 or OSPF for automatic router configuration.
Perform address- and port-based Network Address Translation (NAT).
Act as a dial-up server or client for ISDN, POTS or VPN connections.
Create demand-dial VPN or dial-up connections only as needed.
Perform packet filtering on each interface, physical or virtual.
Act as a NetBIOS gateway to transpose NetBios-based protocols from one type of
carrier packet used by the client, e.g., IPX/SPX, to another type used on the LAN,
e.g., TCP/IP.
RRAS is available on Windows Server, not Windows XP/Vista or other client systems.
SANS Institute
h e eature Cannot
This course is concerned with the security features of RRAS only. See the Help files that
come with Windows Server for basic configuration tasks and routing concepts. The
RRAS security features discussed below are leveraged by all the dial-up and VPN
capabilities of RRAS. Hence, they will be discussed in a way which applies to them all.
Important: Everything in the following sections apply to L2TP/IPSec VPNs.

L2TP uses MS-CHAPv2 and RRAS for user authentication and access control.
The following sections also apply to PPTP and dial-up phone connections.
Overcome Limitations in I e
Windows supports IPSec tunnel mode for bare RFC compliance, but that's it. The reason
for this is that IPSec tunnel mode currently has limitations which make it inconvenient
for remote access (see http://www.ietf.org/html.charters/ipsra-charter.html).
Some limitations of IPSec which are overcome by RRAS and L2TP include:
IPSec cannot dynamically allocate temporary IP addresses to remote VPN clients.
IPSec cannot dynamically manage the route tables on either the VPN server or
client as connections are created and torn down.
IPSec does not itself authenticate users on Windows versions prior to Vista, it
only authenticates hosts and routers. Hence, it is difficult to control access and
manage connection properties based on the user's identity or group memberships
on those older operating systems.
IPSec does not provide load balancing or failover fault tolerance across multiple
VPN gateways in a farm providing client access, but RRAS can utilize the
Network Load Balancing (NLB) of Windows Server to do just this. When used
with ISA Server Enterprise Edition, site-to-site IPSec VPNs are also maintained
in a fault tolerant manner.
IPSec does not provide its own auditing capabilities. In particular, we want to be
able to control/audit VPN connections with RADIUS servers.
IPSec does not compress its packet payload, but L2TP compresses typical user
data to roughly 50% of its original size, thus almost doubling throughput.
IPSec by itself cannot tunnel non-IP protocols such as IPWSPX and AppleTalk.
Note that the IPSec protocol suite is currently under development to overcome these
limitations. Other vendors are jumping on these enhancements early, e.g., Cisco's "mode
config" and "XAuth", but it remains to be seen what Microsoft will do.
i
SANS Institute
The security features of RRAS for dial-up and VPN connections include the following:
ermissions and olicies. Remote user access control is

determined both by a dial-in permission on the account itself and remote access
policies. Policies are keyed off of a user's group membership, time/day of the
connection attempt, LAN protocol being used, dial-up protocol being used, or
other features of the VPN/dial-up connection. When a policy is triggered, it can
grant/deny the connection attempt, enforce authentication and encryption options,
and set various connection parameters such as idle time-outs.
US Server Support. RRAS can be a client to a Remote Authentication

Dial-In User Service (RADIUS) server to outsource its authentication,
authorization and logging. RADIUS is a popular industry-standard protocol for
centralizing the management of remote access solutions. Deploying a RADIUS
server is usually a necessary part of maintaining a large number of RRAS servers.
olicy Server (N S). Windows Server 2008 and later includes its own
RADIUS server named the Network Policy Server (NPS) services, formally
named the Internet Authentication Service (IAS). RRAS and NPS can be tightly
integrated. The configuration of NPS is similar to the configuration of policies
and logging on RRAS. Once you understand RRAS policies and logging, you
understand how to configure NPS.
iltering. RRAS can perform packet filtering on each of its interfaces,

whether the interface is physical, virtual or dial-up. Filtering can be based on a
packet's direction of travel (in or out of the interface), protocol type,
source/destination addresses, source/destination port numbers, or the packet's
fragmentation state. Another type of filtering can be performed on a per-user
basis: each remote user could have a different set of packet filtering rules applied
to just his or her connection. This is enforced through RRAS policies.
tro tication. RRAS supports MS-CHAPv2 and EAP-TLS

for mutual authentication. The Microsoft Challenge-Handshake Authentication
Protocol version 2 (MS-CHAPv2) is a vast improvement over its predecessor
(version 1). The Extensible Authentication Protocol (EAP) can use Transport
Layer Security (TLS) for certificate-based authentication. This is the same type
of authentication used for certificate authentication on 11s.
. EAP-TLS authentication can use X.509~3

digital certificates stored on smart cards. EAP-TLS smart card authentication of
remote VPN/dial-up users is the strongest authentication option on RRAS. Smart
card logon can be required if necessary.
SANS Institute
124 IPSec. RADIUS, Wireless. and VPNs
ata Encryption. Data encryption will be discussed later with Virtual Private
Networking (VPN). RRAS supports both IPSec, MPPE with PPTP, or SSL/TLS
with SSTP for encryption.
RRAS Account Lockout. This feature is not related to the "Account Locked
Out" setting on the Account tab of a user's property sheet. Nor is it related to
account lockout policies as defined through Group Policy. RRAS account lockout
will disable a user account if it suffers too many failed remote connections. But
the lockout only applies to remote access connections-- regular network or
interactive logons are not affected.
Logging and Accounting. RRAS and IAS support extensive logging of remote
access activity. Logging occurs to both the Event Viewer system log and to text
files.
Callback (dial-up only). Dial-up users can be forced to call in from a fixed phone
number. After successfully logging into the RRAS server, the server can be made
to disconnect and call the user back at a previously-defined number. The user's
computer will answer the phone and communications will resume. This feature
helps to thwart attackers who dial in fi-om random locations, such as hotel rooms.
(dial-up only). RRAS can reject a dial-up connection if the phone

number of the user does not match the previously-configured number associated
with that user's account. The RRAS server is aware of the client's phone number
in virtue of Caller-ID. This is similar in purpose to the callback feature, but is
more convenient.
S
There drawbacks to using RRAS that you should factor into your decision-making:
As a software solution, RRAS will not scale as well as a hardware-only solution.

Devil's advocate will point out that IPSec-offload network adapter cards, multi-
CPU mainboards, clustered arrays of RRAS boxes, and specialized dial-up
concentrators, like Digi cards, can be used to upgrade this scalability
(www.digi.com). And bandwidth limitations are often the bottleneck before any
hardware or software limitations kick in anyway.
RRAS is complex, and the snap-in interface is not completely intuitive. This
complexity translates into difficult configuration and troubleshooting. There are
numerous KnowledgeBase KB-articles related to RAS and RRAS. For example,
the way RRAS injects the necessary IPSec Rules into the driver for L2TP
support-- if you didn't know about this behavior beforehand, you would have to
dig through quite a bit of documentation to find it. Devil's advocate will point out
that, for example, Cisco's command-line interface is about ten times less fi-iendly.
SANS Institute
Installing an RRAS box requires both the hardware and the license for the
operating system. This can often be more expensive than a "VPN appliance".
However, total cost of ownership is what must be considered, and TCO includes
manageability, training of administrators, integration into the environment, etc.
Secure Socket Tunneling Protocol (SSTP) requires Windows Server 2008 or later,
and currently SSTP cannot be used with site-to-site VPNs.
SANS Institute
To install RRAS in Server 2008 and later, open the Server Manager tool > right-click
Roles > Add Roles > select "Network Policy and Access Services".
__.__I"__." -..-.,-. . . . . . . . . .
. - ............ . . -
xi I
Select Sewer Roles
SANS Institute
When prompted to choose which subcomponents to install, check the boxes for "Network
Policy Server" and "Routing and Remote Access Services", but do not check the boxes
for "Health Registration Authority" or "Host Credential Authorization Protocol".
Select Rofe Services
When the RRAS service is enabled by an administrator on a computer which is a member

of an Active Directory domain, the computer's account will be added to the "RAS and
IAS Servers" group. If for some reason it is not added automatically, add it manually.
3)
To enable RRAS in Server 2003, open the Routing and Remote Access snap-in in the
Administrative Tools folder > right-click on the desired server > select Configure and
Enable Routing and Remote Access > Next > select Custom Configuration > Next >
check all boxes > Next > Finish > OK > Start Service.
In Server 2003, don't select the option for "Virtual Private Network (VPN) Server". This
will create PPTP and L2TP packet filters automatically without your knowledge
(ISB243374). This will be a troubleshooting headache if you're not aware of these filters
or how to modify them.
. The most important tool for managing RRAS is

the "Routing and Remote Access" snap-in in the Administrative Tools folder. This is
used to enable RRAS, configure ports, edit packet filters, manage routing tables and
protocols, and start NAT. Local and remote RRAS servers can be configured with this
SANS Institute
snap-in. Before any configuration can be performed, however, the RRAS service must be
enabled.
When RRAS is enabled, the snap-in will show the containers in the following screenshot.
. . . . . . . . . . . . .
.... ................... .
Routing a n d Remote Access
... . . .
Server Status
1 Type 1 IP Address
3pback Loopback 127.0.0.1
al Area Connecbon Dedicated 10.4.S.5
I_
Internal Not available
B
a9 Remote Access Clients f0)
Remote Access Logging d Poliaes
IPv4
DHCP Relay Agent

IGMP
NAT
IPv6
I
I
9 General
The other RRAS utilities are not as important. Their purposes are listed below:
.EXE (built-in) -- The NETSH.EXE command-line utility can be used to

manage virtually every aspect of RRAS. It is scriptable. Execute "netsh ras
dump > rascript .txt'I to dump the RRAS server's configuration to a text
file which can be used as a script to configure an RRAS server identically. Import
the configuration file with "netsh exec rascript .txt".
RASDIAL.EXE -- Connect or disconnect dial-up or VPN sessions from the

client's side. Useful when scripting connections for users.
RASSVRMON.EXE and PORTGEN.EXE (Resource Kit)-- These

command-line monitoring tools can display a vast amount of per server, per user,
per connection or per port information. Use these to gather statistical and
performance data on multiple RRAS servers over the network.
RASUSERS.EXE (Resource Kit)-- This command-line utility will list all the
user accounts which have the dial-in permission in the domain or on a remote
server. Run this periodically to keep track which users have acquired dial-in
permissions. Hackers will also attempt to use this utility too.
SE.EXE (Resource Kit)-- This command-line tool converts IAS-

formatted logs into a more user-friendly format.
SANS Institute
(Resource Kit) -- This command-line monitoring tool shows

RRAS server announcements on the network.
(Resource Kit) -- This tool enables "tracing" for RRAS

and NPS/IAS. Tracing is a type of extremely detailed low-level logging of the
internal activities of the various components comprising RRAS and NPS/IAS.
Tracing would be used to troubleshoot only the most bizarre and intractable
problems. Tracing logs are written to %WinDir%\Tracing\. (Search "tracing" in
the Resource Kit Books Online.)
er io
The Connection Manager Administration Kit (CMAK) is used to create small executables
which, when run, install a dial-up or VPN connection icon in the Network Connections
folder on the client. This is the icon the user double-clicks in order to establish a dial-up
or VPN connection.
The CMAK is a wizards-based tool that will walk you through the process of selecting all
the connection options you want configured in the resulting connection icon. You can
configure virtually every aspect of the connection icon's properties, including security
settings and scripts. The CMAK will produce a small executable which can be
distributed to your users as you see fit, e.g., shared folder, web page, e-mail, floppy, etc..
The user simply double-clicks the executable and the pre-configured connection icon is
created.
You install the CMAK by going to Server Manager > right-click Features > Add Feature
> check "Connection Manager Administration Kit" > Next > Install. (On Windows
Server 2003, go to Control Panel > Add/Remove Programs applet > Add/Remove
Windows Components > Management and Monitoring Tools > check the box for
Connection Manager Components.)
Once installed, the CMAK wizard is launched fiom the Administrative Tools folder >
Connection Manager Administration Kit.
There are numerous options that can be configured. See the CMAK Resource Kit built
into the Help system in the CMAK.
SANS Institute
Before a user can authenticate with a Remote Access Policy, that user's account must be
configured to be controlled through Remote Access Policy. Starting with Server 2008,
Remote Access Policies are also called "NPS Network Policies".
RRAS controls remote user access through 1) user account dial-in properties and 2)
RRAS policies. User access control requires authentication of the person. This is one of
the limitations of pure IPSec which RRAS+L2TP can overcome.
The property sheet of a user account contains a Dial-In tab to configure remote access
permissions for that user. View the property sheet for a user account in the "Active
Directory Users and Computers" snap-in to see the Dial-In tab. Or, on a stand-alone
RRAS server, see the Users container in the Computer Management snap-in (as in the
screenshot below).
SANS Institute
ptions Grayed
The options to ''Control access through Remote Access Policy", "Verify Caller-ID",
"Assign a Static IP Address" and "Apply Static Routes" on the Dial-In tab of a user's
property sheet are available only if the account exists:
1) in a native mode Active Directory domain, or

2) in the local accounts database of a stand-alone server which is not a member
of any domain whatsoever.
If the user is a member of a mixed mode Active Directory domain or a Windows NT 4.0
domain, the options are grayed out.
ote Access
There are two ways to define a user's remote access permissions: 1) configure the Dial-In
tab of the user's property sheet and/or 2) configure RRAS policies. These methods
interact with each other and their settings can conflict.
When there is a conflict between remote access permissions set on a user's property sheet
and permissions in Remote Access Policy, the following rules summarize how the
conflict is resolved:
If the remote access permission on the Dial-In tab of a user's property sheet is set
to "Control Access Through Remote Access Policy", then there can be no
conflicts. Permissions are managed exclusively through RRAS policies. This
-
option is available only on native mode domains and stand-alone RRAS servers.
SANS Institute
If the remote access permission is set to "Deny Access", then the user is always
denied, no matter what RRAS policies exist to allow it.
If the remote access permission is set to "Allow Access", then the user is always
allowed, no matter what RRAS policies exist to deny. However, if there are no
RRAS policies whatsoever, or if no policy Conditions apply to the connecting
user, then the user is denied.
In short, the allow/deny permissions on the user account always override the permissions
specified in RRAS policies. The exception is when none of the conditions specified in
any RRAS policy match the connecting user; in this case, the user is denied. If there are
no policies defined, then it is impossible for there to be a matching condition, hence, all
users are denied no matter what.
That last point is important for mixed-mode domains. The only way to block access to
users with the Allow permission in such domains is to try to configure all the conditions
in all the RRAS policies to not match the undesired connection attempts. For example, to
prevent mixed-mode domain users with the Allow Access dial-in permission from
dialing-in on the weekends, make sure that none of the conditions on any of the policies
match the connection request except during weekdays; it doesn't matter whether the
Policy specifies Allow or Deny for these users. Needless to say, this is very awkward
and will likely be intolerable. This limitation is a strong motivator to convert to native-
mode domains.
Important! Regularly audit the list of users with accounts that have the Allow
Access dial-in permission. These users can circumvent RRAS policies whose
purpose is to deny access. The RASUSERS.EXE Resource Kit utility will dump
a list of these users from local or remote systems.
Verify Caller-ID
If the user's phone equipment, the intervening phone system, and the RRAS server's
hardware all support Caller-ID, then connection attempts can be denied if the originating
phone number does not match the number entered in this field. This prevents attackers
from gaining dial-up entry from random locations like hotel rooms and payphones.
Beware, though, because if a Caller-ID number is entered and something prevents the ID
information from reaching RRAS, the connection will be denied. On the other hand,
verifying Caller-ID is more convenient than callback security.
,
Callback Options
When callback is configured, the client will connect and authenticate successfully, then
the RRAS server will hang up and call the user back at the number specified. The
purpose is the same as verifying Caller-ID.
SANS Institute
The option to have the callback number "Set By Caller" is not a security feature. Another
purpose of callback is to reverse long-distance charges that the user would otherwise
have to pay.
Normally, a RRAS server will use DHCP or a pool of addresses to temporarily configure
remote access clients with an IP address valid on the RRAS server's LAN. If desired,
each user could be assigned a unique static IP address instead. This improves the
auditing of remote access (since IP addresses can be mapped back to user accounts). It
can also circumvent DHCP problems and facilitate packet filtering.
This option configures additional routes in the route table of the RRAS server, not the
user's computer. Sometimes the connecting "user" is actually another RRAS router on a
remote LAN (call this the branch-office RRAS server). When this remote branch-office
RRAS server connects to the main corporate RRAS server, the branch RRAS box
provides two-way routing of packets between the two LANs. The corporate RRAS
server needs to add routes to its own route table on-the-fly when the branch-office RRAS
server connects; without it, the corporate RRAS box would not know how to forward
packets to the branch network while connected to it. This is where these only-while-
connected routes are defined for the sake of the corporate RRAS server receiving the
connection.
icies =
Remote Access Policies (a.k.a., RRAS policies or NPS Network Policies) are much more
configurable than the simple Allow/Deny permission on a user's Dial-In tab. An RRAS
policy has three parts:
1) a set of matching conditions,

2) the dial-in permission (allow/deny), and
3) a connection profile.
The conditions specify when the policy applies to the connecting user. If the policy does
apply to a connection, the dial-in permission allows or denies access. If the connection is
allowed, the connection profile manages the connection. By analogy with IPSec, the
conditions are the ''Filters'' and the permission and profile are the "Filter Actions".
When multiple RRAS policies are active simultaneously, they will be ranked in order of
processing. The first policy whose conditions match the connection attempt will be the
policy whose dial-in permission and profile manages the connection. Lower-ranked
policies that might have also matched the connection will simply not be processed.
RRAS policies are not a part of Group Policy. Each RRAS server will have its own
RRAS policies unless a RADIUS server is used to centralize management and logging
(discussed later, see IAS).
SANS Institute
atching Con
The conditions of a RRAS policy specify the criteria which test whether or not the policy
applies to a particular connection attempt. The features of a connection attempt which a
condition can scrutinize include:
Group(s) to which the user belongs.

Day and time of the connection attempt.
Remote access protocol used by the client, e.g., PPP, SLIP, etc..
Tunneling protocol used by the client, e.g., PPTP, L2TP, GRE, AH, ESP, etc..
Type of service requested by client, e.g., login, callback, etc.
Phone number dialed by user.
Phone number from which the call originated.
Type of port for the connection, e.g., ISDN, DSL, X.25, Ethernet, Modem, etc..
And other criteria related to Internet Authentication Server (IAS) RADIUS.
A single policy can contain more than one condition from the above list. If any of the
conditions in a RRAS policy match a connection attempt, that policy is triggered. If none
of the conditions in any of the RRAS policies match a connection attempt, the connection
is denied.
RRAS policies are configured with the RRAS snap-in and listed in its Remote Access
Logging & Policies container.
To create a RRAS policy which denies connections evenings and weekends, open the
RRAS snap-in > right-click on Remote Access Logging & Policies > Launch NPS > right-
click Network Policies > New > enter "Evening and Weekend Policy" for the Policy name
> select "Remote Access Server" from the pull-down list > Next > Add > select Day-And-
Time-Restrictions > Add > repeatedly highlight and mark as "Permitted" the weekend and
evening hours you want this Policy to apply to > OK > Next > select "Access Granted" >
Next > Next > Next > Next > Finish.
SANS Institute
i
olicies
Once a Policy has been created, it can be edited afterwards by viewing its properties
(double-click it). The wizard is fine to get started, but we'll focus on hand editing the
Policies ourselves from now on.
Note too that you can right-click a Policy and move it up or down in the list. This is
important because Policies are evaluated from top to bottom. If a Policy is matched, it
determines whether or not the access is allowed. If the permission set is to deny access,
then the attempt is rejected and no further Policies are evaluated. If a remote access
attempt does not match any Policies, then the attempt is rejected automatically.
s s
If a connection attempt matches all the conditions in a policy, and if the permission in
that policy grants access, then the connection is not yet permitted. A connection attempt
must also satisfy the constraints defined in the policy granting the connection, and then
the connection, if still allowed, will be regulated by the settings defined in that policy.
A network policy constraints lists is a set of configuration options for the connection
which include:
Permitted idle time before disconnect.

Maximum session time length.
SANS Institute
Permitted days and times. r
Permitted dial-in number.

Permitted dial-in media: ISDN, DSL, POTS, etc..
IP address assignment method: server-assigned, client-requested, DHCP.
Per-connection packet filters to/frorn client.
Multilink options.
Bandwidth Allocation Protocol (BAP) settings for multilink connections.
Authentication requirements: SSL-EAP, CHAP, MS-CHAPv2, etc..
Encryption requirements: cleartext allowed, strongest encryption required, etc..
The constraints of a network policy is viewed by double-clicking that policy or by right-

clicking it and selecting Properties.
Try It Now!
To edit a policy constraint so that only MS-CHAPv2 authentication is permitted, double-
click a policy in the Network Policies container in the NPS snap-in > Constraints tab >
Authentication Methods > uncheck all boxes except for the one next to "Microsoft
Encrypted Authentication version 2 (MS-CHAPv2)" > OK.
The next few pages describe the other options.
Many of the policy settings have the option to "Use Server Default" or to override that
default with the policy. These server defaults are configured on the tabs of the server's
property sheet.
To configure the default options on the RRAS server, right-click on the server in the
RRAS snap-in > Properties. The various tabs expose options, most of which can be
overridden by identical settings in a network policy. (We will return to this property sheet
later in the course.)
Best Practices
0 Mandatory (RRAS: Policies): Use RRAS Policies to regulate remote access, not the
old NT-style permissions on the Dial-In tab of user accounts.
0 Mandatory (RRAS: Policies): Organize your remote access RRAS Policies around
your global groups. Some groups will be allowed dial-up or VPN access, others should
always be denied. If some groups are allowed, then different groups will face different
security requirements and restrictions, e.g., Domain Admins may be required to
authenticate with their smart cards while regular users can just use their passwords.
0 Recommended (RRAS: Policies): If possible, convert Active Directory to native

mode or higher in order to fully benefit from RRAS Policies and other security features
such as Caller-ID. Otherwise, to use some of these features, the RRAS server would
have to be a stand-alone and only use local user accounts.
0 Recommended (RRAS: Policies): Regularly audit which users have the Allow
Access permission on the Dial-In tab of their accounts. These users might be able to
SANS Institute
circumvent RRAS policies. The Resource Kif RASUSERS.EXE tool can list them, as well
as ADS1 scripts.
0 Recommended (RRAS: Policies): Consider assigning static IP addresses to users

who either need to be more closely monitored or who require special entries in the
access control lists of firewalls.
Recommended (RRAS: Policies): For dial-up users, consider using Caller-ID or

callback security to help prevent hackers from dialing in from random locations.
Recommended (RRAS: Policies): Create a global group named "Denied All Remote
Access" and use RRAS Policies to deny all remote access to that group. Add users and
other groups to this one as necessary. This is a better method of excluding certain users
than setting the Deny Access permission on each of their accounts individually (Dial-In
tab).
SANS Institute
The Authentication Methods constraints control how the remote client is permitted to
veri@ its identity to the RRAS server. The different authentication options are listed
from most secure at the top to least secure at the bottom.
EA
Extensible Authentication Protocol (EAP) will be discussed with the next slide. EAP-
TLS supports smart card authentication over dial-up and VPN connections.
and S
MS-CHAP, CHAP, PAP and SPAP should not be used for PPTP VPN connections over
the Internet due to the weaknesses of these protocols. For example, there are sniffers
available which can extract password hashes from MS-CHAP authentication sessions
(http://www.oxid.it). L2TP VPN tunnels are different: all data is protected by IPSec, so
it doesn't matter if the authentication protocol is weak.
These protocols are safer to use over non-VPN ISDN or POTS lines because of the
physical security; if anyone has tapped these lines, then you have bigger problems to
worry about than compromised passwords anyway. However, only unavoidable
backwards-compatibility issues should make one consider using these obsolete
authentication methods.
SANS institute
1
MS-CHAPv2 is safe to use over the Internet with PPTP as long as one's passphrase is
sufficiently long or when using certificate authentication. When used with L2TP, the
MS-CHAPv2 data is encrypted again with IPSec anyway.
MS-CHAPv2 is a significant upgrade and fixes virtually all of the security vulnerabilities
of the original version. MS-CHAPv2 is a stronger authentication method than NTLMvl .
The client portion of a MS-CHAPv2 authentication session proceeds as follows:
Client requests MS-CHAPv2 authentication from server.

Server sends client a session ID number and a 64-bit random challenge.
Client sends server a message which contains the user's username, a client-
generated 128-bit challenge, and a hash value. This value is from an SHA-1 hash
of the concatenation of the server-generated challenge, the client-generated
challenge, the session ID number, and the MD4 hash of the user's password.
Server checks the client's returned hash value by performing the same function.
From the above it can be seen that the LanManager hash of the user's password is not
used in any way and the hash value exchanged is "salted" with random input generated
by each side independently. The only thing an eavesdropping attacker would not learn is
the MD4 hash of the user's password. As always, rigorous password policy is necessary.
The server portion of MS-CHAPv2 --where the client authenticates the server for mutual
authentication-- is documented in RFC 2759. Interestingly, the unique identity of the
server is not authenticated, rather, only the fact that the server has a copy of the user's
MD4 password hash is verified.
Server takes the user's MD4 password hash, user's hash response value, user-
generated challenge, server-generated challenge, plus two knowdfixed "magic''
numbers, and hashes all of this with SHA- 1. This hash value is returned to the
client along with a success for the client portion of the authentication.
Finally, the client performs the same SHA-1 hashing as in the prior step to
authenticate the server, or, rather, to verify that the server possesses the user's
MD4 password hash. It is simply assumed that if the server has the user's MD4
password hash then the server must be trustworthy. The unique identity of the
server is not authenticated by the client, i.e., the client does not know the name or
GUID of the RRAS server from MS-CHAPv2.
ote: Window 9x only supports MS-CHAPv2 for VPN connections, not dial-up
connections. Windows 9x must be patched to support MS-CHAPv2 (KB 189771 and
VPNUPD.EXE).
When unauthenticated access is enabled, the authentication phase of PPP is skipped

entirely. This option exists to support two rare uses: 1) when authentication will be based
S A N S Institute
solely on the phone numbers dialed to/from, and 2) for automatic logon with a specified
account such as Guest (similar to the IUSR-computemame account on 11s).
Authentication based on phone numbers is either Dialed Number Identification Service

(DNIS) or Automatic Number IdentificatiodCalling Line Identification (ANUCLI). This
is authentication based on the number dialed (server's number) or number dialed from
(client's number), respectively. Use these options in the RRAS policy profile to control
access.
The default unauthenticated access account is the Guest account. Enable the account if
you wish to use this feature. If you desire a different account, add a REG-SZ value
named "Default User Identity" to the following registry key:
HKLM\System\CurrentControlSet\Senl-ices\liemoteAccess\Policy.
Server-LeveI Permitted uthentication

You must ensure that your desired authentication protocol is permitted at the server-level
property sheet for acceptable authentication methods. To do this, right-click your RRAS
server > Properties > Security tab > Authentication Methods button > (un)check your
(un)desired authentication protocols. Conversely, if you want to ensure that MS-
CHAPv1 is never used, uncheck the box for that method here.
sing a IUS Server to uthentication

A RRAS server can be a client to a RADIUS server. In this case, the RRAS will
outsowce its authentication to the central RADIUS server. Please see the sections below
on RADIUS, NPS and Logging for more information and configuration steps.
0Mandatory (RRAS: Authentication): Only allow MS-CHAPv2 or EAP-based

authentication methods for dial-up or VPN access to RRAS. All other authentication
methods should be considered obsolete. MS-CHAPv2 or better is required for PPTPv2
support, and you must use PPTPv2 if you plan to support PPTP at all (never use plain
MS-CHAP with PPTP). If possible, prefer PEAP-TLS over MS-CHAPv2.
17 Mandatory (RRAS: Authentication): Even MS-CHAPv2 is vulnerable to password

hash sniffing, hence, it is critical that you enforce the toughest passphrase policy your
users can endure. This is especially important for PPTPv2 VPNs. Keep in mind that
passphrase length is more important than complexity. If possible, require at least 25
characters.
SANS Institute
- RRAS dial-up servers

- IIS web sites
- Terminal Services (2003)
- Into your desktop
The Extensible Authentication Protocol (EAP) is an extension of the PPP protocol for
negotiating a variety of authentication methods (RFC 2284). EAP is extensible in that
vendors can produce custom authentication modules and simply plug them into EAP
without making changes to PPP itself. EAP is not an authentication method itself, rather,
it is a protocol for negotiating which authentication method to use.
Windows supports two EAP-negotiated authentication methods by default:
EAP-MDS
EAP-TLS
EAP-MDS is actually just plain CHAP and exists for testing purposes and RFC
compliance. It is not more secure than using straight CHAP. Don't use it.
EAP-TLS is the same Transport Layer Security authentication used with HTTPS. TLS is
the next version of SSL (see RFC 2246). TLS uses an exchange of X.509~3digital
certificates to mutually authenticate communicating parties.
ote: EAP-TLS is only supported on RRAS servers which are domain members,
native or mixed. EAP-TLS is not supported on stand-alone RRAS servers.
SANS Institute
uthenticat ion
EAP-TLS supports logon with X . 509~3digital certificates. These certificates can either
be stored on a userk smart card or in the Certificate Store on the user's computer. EAP-
TLS with a smart card is the strongest authentication method available on RRAS.
Smart card EAP-TLS has the same implementation requirements as regular smart card
logon, namely:
A computer certificate installed on the RRAS server issued from a Windows CA

using a template that supports the Server Authentication purpose, e.g., the
Computer, Domain Controller or Web Server templates.
The user must have a smart card loaded with a certificate fiom a Windows CA
using either the Smartcard User or Smartcard Logon templates.
Both server and client must be configured to trust the CA which issued each
otherk certificate.
The RRAS server must be able to contact a mixed- or native-mode domain
controller which contains the user's account. The RRAS server cannot be a stand-
alone.
RRAS servers can acquire computer certificates either through computer auto-enrollment
with an Enterprise CA or from an administrator by hand using the Certificates snap-in.
Clients can obtain a smart card certificate either by hand using the Certificates snap-in or
rely upon an "enrollment agent" to load the smart card for them.
To configure EAP-TLS on the RRAS server, first EAP must be enabled and then a policy
must be configured to permit EAP-TLS.
To permit EAP on the RRAS server, right-click the server in the RRAS snap-in >
Properties > Security tab > click Authentication Methods > check the box for Extensible
Authentication Protocol (EAP) > OK > OK > No.
SANS Institute
To configure a RRAS Policy Profile to accept EAP-TLS, double-click a policy in the

Network Policies container in the NPS snap-in > Constraints > Authentication Methods >
Add > select "Microsoft: Smart Card or Other Certificate" > OK > highlight the new
"Microsoft: Smart Card or Other Certificate" option > Edit > select the computer certificate
for this RRAS server > OK > OK.
ev ec
By default, RRAS will check the Certificate Revocation List (CRL) for the certificate the
client presents to ensure that the client's certificate has not been revoked. If the certificate
has been revoked or if the CRL is unobtainable, the RRAS server will reject the
connection attempt.
To disable CRL-checking for EAP-TLS authentication, set the following registry value to
one:
Hive: HKEY-LOCALMACHINE
Key: \SY STEM\CurrentControlSet\Sewices\RasManWPP\EAP\13\
Value Name: IgnoreRevocationOffline
Value Data: 1 or 0 (default: 0, set to 1 to disable CRL-checking)
There are other registry values available to further fine-tune how certificate
authentication is handled. Do a Google search of the above registry value's name to find
the page on Microsoft's site where they are discussed.
ices
Recommended (RRAS: Authentication): Use certificate-based EAP-TLS
authenticationfor very secure authentication to RRAS. The user's certificate can be
stored in his or her smart card for added security. Other EAP-based authentication
modules can be purchased from third-party vendors.
SANS Institute
144 IPSec. RADIUS. Wireless, and VPNs
- Idle Timeout
- ADSL/IDSL/SDSL - Maximum Session
- G.3Fax - Dayofweek
- Virtual (VPM) - Hoursof Day
- Async ( ~ ~ ~ ~ ~ r n ~
- Sync (T-I Line)
..
The settings on the Dial-In Constraints tab are fairly self-explanatory, except for the
restriction on dial-in media.
This setting will disconnect a client who has not initiated any transmissions during the
last Xnumber minutes. Packets sent from the server to the client do not affect the idle
timer.
aximum Session To
This setting puts an upper limit on the number of minutes a client can stay connected per
session. If disconnected, a user will have to dial or VPN back in, but there may be
dayhime restrictions which block the attempt.
ccess To The
By clicking the Edit button, the exact daydhours remote access are permitted can be
specified. This is where time restrictions should be enforced. There is a RRAS policy
Condition named Day-And-Time-Restrictions, but the hours "permitted" in the Condition
are only for matching connection attempts with policies, not actually permitting or
denying access.
SANS institute
es is
When a remote client dials in over a phone line, the number dialed must match the
number specified here or else the connection will be dropped. This option is intended for
modem pools. It is also useful when creating a policy that will deny all dial-in attempts:
set the number to one which corresponds to no existing port on the server.
The media is the method the client is using to connect to the RRAS server, e.g., ADSL,
X.25, analog modem, etc. Each permitted media type must have a checkmark next to it
to allow remote access clients to connect over that media. If the checkbox for the entire
category, "Restrict Dial-In Media", is unchecked, then any medium is allowed.
I
Note that "Virtual (VPN)" is one of the media types. Hence, one profile could apply to
remote users dialing directly into the server via ISDN, while another would be for just
VPN clients coming in through the Internet.
es ices
0 Paranoid (RRAS: Constraints): Consider restricting the days and hours when users
are permitted to dial or VPN into the LAN to those times when security personnel are
present who can respond to incidents or IDS alerts.
SANS Institute
- No Encryption (0-bit)
- Basic (40-bit)
- Strong (56-bit)
- Strongest (128-bit)
- Passphrase
- Smartcard
The Encryption tab configures overall data encryption levels. The tab is humorously
sparse because it is intended to cover both PPTP and L2TPIIPSec.
No Encryption will permit, but not require, cleartext communications. Uncheck

the box to prevent unencrypted sessions.
Basic will permit, but not require, 40-bit RC4 with PPTP connections, and 56-bit
DES with L2TP/IPSec. (The documentation says 40-bit DES, but this is
incorrect: KB24448 1.)
Strong will permit, but not require, 56-bit RC4 with PPTP connections, and 56-
bit DES with L2TP/IPSec. Uncheck the box to prevent its use.
Strongest will permit, but not require, 128-bit RC4 with PPTP connections, and
168-bit 3DES with L2TP/IPSec. If you wish to require Strongest encryption,
uncheck all other boxes and verify that all peers have the High Encryption Pack
installed.
56-bit keys are widely considered to be insecure for any purpose other than thwarting
casual eavesdropping on low-sensitivity communications (and 40-bit keys are completely
insecure). Hence, use Strongest encryption --128-bit RC4 or 168-bit 3DES-- if at all
possible.
SANS Institute
L2TP uses IPSec for its encryption. Dial-up and PPTP VPN connections, on the other
hand, use MPPE for their encryption: the Microsoft Point-to-Point Encryption protocol
(search "mppe" at http://www.ietf.org for more information).
MPPE uses the RC4 cipher with the key lengths described just above. The keys are
derived from a SHA-1 hash of the user's password and other (known or deterministic)
elements extracted the MS-CHAP authentication sequence. Also, if MS-CHAPv2 is
used, then two different encryption keys are employed: one for securing data sent to the
client, and another for data sent9om the client. If MS-CHAPvl is used, then a single
RC4 key is employed for encryption in both directions; this is a significant weakness.
Hence, two factors determine the strength of MPPE encryption: 1) whether or not MS-
CHAPv2 was the authentication protocol, and 2) the length and randomness of the user's
passphrase. An MPPE RC4 key might be 128 bits long, but these are not random bits,
but bits ultimately derived from a passphrase.
portant! The Achilles' Heel of MPPE RC4 encryption is that its keys are
password-derived. Hence, use MS-CHAPv2 and enforce strong password policy!
ote: For an independent analysis of MPPE and MS-CHAPv2, see the article by
Bruce Schneier and Mudge at http://www.counterpane.com/pptpv2-paper.htrn1.
This is a different paper than their original analysis of PPTPvl and CHAPv1.
ry (RRAS: Encryption): When using PPTP, the strength of the encryption

on a user's VPN tunnel is mainly determined by the length and randomness of the user's
passphrase. Hence, enforce the toughest password policy your users can endure, e.g., a
minimum of 25 characters in length. Alternatively, use EAP-TLS certificate authentication
with PPTPv2 and the keys for tunnel encryption will be randomly derived.
Recommended (RRAS: Encryption): Require the strongest available encryption for

the remote access sessions of Domain Admins and other sensitive users. In low- to
medium-security environments, regular users can be permitted to use just strong
encryption, if necessary. "Strongest" encryption is 168-bit 3DES with IPSec and 128-bit
RC4 with PPTP, or better. "Strong" encryption is 56-bit DES with IPSec and 56-bit RC4
with PPTP, or better.
SANS Institute
- IPv4 and IPv6

- Static rules only.
- Not dynamidstateful.
- RRAS Pool
The IP tab of the profile controls how the client is assigned an IP address and how packet
filters are configured for the client.
Speafy the client 1P address a assignment ides forthts policy
r Server must supply an IP address
t-' Client may request an IP address

I$' Sewer settings determine IP address assignment
t-' Assign a static IPv4 address
To configure IPv6settings. go to the Standard page of RADIUS Attributes.
When a remote access client connects, it must have an IP address which is interoperable
with the RRAS server and perhaps the server's LAN too. The IP Address Assignment
policy controls this:
Server Must Supply an IP Address: an IP address for the client will come
either from DHCP or the RRAS server's own pool of addresses, but the client
cannot choose its own IP address.
Client May Request an IP Address: if the client does not choose its own IP
address, the server will assign one from DHCP or its own pool.
SANS Institute
olicy: the default IP address options on the property

mer itself in the snap-in will control assignment.
address: enter the IP address to be assigned.
ic se
Each profile can have its own separate packet filtering rules for both inbound and
outbound packets for just the clients who connect under the policy. This filtering is
different than the standard interface filtering (discussed later) or the filtering provided by
IPSec.
Packet filters are defined as exceptions to either a pennit-all or deny-all policy. Multiple
filters can be defined. Filters can permit/deny packets based on the following criteria:
Direction of travel: to or from client.

Source or destination IP address(es): individual IP or subnets.
Protocol type: TCP, UDP, ICMP or any protocol type number.
Source or destination port number: TCP or UDP.
ICMP type or code.
Per-user packet filtering is a terribly nice feature. For example, the Sales group might
have its own RRAS profile; this profile would filter the packets of Sales members so that
they can only connect to the e-mail server and the sales department database when they
VPN into the corporate network; the profile for the Administrators group, on the other
hand, might have no special packet filters; each group could have its own set of filters.
The Multilink tab does not directly concern security. "Multilink" is a feature of PPP
which allows a dial-up client to use multiple ISDN or phone connections in parallel for
greater bandwidth. The Bandwidth Allocation Protocol (BAP) is used to ensure that
ports and bandwidth is not wasted.
ssi
When distributing IP addresses to clients through RRAS from a DHCP server, DHCP
options such as DNS and WINS settings are not distributed to the clients. Rather, the
DNS/WINS settings from the RRAS server's internal interface are distributed instead. If
you wish to obtain all options from the DHCP server you must make the RRAS box a
DHCP Relay Agent (KB232703).
S: IP): Use RRAS Policies to filter the packets of remote users in

accordance with the principle of least privilege. Domain Admins will likely need unfiltered
access, but members of the Sales group, for example, might only need access to the e-
mail server or to a certain database server. lf another group only needs access to a
Terminal Server, for instance, then block all packets except TCP/3389 to just that server.
SANS Institute
150 IPSec, RADIUS. Wireless, and VPNs
RRAS can perform packet filtering on each of its interfaces, whether the interface is
physical, virtual or dial-up. RRAS can also perform dynamic filtering on each interface
with the same technology as the Windows XP Internet Connection Firewall.
There are two ways of configuring RRAS packet filtering:
With the connection profile of the dial-up or VPN client, so that the filter only
applies to the packets to/fiom that client and is enabled on-the-fly.
On the interface itself, so that the filtering is always enforced no matter the source
or destination of the packet traveling through it.
We have already discussed connection profile packet filters for dial-up and VPN clients
(see above). The following concerns interface-based packet filtering.
olicy-Based) acket Filtering

Interface-based filtering can be based on any of the following features of packets:
direction of travel (in or out of the interface)

protocol type (TCP, TCP established, UDP, ICMP, protocol number)
source/destination addresses (single, subnet, supernet)
source/destination port numbers
fiagmentation state (drop fragmented packets)
SANS Institute
Packet filtering is configured with the RRAS snap-in, IP Routing > General container.
Ensure that the checkbox "Enable IP Router Manger" is enabled or else no TCP/IP
packets will be permitted through the interface at all.
1
To configure static packet filters on an interface, open the RRAS snap-in > double-click
the desired RRAS server > IPvX> General container > right-click the desired interface >
Properties > General tab > click either Input Filters or Output Filters, depending on the
direction of travel of the packets you wish to filter.
"Enable Fragmentation
Checking" will discard all
in-coming packets which
are fragmented. Use with
caution to prevent a self-
inflicted DoS attack.
Next, click Add and configure the filter to match the packets you wish to accept or block >
OK. The interface support super- and subnetting techniques, TCP and UDP ports, ICMP
types and codes, or raw protocol ID numbers. Leave a port field blank to indicate "any
port".
SANS Institute
Protocols include:
TCP, UDP, TCP
established sessions,
ICMP, Any protocol,
and Other protocol ID
number.
At the top, choose the default policy for which your filter defines an exception > OK.
ows Server 2003 Dynamic Filtering and

Windows Server 2003 provides dynamic filtering using the same technology as is used in
the Windows XP Internet Connection Firewall. When combined with Network Address
Translation (NAT), Windows 2003 can provide a basic but effective firewall. These
capabilities were removed in Server 2008 because vastly superior filtering is provided by
the Windows Firewall, which can (and should) be enabled at the same time as RRAS.
To add dynamic packet filtering to an interface, right-click on the IP Routing\General

container in the RRAS snap-in and select New Routing Protocol > NAT/Basic Firewall >
OK. A new “NAT/Basic Firewall” container will appear under General. Right-click the
new NAT/Basic Firewall container > New Interface > select the desired interface > OK >
SANS Institute
select “Public Interface Connected To The Internet” if you want NAT, or select “Basic
Firewall Only” if you only want dynamic filtering > OK.
Using NAT is optional; both the static and the dynamic filtering (“Basic Firewall”) can
be enabled separately from it. If you do enable NAT, though, you can designate a range
of shared IP addresses RRAS should use for its Internet-facing interface. You can also
reserve some of these public IP addresses and map them to particular private IP addresses
inside the LAN.
If you want to perform more customizable dynamic filtering and stateful inspection on
the traffic going through your VPN tunnels you’ll have to install Microsoft’s Threat
Management Gateway (TMG), previously lcnown as Internet Security and Acceleration
Server.
IPSec packet filtering occurs at a lower level in the protocol stack than the filtering
performed by REUS. A bastion host in the DMZ might use both, but it is probably better
to choose one method and use it exclusively
ote: It is important to have Service Pack 1 or later applied on Windows 2000 in

order for RRAS packet filtering to interoperate correctly with IPSec (IU3257949).
SANS institute
There are two places where L2TP/PPTP packets can be filtered for security:
At the firewall.
By the RRAS service itself.
The firewall can be another RRAS server or any other static packet-filtering product. A
stateful or dynamic firewall is not necessarily required because of the simplicity of the
filtering rules.
The RRAS server should be behind a firewall, but it can provide its own packet filtering
alone if necessary (not recommended). Alternatively, filtering can be carried out both at
the firewall and on the RRAS server itself for added security.
L2TP Packet Filters On The Firewall

L2TP uses IPSec ESP in transport mode for its encryption, hence, UDP 500 is required
for IKE and protocol ID 50 for ESP. AH has a protocol ID number of 5 1.
L2TP Input Filters

Drop all incoming packets destined for the RRAS server except the following:
Destination UDP port 500 (OxOlF4).
Protocol ID 50 (0x32).
utput Filters
outgoing packets destined for the RRAS server except the following:
Source UDP port 500 (OxOlF4).
Protocol ID 50 (0x32).
Note: The filtering of out-going packets is particularly important to ensure that

L2TP packets do not escape in cleartext. This may happen if dynamic Rules are
cleared or if static Policies have been misconfigured.
acket Filters In RR
The IPSec protocol driver decrypts packets and strips off ESP headers before passing
packets up to the RRAS service. Since RRAS is doing the packet filtering itself, its
filters ignore the (stripped) protocol ID 50 ESP header and must instead filter on the
L2TP UDP port 1701. Again, by the time the RRAS service receives the L2TP packet,
the packet is in cleartext.
L2TP Input Filters

Destination UDP port 500 (OxOlF4).
Destination UDP port 1701 (Ox6A5). i
Drop all outgoing packets destined for the RRAS server except the following:
SANS Institute
Source UDP port 500 (OxOlF4).

Source UDP port 1701 (Ox6A5).
ote: Do not block fragmented UDP 500 packets when using certificate
authentication. Certificates are often fragmented during transit.
eri
Additionally, for a router-to-router VPN, the firewall and/or RRAS servers should drop
all packets which are not to or from the other RRAS server. Only the two IP addresses of
the RRAS servers should be permitted between them.
ec
The default authentication protocol is Kerberos (UDP and TCP port 88). Two peers
might wish to use IPSec over the Internet when they are separated by one or more
firewalls, e.g., two domain controllers might use IPSec to provide additional security for
their RPC-based replication over the Internet. However, it is undesirable to open a
firewall to Kerberos traffic.
The best alternative is to use certificate authentication. IPSec peers can authenticate with
digital certificates since this authentication occurs over IPSec itself. Also, certificate
authentication works more reliably than Kerberos over slow connections.
ote: Do not filter out fragmented UDP 500 or UDP 4500 packets at the firewall
when using certificate authentication. The certificate data is often fragmented.
ess
IPSec is incompatible with any service or device that modifies any section of the packet
authenticated/encryptedby AH or ESP. Hence, packets authenticated with vanilla AH
cannot go through NAT routers or through proxy servers that perform NAT. This is true
for both transport and tunnel mode.
Nor can ESP in transport mode traverse NAT routers even though the IP header is not
authenticated by ESP. The reason is that ESP authenticates and encrypts the UDP/TCP
transport layer, and the checksum in the transport layer covers the source and destination
IP addresses in the network layer, i.e., the IPSec hash of the UDP/TCP checksum of the
network layer data is an indirect hash of that data as well.
ESP in tunnel mode, however, is compatible with NAT because the entire original packet
in encapsulated behind the new IP header forged by ESP; hence, neither the original IP
header nor the original UDP/TCP header is modified by the NAT router.
Keep in mind, though, that if the NAT router or proxy server is also IPSec-enabled, then
it is possible for that router to use both NAT and all types of IPSec. In this case, the
NATing router must be one of the end-point IPSec peers, i.e., it is not merely forwarding
the IPSec packets of other peers, rather, it has established its own separate SAs with other
SANS Institute
peers. Since the router is doing the encryptioddecryption and hashing itself, it can
perform these operations independently of its NAT-ing.
For example, a client could establish an IPSec session with a NATing router; the client
forwards a packet to the router through this session; the router decrypts and authenticates
the packet; the router could open a second, separate IPSec session with the destination
machine; the cleartext packet is then re-encrypted to the second IPSec session and
forwarded to the destination. All the NATing is done while the packet is in cleartext.
The downside is that there is not an end-to-end secure IPSec channel between the two
computers; if the router is compromised, the cleartext packets could be recorded or
modified while in the RAM of the router.
UDP Encapsulation of IPSec ESP for NAT Traversal (NAT-T)

Windows Server 2003 natively supports “IPSec NAT Traversal (NAT-T)” (but see KB
885348). IPSec NAT-T is an IETF-sponsored enhancement which encapsulates ESP
traffic behind a UDP header injected on-the-fly to solve the NAT problem. Because the
injected UDP header can be modified by NAT, it can pass through NATing routers and
proxy servers without problems. The UDP header will include the original source and
destination IP addresses and port numbers, hence, the original packet can be
reconstructed and authenticated at the destination even if multiple NAT devices have
modified the packet. This technique currently works only for ESP, however, not AH.
UDP encapsulation works in both ESP transport and tunnel modes.
The IKE protocol has been modified so that each IPSec NAT-T peer can 1) determine
that the other peer supports NAT-T and 2) that indeed a NAT device stands between the
peers. When there are no intermediary NAT devices, regular IPSec will be used and the
UDP encapsulation is omitted. There are no checkboxes or dialog boxes to view to
enable or configure NAT-T, it simply works invisibly.
IPSec NAT-T also permits the use of different IKE port numbers besides UDP 500. UDP
4500 is the preferred port when NAT-T is engaged. Hence, if you are filtering to allow
IPSec through a firewall, you will need to allow UDP 4500 as well.
NAT-T for Windows 98/Me/NT/2000/XP

As described in KB818043, a patch is available for Windows 2000/XP to enable support
for NAT-T in those operating systems as well. Service Pack 2 for XP and Service Pack 4
for Windows 2000 enable NAT-T support, but only for these operating systems acting as
clients. A Windows 2000 RRAS VPN gateway cannot use NAT-T, you must upgrade to
Windows Server 2003 or later.
Be aware that hardware acceleration is typically not available when NAT-T is used to
enable IPSec sessions to traverse NAT devices. If your hardware acceleration device was
not specifically designed for NAT-T, it is unlikely that NAT-T will be compatible with it.
You can still use NAT-T and IPSec with the offload card, but the card may not be able to
perform the encryptiodhashing itself. It depends on the card and the vendor.
SANS Institute
NAT-T is also a feature of the L2TP/IPSec VPN Client for Windows 98/Me/NTW. The
L2TP Client can be downloaded for free from Microsoft's website; just do a search on
the phrase "Microsoft L2TP/IPSec VPN Client". It was last seen at the following URL:
http://www.microsoft. comlwindows2000/server/evaluation/news~ulletins/l2~client.asp.
Importantly, the L2TP/IPSec VPN Client does not add general-purpose IPSec
functionality to Windows 98/Me/NTW, it is only for L2TP VPNs.
SP2 for Windows X P disables the NAT-T feature in the name of better security (KB
885348). However, there is a DWORD registry value which can be set to restore the pre-
SP2 NAT-T behavior.
It is located under HKLM\System\CurrentControlSet\Services\IPSec\ and the value is

named AssumeUDPEncapsulationContextOnSendRule. The default is 0, which disables
NAT-T. Set to 1 and the VPN gateway can be NATed, but the client cannot, i.e., the
client must have an Internet-valid IP address. Set to 2 and both peers can be behind
devices that perform NAT. (Of course, the real effect of disabling NAT-T is to incline
people to use PPTP, which is much less secure than a properly authenticated and
encrypted IPSec/L2TP VPN tunnel, even if packets are being NATed.)
datory (RRAS:Firewall): Your firewall should filter both the VPN packets
streaming into your RRAS gateway from the Internet and the clear-text packets coming
out of the VPN tunnel on their way into the LAN. Don't route or bridge users' packets
coming through the VPN into the LAN without first passing them through another layer of
firewall filtering. This layer of filtering might be implemented on the RRAS gateway itself
(not ideal), by passing the users' packets back through the main firewall again (better), or
by implementing another internal firewall behind which the RRAS gateway sits (best).
Sitting behind this internal firewall might also be your 802.1 1 wireless access points,
other dial-up servers, routers with WAN links to remote sites, etc.
andatory (IPSec: Firewalls): When planning your IPSec rollout, you must take into
consideration any routers, proxy servers or firewalls in your environment that perform
Network Address Translation (NAT). IPSec has complex NAT compatibility issues. The
best general solution to the NAT problem is to use IPSec NAT-Traversal (NAT-T) as
described in KB818043. NAT-T is available for Windows 2000 and later, but Windows
2000/XP do not support it by default, they require free software upgrades, and Windows
2000 RRAS VPN gateways cannot use NAT-T at all, only Windows Server 2003 or later
RRAS can. Be aware that XP-SP2 disables NAT-T by default, but it can be re-enabled
through a registry value modification. However, there is rare exploit associated with
NAT-T that can make it unacceptable in high security environments (KB885348).
Recommended (IPSec: Firewalls): When using IPSec certificates to authenticate

through a firewall, the firewall cannot filter out fragmented UDP 500/4500 packets
because the size of the certificates often causes packet fragmentation.
Recommended (RRAS: Firewall): If you have deployed Intrusion Detection System

(IDS) sensors on your LAN, place a sensor on the segment(s) through which VPN, dial-
up and wireless packets are routed.
SANS Institute
0 Recommended (RRAS: Firewall): Consider distributing CD-ROMs to your users with

anti-virus and personal firewall software which they can install and use on their corporate
laptops and personal computers at home (get enterprise licenses first, of course).
Consider including a script on that CD which makes other desirable configuration
changes, but make sure it doesn't break their critical applications, e.g., Solitaire, Quake,
Pinball, etc. Windows XP Service Pack 2 and later automatically installs and enables the
Windows Firewall, so apply SP2 or later to XP as soon as possible.
17 Recommended (RRAS: Firewall): Train users how to use the Windows Automatic
Updates feature and encourage (or beg) them to use it regularly on their personal
systems at home. If possible, encourage their use of Windows XP or later with the latest
Service Pack. Use Group Policy to push out custom Windows Firewall settings or use a
NETSH.EXE script to do the same.
17 Recommended (RRAS: Firewall): Consider setting up a Microsoft Terminal Server,

Citrix Server, or some other "thin-client" server for your users. Next, block all your users'
dial-up and VPN packets except the necessary packets to/from the thin-client server.
Enforce strong password policies and don't forget that Group Policy applies to virtual
desktops too.
17 Recommended (RRAS: Firewall): As much as feasible, prevent users from

modifying their route tables to do "split tunneling", that is to say, prevent them from
changing their default gateways in their route tables to anything other than the VPN
tunnel itself. This may require a third-party product or a corporate policy that prevents
users from having local administrative access on their computers. RRAS quarantine
mode will help in this effort.
0 Recommended (RRAS: General): Don't forget that RRAS can do its own packet
filtering on each of its interfaces, and dial-upNPN connections are considered
"interfaces" in this regard. Hence, filter these packets in accordance with the principle of
least privilege. Windows 2000 RRAS provides only static filtering, but Windows Server
2003 includes XP-style dynamic filtering as well. For even more packet control from a
Microsoft product, install Internet Security and Acceleration Server (ISA Server).
SANS Institute
RRAS account lockout is not related to the "Account Locked Out" setting on the Account
tab of a user's property sheet. Nor is it the same as lockout policies as defined through
Group Policy.
RRAS account lockout is triggered when a remote user guesses too many incorrect
passwords, as specified by the administrator. After an administrator-configurablenumber
of minutes, the counter for bad passwords is reset to zero. When an account is locked out
in this way, it is only locked out for VPN or dial-up connections, not regular logons
sitting at a workstation.
arning! Enabling remote access account lockout opens a Denial of Service

Attack vulnerability. Attackers can deliberately lock out accounts if they
know/guess that the feature is enabled and the lockout period is long.
After too many bad logon attempts, the remote user will see the following dialog box:
SANS Institute
RRAS account lockout is enabled on the RRAS or IAS server by setting the MaxDenials
value to a number greater than zero. The number specifies how many bad passwords can
be entered before lockout is triggered.

Key: \SY STEM\Curre&tControlSet\Services\RemoteAccess\ -
Parameters\AccountLockout
Value Name: MaxDenials
Value Data: 0 - 15000 (default is 0, which implies no lockout)
To configure how many minutes must transpire before a user's bad-password counter is
automatically reset to zero, the "ResetTime (mins)" value can be edited. The default
value is 2,880 minutes (48 hours) and can be left untouched if this is acceptable.
Hive: HKEY LOCALMACHINE

Key: \SY STEM\CurrentContxolSet\Services\RemoteAccess\ __
Parameterskccountlockout
Value Name: ResetTime (mins)
Value Data: 0 - 15000 (default is 2880 in decimal: 48 hours)
Reboot or restart the RRAS service for the change to take effect.
When an account is locked out, a subkey in the form of \domainname:username is

created under the \AccountLockout key listed above. If you need to re-enable an account
before the reset timer does so automatically, delete the subkey corresponding to the user's
account.
If you received a CD-ROM with this manual, the CD has a script for configuring RRAS
account lockout and immediately re-enabling locked accounts.
est Practices
andatory (RRAS: General): Enable RRAS account lockout for failed remote access
attempts. Consider setting a threshold of five attempts for a 20-minute lockout to mitigate
DoS attacks while thwarting brute-force password guessing. These changes are made in
the registry of the RRAS or IAS server itself, not in Active Directory.
SANS Institute
- Compatible with NAT, IPv6, NLB, CMAK and NAP.
indows Vista+SPI , Server 2008, or later.
Windows Server 2008 and Windows Vista'rSPl include support for a new VPN protocol
named "Secure Socket Tunneling Protocol (SSTP)". SSTP does not use PPTP or
L2TP/IPSec. SSTP encapsulates packets in standard Point to Point Protocol (PPP),
encodes the PPP data as the payloads of HTTP packets, then encrypts this HTTP with
SSL/TLS. SSTP traffic on the wire looks like standard SSL/TLS operating on TCP port
443. To the user, an SSTP VPN looks and behaves no differently than a PPTP or
L2TP/IPSec VPN, so there's no special user training required. SSTP is a standard part of
the built-in RRAS service. In short, SSTP is Microsoft's implementation of a full "SSL
VPN" using RRAS.
Advantages of SSTP on RRAS include the following:
SSTP is compatible with NAT, IPv4 and IPv6, both "inside" and "outside" the
tunnel. For example, IPv4 is used with the "outer" SSL packets to get to the
RRAS box, but inside the tunnel are IPv6 packets that get NATed at RRAS.
For load balancing, SSTP is compatible with DNS round robin, Windows NLB,
and hardware-based SSL load balancers with the SSL enabled or disabled on the
RRAS boxes.
RRAS can use RADIUS policies for SSTP connections just like for L2TP/IPSec.
S A N S Institute
The Connection Manager Administration Kit (CMAK) can create SETUP.EXE

installer programs for SSTP connectoids just like for L2TP/IPSec and PPTP.
Third-party EAP authentication modules are also supported, such as RSA

SecurID tokens, biometric devices, smart cards, etc.
SSTP connections are compatible with and can be regulated by one's Network
Access Protection (NAP) infrastructure. This means the "health" of the SSTP
client can be verified before permitting remote access.
In contrast to IPSec and PPTP, SSTP can better traverse firewalls and devices performing
Network Address Translation (NAT). Virtually all firewalls, whether this is foolish or
not, allow TCP/443 traffic without regard to IP address, hence, SSTP will usually not be
blocked by the firewalls of corporate perimeters, ISPs, hotels, airports, coffee shops, etc.
IPSec can have issues with NAT, especially when double-NATing occurs, but SSTP
should suffer very few of these problems.
To use SSTP, the following requirements must be met:

RRAS gateway be running Windows Server 2008 or later.
RRAS gateway must have an appropriate SSL/TLS certificate installed.
VPN client must be Windows Vista + SPl, Windows Server 2008, or later.
Client must trust the root CA of the SSL/TLS certificate installed on the gateway.
Client must have a connectoid configured to use SSTP instead of PPTP or IPSec.
It is possible that a patch or Service Pack will be made available for Windows XP/2003
to add support for SSTP, but this hasn't been promised and will likely never be released.
The client does not require an SSL/TLS certificate (it can authenticate with a standard
username and passphrase) but a user certificate can optionally be installed and used with
EAP-TLS or PEAP-TLS authentication. This is because user authentication is handled
by the PPP layer, not the SSL/TLS or HTTP layers. The certificate on the RRAS
gateway must support the "Server Authentication" or "All-Purpose" enhanced key usage
restriction, which is standard on SSL/TLS certificates.
You do not have to install 11s on the RRAS box. RRAS uses the HTTP.SYS driver
directly without 11s as an intermediary. 11s and RRAS can co-exist on one box, if
desired, because SSTP uses a unique URI, "/sra-(BAl95980-CD49-458b-9E23-
C84EEOADCD75)", and a special HTTP request verb, "SSTP-DUPLEX-POST".
If you want to allow outbound SSTP connections, but your proxy server requires
authentication before Internet access is permitted (which is a very good idea), be aware
that SSTP does not support authentication to proxies (so we're stuck for now).
SSTP does not currently support site-to-site VPN connections.
SANS Institute
Assuming you have an SSL/TLS certificate installed, support for SSTP as a VPN
protocol is enabled by default in RRAS. You can see the SSTP ports in the Ports
container. You still need to configure the RADIUS policies on the Network Policy
Server (NPS) to allow the connection though, but these steps are the same whether it is
L2TP/IPSec, PPTP or SSTP.
On the client, you'll create a VPN connectoid like normal (discussed elsewhere in this
manual), but then you'll configure the connectoid to use SSTP afterwards. This is done
by going to the Networking tab in the properties of the connectoid.
SANS Institute
To configure a VPN connectoid to use SSTP, open Control Panel > Network And Sharing
Center > Manage Network Connections link on left-hand side > right-click the VPN
connectoid you had created earlier > Properties > Networking tab > at the top select
"Secure Socket Tunneling Protocol (SSTP)" > OK.
iscellaneous
To change the TCP port number used for SSTP, open regedit.exe and navigate to
H~M\System\CurrentControlSet\Services\SstpSvc~arameters\, then change the
ListenerPort value to the port number desired. In that same key, you can set the
UseHTTPS value to zero in order to support SSTP in plaintext without SSL. However,
the client can only connect to TCP/443 using SSL, so these registry values are for dealing
with firewall, NAT, proxy or SSL load-balancer issues on the RRAS network.
To block outbound SSTP from within your network, force all outbound HTTP/HTTPS
connections through a proxy server, such as Microsoft ISA Server. When the SSTP
client sends the CONNECT request to the proxy, the request will include a custom header
in plaintext named "SSTPVERSION:" which can be detected by the proxy and used as
the basis for denying the request. You can also block outbound SSTP by requiring
authentication at the proxy for all Internet access; SSTP currently does not support
authentication to proxy servers at all. The SSTP client picks up the proxy information
from the proxy settings in IE.
ore lnformatio
For more information about SSTP, Google on "site:microsoft.com sstp" and check out the
RRAS blog at http://blogs.technet.com/rrasblog/.
SANS Institute
The following are the fewest steps necessary to configure a host-to-router VPN. There
are many more configuration options available --as always-- but the following are the
minimal steps (configuration in a nutshell).
Except for installing the computer certificate, the steps are virtually identical for using
either PPTP, L2TP/IPSec or SSTP.
IP addresses for clients are obtained either from a DHCP server or a pool of addresses
configured on the RRAS server itself. If a pool of addresses is configured, take care to
ensure that the addresses are all valid for the LAN subnet to which the RRAS server is
attached. In this case, no route tables will need to be modified; the RRAS server will use
proxy-ARP and will bridge remote users' packets onto the wire. If a pool of addresses is
chosen for a different subnet, route tables on the RRAS server and perhaps other LAN
routers will need to be modified to forward packets destined for that new subnet to the
RRAS server. It is much easier to use DHCP and allow the RRAS server to bridge.
The following instructions assume that 1) the RRAS server has two interfaces, 2) one
interface is connected to the local LAN, 3) the other interface is connected to the Internet
with a valid IP address, 4) the RRAS server is configured as a client to one or more DNS
servers and zero or more WINS servers, and 5 ) the High Encryption Pack has been
applied.
SANS Institute
._
1) Install computer certificate and Root CA certificate (L2TP only).

A computer certificate is necessary for L2TP and SSTP, but not PPTP. The
RRAS server must also trust the Root CA which ultimately issued the certificate
and the certificate installed on the client host.
The easiest way to distribute computer certificates is with an Enterprise CA and

auto-enrollment for certificates based on the Tomputer" template. Similarly, the
best way to distribute trusted Root CA certificates is with Group Policy.
The Certificate Services website on the CA (http://servername/certsrv/) can also

be used. Select "Request A Client Authentication Certificate" > type the FQDN
of the RRAS server in the Name field > Advanced > select User Local Machine
Store in Properties, Server Authentication in Usage, Machine in Cert Type,
Microsoft RSA SChannel in CSP > OK > Submit Request > Download.
Another option is to use the Certificates MMC snap-in for the Computer Account
of the RRAS server. Right-click the Personal container > All Tasks > Request
New Certificate.
2) Enable "Remote Access Server" on RRAS.

In the RRAS snap-in, right-click the RRAS server > Properties > General tab >
check the box "IP Router'' > select "LAN and Demand-Dial Routing" > check the
box "IP Remote Access Server" > OK.
SANS Institute
addresses for clients from a server.

In the RRAS snap-in, right-click the RRAS server > Properties > IP tab > select
DHCP > select the Adapter at the bottom which is connected to the internal LAN
> check "Enable IP Forwarding" > OK. Keep in mind that, by default, the
WINS/DNS settings of this adapter will be inherited by the VPN clients, not the
WINS/DNS settings normally distributed through DHCP (to change this behavior,
make the RRAS box a DHCP Relay Agent).
If "Enable IP Routing" is not checked, remote clients will only be able to access
the RRAS server itself; RRAS will not route packets between interfaces.
4) Configure and/or ports.

In the RRAS snap-in, locate the Ports container > Properties > Devices tab >
select WAN Miniport (L2TP) > Configure > check both checkboxes > increase
the maximum number of ports you are willing to be active simultaneously, e.g.,
100 > OK > OK.
If both checkboxes are unchecked, this will disable all remote access over the
selected VPN protocol. Demand-dial connections are those initiated by either the
local or a remote RRAS server. Remote access connections (inbound only) are
initiated by users. The Phone Number for This Device field can be used for the
Called-Station ID number in connection policies, but the number will actually be
the IP address of the Internet-attached network adapter card on the RRAS server.
The number of available ports is used for capacity planning.
efine connection policies

As discussed in the sections above, RRAS connection policies, and user account
dial-in permissions, apply to VPN sessions as well. At least one policy must
match the VPN connection attempt.
These are the steps for manually creating a VPN connectoid. For all your users it is much
easier to use the Connection Manager Administration Kit and create a hands-free
installation program.
uter certificate an only).

A computer certificate is necessary for L2TP, but not PPTP. The VPN host must
also trust the Root CA which ultimately issued the certificate and the certificate
installed on the RRAS router.

auto-enrollment for certificates based on the Tomputer" template. Similarly, the
The Certificate Services website on the CA (http:/lsewer.name/certsrv/) can also

be used. Select "Request A Client Authentication Certifi,cate"> type the FQDN
SANS institute
of the VPN host in the Name field > Advanced > select User Local Machine Store
in Properties, Server Authentication in Usage, Machine in Cert Type, Microsoft
RSA SChannel in CSP > OK > Submit Request > Download.
of the VPN host. Right-click the Personal container > All Tasks > Request New
Certificate.
2) Make VPN connection icon.

Control Panel > Network and Sharing Center > Set Up A Connection Or Network
> Connect To A Workplace > Next > No, create a new connection > Next > Use
my Internet connection (VPN) > Next > enter the IP address, username, password
and other information necessary for the VPN connectoid.
3) Configure VPN connection icon.

Control Panel > Network and Sharing Center > Manage Network Connections >
Right-click the Virtual Private Connection icon just created > Properties >
Security tab > select Advanced (Custom Settings) > Settings button > select
Maximum Encryption from the pull-down menu for data encryption > uncheck all
boxes except Microsoft CHAP Version 2 (MS-CHAPv2) > OK > OK.
SANS Institute
i
Double-click the Virtual Private Networking icon just configured > enter your
usernaine and password > Connect.
You computer will connect to the VPN server, obtain an IP address, obtain
DNS/WINS server IP addresses, and change the local route table to make the
VPN server's LAN your default gateway. When you disconnect, your system will
reconfigure itself as it was before the connection.
SANS Institute
I
The following are the fewest steps necessary to configure a router-to-router VPN with a
persistent connection. Except for installing the computer certificate, the steps are
virtually identical for using either PPTP or L2TPAPSec.
Router-to-router VPNs require configuration of the route tables on each machine so that
packets will be correctly forwarded between the two networks. This can be accomplished
with a routing protocol, like OSPF or RTPv2, or by manually configuring static routes.
Routing protocols on RRAS are beyond the scope of this course. The steps below
describe how to create static routes.
of Configuration Steps
The essential configuration steps are:
Install computer certificates (L2TP only).

Configure VPN ports.
Define RRAS policies and profiles.
Create demand-dial VPN routing interfaces.
Create static routes in the route table.
Configuration Ste S-
The following instructions assume that both RRAS routers 1) have at least two interfaces,
2) one interface on each RRAS server is connected to the local LAN, 3) a second
SANS Institute
IPSec, RADIUS, Wireless, a n d VPNs 171
interface is connected to the Internet with a valid IP address, 4) each RRAS router is the
default gateway for all hosts on its LAN, and 5 ) the High Encryption Pack has been
applied.
The example includes two networks: Network A and Network B. Network A has a
network ID of 10.3.0.0/16 andNetwork B has a network ID of 10.6.0.0/16. The RRAS
router on Network A is named RRAS-A, and on Network B, RRAS-B.
A "virtual segment" between the two routers will have a network ID of 10.254.0.0/16.
On this segment, RRAS-A will have an IP address of 10.254.3.3, and RRAS-B will have
an IP address of 10.254.6.6. These are IP addresses assigned to VPN tunnel endpoints,
not physical interfaces.
nstall computer certificate and oot CA certificate (both routers;

A computer certificate is necessary for L2TP, but not PPTP. Each RRAS server
must also trust the Root CA which ultimately issued the certificate and the
certificate installed on the other RRAS box.

auto-enrollment for certificates based on the "Computer" template. Similarly, the
The Certificate Services website on the CA (http://SeTveTYZa~~e/certsrv/)

can also
be used. Select "Request A Client Authentication Certificate" > type the FQDN
of the RRAS server in the Name field > Advanced > select User Local Machine
Store in Properties, Server Authentication in Usage, Machine in Cert Type,
Microsoft RSA SChannel in CSP > OK > Submit Request > Download.
of the RRAS server. Right-click the Personal container > All Tasks > Request
New Certificate.
2) eman outing" on
In the RRAS snap-in, right-click the RRAS server > Properties > General tab >
check the box "IP Router" > select "LAN and Demand-Dial Routing" > check the
box "IP Remote Access Sewer" > OK.
SANS Institute
3) Enable IP Routing and Provide IP Addresses (both routers).

In the RRAS snap-in, right-click the RRAS server > Properties > IP tab > check
"Enable IP Forwarding" > OK. It doesn't matter whether the RRAS server has
DHCP or static pool selected since each RRAS box will request a pre-configured
IP address. Select DHCP if in doubt.
If "Enable IP Routing" is not checked, remote clients will only be able to access
the RRAS server itself; RRAS will not route packets between its interfaces.
SANS Institute
I
onfigure and/or ports (both routers).

In the RRAS snap-in, locate the Ports container > Properties > Devices tab >
select WAN Miniport (L2TP) > Configure > check both checkboxes > increase
the maximum number of ports you are willing to be active simultaneously, e.g.,
100 > OK > OK.
If both checkboxes are unchecked, this will disable all remote access over the
selected VPN protocol. Demand-dial connections are those initiated by either the
local or a remote RRAS server. Remote access connections (inbound only) are
initiated by remote hosts. The Phone Number for This Device field can be used
for the Called-Station ID number in connection policies, but the number will
actually be the IP address of the Internet-attached network adapter card on the
RRAS server.
efine connection policies (both routers).

As discussed in the sections above, RRAS connection policies and profiles apply
to VPN sessions as well. Remember, at least one Allow Policy must match the
connection attempt in order for it to succeed. For added security on a router-to-
router tunnel, consider only permitting the computer account of the other RRAS
machine to log in, require MS-CHAPv2, and require the "Maximum encryption"
level.
-dial interfaces (both routers).

In the RRAS snap-in, right-click on Routing Interfaces > New Demand-Dial
Interface > Next > enter the name of the local network ("Network A" or "Network
B") > Next > select "Connect using VPN" > Next > select either PPTP or L2TP >
Next > enter the external Internet-accessible IP address of the other router > Next
> check the boxes to "Route IP packets on this interface" and to "Add a user
account so a remote router can dial in'' > Next > if necessary, configure a static
route > Next > enter a long and complex passphrase for the other router to dial-
into the local router > Next > enter the username, domain and password created
on the remote router (in the prior step) > Next > Finish. (Note: If you're not
prompted to create a local account, create one by hand and give it a name which is
character-for-character identical to the name of the interface. In a two-way on-
demand VPN connection, the user account name on the local receiving gateway
SANS Institute
must be identical to the name of the VPN interface on the remote connecting
gateway.)
ame and password to be used when connecling to the remote

I
7) Configure security and 1P addresses on demand-dial interfaces (both routers).

In the RRAS snap-in, highlight Routing Interfaces > right-click the "Network
A/B" interface > Properties > Options tab > click "Persistent connection" >
Security tab > select Advanced > Settings button > select "Maximum strength
encryption" at the top > uncheck all boxes below except for MS-CHAPv2 > OK >
Networking tab > highlight Internet Protocol (TCP/IP) > Properties > select "Use
the following IF' address" and enter the appropriate address below for your router:
RRAS-A: 10.254.3.3
RRAS-B: 10.254.6.6
Then click OK > OK.
SANS Institute
able Configuration
In order for hosts on Network A to reach Network B, and vice versa, each router's
route table must be edited to include the path to the other router's network. This
can be done with RIPv2 or OSPF, but this example will use static route paths.
In the RRAS snap-in, open the IP container > right-click Static Routes > New
Static route > select your VPN interface (Network A/B) > enter the network and
subnet mask ID numbers for the remote network > OK. The following table lists
the correct settings for this example:
RRAS-A Interface Name Network A

I
RRAS-A Network ID 10.6.0.0 I
RRAS-A I Subnet Mask I 255.255.0.0
RRAS-B I InterfaceName I NetworkB
RRAS-B Network ID 10.3.0.0
RRAS-B Subnet Mask 255.255.0.0
On either router, open the RRAS snap-in and highlight Network Interfaces >
right-click the VPN interface to the remote network (Network A/B) > Connect.
After a few moments, the "Connection State" column should read Connected.
Test the link by pinging hosts on the remote network fiom various hosts on the
local network.
You can use the built-in Network Load Balancing (NLB) service to create a cluster of
two or more VPN servers for fault tolerance and load balancing (not just failover).
Multiple clusters can be used with DNS round robin load-balancing for even greater
throughput.
SANS Institute
,
The Network Connections folder is in Control Panel. Here you’ll find icons representing
your physical network adapter cards, dial-up connections, and VPN connections. The
icons for dial-up and VPN links are unofficially called “connectoids”. A connectoid
stores all the configuration settings related to the dial-up or VPN connection, and, when
double-clicked, will begin the connection sequence to establish the link. Once the link is
up, the operating system treats it like just another network adapter card.
. . . . . . . . . . . . . . . . . ...... - ....... .-
. . . . . . . . . . . . ............ -. . -”
G Address
........
1
1
-
3Network
__
......
and W - u p Ccmections
...... _____________
7
........
Name .’ I Type I Status I

Incoming Disconnected
LAM Nettwork cable unplugged
Connection pfianager Disconnected
Virtual Private Network Disconnected
The biggest problem with connectoids, though, is that they’re too difficult for regular
users to create. This is a major stumbling block for VPN roll-outs when there are
hundreds or perhaps thousands of remote users who need to connect. Moreover, if you
i
SANS Institute
do give these users the rights necessary to create connectoids, it means they can
reconfigure them to do bad things like save passwords or do “split tunneling”.
However, using the fi-ee Connection Manager Administration Kit (CMAK) that comes
with Windows Server, you can easily create a small SETUP.EXE program that will
create a pre-configured VPN connectoid for the user automatically. All you have to do is
distribute the program to your users and have them execute it. You can do this by e-
mailing it to them, placing it in a shared folder, having a link to it on a website along with
instructions, or by having a logon script automatically install it hands-free if it hasn’t
been installed already. This technique can be used to create a SETUP.EXE binary that
works on Windows 95 and later.
Once installed, the user will not be able to view or edit the properties of the connectoid.
You can also have custom programs or scripts executed that validate the user’s computer
prior to allowing them onto the network.
i The following will walk you through the process of installing the CMAK on Windows
i
Server and creating a VPN connectoid installation program. When in doubt about an
option being presented, click the Help button in the lower right-hand corner.
1. Install the CMAK on Windows Server 2008 and later by going to Server Manager
> right-click Features > Add Features > check Tonnection Manager
Administration Kit” > Install. (Install CMAK on Windows Server 2003 by going
to the Control Panel > AddRemove Programs applet > AddRemove Windows
Components > Management and Monitoring Tools > check the box for
Connection Manager Components > Next > Next > Finish.)
2. Launch the CMAK fi-om the Start menu > Programs > Administrative Tools >
Connection Manager Administration Kit shortcut. Click Next.
3. Click Next to create a new “service profile”, Le., a new set of configuration
options that will be built into the final connectoid.
4. Enter a descriptive service name, such as “VPN Connection To Main Office”.

And enter the name of the executable file that should be created (not including the
.EXE extension) such as “SETUPVPN”. Click Next.
SANS institute
5. Click Next to bypass merging a pre-existing service profile into the current one.
The ability to merge settings from prior profiles saves you time when you need to
create multiple profiles which are very similar.
6. If desired, enter a phone number, e-mail address or URL where you users can
obtain technical support if they experience difficulties. This information appears
in the dialog box users see when attempting to connect. Click Next.
7. Click the “Add A Realm Name” radiobutton, select the “Suffix” option, then, in
the textbox, enter the DNS name of your Active Directory domain which will be
used to authenticate the user. If your users are running Windows 9x/Me/NT, then
use the “Prefix” option instead. The user will now only have to enter their
username and password, not their domain name, when they connect. Click Next.
I
8. Click Next to bypass the selection of phone numbers. (This is for dial-up
connectoids when using Connection Points Services to manage Phone Books.)
9. Check the “This Service Profile” box to make this a VPN service profile. Click
Next.
10. Enter the IP address or DNS name of your VPN gateway. Optionally, configure
the DNS and WINS settings with static IP addresses as well. Click Next.
SANS Institute
11. Uncheck every checkbox. Click Next. These are for having custom scripts or
programs run pre- and post-connection. Interestingly, you can bundle all the
necessary files right into the SETUPVPN.EXE install program itself.
12. Click Next to bypass automatic application launch. Auto-applications are

programs resident on the user’s computer which should be run after establishing
the link, e.g., an e-mail application.
13. Click Next to accept the default graphic in the logon box.
14. Click Next to accept the default graphic for the Phone Book.
15. Click Next to bypass creating a Phone Book file.
16. Click Next to accept the default icon image.
17. Click Next to bypass creating new shortcut menu options. These are custom
commands you can make appear on the context menu when you right-click on the
interface icon next to the clock on the taskbar. If the commands run scripts or
programs, you can include those files in SETUPVPN.EXE itself.
18. Click Next to accept the default Help file. You can include your own if desired.
19. Uncheck the “Include Connection Manager Software” box if all your users will be
running Windows 2000 or later. It doesn’t hurt to leave the box checked in any
case though. Click Next.
20. Click Next to bypass the inclusion of a license text file.
2 1. Click Next to bypass the inclusion of additional executable files or binaries.
--
SANS Institute
22. Click Next and then Finish! The path to your SETUPVPN.EXE program will be
displayed. This is the executable you will distribute to your users.
ands-Free Installation
You can make the installation completely hands-free by executing the following
command (where SETUPVPN is the name of your connectoid install package):
SETUPVPN.EXE / q : a /c:”cmstp.exe setupvpn.inf /s”
Note, the command is strangely case sensitive, so enter it exactly as above. The
CMSTP.EXE program and the SETUPVPN.INF file are both contained inside of
SETUPVPN.EXE, so they don’t have to be copied separately.
Other command-line switches are available too. See the section entitled “Using
Command-Line Parameters” in Help in the CMAK wizard. And further customization is
possible by modifying the textual build file used by the CMAK wizard to create the
installation program.
iri SecIL2 S-6

By default, the connectoid created with the above steps will only attempt PPTP sessions.
You must edit a text file and rebuild your SETUPVPN.EXE program in order to require
IPSec/L2TP only. Edits to this file can also require high encryption, MS-CHAPv2
authentication, no saving of the password, and other security-enhancing preferences.
The text file to edit and the changes to make are described in the CMAK’s Help file
under these two section headings (do a search for them if necessary):
“Implementing VPN Support”
“Advanced Customization: Editing Service-Profile Files”
Specifically, you must addedit a line in the SETUPVPN.CMS text file so that it reads
“VpnStrategy = 3”. The options for this line are:
0 (default) = Automatically select the primary protocol (PPTP).

1 = Use PPTP only
2 = Try PPTP first and then L2TP
3 = Use L2TP only.
4 = Try L2TP first and then PPTP.
Furthermore, set the following three lines to require maximum strength encryption, forbid .
MS-CHAPv1 and require MS-CHAPv2:
EncryptionType = 2
Require MSCHAP = 0
RequireMSCHAP2 = 1
PW-En&ypt= 1
SANS Institute
If you don’t wish your users to be able to save their passwords, there is an option in the
CMS file for that as well (HideRememberPassword = 1).
Save your edits to the CMS file, then run the CMAK wizard again. But instead of
starting over from scratch, select the option to “Edit This Existing Service Profile” at the
first screen, select SETUPVPN, and repeatedly click Next all the way through to the end
to rebuild your installation program with the new options.
olicies ol
The Windows Server Resource Kit includes two programs (RQC.EXE and RQS.EXE)
that can be used to implement your own custom client validation solution to regulate
remote access into the LAN. A client validation script could, for example, verify that a
virus scanner has been installed, that the Internet Connection Firewall has been enabled
on all interfaces, and that “split tunneling” has not been configured on the client.
Unfortunately, until Microsoft develops one or unless you purchase a third-party solution
to do the same, you will have to write this client validation script yourself. Microsoft
provides the raw infrastructure and expects you (or, more likely, a third-party solution
provider) to write the code that hooks into it-- disappointing, but that’s the way it is.
Here’s how it works: during the creation of a VPN connectoid installation program with
the CMAK above, you will import your client validation script and bundle it into the
installation program binary; this script will be configured with the CMAK as a “post-
connect action” script; you will also bundle into this binary a copy of RQC.EXE from the
Windows Server Resource Kit;the last thing your validation script will do, assuming the
client meets your criteria, is to use RQC.EXE to send a message to the RQS service on
your RRAS gateway; this message will cause RRAS to take the client’s VPN tunnel out
of “quarantine mode”, i.e., to permit full two-way routing of packets with the LAN.
RRAS has placed the client’s VPN tunnel into quarantine mode because the RRAS
Policy under which the client connected has an RRAS Profile which specifies, on the
Advanced tab of the Profile, two options: MS-Quarantine-Session-Timeout and MS-
Quarantine-IPFilter. While in quarantine mode the client can only send or receive
packets as defined in the MS-Quarantine-IPFilter option in the Profile.
However, all this is just the beginning. This quarantine feature has been enhanced and
renamed to “Network Access Protection (NAP)”. NAP is available in Windows Server
2003 Release 2.
S
As long as we are on the subject, a related capability available on Windows Server is
“Connection Point Services (CPS)”. CPS allow you to designate an internal 11s server as
a “phone book server”. A phone book server contains compressed files, whose contents
you will edit, that list all the current locations and dial-up numbers that clients have
available to them.
This feature is intended for large organizations or ISPs which have remote access servers
(Points of Presence) scattered across the country or world, hence, users need to find their
SANS Institute
local server(s). When remote access clients connect to the LAN, their Connection
Manager software will automatically download updated phone book files so that the next
time the user needs to choose a new number the latest numbers have already been
installed on the user’s machine (and they don’t have to call technical support to get it).
For more information and setup instructions, search on “Connection Point Services” in
the Windows Server Resource Kits and on Microsoft’s website.
E7 Recommended (Connection anager: General): Use the free Connection Manager

Administration Kit (CMAK) to create a setup program which can install a dial-up or VPN
“connectoid” on your users’ machines. When you do this, configure the setup program to
create a connectoid which enforces your desired access policies, e.g., IPSec/L2TP only,
MS-CHAPv2 only, strongest available encryption only, preventing the saving of
passwords, etc. Use Group Policy, logon scripts or some other method of running the
setup program hands-free on all your users’ systems.
SANS Institute
An RRAS gateway can be a client to a RADIUS server (Microsoft's or otherwise) or be a

RADIUS server itself. This section will answer the following questions: What is
RADIUS? How is RRAS configured as a RADIUS client? How is a Windows system
configured as a RADIUS server itself? A nice feature of Microsoft's RADIUS server is
that it can use Active Directory as its accounts database, thus extending single sign-on
across a variety of remote access technologies and vendors.
Wireless Access Points (APs) that support 802.1X authentication can also use a RADIUS
server to authenticate wireless clients. 802.1X authentication is a part of the 802.1l i and
Wi-Fi Protected Access (WPA) standards. This section will also discuss how to use a
Microsoft RADIUS server for securing wireless networks as well.
SANS Institute
The RRAS server can be a client to a RADIUS server. Remote Authentication Dial-In
User Service (RADIUS) is an industry standard protocol which network access devices --
such as dial-up and VPN servers-- use to forward authentication, authorization and
logging requests to a RADIUS server (see RFC 2138 and 2139). Instead of RRAS
performing its own authentication, policy enforcement and logging, it can outsource these
tasks to a RADIUS server. A RADIUS server is like a cross-platform and vendor-neutral
domain controller.
enefits of Using IUS Server

The benefits of having RRAS use a RADIUS server include:
Centralized policy management.

Centralized logging and accounting.
Supports multiple types of network access device (dial-up modem bank, VPN
server, etc.) from multiple vendors simultaneously (3COM, Cisco, Microsoft,
etc.).
RRAS policies are configured on a per-server basis. This can be inconvenient if one
manages more than a few servers, and is intolerable if you have dozens of RRAS servers
or if they are geographically distributed.
Another shortcoming of per-server policy configuration is the lack of centralized logging.

Each RRAS server will maintain its own separate access logs by default. When a user
SANS Institute
repeatedly reconnects to the VPN server farm, there is no guarantee that the user will
connect to the same server each time, hence, in order to view a complete history of that
user's remote access activities, that history would have to be "reconstructed" from all the
servers' logs. Centralized logging would overcome this inconvenience. (See also the
RASSRVMON.EXE tool.)
Centralized policies and logging through RADIUS is particularly useful if one is using a
variety of remote access server products from different vendors. For example, one might
use RRAS as a VPN server for clients, another vendor's hardware POTS solution for dial-
up access, and a third vendor's hardware-based VPN solution for network-to-network
connectivity. As long as all the products support RADIUS (and most do) then all
authentication, authorization and logging can be centralized on the RADIUS server.
RRAS can be a client to any vendor's RADIUS server. As always with Microsoft,
though, more features are supported if the RADIUS server is Microsoft's.
Microsoft's RADIUS server is the Network Policy Server (NPS). NPS was previously
known as the Internet Authentication Service (IAS). NPSAAS comes bundled with
Windows Server.
SANS Institute
Microsoft's RADIUS server is the Network Policy Server (NPS) service. NPS is bundled
with Windows Server 2008 and later, while earlier versions of Microsoft's RADIUS
service were called the Internet Authentication Server (IAS) service. NPS is RFC-
compliant and can be used with RRAS or other vendors' products. NPS also supports
802.1X authentication of 802.11 wireless devices with RADIUS.
The configuration of NPS is very similar to the configuration of RRAS policies. Once
you learn RRAS, you've learned 70% of IAS.
stalla
If NPS was not already installed with RRAS, then install NPS with Server Manager.
Try It I
To install NPS, open Server Manager > right-click Roles Add Roles > check Network
Policy and Access Services > Next > check Network Policy Server > Install.
NPS can be installed on one of your RRAS servers --it does not have to be installed on a
separate box alone-- but security and performance is increased if it is on a dedicated box.
e "
The most important NPS tool is the Network Policy Server MMC snap-in. It will be
found in the Administrative Tools folder after NPS is installed. Most likely, you have
already installed NPS if you've installed RRAS.
SANS Institute
RADIUS Cl:enk
Remote RAClItiS Server Grougs
Ccmection Request Policies

Standard Configuration *
Select a codiguration 8csnar;o irrm :lie lid and then click :he link beioi:. io open the scenanu ~2:iisrj.
%sSecurity Hea'th 'Vsiidab:
RADlUS sewer for 8Ci2.1X Wireless or Wired Connections

.<%
' f h e n y o u cudigure :IPS as a RkEIUS sewerfcr SZ?.lXco
WPS io aLknti-a:e and authoi?econnections from i.iii-eIes~
i called RADlliS clients).
emote RADIUS SEwei-s

learn inure
Advanced Configuration v
Templates Configuration 7
If the NPS server will authenticate users from a domain, the NPS server needs permission
to access account information in Active Directory. This is accomplished by "registering"
the NPS server, which simply adds the server's account to the "RAS And IAS Servers"
group in Active Directory.
To register the NPS server with Active Directory so the server can read the necessary
account information, open the NPS snap-in > pull down the Action menu > Register
Server in Active Directory. This will add the machine's account to the RAS And IAS
Servers group.
e
An NPS client is a remote access server such as RRAS or a Terminal Server. Before an
NPS client can outsowce its authentication, authorization and logging to the NPS server,
the server must create an object representing that client. This object will specifL the
client's IP address, vendor type, and the password the client uses to authenticate itself to
the NPS server.
To let your RRAS server be a client to your NPS server, right-click on the RADIUS
Clients container in the NPS snap-in > New RADIUS Client > enter the name, IP address,
and shared secret (password) > select "RADIUS Standard" as the vendor on the
Advanced tab > check the box for "Access-Request messages must contain the
Message-Authenticatorattribute" > if the client is Server 2008 or later, then check the box
"RADIUS client is NAP-capable" on the Advanced tab > OK.
SANS Institute
The vendor information might not be "RADIUS Standard" when using a third-party client
with extensions to the generic RADIUS protocol, such as a Cisco product. Usually,
however, you won't need to modify this, even with many Cisco products.
The Message-Authenticator attribute is a digital signature of the request from the client
which is based on the shared secret. It is used to integrity-check the request to help
thwart spoofing. It is enabled automatically when EAP authentication is used.
Network Access Protection (NAP) is a suite of security technologies introduced with

Windows Vista and Windows Server 2008.
NPS remote access policies and logging options are almost identical to those of RRAS.
Configure these options just as you would on RRAS.
0 Recommended (RADIUS: General): Consider using a RADIUS server, Microsoft's or

otherwise, to centralize policy enforcement and logging.
SANS lnstitute I
This section applies to both RRAS and NPS because they are identical under the hood,
even logging to the exact same file. Logging in RRAS and NPS servers is important to
detect penetration attempts, analyze DoS attacks, and to make users accountable for their
actions. RRAS can log information to the Event Viewer logs, to text files, or to an
ODBC database, such as SQL Server.
Each RRAS server can keep its own textual log files, or an RRAS server can be
configured as a RADIUS client to centralize all logging on the RADIUS server. The
following describes configuration procedures for both RRAS and NPS.
s
Event Viewer logging, mainly to the System log, is enabled on a per-server basis by
going to the property sheet of the server in the RRAS snap-in. Logging the maximum
amount of information possible is recommended for the sake of auditing and
troubleshooting. Make sure to increase the size of the System log and provide for
wrapping/backup options.
To enable Event Viewer logging on RRAS, right-click a server in the RRAS snap-in >
Properties > Logging tab > select desired logging level > OK. Rebooting is not
necessary. Most events will be written to the System log.
SANS Institute
The checkbox to log additional RRAS information will write very detailed PPP session
information to the \%SystemRoot%\Tracing\ppp.logfile. This is mainly useful for
troubleshooting authentication failures. Interpretation of the log requires in-depth
knowledge of the PPP protocol and its extensions.
Event Logging On NPS

The corresponding options on NPS are similar. NPS can also write information about
failed or successful authentication requests to the System log.
To configure NPS to write information about authentication attempts to the System Event
Log, right-click the NPS snap-in Properties > General tab > check the desired boxes.
SANS Institute
IPSec, RADIUS, Wireless. and VPNs 191
CC -
_I
In RADIUS terminology, logging is called "accounting". RADIUS logging is configured

for both RRAS and NPS in the NPS snap-in by selecting the Accounting container in the
NPS snap-in. You can log to either a text file or to a SQL Server database.
Accounting
Log File Properties
SQL Sewer Logging Properties
. - ..
SANS Institute
To configure accounting options, select the Accounting container in the NPS snap-in >
click the "Change Log File Properties" link > check all boxes on the Settings tab > OK.
1ASPARSE.EXE
Log file format is determined by how you will use the logs. Log format is compatible
with most RADIUS log-analysis software, but is somewhat cryptic to understand. (The
Windows Resource Kit utility 1ASPARSE.EXE will convert these logs into a more user-
friendly format if desired.)
SANS Institute
IPSec. RADIUS. Wireless. a n d VPNs 193
he l i n e l o g g e d i n t o t h e f i l e : 199.62.89.123,SClNS\jfassen~02/27/
5,6,61,5,64,1,118,1,31~118~118~209.76,66~118~118~209.76~4108~19
00,4129,S~NS\jfossen,25,311 I10.1.1.1 12/18/2000 21:39:37 29.4
en 4127,4.4136. I4142,0
NCIS-I P-Clddress t 199.62.89.123
Use 1.-Name : SClNS\jfossen
Record-Dat e : 02/27/2001
Recod-T i m e : 00:53:18
S e r v ice-Name : RClS
Computer-Name : UEBSERUERI
Se1.v i c e -T ype : Ft*amed
Framed-Pro t oca 1 : PPP
NCIS-Port : 6
NClS-PO 1 s t -Type : Uirtual
Tun n e 1-T ype : PPTP
Clscend-Route-Appletalk: I
Calling-Station-Id : 118.118.209.76
Tunnel-Client-Endpt : 118.118.209.76
Client-IP-Clddress : 199 -62 - 8 9 -123
MS-RClS-Uendor : Microsoft
MS -RCl S-U ers i o n : MSRClSU5.00
SClM-Clccount-Name : SANS\jfossen
Class : 311 I10.1.1.1 12/18/2000 21:39:37 29
Fully-Qualifed-User-Name : c a i - p - s a n s . o ~ g / U s e r s / J a s o n Cl. F o s s e n
Cluthent i c a t ion-Type : MS-CHClP-U2
Packet-Type : Access-Request
Reason-Code : The o p e m t i o n c o m p l e t e d s u c c e s s f u l l y .
Database format simply means the files are comma-delimited into fixed and known
columns. Database format is better suited for import into spreadsheets or scripted merges
into a database.
er
You can also write accounting data to SQL Server. In the Accounting container of the
NPS snap-in, click the "Configure SQL Server Logging" link. The options are nearly
identical as for text file logging, except that you'll need to define database connection
information (click the Configure button).
SANS Institute
If you have a farm of RRAS/NPS servers, it would be convenient to consolidate all

logging data to one database. If speed is most important, though, logging to a local text
file on a separate drive is the most efficient.
ry (NPS): Enable logging of failed and successful remote access attempts,

then actually review the logs with an automated script or other tool.
SANS Institute
- Stations and Access Points
- Smart Card or Certificate
- PEAP-TLS
- PEAP-MS-CHAPV~
- Open System Authen~ication
- Shared Key Authentication
- 40- or 104-bit RC4
Keep in mind that the RADIUS/IAS policies being discussed for securing VPN access
can also be used for securing 802.1 1 wireless access as well. Before considering how to
set this up, let’s quickly review some 802.1 1 concepts and protocols.
Similar to Ethernet (802.3) and Token Ring (802.5), the various Institute of Electrical and
) 802.11 standards define both physical layer and media
ayer components for computer networking over radio
transmissions instead of copper wire or fiber optic cable.
At the physical layer, 802.1 1 networks can use a variety of transmission schemes,
including Frequency Hopping Spread Spectrum ( SS) with 802.11, Direct Sequence
Spread Spect ) with 802.1 1b, and Orthogonal Frequency-Division
Multiplexing . These electromagnetic transmissions typically
occur in the 2.4 to 2.5 and), but 802.1 l a operates in the 5.725 to 5.875
GHz range (C- o avoid interference with cordless phones, baby
monitors, microwave ovens, elevator motors, Bluetooth stations, and other devices which
radiate in or near the S-Band range.
At the MAC layer, all the 802.1 1 versions use Carrier Sense Multiple Access with
Collision Avoidance ( ) to help prevent two stations from transmitting at the
same time on the same frequency. The exchange of Request To Send (
SANS Institute
To Send (CTS) messages also helps to coordinate the transmissions of multiple stations
all contending for the same bandwidth.
The different 802.1 1 standards have different maximum bandwidths:
802.11 2 Mbps (obsolete)

802.11b 11 Mbps (compatible with 802.1 1g Access Points)
802.llg 54 Mbps (backwards compatible with 802.1 1b)
802.11a 54 Mbps (not backwards compatible)
802.11n 200 Mbps (backwards Compatible with 802.1 1b/g)
Some 802.1 la/g vendors sell devices that bond two 54 Mbps channels into one logical
108 Mbps channel, and 802.1 In devices do this standardly. 802.1 1b devices are not
upwards compatible with parallel multiple channels, but can still connect at 11 Mbps.
Some vendors offer firmware updates to increase the functionality of their devices, but
not all models can be updated to get the latest security features.
A "station"is any device that can communicate using 802.11 wireless networking. An
oint (AP)" is a station that acts as a hub, bridge, router, firewall, and/or
authenticating gateway for the sake of other wireless stations. APs are usually dedicated
hardware appliances, while most stations are general-purpose computers with special
client software and wireless network adapter cards installed. All of your APs and client
stations make up your Wireless Local Area Network (WLAN).
Service Sets ssociations

A wireless netw entified by its Service Set Identifier (SSI ), which is just a user-
configurable name to keep it distinct from other wireless networks within transmission
range of each other. An identical SSID is configured through software applications at the
stations and APs that wish to communicate. Each wireless network adapter has a unique
hardware address, but hardware addresses are not SSIDs. The hardware addresses of
some wireless cards can be set programmatically.
When an AP is configured to periodically broadcast its SSID name, this is called

"beaconing". On the client's side, stations can "scan"for APs and other stations by
sending Probe-Request frames in order to elicit Probe-Response replies. When two
wireless devices open a communications channel with each other, they are said to be
"associating" with each other, and the resulting connection is called an "association". If
two wireless devices have associated, then they can talk to each other, but a fully-
functional and encrypted association may require a successful authentication first (it
depends on how the stations and APs are configured).
e vs. oc e
802.11 networks operate in one of two modes: infrastructure mode or ad hoc mode.
In infrastructure mode, one or more APs are set up with the same SSIDs and all client
stations associate with one of these APs, not directly with each other; hence, all wireless
SANS Institute
packets are bridgedhouted through the APs. If there is only one AP, then it and all of its
associated stations are collectively called a "
multiple APs and they all reside on the Sam then these APs and
their associated stations are together called
though a station may "roam" from one AP to another within an ESS, that station will
keep its same IP address and its active TCP sessions will not be broken (ideally) even
though it is reassociating with different APs during the life of that TCP session.
oc mode, two to nine wireless stations communicate directly with each other
without the use of a dedicated AP (nine is the 802.1 1-defined upper limit). Strictly
speaking, one of these stations will play the role of the AP, but which station is playing
that role can change on-the-fly as needed and doesn't need to be configured manually.
11 the stations co ' ating in ad hoc mode are collectively called an "Independent
asic Service Set '. However, most 802.11 security features, such as WPA, are
not available in ad hoc networks.
The original 802.1 1 specification defined two methods of authenticating to an AP before

that AP would permit a station to communicate through it:
en System. Open System Authentication actually performs no authentication

11. Some APs can be configured with a list of permitted station MAC
addresses, but this is not authentication (it's firewalling) and is easy to defeat
since an adversary would only need to sniff the wireless traffic and copy the MAC
address of one of the permitted stations. This MAC address filtering does not
scale to hundreds (or even dozens) of stations verily easily.
ey. Shared Key Authentication uses the same encryption key used for
WEP (see below) to encrypt a plaintext challenge from the AP, which the AP then
decrypts with an identical copy of that key. The key is typically just a password
or string of hex/ASCII digits entered on both the AP and station. Shared Key
authentication should never be used because the key can be cracked after sniffing
the authentication sequence, which would then also reveal the WEP encryption
key too; hence, though it seems counter-intuitive, Open System authentication is
actually more secure than Shared Key when WEP is also being used.
Wired Equivalent Privacy ( ) is the encryption and integrity-checking scheme

defined in the original 802.1 1 standard. To confirm that data has not changed during
transit, an Integrity Check Value ( ) is computed at the receiver and compared with
the ICV in the sender's frame; that is to say, WEP's method of integrity-checking is
similar to the use of checksums in TCP/IP, and therefore suffers the same limitations.
WEP encryption uses either a 40- or 104-bit RC4 key to encrypt packet payloads (some
vendors advertise 128-bit encryption, but this is just the 104-bit key plus a 24-bit
Initialization Vector ( ) that is appended to the header of each frame in cleartext
anyway). The RC4 WEP key is derived from an ASCII password or string of hex
SANS Institute
characters configured on the stations and APs. WEP is bad because the key distribution
mechanism is undefined, there’s no automatic rekeying performed, the same key is used
for large amounts of data over long periods of time, password-derived keys usually lack
sufficient randomness/entropy to give true 104-bit encryption, the WEP key is the same
key used for Shared Key authentication, there’s no per-user authentication (just one key
everyone uses), there’s no support for the use of other authentication modules (like smart
cards or SecureID tokens), rouge APs can trick stations into associating with them, and
well-known tools are in circulation on the Internet to attack it, e.g., AirSnort from
http://airsnort.shmoo.com.
2 Implement 802.11i
802.1 l i is the set of IEEE standards which overcome all the weaknesses of WEP and
shared key authentication. The 802.1 l i standard was ratified in June of 2004.
A subset of the 802.1 l i standards is available in devices which implement “Wi-Fi

Protected Access (WPA)”. WPA includes the most important elements of 802.1 li, but is
not a full implementation. WPA2, on the other hand, is considered a complete (or nearly
complete) implementation of the 802. I l i standards. All wireless products today which
bear the “WiFi Alliance” logo must implement at least the WPA2 standards.
Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP) is not an authentication method itself,
but a way of negotiating the agreement to use some other authentication method (RFC
2284). VPN gateways and dial-up servers can use EAP, for example, to negotiate some
other authentication method with a client attempting to gain access using the Point-to-
oint Protocol ( PP). To negotiate a particular authentication method, both the client
and the servedgateway must have the same EAP library or module installed (these are
called “EAP types” or “EAP providers”). EAP is designed so that future modules can
simply be plugged in without requiring a massive coding or upgrade effort, e.g.,
cryptographic tokens or biometric authentication could be added as an EAP type
relatively easily.
In addition to PPP for dial-up and VPN access, EAP is also supported for authenticating
to IEEE 802 link layer devices such as Ethernet switches and 802.1 1 wireless Access
Points. The IEEE 802.1X standard defines exactly how EAP should be used to
authenticate to such LAN/WLAN devices.
With the latest Service Packs and patches applied, there are only two wireless EAP types
that we care about here for security (or have the time to discuss):
EM-TLS (listed as “Smart Card or Other Certificate” in Windows)

Protected EAP (PEAP)
EAP-TLS is certificate-based authentication without first creating a TLS-encrypted

channel. The client’s certificate can be stored either in a smart card or on the hard drive.
The server-side certificate is not installed in the wireless AP, but on a RADIUS server the
SANS institute
I
AP is configured to use. The AP simply passes encrypted messages back and forth
between the client station and the back-end RADIUS server, then the AP will allow/deny
the client according to the commands of the RADIUS server.
is a protected form of EAP in the sense that a full TLS-encrypted channel is first
established between the client and the back-end RADIUS server, then authentication data
is exchanged with the RADIUS server through this channel. The TLS channel is not
opened to the AP itself, the AP merely passes this data through to the back-end RADIUS
server. This is different than EAP-TLS because PEAP uses a TLS channel whereas EAP-
TLS authentication merely uses certificate-based authentication over a cleartext channel.
Importantly, understand that PEAP itself is not an authentication method, but a way of
securing further authentication traffic. Through the PEAP-encrypted channel to the
RADIUS server, what authentication methods can a client use? There are two PEAP-
secured authentication methods available from Microsoft, though third-party vendors will
have others:
PEAP-TLS
PEAP-MS-CHAPV~
S is just like EAP-TLS except that PEAP-TLS does its authentication over an
encrypted channel while EAP-TLS does it over a cleartext channel. The acronyms get
confusing here, so be careful to distinguish TLS certificate-based authentication (which
both PEAP-TLS and EAP-TLS use) and TLS channel encryption (which only PEAP-TLS
uses). PEAP-TLS is more secure than EAP-TLS, but is probably overkill for most
organizations.
s- v2 simply does a regular Microsoft CHAPv2 authentication through

the TLS-encrypted channel established by PEAP. This is the same MS-CHAPv2 used for
dial-up and VPN access, but secured by PEAP too. A practical advantage of PEAP-MS-
CHAPv2 is that you do not have to install certificates on all the client stations, only the
RADIUS server requires a certificate to be installed; both EAP-TLS and PEAP-TLS, on
the other hand, require certificates to be installed on both the RADIUS servers and all the
client stations.
802.1 1i. WPA defines better methods of

wireless authentication, encryption and integrity-checking than WEP:
WPA requires either EAP or pre-shared key authentication. For environments

DIUS server, WPA provides a pre-shared key authentication method
that is much more secure than WEP Shared Key authentication.
WPA requires data encryption using

Think of TKIP as a better version of WEP; for example, T U P changes the
encryption key with every frame exchanged between station and AP. Advanced
SANS Institute
Encryption Standard (AES) encryption is also supported and is superior to TKIP

is security and speed.
WPA also uses a better integrity-checking scheme called “Michael” for detecting
bit changes in frames. It also helps to prevent replay attacks through a frame
counter field in the 802.1 1 MAC header.
WPA2 is a full (or nearly full) implementation of 802.1 li. A patch from Microsoft
(KB893357) will upgrade the system to support WPA2, but keep in mind that the
wireless NICs, Access Points, device drivers, firmware, etc. all must be upgraded to
support WPA2 too in order for it to work.
Because WiMax (802.16) is not yet widely available, this refresher doesn’t discuss it, but
be on the lookout because WiMax can do 70 Mbps up to 30 miles! If you would like to
read more about 802.1 l i or WiMax, see http://www.wikipedia.org.
SANS Institute
Not all 802.1 1 hardware, firmware or drivers support WPA2. You have to check the
manufacturer’s website and confirm that your hardware is firmware-upgradeable and that
there are drivers for the specific operating systems you want to use. Moreover, you can’t
assume that all options will be available --such as AES or smart card authentication--
even if a product is marked as “WPA2 Compliant”.
The configuration of each vendor’s AP for WPA2 will be different, but typically this is
done over an HTTP/HTTPS session to the AP itself. For example, the screenshot in the
slide above shows the configuration web page for a D-Link DI-624-C Access Point. The
WPA Authentication option is selected along with the IP address of the NPS server
(10.4.2.2), the default port number for RADIUS (1812) and a long passphrase for AP-to-
RADIUS server security. Click “Apply” and that’s it for the AP!
Notice that WPA-PSK can also be chosen for Wi-Fi Protected Access Pre-Shared Key
authentication. This is much better than WEP when a RADIUS infrastructure is not
available, e.g., in a small/home office. The screenshot below shows how simple it is to
configure WPA-PSK.
SANS Institute
Make sure to choose a long random passphrase for WPA-PSK though, where long is at
least 35 characters. Inexpensive hardware acceleration of PSK cracking, using video card
GPUs of all things, can crack most short passphrases in less than two days, and often in
less than two hours. If you are using WPA-PSK to secure sensitive data, determine what
the maximum number of characters are permitted by your vendor, then generate random
string of that length. If you have the option to use hex instead of standard ASCII, even
better, use the hex.
SANS Institute
- Choose EAP type: EAP-TLS, PEAP-TLS, or PEAP-MS-CHAP

- Select which group(s) should have wireless access.
- Configure VLAN settings, if necessary.
i
c
i
i
\~
c
t
i
For the sake of EAP authentication, the IAS service can be installed on Windows 2000-
Li SP3 with the IU33 13664 update and later, and on Windows Server 2003 and later server
operating systems (in Server 2008 and later, IAS has been renamed to NPS). The NPS
server can authenticate users against a Windows NT domain, an Active Directory
domain, or the local accounts SAM database on the NPS server itself. The NPS server
can be a stand-alone, a member server or a domain controller. To optimize performance
as much as possible, NPS should be installed on a domain controller. To maximize fault
tolerance and load balancing, install at least two NPS servers for your organization and
configure your APs with both a primary and a backup RADIUS server.
Windows Server 2003 and later can be a “RADIUS proxy”, that is to say, it can forward
authentication messages to other RADIUS servers. These other RADIUS servers do not
have to run Windows and, if they are running Windows, do not have to be in the same
forest or have any trust relationships whatsoever. RADIUS proxies can also provide
additional load-balancing by spreading authentication work across multiple back-end
RADIUS servers (where the real authentication work occurs).
SANS Institute
,
ConnectionR E ~ M .
rl& ork Po~icies Standard Configuration
'b.
a uenfigurctiun scenzno h n the list and then c!ick the ink beiwii to open the scrnano rv!za:d
System Health Lalidato%-
Remediation S e r x Groups
RADIUS Clients
Reino:e RAD:US Series
3 Renediawn Sen e: Groups

Cnnfipre 8i.2 1): k e r n insre
Ternplatcs Configuration v
indows Server 2008 PS Configuration Steps

To configure a Windows Server 2008 NPS member server or domain controller as a
RADIUS server for EAP authentication, follow these steps:
1. Install a certificate on the NPS server using the Computer certificate template
from a Windows Certification Authority (CA). This can be done manually or
through Group Policy auto-enrollment fi-om an Enterprise CA.
2. Right-click the NPS snap-in itself and, if it is not greyed out already, click
"Register Server In Active Directory".
3. Verify that the computer account of the NPS server is a member of the RAS And
IAS Servers group, and, if not, add it to that group now manually.
4. Select the NPS snap-in itself and notice on the right-hand side of the MMC
console a pull-down menu of configuration scenarios. From that menu, select
"RADIUS Server for 802.1 1 Wireless or Wired Connections" and click the /
''Configure 802.1X" link.

i
5. Select "Secure Wireless Connections" > Next.
6. Select and/or create RADIUS client objects to represent your wireless APs and
their shared secrets > Next.
SANS Institute
7. Choose and configure your EAP authentication type; for example, select
“Microsoft: Smart Card or Other Certificate”, then click Configure to choose the
computer certificate installed on the NPS server. Click Next.
8. Add those groups, if any, membership of which will be required for getting
wireless network access. It is recommended that you create a group similar to
“Wireless Users” and only add the minimum necessary to the group to support
legitimate purposes. Click Next.
9. If you are using VLANs, you may configure VLAN settings to be applied to the
traffic of the user/computer being allowed by this policy. If you are not using
VLANs, simply click Next and then Finish.
In the NPS snap-in, select the Policies > Network Policies container. Notice your new
secure wireless policy. Move that policy up/down to place it correctly in the list of other
policies, then examine the settings of your new policy. Notice that you did not need the
wizard to create this policy, you could have done it by hand, and now you can edit the
policy if desired, e.g., to switch from EAP-TLS to PEAP-TLS.
3 S
To configure a Windows Server 2003 IAS member server or domain controller as a
RADIUS server for EAP authentication, follow these steps:
1. Install a certificate on the IAS server using the Computer certificate template from
a Windows Certification Authority (CA). This can be done manually or through
Croup Policy auto-enrollment from an Enterprise CA.
2. Right-click the Internet Authentication Service snap-in itself and click “Register
Server In Active Directory”.
3. Verify that the computer account of the IAS server is a member of the RAS And
IAS Servers group, and, if it is not, add it to that group now.
4. In the IAS snap-in, right-click the RADIUS Clients container > New > RADIUS
Client > enter the name and IP of your wireless AP > Next > enter the passphrase
for the shared secret (and leave the Client-Vendor as RADIUS Standard) > Finish.
Repeat as necessary for your other wireless APs.
5. Create a global or universal security group in Active Directory named “Wireless

Users” or something similar. Add the users and other groups to this one which
should be permitted to use the WLAN.
6. In the IAS snap-in, right-click the Remote Access Policies container > New >
Remote Access Policy > Next > name the policy “Wireless Policy” (and use the
Wizard) > select Wireless > Next > enter the Wireless Users group > Next >
SANS Institute
select either “Protected EAP (PEAP)” or “Smart Card Or Other Certificate (EAP-
TLS)” > Next > Finish.
Using the Wizard to configure the Remote Access Policy is quicker, but what are the
settings if they need to be done by hand or on a Windows IAS server? Only one criterion
for the policy is required, and that is to match on the NAS-Port-Type condition for either
the “Wireless - IEEE 802.11” or the “Wireless - Other” types. The policy must grant
access, of course, and the authentication method will be EAP with either the “Protected
EAP (PEAP)” or “Smart Card Or Other Certificate (EAP-TLS)” type selected.
Though not necessarily required to make it work, you should also go to the
Authentication tab in the Profile and uncheck the “No Encryption” box for the sake of
security. You may also need to move your new Wireless Access policy to the top of the
list of policies.
SANS Institute
You are also not required to create a special group just for authorizing wireless access
simply because the Wizard created one, but it’s a good idea. You can delete the group if
you wish and then edit the policy to remove the Windows-Groups policy condition.
S
To configure a Windows Server IAS member server or domain controller as a RADIUS
server for EAP authentication, follow these steps:
1. Install a certificate on the IAS server using the Computer certificate template from
a Windows Certification Authority (CA). This can be done manually or through
Group Policy and auto-enrollment from an Enterprise CA.
2. Right-click the Internet Authentication Service snap-in itself and click “Register
Server In Active Directory”.
3. If the RAS And IAS Servers group exists in your domain, verify that the
computer account of the IAS server is a member of that group, and, if it is not,
add it to that group now. If the group does not exist, do not create it.
4. In the IAS snap-in, right-click the RADIUS Clients container > New > RADIUS
Client > enter the name of your wireless AP > Next > enter the IP address and
passphrase for the shared secret > Finish. Repeat as necessary for your other
wireless APs.
5. In the IAS snap-in, right-click the Remote Access Policies container > New >
Remote Access Policy > Next > name the policy “Wireless Access” > Next > add
a condition for the NAS-Port-Type attribute and add the “Wireless - IEEE
802.1 1” and “Wireless - Other” options to the list > Next > click Grant > Next >
click Edit Profile > on the Authentication tab uncheck all boxes except for
Extensible Authentication Protocol > select either “Protected EAP (PEAP)” or
“Smart Card Or Other Certificate (EAP-TLS)” from the list of EAP types > OK >
No > Finish.
Though not necessarily required to make it work, you should also go to the
Authentication tab in the Profile and uncheck the “No Encryption” box for the sake of
security. You may also need to move your new Wireless Access policy to the top of the
list of policies.
SANS Institute
C
- Windows 2003+SP1 or later.
- Windows XP+SP2 or later.
- Plus latest updates.
- Server 2003 or later DC’s.

- XP or later clients.
Wireless clients can be configured by hand of course, but this doesn’t scale out.
Fortunately, you can Group Policy to manage wireless settings. When a laptop is first
joined to the domain it will need to use a wired connection, but once Group Policy is
applied to the machine it will have the wireless settings it needs.
The Windows 2000/XP/2003 operating systems do not support WPA2 out of the box, but
software updates are available to enable all or some of it. Windows Vista/2008/7 and
later support WPA2 without any additional updates.
For pre-Vista computers, here are some o f the updates available:
Windows Server 2003 requires the update described in Kl38 15485 to support
WPA and 802. IX, or simply apply Service Pack 1 or later to get it.
Windows XP requires Service Pack 1 and the same KB815485 update to support
WPA and 802. lX, or simply apply Service Pack 2 or later.
Windows 2000 does not support WPA at the time of this writing, but it can
support 802.1X authentication with Service Pack 3 and the “802.1X
Authentication Client” described in KB313664. Note that this update does not
install the Wireless Zero Configuration (WZC) service, so the 802.1X settings
must be configured manually with a utility provided by the WLAN adapter’s
SANS Institute
vendor. Nor can the wireless settings in Windows 2000 be managed directly
i
through Group Policy (though a GPO-assigned script could do it).
Windows 98/Me/NT apparently can be updated to support 802.1X authentication

(not WPA) but the updates are only available to customers with Premier and
Alliance support contracts with Microsoft. The updates cannot be downloaded
from Microsoft’s website, you’ll have to contact Microsoft directly.
Once updated to support WPA and/or 802.lX, the client can either be manually
configured or, with Windows XP-SP 1/2003, configured automatically through Group
Policy.
ess Iic
The wireless settings on Windows 2000 cannot be managed through Group Policy even
with the 802.1X Client installed, but they can be managed on Windows XP-SPl/2003
and later. Moreover, the domain controllers must be Windows Server 2003 or later as
well. Let’s walk through the process of creating a wireless policy inside of a GPO. If
you configure these settings manually, then the settings and choices will be the same
even though the dialog box(es) for configuring them may look different.
To create a wireless policy in a GPO, open the GPO > Computer Configuration > Policies
> Windows Settings > Security Settings > right-click on the Wireless Network (IEEE
802.1 1) Policies container > Create A New Wireless Network Policy for Windows Vista
and Later Releases.
To edit your wireless policy, right-click the policy icon > Properties.
SANS Institute
General Ta
When the policy is completely configured, you might have many networks configured on
the General tab, some of which might be for A P s and some for ad hoc networks. If a
client finds itself within range of multiple networks at the same time, will it use an
infrastructure AP network or an ad hoc network? This problem in solved on the Network
Permissions tab where you can prevent connections to either ad-hoc or infrastructure
networks. If you have a mix of infrastructure and ad hoc networks which are permissible,
then you can order then on the General tab from most to least preferred.
On the General tab you should also check the box to “Use Windows WLAN Autoconfig
service for clients” so that the WLAN Autoconfig service knows to ignore the
configuration settings from any utility provided by the WLAN NIC’s hardware vendor;
instead, the service will use the settings configured either through Group Policy or the
native Windows configuration tools in the NIC’s property sheets (note that in XP this
service is named the “Wireless Zero Configuration” service).
On the General tab in a wireless policy you can create multiple “networks” (sets of
configuration settings) and arrange them in order of most to least preferred. The WLAN
Autoconfig service automatically scans for and connects to these networks, even if their
APs do not broadcast or beacon their SSIDs. Note that a roaming client will
automatically switch on-the-fly from one network to another as needed or as better-
preferred WLANs come within range.
To add a network object on the General tab, click Add and choose either Infrastructure or
Ad Hoc. In the dialog box, choose an SSID, EAP authentication type, encryption cipher,
and the other details.
Note that you cannot enter WPA pre-shared keys at this time, but future Service Packs
will hopefully add this option.
ork Permissions Tab

The Network Permissions tab allows administrators to pre-specify SSIDs to either deny
or allow them. The tab also has checkboxes for controlling general policies, e.g.,
allowing users to even see SSIDs which are denied. An important option is named “Only
use Group Policy profiles for allowed networks”, which prevents users from choosing
any new SSIDs that have not been pre-approved by administrators through Group Policy.
Recommended Reading
Unfortunately, because of limited time and the wide variety of issues that would need to
be discussed in a course just on wireless networking, what follows can only be an
overview of Group Policy configuration. If you would like to get a book for step-by-step
configuration instructions and practical deployment advice, then a nice one is Deploying
Secure 802.11 Wireless Networh with Microsoft Windows (Microsoft Press: 2004) by
Joseph Davies. However, the first edition of this book does not include the new wireless
options for XP+SP2 or 2003+SPl and later.
SANS Institute
IPSec, RADIUS, Wireless, and VPNs 21 1
- Physical security
- HTTPSadministration
- Scheduled off-times
The following are best practices for enhancing the security of wireless networks.
re t?S
Before purchasing WLAN network interface cards or Access Points, verify that the
device supports or can be upgraded to support WPA2. It is also highly desirable that the
drivers and firmware of the WLAN NICs be configurable through Group Policy and the
WLAN Autoconfig or Wireless Zero Configuration service (look for the “Windows
Compatible” logo and test a sample card before purchasing in bulk). You can start your
search for new hardware by visiting http://wi-fi.org and searching by vendor for products
certified by the Wi-Fi Alliance to be WPA2-capable. This website is also a good source
of wireless information.
Apply the latest Service Pack and patches for the operating system. At a minimum,
Windows Server 2003 should either have at least Service Pack 1 or the KB815485
update; Windows XP should have Service Pack 1 and the same KB815485 update at a
minimum; and Windows 2000 should have at least Service Pack 3 and the “802.1X
Authentication Client” described in KB3 13664 for 802.lX, but be on the lookout for
updates that provide WPA support as well. Also, your Windows Server 2003 domain
controllers should be updated with at least Service Pack 1 to enable enhanced Group
Policy control over WPA and 802.1X settings; Server 2008 and later have this built in by
default.
SANS Institute
For non-Windows WLAN clients and RADIUS servers, there is a wide variety of
products to choose from. You might begin your search at http://www.mtghouse.com and
http://www.funk.com.
,E nd S Configuration
If an NPS/RADIUS server and a Windows Certificate Services PKI are available, then
implement one of the following combinations of settings (in order of preference):
WPA2-AES and PEAP-TLS
WPA2-AES and EAP-TLS
WPA2-AES and PEAP-MS-CHAPv2 (with long passphrases)
If an NPS/RADIUS server or a Windows Certificate Services PKI is not available, or if

you are using ad hoc wireless, then implement the following combinations of settings:
WPA2-AES and WPA-PSK (long hex key)
If you are compelled to use WEP or TIUP encryption, then try to force all wireless traffic
through a VPN gateway, preferably using IPSec.
In general, prefer smart cards over locally-installed certificates, PEAP-TLS over EAP-
TLS, EAP-TLS over PEAP-MS-CHAPv2, AES over TKIP, TKIP over WEP, hex keys
over ASCII keys, longer keys over shorter keys, WPA2-PSK over WEP Shared Key
authentication, and Open System authentication over Shared Key authentication when
WEP is being used. But keep in mind that security must be balanced with performance
and ease of deployment. You’ll need to consider who your likely adversaries are and
how much performance and overhead you’re willing to pay to secure against them.
If PEAP-MS-CHAPv2 is used, then enforce a strong passphrase policy. The PEAP data
might not be decrypted, but passphrases could still be brute-force guessed. PEAP-MS-
CHAPv2 is the most secure option currently available when client-side certificates or
smart cards cannot be deployed.
Enable logging on RADIUS servers. Logs should at least include all successful and
failed authentications.
RADIUS policies for EAP should require encryption and require membership in one or
more groups specifically designed to allow wireless access. You might also create a
group for the sake of explicitly denying wireless access.
Use Group Policy to enforce consistent wireless settings.
Use random hex characters instead of random ASCII characters when setting pre-shared
authentication or encryption keys. Hex characters provide a larger keyspace and less
incentive to use easy-to-guess passwords. And use the largest number of characters
permitted for the key. (Tip: Have an authenticated and SSL-encrypted internal web page
with these keys so that you can simply copy-and-paste them into the property sheets of
SANS Institute
WLAN NICs that must be manually configured, or carry a flash drive with an encrypted
file with the same if a regular LAN connection is unavailable.)
If you must use WEP, it is preferable to use Open System authentication instead of
Shared Key authentication. Try to upgrade as quickly as possible or force all wireless
traffic through a VPN gateway.
ccess s
Physically secure APs to prevent theft or tampering. When wireless access is mission-
critical, don’t forget to have Uninterruptible Power Supplies (UPSs) for the A P s ,
switches, firewalls, etc. Through custom scripts or third-party utilities, continuously
monitor the health of all APs (if only by pinging them every 60 seconds).
Change the default SSID on your Access Points. Do not include your name, company
name, or other identifying information in the SSID. Do not make your SSID identical to
any of your keys.
Don’t disable SSID beaconing, this only makes it more likely that your users will be
tricked into connecting bogus APs, and there are well-known wireless hacking tools that
can still passively detect your SSID even with beaconing disabled.
Only permit HTTP access to the management web pages on APs from LAN segments,
not from the WAN port or wireless ports. Assign a long and complex passphrase to the
admin account on the AP. Do not connect to these management pages over insecure
segments which may be sniffed; instead, directly connect to a LAN port on the AP itself.
Consider implementing firewall rules in the AP that limit HTTP access to it only from
one or a small range of source IP addresses. Document the configuration of each AP or
dump their configurations to exported files.
If possible, schedule APs to go off-line during the days or hours when it will not be used,
such as on weekends or nights.
Enable security logging on APs. Different vendors provide widely different capabilities,
so investigate what’s possible for you. Ideally, the AP should support syslog.
Turn off the DHCP service on your APs and use only the DHCP servers inside the LAN.
If nothing else, this will simplify administration. Static IP addresses are slightly more
secure, but their management doesn’t scale.
If the AP has an SNMP agent in it, disable it. If needed, then assign a long and random
community string and, if possible, allow only read access instead of readwrite.
s, G
Consider placing all remote access gateways --such as dial-in servers, VPN servers and
wireless APs-- behind an internal firewall that regulates packets coming through the
gateways to the internal LAN. If this is not possible, then consider using the built-in
SANS Institute
firewall that many APs include; for example, you may wish to only provide thin-client
RDP/ICA access from the WLAN, so configure the APs to allow that and nothing else. If
you’ve got a network IDS infrastructure, plant an IDS sensor near your APs as well.
On each client, enable a personal firewall which can bind to the wireless interface, such
as the Windows Firewall in Windows XP+SP2 and later. Don’t forget that the Windows
Firewall in Vista and later can be managed through Group Policy and have different rules
for different types of interfaces.
Make a VPN gateway available on the Internet for the sake of roaming clients that inust
use public wireless APs, like at airports or cafes. The client can use the unsecured AP,
but only for the sake of opening the VPN tunnel. The VPN gateway doesn’t necessarily
have to provide access to the internal LAN, it may simply exist to route the NAT-ed
packets of the wireless users back out to the Internet, but corporate LAN access will
probably be desired too. With a personal firewall and a default gateway pointed at the
VPN, such roaming clients can get insecure wireless Internet access much more securely.
Don’t forget that IPSec is compatible with wireless too. Require IPSec ESP at the critical
servers in the LAN which may be accessed by wireless clients, such as e-mail and
database servers. If you do use IPSec, then disable NetBIOS and set the
NoDefaultExempt registry value (KB8 11832).
If your AP supports it, you might consider using MAC address filtering to limit the
hardware addresses of the stations that can associate with the WLAN. However, keep in
mind that MAC addresses can be easily spoofed, managing the MAC filter list on all APs
is difficult, and, in comparison to WPA2/PEAP-TLS/AES/IPSec and keeping your
firmware and operating systems up-to-date, MAC address filtering gives only trivial
advantages.
udit Your 0 nd Learn About

Periodically “war drive” or audit your own network to find unauthorized Access Points or
ad hoc networks, and to check how far your wireless signal extends off-premises. If your
signal extends too far, relocate APs more towards the center of the building, set up wire
mesh shields to keep the signal inside, or reduce the output power of the APs. Reducing
AP transmission power may also be necessary to have more APs in close proximity to
support a larger number of simultaneous clients. Ad hoc networking should be strongly
discouraged.
Periodically scan the hard drives of users to find unauthorized wireless hacking tools.
This is most easily done with a Group Policy assigned script that e-mails any finding to
network administrators.
It’s important to be familiar with the wireless auditing and hacking tools available on the
Internet in order to raise your sensitivity to potential vulnerabilities (and know what
you’re up against). A good book for this is Wi-FooII: The Secrets of Wireless Hacking
(Addison Wesley/Pearson: 2008) by Vladimirov, and S A N S has a great wireless security
SANS Institute
course (SEC617). You can also browse well-known security websites (like
http://www.securityfocus.com and http://www.packetstormsecurity.nl)and search on
terms like “wireless” or “802.1 I” to find the latest-and-greatest. Here is a sampling of
some of the more popular auditing tools:
AiroPeek NX (www.wildpackets.com) -- Wireless protocol analyzer. (Windows)

AirSnort (airsnort.shmoo.com) -- Crack WEP encryption. (Linux)
coWPAtty (www.willhackforsushi.com)-- WPA-PSK cracking (Linux)
Wireshark (www.wireshark.org) -- Free protocol analyzer. (Windows & Linux)
AirPcap (www.cacetech.com) -- Wireless sniffer adapter (Windows)
Kismet (www.kismetwire1ess.net) -- Wireless network scanner. (Linux)
Ministumbler (www.netstumbler.com) -- Mini-Netstumbler. (Windows CE)
Netstumbler (www.netstumbler.com) -- Wireless network scanner. (Windows)
- -0 G
OOOC41B6021C
1000OC41BGDZlC linksys 6 AP 29
fl Default SSlD
SANS Institute
You have finished the course! Please complete the evaluation form and return it to the
room monitor or drop it in the "Evaluations" box. Written comments are especially
appreciated, and play a large role in how we update the manual.
Thank You for attending this seminar!
SANS Institute
Have you noticed that there are no IPSec Policies created for L2TP when RRAS is
configured as a VPN server? These IPSec Policies exist, but they are dynamic (in the
same sense that the 1PSECCMD.EXE tool can create dynamic entries).
When the RRAS service starts, it injects an IPSec Policy into the IPSec Policy Agent
service for the sake of L2TP. This Policy is not visible in the IPSec snap-in or in Group
Policy objects, but it can be seen with 1PSECMON.EXE or NETDIAG.EXE after a
L2TP/IPSec session has been created. On the client's side, the Policy is injected either by
RRAS or when a L2TP VPN icon in the "Network and Dial-Up Connections" folder is
executed.
If the IPSec Policy Agent service is restarted, it will lose the dynamic Policy injected into
it by RRAS. Hence, if you must restart the IPSec Policy Agent service on an L2TP
server, then immediately restart the RRAS service too so that it may re-inject the
necessary Policy.
!
To see how RRAS injects IPSec Policies into the IPSec Agent, open a command-prompt
window > execute "netdiag /test:ipsec /debug" > note the IPSec filters with a destination
port UDP 1701 > execute "net stop "ipsec policy agent"" > execute "net start "ipsec policy
agent"" > execute "netdiag /test:ipsec /debug" > note that the IPSec filters for L2TP (on
UDP port 1701) are gone > execute "net stop "routing and remote access"" > execute
"net start "routing and remote access"" > execute "netdiag /test:ipsec /debug" > note that
the L2TP IPSec Policy exists again. (Note: netdiag.exe is a Support Tool.)
conds / 250000 b y t e s .
Off e P #I5 :
Method = Cert: E=cei*t@sans .ok*y, G=US, S=Texas, L=Dallas, O=S

Src Rddr : 0 . 0 . 0 . 0 SPC Mask : 0 . 0 . 0 . 0
Dest Rcldi- : 169.254.222.222 Dest Mask : 255.255.255.255
Tunnel CIddr : 0 . 0 . 0 . 0 SPC Poist : 1701 Dest Poist : 0 UDP port
Pi-otocol : 17 TunnelFilter: No
Flags : Inbound 1701 for
e command completed s u c c e s s f u l l y
The L2TP server's IPSec Policy has these characteristics:

Policy Name: L2TP Rule
Authentication: Certificate
Source IP: Me
Destination IP: Any
Source Port: Any
SANS Institute
Destination Port: 1701 UDP

Mirrored: Yes
Enable Default Response Rule: No
olicy Injection for L2T

You can disable this automatic injection of IPSec Policies for L2TP on the RRAS box.
In this case, you must take care to recreate the above Policy by hand on the RRAS server;
without it, L2TP packets will be sent in the clear (see KB240262 and KB248750 for step-
by-step instructions).
It is possible to establish an L2TP VPN tunnel without IPSec encryption. This is because
IPSec and L2TP are more-or-less completely independent of each other. The last thing
that happens to an L2TP packet before it leaves the computer is to be encrypted with
IPSec, hence, IPSec can be disabled and the packet will go in the clear.
To disable the automatic injection of a dynamic IPSec Policy, add the following registry
value on the RRAS server then reboot (KB258261):

Key: \System\CurrentControlSet\Services\Rasman~arameters
Value Name: ProhibitIpSec
DataType: REG DWORD
Value: 1 (deTault is 0 = create dynamic L2TP IPSec Policy)
olicy lnjectio
Instead of relying on RRAS to inject dynamic IPSec Rules for the sake of L2TP, one can
simply disable the injection and create a regular IPSec Policy for L2TP. This IPSec
Policy should have the configuration described above.
There are a number of advantages to creating an IPSec Policy for L2TP by hand:
The dynamic Rules injected by RRAS include the option to use AH by itself if
ESP cannot be successfully negotiated. AH should never be used alone for
Internet VPNs when confidentiality is desired.
Creating a static IPSec Policy for L2TP by hand enables you to precisely control
the protocols, key lengths, key regeneration, authentication, and other IPSec
options for your VPN. If you want 3DES ESP for best encryption and NAT-
compatibility, then you can configure your VPN to accept and require only that.
If the IPSec Policy Agent service is restarted, but RRAS is not, then the dynamic
L2TP Rules are erased from the IPSec Driver's working cache. This can result in
i
some L2TP packets being sent in the clear, even though the other peer will reject
them since they are not protected with IPSec.
SANS Institute
I
A manually created static IPSec Policy for L2TP will survive restarts of the IPSec
Policy Agent service. You will not have to restart RRAS as well. Hence, you
don't have to worry that you dynamic Rules have been cleared or overridden.
Static IPSec Policies will also be visible in the MMC snap-ins for IPSec, which
will solve the mystery of where these come from. Also, you can deploy these
IPSec Policies through Group Policy.
Again, to configure a static IPSec Policy for L2TP, set the registry value above, reboot,
then create an IPSec Policy with the following characteristics and assign it to your RRAS
servers through local or Group Policy:
i Policy Name: L2TP Rule

Authentication: Certificate
Source IP: Me
Destination IP: Any
Source Port: Any
Destination Port: 1701 UDP
Mirrored: Yes
Enable Default Response Rule: No
ote: Make certain that your L2TP Policy does not have the option enabled to
"Allow unsecured communication with non-IPSec-aware computers".
Also, if the IPSec Policy Agent service is stopped, L2TP connections cannot be
established.
GE?S
Cl Recommended (RRAS: General): Set the ProhibitlpSec registry value to prevent
RRAS from injecting dynamic settings into the IPSec driver. Next, create an IPSec policy
by hand --with just the settings you want-- to encrypt all L2TP traffic (UDP 1701).
SANS Institute
Layer 2 Tunneling Protocol (L2TP) and the Point-to-Point Tunneling Protocol (PPTP)
are the two native VPN protocols in Windows. Both use the Point-to-Point Protocol
(PPP) for link control and user authentication. PPP is more widely known for its use in
dial-up networking, but L2TP and PPTP adapt it for use with VPNs.
L2TP and PPTP have important differences which may force you to use one instead of
the other. If security is your only concern, then use IPSec/L2TP. PPTP has a horrible
reputation, and deservedly so, but most of the vulnerabilities are found in PPTPvl .
However, there is a second version (PPTPv2) and its use isn't out of the question if
certain precautions are taken. IPSec/L2TP is still better than PPTPv2, but it deserves a
second look. Let's do a comparison-contrast.
L2TP is not vulnerable to password sniffing attacks because it uses IPSec to

encrypt all password-related information.
Both PPTPvl and PPTPv2 authentication sessions can be sniffed to extract

password hashes, which can then be loaded into password crackers (like
LOphtCrack) or used in custom hash-only SMB clients to log into the VPN server.
ion
L2TP uses IPSec ESP in transport mode for its data encryption, hence, L2TP
encryption can be excellent. Initial keys can be negotiated with a 1024-bit or
larger Diffie-Hellman exchange and Perfect Forward Secrecy, then 168-bit 3DES
session encryption keys can be used with PFS as well for the bulk encryption.
PPTP uses Microsoft Point-to-Point Encryption (MPPE) described earlier. MPPE

encryption can be up to 128-bit RC4. The RC4 key is ultimately based on the
user's password, however, and passwords are far easier to guess than pseudo-
random bits. Hence, encryption strength is mainly determined by the length and
randomness of the user's password (and whether or not MS-CHAPv2 was used).
Computer Ce
L2TP uses certificates for IPSec authentication. Hence, every RRAS server and
client must have an X .509~3digital certificate installed. This can be greatly
simplified with computer auto-enrollment, but the PKI does add more complexity.
PPTP servers and clients do not require computer certificates.
SANS Institute
IPSec has complex NAT compatibility issues, hence, L2TP VPN's have complex
NAT issues. However, with Windows 200O+SP4/XP+SP2/2003 and later the
IPSec driver has been updated to support NAT-T to overcome these limitations.
And if the NAT is being performed by the RRAS gateway itself, then the NAT-
ing is generally not a problem since the IPSec and NAT operations are performed
separately from each other.
PPTP is compatible with NAT.
lie
Windows 2000 and later natively supports L2TP/IPSec, but Windows
NT/9x/Me/Ce do not. Hence, if you require L2TP/IPSec at the VPN server, your
clients must be Windows 2000 or later. However, there is an upgrade available
from Microsoft to add L2TP/IPSec support to Windows 98/Me/NTW (see below).
Windows Me and later supports PPTP. Importantly, though, only Windows Me

and later supports MS-CHAPv2 out of the box. Windows NT/9x must be patched
to support MS-CHAPv2 (see below in the section on the L2TP client). Some
Cisco products also support PPTP natively, and there are PPTP clients for Linux
as well.
6?C lie
Microsoft provides a free upgrade to Windows 98/Me/NT so that these clients can
support L2TP tunnels with IPSec encryption.
ote: The L2TP/IPSec VPN Client does not add general-purpose IPSec
functionality to Windows 98/Me/NTW. It is only for L2TP VPNs.
The upgrade can be downloaded from Microsoft's website; just do a search on the phrase
"Microsoft L2TP/IPSec VPN Client". It was last seen at the following URL:
http://vv\;vw.i~icrosoft.coi~windows2OOO/server/evaluatio~news/bulletins/l2tpclient.asp
This page also describes the Dial-Up Networking Upgrade necessary to support MS-
CHAPv2, which is important for PPTPv2 and dial-up connections as well. The page also
links to a FAQ and release notes for the upgrade that discuss important restrictions and
limitations. For example, only a singlk VPN session can be established at a time, the
IPSec offers are hard-coded, only certificate and pre-shared key authentication methods
are available.
The upgrade also includes support for UDP encapsulation of IPSec (NAT-T). This
permits the traffic to pass through a NAT router or proxy server without problems.
Windows 2OOO-SP4/xP-SP2 and later also provide this feature.
SANS Institute
ord Sniffing
Even with MS-CHAPv2, PPTPv2 logon sessions can still be sniffed to extract the NT
hash of the user’s password. This hash can then be loaded into LOphtCrack or other
similar tools for dictionary-based and brute-force cracking. The hash could also be used
with a modified SMB or PPTP client that doesn’t require the cleartext password in order
to successfully authenticate.
However, Windows supports passphrases up to 127 characters in length. The NT hash of

this passphrase is actually an MD4 hash of this entire case-sensitive Unicode string.
Provided that the passphrase is complex and long enough (25 or more characters) then the
passphrase could not be recovered in any reasonable period of time. Non-standard
characters from the Unicode character set would also prevent successful cracking. Since
PPTPv2 doesn’t use the LM hash in any form, LM vulnerabilities don’t apply.
Nonetheless, even without the cleartext passphrase, hash-only authentications with
modified SMB or PPTP clients would still be possible.
Hash-only authentications do not work, though, if you require certificate-based

authentication for your PPTPv2 tunnels. Like IPSec/L2TP VPNs, PPTP also supports the
use of EAP-TLS certificate authentication. Certificates are ideally distributed to users as
smart cards, but these certificates can also simply be installed in their profiles. With a
Windows Enterprise CA, these certificates can be deployed hands-free through Group
Policy. Alternatively, EAP on RRAS can also be used to authenticate with SecureID
tokens, crypto-cards, biometric devices, etc., assuming that your vendor provides a PPTP
plug-in for the client’s side, and these other EAP methods block the hash-only
authentication threat as well.
In Bruce Schneier and Mudge’s analysis of PPTPv2 --this is the second paper, not the
first one on PPTPvl-- they summarize their conclusions as follows: “Microsoft has
improved PPTP to correct the major security weaknesses described in [our earlier
analysis of PPTPvl]. However, the fundamental weakness of the authentication and
encryption protocol is that it is only as secure as the password chosen by the user.”
Hence, use a smart card, or use a certificate in your local profile, or use a good
passphrase. Or, better yet, use IPSec and L2TP instead.
PTP Packet Filters

PPTP uses two channels of communication: TCP port 1723 for tunnel maintenance and
protocol ID 47 for the GRE packets which actually carry the tunneled data.
PPTP Input Filters

Destination TCP port 1723 (Ox06BB).
Protocol ID 47 (Ox2F).
Source established TCP port 1723 (Ox06BB); only needed if the RRAS
server is a PPTP client to another RRAS server.
SANS Institute
Drop all outgoing packets from the RRAS server except the following:
Source TCP port 1723 (OxOGBB).
Protocol ID 47 (Ox2F).
Destination established TCP 1723 (OxOGBB); only needed if the RRAS
server is a PPTP client to another RRAS server.
S ses
Schneier and Mudge's analysis of PPTPv2 and MS-CHAPv2:
http://www.counterpane.com/pptpv2-paper. html
Aleph One's PPTPv2 password sniffer for LinudUnix (Anger-1.33):

http://www. securityfocus.com/tools/5
Linux/Unix version of Dsniff (which implements Aleph One's Anger):

http://pacltetstormsecurity.nl (and search for "dsniff I )
PPTP clients and servers for Linux:

http://www.cag.lcs.init.edu/-cananianjProjects/PPTP/ (client)
http://poptop.lineo.com/ (server)
ftp://ftp .rubyriver.com/pub/jhardin/masquerade/ip masq-vpn. html
http ://bmrc.berkeley .edu/people/chaffee/linuxgpG.htrnl
http ://cag.ICs .init.edu/-cananian/Proj ects/IPfwdl
Modifying an SMB client (SAMBA) to use just a password hash:

http://packetstonnsecurity.nl/papers/NT/NTcred.txt
http ://www.core-sdi.com/papers/nt-cred. htm
SANS Institute
The following is a summary of the checklists from the document. The number following
each step is the page number in the manual where it is discussed further.
Mandatory : A mandatory step must be done unless there is a compelling reason

not to do so and compensating measures have been exerted.
Recommended: A recommended step should be completed unless there is a valid

reason for not doing so.
Paranoid: Paranoid steps will improve the security of your server, but the benefit
of doing so may be outweighed by the effort required, confusion entailed or
features sacrificed.
Mandatory (IPSec: Phase I): For Phase I settings, always set the Diffie-Hellman group
to Medium(2) or higher ..................................................................................................... 57
Mandatory (IPSec: Phase I): In both Phase I and Phase 11, remove any offers from the
list you are not willing to accept, don't just move them to the bottom. ............................ 57
Mandatory (IPSec: Phase 11): If you want 3DES support in Windows 2000, install
Service Pack 2 or later. Windows XP and later supports 3DES by default. To balance
compatibility and security, choose 3DES encryption. To maximize security, choose
AES-256, but remember that this (currently) only compatible with Windows Vista and
later. .................................................................................................................................. 60
Mandatory (IPSec: Authentication): Do not use preshared key authentication if you
can help it. The "keys" are stored in the registry in cleartext. However, don't be
surprised when preshared keys are necessary to interoperate with other vendors' products.
The compromise of a preshared key does not enable one's adversaries to decrypt other
captured IPSec sessions. ................................................................................................... 66
Mandatory (IPSec): Set the NoDefaultExempt registry value to 1 on Windows 2000/XP
and to 1 or 3 on Windows Server 2003 and later (KB811832). These values are set
automatically with SP4 for Windows 2000, SP2 for XP, and is set to 3 on Windows
Server 2003 and later by default. This value determines, among other things, whether
Kerberos traffic is exempt from IPSec filters. .................................................................. 76
Mandatory (IPSec: Filter Actions): In Windows 2000/XP/2003, be very cautious when
choosing to "Allow unsecured communication with non-IPSec-aware computers". This
can defeat the point of using IPSec in the first place. This is the "fail open" option, i.e.,
fail to cleartext. This option may be required, however, in a mixed environment where
backwards compatibility must be maintained.. ................................................................. 97
Mandatory (IPSec: Filter Actions): In Windows 2000/XP/2003, on an intranet, it is
generally safe to enable "Accept unsecured communication, but always respond using
SANS Institute
IPSec". However, on Internet-accessible peers, do not check this box and try to restrict
the IP addresses which are permitted to access UDP ports 500 and 4500 ........................ 97
olicies): Use RRAS Policies to regulate remote access, not the old
issions on the Dial-In tab of user accounts. ............................................. 136
olicies): Organize your remote access RRAS Policies around
your global groups. Some groups will be allowed dial-up or VPN access, others should
always be denied. If some groups are allowed, then different groups will face different
security requirements and restrictions, e.g., Domain Admins may be required to
authenticate with their smart cards while regular users can just use their passwords. ... 136
:Authentication): Only allow MS-CHAPv2 or EAP-based
ds for dial-up or VPN access to RRAS. All other authentication
methods should be considered obsolete. MS-CHAPv2 or better is required for PPTPv2
support, and you must use PPTPv2 if you plan to support PPTP at all (never use plain
MS-CHAP with PPTP). If possible, prefer PEAP-TLS over MS-CHAPv2. ................. 140
S: Authentication): Even MS-CHAPv2 is vulnerable to password
hash sniffing, hence, it is critical that you enforce the toughest passphrase policy your
users can endure. This is especially important for PPTPv2 VPNs. Keep in mind that
passphrase length is more important than complexity. If possible, require at least 25
................................................................................................... 140
ncryption): When using PPTP, the strength of the encryption on
a user's VPN tunnel is mainly determined by the length and randomness of the user's
passphrase. Hence, enforce the toughest password policy your users can endure, e.g., a
minimum of 25 characters in length. Alternatively, use EAP-TLS certificate
authentication with PPTPv2 and the keys for tunnel encryption will be randomly derived.
......................................................................................................................................... 147
): Use RRAS Policies to filter the packets of remote users in
e principle of least privilege. Domain Admins will likely need
unfiltered access, but members of the Sales group, for example, might only need access
to the e-mail server or to a certain database server. If another group only needs access to
a Terminal Server, for instance, then block all packets except TCP/3389 to just that
server.. ............................................................................................................................. 149
irewalls): When planning your IPSec rollout, you must take into
consideration any routers, proxy servers or firewalls in your environment that perform
Network Address Translation (NAT). IPSec has complex NAT compatibility issues. The
best general solution to the NAT problem is to use IPSec NAT-Traversal (NAT-T) as
described in KB8 18043. NAT-T is available for Windows 2000 and later, but Windows
2000/XP do not support it by default, they require free software upgrades, and Windows
1 2000 RRAS VPN gateways cannot use NAT-T at all, only Windows Server 2003 or later
RRAS can. Be aware that XP-SP2 disables NAT-T by default, but it can be re-enabled
through a registry value modification. However, there is rare exploit associated with
NAT-T that can make it unacceptable in high security environments (KE3885348). ..... 157
eneral): Enable RRAS account lockout for failed remote access
attempts. Consider setting a threshold of five attempts for a 20-minute lockout to
mitigate DoS attacks while thwarting brute-force password guessing. These changes are
made in the registry of the RRAS or IAS server itself, not in Active Directory. ........... 160
- SANS Institute
S): Enable logging of failed and successful remote access attempts, then
actually review the logs with an automated script or other tool. .................................... 194
ec S
ecommended (I Sec: General): Use Performance Monitor to track CPU utilization

and packet throughput after implementing IPSec or after increasing the security settings
of your IPSec policies. In general, tailor your IPSec settings to your likely adversaries
and your overall security posture, i.e., don't needlessly kill the performance of your
network. ............................................................................................................................ 55
ecommended (I Sec: General): Purchase IPSec-offload network adapter cards to
dramatically improve the performance of IPSec. Faster CPUs and multi-processor
motherboards will also alleviate the stress of using IPSec on servers and VPN gateways.
If an SSL accelerator card supports the CNG/CryptoAPI interface, then some models can
be used to accelerate main mode negotiations as well ...................................................... 55
Recommended (I hase I): In very high security environments, enable Master
Key Perfect Fonv cy for Phase I. It is more important to enable PFS in Phase I1
however. Keep in mind that PFS issues are a common cause of incompatibilities between
different vendors' implementations of IPSec. ................................................................... 57
ecommended (I hase I): In Phase I, rekey and reauthenticate on the basis of
minutes of time transpired, not on the number of sessions (set sessions to zero). The rate
of new sessions can be unpredictable and is not the relevant factor. As a rule of thumb,
no more than lOOMB of data should be secured with a single key. Hence, estimate how
many minutes it typically takes for the computer(s) under consideration to transmit
1O O M B of data, then rekey before that number of minutes. If in doubt, change the
number of minutes to 120 and set the number of sessions to zero. This also has the
advantage of reducing the number of stale security associations a peer must hold in
memory (about 5Kl3 per session). Main mode rekeying has a relatively small impact on
performance. ..................................................................................................................... 58
ecommended (I hase I): Require 3DES encryption or better in both Phase I
and Phase I1 whenever possible. Don't forget that Windows 2000 requires Service Pack 2
or later in order to support 3DES. Regular DES encryption is fine for low security
environments where the intent is to only thwart casual eavesdropping............................ 58
ecommended (I ): In both Phase I and Phase 11, always use SHA-1 or
etter. Never use .................................................................................... 58
ecommended (I : In both Phase I and Phase 11, always use SHA-1 or
etter. Never use .................................................................................... 60
ecommended (I Key lifetime should be 60 minutes (or less) and
100MB (or less). Smaller numbers are more secure, but less efficient. The defaults are
fine for most environments. .............................................................................................. 60
ecommended (I See: Authentication): In general, intranet peers should use
Kerberos, and only Kerberos, while external Internet peers should use only certificate
authentication. RRAS VPN servers will need to be configured with both certificate and
Kerberos authentication methods. If you can only support having a single authentication
method, then choose certificate......................................................................................... 66
SANS Institute
uthentication): When both certificate and Kerberos

ed, make certificate authentication the first method in the list,
sfies a number of design scenarios and avoids problems. .....67
thentication): Enable certificate revocation checking only in
very high security environments. It will slow authentication and adds another step which
can fail. Set Stro CrlCheck = 1 for a compromise between security and stability. ...... 67
ecommended ( uthentication): Use computer auto-enrollment with a
Windows Enterprise CA to simplify the distribution of certificates. Use the Certificate
Services Website ( h t t p : / / ~ e ~ e ~ ~ ~ ~ e /for c edistribution
r t s r v ~ to foreign-domain or
e Internet. ........................................................................................... 67
See): Ideally, your physical network topology should reflect the
security requirements of the hosts on each segment. Each segment will have a different
IP subnet number, and endpoints can then be keyed to these subnets. This will have other
security benefits related to switches, routers and internal firewalls. ................................ 76
See): Disable NetBIOS when possible. Remember that IPSec does
not apply to broadcast traffic, including NetBIOS broadcast traffic, and a lot of
reconnaissance information can be sniffed fi-om NetBIOS broadcasts. This
recommendation is especially important if you intend to use IPSec to secure your
ons. ................................................................................................. 76
ec): Be careful when assigning IPSec policies to infrastructure
servers such as DNS, WINS, and DHCP servers. Domain controllers should also be
carefully configured to avoid obstructing their Kerberos, LDAP, SMB and RPC traffic.
Consider exempting internal ICMP traffic for the sake of PMTU discovery and network
. .
........................................................................................................... 76
eneral): In Windows 2000/XP/2003, a Policy can have
multiple Rules enabled in it. Instead of creating a single Rule with a very complex Filter
List, create multiple Rules with relatively simple Filter Lists. Give each a descriptive
name. This will give you more manageable granularity and the IPSec Policy will be
easier to understand........................................................................................................... 88
ists): In Windows 2000/XP/2003, try to specify only IP
types or port numbers. For IP addresses, prefer to use
“Any IP Address” and subnets instead of “My IP Address” or large numbers of individual
addresses. Prefer “Any<->Subnet” Filters over “Any<->Any” Filters, especially on
laptops and Windows 2000 systems. In general, try to simplify the Filters as much as
possible to optimize performance. Another advantage of this is that you will not have to
predict or understand which protocols a client can use to access a server-- you can trust
that all packets going between them will be secured no matter what new application or
service is installed. This is particularly important for FWC-based services. (This can also
help to avoid problems related to incompatible authentication methods.) It is feasible to
have 500 mirrored Filters in a Filter List on a high-end machine, but the fewer Filters the
better. ................................................................................................................................ 91
eco ists): In Windows 2000/XP/2003, mirror your Filters
whenever possible. Problems can arise if traffic is secured going in one direction (A +
B) but not in the other (A C- B). Mirroring also makes complex Filter Lists easier to
understand. ........................................................................................................................ 92
SANS Institute
Recommended (IPSec: Filter Lists): In Windows 2000/XP/2003, use the Name and
Description fields in a Filter List to reduce misunderstandings. Be explicit in what the
Filter List covers. Don’t customize standard Filter Lists that have been in use a long time;
instead, create a new Filter List with your modification so that it will be clear to others
that it is different. Consider defining a collection of standardized Filter Lists in your
organization in a whitepaper or policy document, and devise a consistent naming
standard. ............................................................................................................................ 92
Recommended (IPSec: Filter Actions): Be mindful that Filter Lists are processed in
order from most-specific to least-specific. This is what determines which Rule’s Filter
Action is triggered. Use this to create “Deny All Except.. .‘I rules, but beware of the
potential complexity.......................................................................................................... 97
Recommended (IPSec: Filter Actions): As described in KB8 18043,2048-bit Diffie
Hellman support requires a registry value change and, on Windows 2000/XP, the
installation of a patch. 2048-bit DH groups should be used in high security
environments. .................................................................................................................... 97
Recommended (IPSec: Group Policy): Consider assigning a Windows 2000/XP/2003
IPSec Policy with the Default Response Rule at the domain level through Group Policy,
then customize IPSec Policies at the OU level. Remember, the very last IPSec Policy to
be assigned on a Windows 2000/XP/2003 host, after all the Group Policy Objects have
been processed, will be the one and only effective IPSec Policy on that host. Hence, an
IPSec Policy assigned at the OU will override any IPSec Policies assigned at the site or
domain. If an OU lacks an assigned IPSec Policy, then the Default Response Rule at the
domain level will be in effect. However, even better than using the Default Response
Rule is to create a fully-configured Policy at the domain level with all the needed
exemptions. As a domain-wide default Policy, this configuration will better permit the
exemptions to function as expected and will cause fewer time-outs. Remember, though,
that on Windows Vista and later, WFAS IPSec policies are merged across multiple
GPOs. .............................................................................................................................. 107
Recommended (IPSec: Group olicy): Consider creating GPOs which contain only
firewall and IPSec settings, then ghtly control the permissions on the GPO and its links
to prevent other administrators fiom modifying them. Audit failed access too. This is
warranted by the complexity and sensitivity of firewalling and IPSec. ......................... 107
Recommended (IPSec: Group Policy): Don’t forget about portable computers when
assigning firewall and IPSec settings through Group Policy. These machines will need to
function normally when outside the LAN away from the forest. For this purpose, avoid
filters constructed around “My<->Any” or “Any<->Any” addresses; use filters tied to
specific internal subnets or particular IP addresses instead. ........................................... 107
Recommended (IPSec: Group Policy): Before deleting a GPO, unassign any IPSec
policies in it and clear any firewall policies in it. Similarly, before deleting an IPSec
policy from a GPO, unassign that IPSec policy first (or assign a different one), let this
change fully replicate through Active Directory and Group Policy, then delete the IPSec
policy afterwards (see KB234320). ................................................................................ 107
Recommended ( S: Policies): If possible, convert Active Directory to native mode
or higher in order to fully benefit from RRAS Policies and other security features such as
Caller-ID. Otherwise, to use some of these features, the RRAS server would have to be a
stand-alone and only use local user accounts. ................................................................ 136
SANS Institute
i
ecommende olicies): Regularly audit which users have the Allow Access
permission on the Dial-In tab of their accounts. These users might be able to circumvent
RRAS policies. The Resource Kit RASUSERS.EXE tool can list them, as well as ADS1
scripts. ............................................................................................................................. 136
olicies): Consider assigning static IP addresses to users who
ely monitored or who require special entries in the access
ntrol lists of fi ............................................................................................ 137
licies): For dial-up users, consider using Caller-ID or
callback security to help prevent hackers from dialing in from random locations. ........ 137
cies): Create a global group named "Denied All Remote
Access" and use RRA es to deny all remote access to that group. Add users and
other groups to this one as necessary. This is a better method of excluding certain users
than setting the Deny Access permission on each of their accounts individually (Dial-In
)..................... ..................................................................................................... 137
ecommended ( S: Authentication): Use certificate-based EAP-TLS
authentication for very secure authentication to RRAS. The user's certificate can be
stored in his or her smart card for added security. Other EAP-based authentication
modules can be purchased fi-om third-party vendors. ..................................................... 143
ecommended ( ncryption): Require the strongest available encryption for the
remote access sessions of Domain Admins and other sensitive users. In low- to medium-
security environments, regular users can be permitted to use just strong encryption, if
necessary. "Strongest" encryption is 168-bit 3DES with IPSec and 128-bit RC4 with
PPTP, or better. "Strong" encryption is 56-bit DES with IPSec and 56-bit RC4 with
PPTP, or better. ............................................................................................................... 147
all): Your firewall should filter both the VPN packets
streaming into your ateway from the Internet and the clear-text packets coming
out of the VPN tunnel on their way into the LAN. Don't route or bridge users' packets
coming through the VPN into the LAN without first passing them through another layer
of firewall filtering. This layer of filtering might be implemented on the RRAS gateway
itself (not ideal), by passing the users' packets back through the main firewall again
(better), or by implementing another internal firewall behind which the RRAS gateway
sits (best). Sitting behind this internal firewall might also be your 802.1 I wireless access
ervers, routers with WAN links to remote sites, etc. ...................157
irewalls): When using IPSec certificates to authenticate
all cannot filter out fragmented UDP 500/4500 packets
because the size of the certificates often causes packet fragmentation. ......................... 157
): If you have deployed Intrusion Detection System
a sensor on the segment(s) through which VPN, dial-
.................................................................................. 157
): Consider distributing CD-ROMs to your users with
anti-virus and personal firewall software which they can install and use on their corporate
laptops and personal computers at home (get enterprise licenses first, of course).
Consider including a script on that CD which makes other desirable configuration
changes, but make sure it doesn't break their critical applications, e.g., Solitaire, Quake,
Pinball, etc. Windows XP Service Pack 2 and later automatically installs and enables the
Windows Firewall, so apply SP2 or later to XP as soon as possible. ............................. 158
SANS Institute
230 IPSec, RADIUS. Wireless. and VPNs
Recommended (RRAS: Firewall): Train users how to use the Windows Automatic
Updates feature and encourage (or beg) them to use it regularly on their personal systems
at home. If possible, encourage their use of Windows XP or later with the latest Service
Pack. Use Group Policy to push out custom Windows Firewall settings or use a
NETSH.EXE script to do the same................................................................................. 158
Recommended (RRAS: Firewall): Consider setting up a Microsoft Terminal Server,
Citrix Server, or some other "thin-client" server for your users. Next, block all your
users' dial-up and VPN packets except the necessary packets to/from the thin-client
server. Enforce strong password policies and don't forget that Group Policy applies to
virtual desktops too. ........................................................................................................ 158
Recommended (RRAS: Firewall): As much as feasible, prevent users from modifying
their route tables to do "split tunneling", that is to say, prevent thein from changing their
default gateways in their route tables to anything other than the VPN tunnel itself. This
may require a third-party product or a corporate policy that prevents users from having
local administrative access on their computers. RRAS quarantine mode will help in this
effort. ............................................................................................................................... 158
Recommended S: General): Don't forget that RRAS can do its own packet
filtering on each interfaces, and dial-up/VPN connections are considered
"interfaces" in this regard. Hence, filter these packets in accordance with the principle of
least privilege. Windows 2000 RRAS provides only static filtering, but Windows Server
2003 includes XP-style dynamic filtering as well. For even more packet control from a
Microsoft product, install Inte Security and Acceleration Server (ISA Server)....... 158
Recommended (Connection ager: General): Use the free Connection Manager
Administration Kit (CMAK) to create a setup program which can install a dial-up or VPN
"connectoid" on your users' machines. When you do this, configure the setup program to
create a connectoid which enforces your desired access policies, e.g., IPSec/L2TP only,
MS-CHAPv2 only, strongest available encryption only, preventing the saving of
passwords, etc. Use Group Policy, logon scripts or some other method of running the
setup program hands-free on all your users' systems...................................................... 182
Recommended (RADIUS: General): Consider using a RADIUS server, Microsoft's or
otherwise, to centralize policy enforcement and logging. .............................................. 188
Recommended (RRAS: General): Set the ProhibitIpSec registry value to prevent
RRAS from injecting dynamic settings into the IPSec driver. Next, create an IPSec
policy by hand --with just the settings you want-- to encrypt all L2TP traffic (UDP 1701).
......................................................................................................................................... 219
aranoid Steps
Paranoid (IPSec: Filter Actions): In Windows 2000/XP/2003, the most secure settings
are 3DES only, SHA-1 hashing, certificate authentication, Perfect Forward Secrecy, no
default filter exemptions, tunnel mode only, and extremely frequent rekeying. That being
said, the performance penalties and management hassles these settings will entail would
only make sense in the most paranoid of environments. You must balance security,
..
performance and manageability. ....................................................................................... 97
SANS Institute
S: Constraints): Consider restricting the days and hours when users are
permitted to dial or VPN into the LAN to those times when security personnel are present
who can respond to incidents or IDS alerts. ................................................................... 145
SANS Institute

SANS Security 505.4 Windows Firewalls, IPSec, Wireless &amp; VPN&#39;s

Uploaded by

Copyright:

Available Formats

You might also like

SANS Security 505.4 Windows Firewalls, IPSec, Wireless &amp; VPN&#39;s

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SANS Security 505.4 Windows Firewalls, IPSec, Wireless &amp; VPN&#39;s

Uploaded by

Copyright:

Available Formats

Copyright 02010, The SANS Institute. All rights reserved.

The entire contents of this i

Document Contact: Jason Fossen (Jason@EnclaveConsulting.com)

Table of Contents ................................................................................................................ 5

Secure Socket Tunneling Protocol (SSTP) ..................................................................... 161

RFC Searchable Library http://www .rfc-editor.org

When a MS-number is referenced in the course, e.g., MS98-003, this refers to a

IPSec RFCs, read in this order: RFCs 2401,2402,2406 and 2409.

elevant Requests for Comments (

The SKEME public key authentication protocol is described in "SKEME: A Versatile

ubleshooting in Windows 2000

KB233256: How to Enable IPSec Traffic Through a Firewall

IPSec is the industry standard for securing network communications. It provides

True end-to-end security requires IPSec/VPN support on user's desktops, on the

handle thousands of tunnels with an aggregate bandwidth of 300 Mbps? If you

TP, L2TP or SST

Configure local IPSec Policies in a computer's registry.

NETSH.EXE is a command-line utility for managing network adapters, protocols and

netsh.exe int ip show address

The NETDIAG.EXE command-line utility is a comprehensive networking diagnostic

In general, NETDIAG.EXE is better than 1PSECMON.EXE for troubleshooting and

Cum*ent Phase I SBs:

Curpent Phase 2 SAs:

File and Printer Siiaring (Echo Request - I

Dircoietyof other ccmputeriand devices will be limited and

A nelwork location identifies the $pe of natviorl that a computer 15

user man change location

User cannot change location

program is prevented from receiving inbound connections (giving administrative users

.7 10.4.77.77 34717 1145 140 AP 4275654230 4059211288 1625i

, 3 10.255.255.255 137 137 78 ---- -- RECEIVE

- First Match Wins (No)

Programs and Services: The exact program binary or background service(s) to

Users and Computers: If only IPSec-secured connections are allowed (General

including dynamically-assigned RPC and NAT ("Edge Traversal") ports, or any

If an IPSec-secured connection is only for particular users or computers (as defined on

The dialog box gives the user two choices:

1. Rules that allow/block traffic for particular services.

I Commands and data used by I Pretty Good Privacy I

An important point to understand is this: as authenticatiodencryption features are

That is the real shortcoming of doing encryption/authentication at the Application and

utual Authentication equired. Unlike SSL, both IPSec peers must

ES Encryption. The payload of a packet (or the entire packet

Static tering. Though IPSec is mainly known for authentication and

lications and Services. Because security is implemented at

ser . Users do not have to be trained to use IPSec. In

anagement. Users do not have to be trained because IPSec can

Remote Command-Line anagement. The IPSec driver is 100% manageable

Windows Firewall Integration. The XP-SP2/2003-SP1 Windows Firewall has a

ardware Accelerators. IPSec cryptographic operations can be off-

have to be predicted and managed. The servers can additionally be required to

nteroperable. Because IPSec is an IETF standard, it is not owned by any single

Extensible. IPSec was designed to be extensible and flexible. For example, as

v6 Support. IPSec was designed with IPv6 in mind. The version of IP in

ort. Virtual Private Networking is the ability

). IPSec and NLB are compatible and can be

backs to the s Implementation of I

A Windows IPSecNPN will not have the same throughput as a hardware-only

With the possible exception of Cisco devices, Microsoft is not particularly

SANS Security 505.4 Windows Firewalls, IPSec, Wireless & VPN's

SANS Security 505.4 Windows Firewalls, IPSec, Wireless & VPN's

SANS Security 505.4 Windows Firewalls, IPSec, Wireless & VPN's