Securing Access for Remote Users and Networks

Planning Remote Access Security Designing Remote Access Security for Users Designing Remote Access Security for

Networks Designing Remote Access Policy Planning RADIUS Security

Planning Remote Access Security

Choosing between dial-up and virtual private network (VPN) solutions

Planning remote access authentication Planning dial-up protocols Planning VPN protocols Planning integration with Microsoft Windows

NT 4.0 Remote Access Service (RAS) servers

Dial-Up Access

VPN Access

Making the Decision: Choosing Between Dial-Up and VPN Remote Access

Use dial-up access if The organization maintains an existing modem pool Most remote connections to the network are through local

access numbers and do not require long distance or toll-free charges

The organization requires an alternative connection method between offices if a dedicated network link fails

Use VPN access if The organization wants to outsource modem support to an

ISP Users have existing Internet access The organization wants to reduce the costs associated with

long-distance and toll-free numbers The organization requires faster access speeds than are

possible with dial-up networking solutions

Applying the Decision: Hanson Brothers Requires Both Dial-Up and VPN Remote Access Dial-up access

The stock application from Adventure Works requires a dial-up connection.

Hanson Brothers will restrict the connection to a specific phone number.

VPN access Connect Montreal to the corporate office in Warroad. Create a demand-dial connection as a backup. Packets will initiate the dial-up connection if the VPN

is unavailable.

Authentication Protocols Supported by Windows 2000 RRAS

Routing and Remote Access Service (RRAS) supports

Password Authentication Protocol (PAP) Shiva Password Authentication Protocol (SPAP) Challenge Handshake Authentication Protocol (CHAP) Microsoft Challenge Handshake Authentication

Protocol (MS-CHAP) Microsoft Challenge Handshake Authentication

Protocol Version 2 (MS-CHAPv2) Extensible Authentication Protocol (EAP)

The Advantage of Two-Factor Authentication

Adds security to the authentication process Requires two forms of identification when

users are authenticating with the network

Making the Decision: Choosing a Remote Access Authentication Protocol

Low level of protection PAP SPAP

Medium level of protection CHAP MS-CHAP

High level of protection MS-CHAPv2 EAP-TLS

Applying the Decision: Hanson Brothers Must Implement MS-CHAP and MS-CHAPv2 These protocols provide the strongest form of

authentication acceptable to both the remote client and the RRAS server.

Implement strong encryption on the remote access connection from Adventure Works.

Internet Protocol Security (IPSec) tunnel mode is the only choice for connecting the Montreal office securely to the Warroad office over the Internet.

Remote Access Protocols Supported by Microsoft Windows 2000

Point-to-Point Protocol (PPP) Serial Line Internet Protocol (SLIP) Asynchronous NetBEUI (AsyBEUI)

Making the Decision: Choosing a Remote Access Protocol

PPP SLIP AsyBEUI

Applying the Decision: Hanson Brothers Implements PPP Remote Access Protocol

Windows 2000 RRAS will provide remote user and office connectivity.

PPP meets all needs for connectivity. SLIP is supported only for remote access

clients. There is no need to configure the remote access

clients to support SLIP connections. There is no need to support AsyBEUI remote access

connections.

Planning VPN Protocols

VPN Protocol Introduction

Windows 2000 supports VPN solutions for both client-to-server and network-

to-network connectivity Both Point-to-Point Tunneling Protocol (PPTP) and

Layer Two Tunneling Protocol (L2TP)/IPSec solutions IPSec tunnel solutions for providing network-to-

network connectivity The design decisions do not vary for client-to-

network and network-to-network solutions. Network-to-network solutions can include

IPSec tunnel mode.

Point-to-Point Tunneling Protocol (PPTP)

PPTP requires an IP connection to exist before the VPN can be established.

PPTP uses Microsoft Point-to-Point Encryption (MPPE) to provide encryption of the transmitted data.

MPPE can use 40-bit, 56-bit, or 128-bit encryption keys. If a firewall is used, it should be configured to

allow the PPTP packets to pass through the firewall.

Use the destination port of TCP port 1723 and protocol ID 47 (Generic Routing Encapsulation (GRE))

Use PPTP to Meet the Following Requirements

If support for down-level clients is needed If the VPN must cross a firewall or perimeter

network that performs Network Address Translation (NAT)

If the organization requires the authentication of the user account only, not the machine account

PPTP Security Weakness

The original implementation of PPTP used MS-CHAP as the authentication protocol.

The latest update to PPTP has added support for MS-CHAPv2 and EAP authentication.

With PPTP deployed, it is possible to determine the password by using a dictionary attack if weak passwords have been used.

If weak passwords are a major concern, ensure that all remote access clients use Windows 2000, and issue smart cards to use EAP authentication.

Differences between L2TP and PPTP

L2TP does not include an encryption mechanism.

L2TP provides two forms of authentication. L2TP cannot pass through a firewall or

perimeter server performing NAT.

L2TP/IPSec Firewall Considerations

Configure the firewall to allow IPSec packets destined for the tunnel server to pass through the firewall.

The IPSec packets are destined for UDP port 500 on the tunnel server using the IPSec ESP protocol identified by protocol ID 50.

Do not configure the firewall to pass L2TP packets (destined for UDP port 1701) because the packets are still encrypted when they pass through the firewall.

IPSec Tunnel Mode

IPSec Tunnel Mode uses Encapsulating Security Payloads (ESPs) to encrypt all traffic passing between the tunnel endpoints.

Original IP packets are encrypted within the IPSec tunnel mode packet as they are transmitted across the unsecured network.

Data is decrypted when it reaches the endpoint nearest the destination computer.

IPSec Tunnel Mode Considerations

IPSec tunnel mode is a highly interoperable solution. IPSec does not provide user authentication of the

two endpoints involved in the IPSec tunnel. IPSec tunnel mode does not support client-to-

network VPN access. IPSec tunnel mode does not provide end-to-end

encryption of data. IPSec supports certificate-based authentication,

Kerberos, and preshared key authentication for IPSec connections.

Tunnel server placement can prevent IPSec tunnel mode communications.

Making the Decision: Selecting a VPN Protocol

PPTP L2TP IPSec Tunnel Mode

Applying the Decision: VPN Solutions for Connecting the Montreal and Warroad Offices

Planning Integration with Windows NT 4.0 RAS Servers

NULL sessions NULL sessions allow anyone connected to the

network to query the Active Directory directory service without the default security mechanisms in place.

Windows NT 4.0 RAS servers determine whether a connecting user has dial-in permissions by connecting to a domain controller (DC) with a NULL session.

Implications of Disallowing NULL Sessions With a Windows NT 4.0 RAS server that connects

to a Windows NT 4.0 backup domain controller (BDC) in a mixed mode network

Authentication will succeed because the Windows NT 4.0 BDC supports NULL sessions

With a Windows NT 4.0 RAS server that is a Windows NT 4.0 BDC in a mixed mode network

Authentication will succeed because the BDC can determine dial-in permissions by looking at its versions of the domain database

With a Windows NT 4.0 RAS server that connects to a Windows 2000 DC

The authentication will fail or succeed depending on the membership of the Pre–Windows Compatible Access security group

Membership of the Pre–Windows 2000 Compatible Access Security Group

Members of this group can query the DC with a NULL session.

Membership is determined by the user who creates a new domain in the forest.

The Everyone group can be added to the Pre–Windows 2000 Compatible Access security group.

There are security implications due to unsecured queries to Active Directory.

Making the Decision: Designing Remote Access when Windows NT RAS Servers Exist on the Network If the Windows NT 4.0 remote access server is

not a BDC, ensure that the membership of the Pre– Windows 2000 Compatible Access group contains the Everyone group.

Upgrade or decommission the Windows NT 4.0 remote access servers as soon as possible.

Remove the Everyone group from the Pre–Windows 2000 Compatible Access group after all servers are upgraded or decommissioned.

Applying the Decision: Windows NT RAS Server Considerations for Hanson Brothers There are no Windows NT 4.0 servers running

remote access services in the network. To prevent excess rights from being granted to

the network, inspect the membership and ensure that the Everyone group is not a member of the Pre–Windows 2000 Compatible Access security group.

Designing Remote Access Security for Users

Planning user settings for dial-up networking security

Authorizing dial-up connections Securing client configuration

Remote Access Settings for User Accounts

Set remote access permissions. Verify caller-ID. Configure callback options. Assign a static IP address. Apply static routes.

Making the Decision: Planning User Properties for Remote Access Security

Prevent remote access to the network. Use remote access policy settings to

determine remote access permissions. Restrict dial-up connections to a specific phone

number. Assign a specific IP address for all connection

attempts by the user. Restrict remote access clients to specific

network segments.

Making the Decision: Enabling the Remote Access Account Lockout Feature

Use this feature to deny remote access to a user account if a preconfigured number of failed authentication attempts occur.

This helps prevent an attacker from attempting dictionary attacks.

The attacked account is disabled for remote access once the number of failed attempts exceeds the configured threshold.

Remote access account lockout is not related to user account lockout.

Enabling remote access lockout leaves the network susceptible to an attacker who could lock out user accounts.

Making the Decision: Registry Settings to Enable Remote Access Account Lockout HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

\RemoteAccess\Parameters\AccountLockout\MaxDenials Sets the value for the failed attempts counter. If the counter exceeds the configured value, remote access is

locked out for the account. A successful authentication resets the failed attempts counter.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Parameters\AccountLockout\ResetTime

Sets the interval, in minutes, to reset the failed attempts counter to a value of 0.

The default value is 2880 minutes, or 48 hours. RADIUS authentication

Make the registry modifications at the server running Internet Authentication Services (IAS).

Applying the Decision: Deploying User Properties for Remote Access Security for Hanson Brothers Hanson Brothers

The default option of Control Access Through Remote Access Policy is appropriate for all user accounts.

Configure Deny Access for the Guest account. Adventure Works

Define a dedicated user account for connecting to the Hanson Brothers network.

Configure the dial-in settings for the account to Verify Caller-ID and set the predefined phone number at Adventure Works.

Hanson Brothers can cover the long-distance phone charges by using callback security to return the call to the specified phone number.

Authorizing Dial-Up Connections

Windows 2000 remote access authorization techniques can be implemented in addition to authenticating remote access connections.

Authorization techniques examine the attributes of the connection attempt, not the user account.

The entire phone system must support the authorization method.

If any part of the connection does not support the authorization method, authorization will fail.

Remote Access Authorization Methods

ANI/CLI and Caller ID Differences

Automatic Number Identification/Calling Line Identification (ANI/CLI) does not require the remote access connection to provide user credentials.

The remote access connection is authorized based on the originating phone number when ANI/CLI is used.

ANI/CLI does not send user credentials in the connection request.

The Caller-ID attribute is not verified until after the credentials are presented for a remote access connection.

Caller ID can be used to secure access to other resources on the network.

Making the Decision: Authorization Methods for Remote Access

ANI/CLI Dialed Number Identification Service (DNIS) Third-party security hosts

Applying the Decision: Authorization Methods for Remote Access at Hanson Brothers Hanson Brothers should consider using a combination of

ANI/CLI and DNIS for the connection from Adventure Works. Adventure Works should use a different phone number

when connecting to the Hanson Brothers network to query stock levels.

DNIS can identify connection attempts to the network and apply the most restrictive remote access policy to the connection.

Hanson Brothers can use ANI/CLI to provide Adventure Works with unauthenticated, but authorized, access to the network.

ANI/CLI cannot be used for requests to the stocking application, since user credentials will not be provided.

Securing Client Configuration

The Configuration Manager Administration Kit (CMAK) allows an administrator to create a dial-up connection that works with Microsoft Windows 95, Microsoft Windows 98, Windows NT 4.0, and Windows 2000.

CMAK allows control of the security settings of remote access connections by

Enforcing the settings the organization requires Restricting access to key configuration screens for remote

access connection objects CMAK reduces administrative overhead by deploying

preset security configuration. CMAK is included with Microsoft Windows 2000 Server.

CMAK Advantages over User-Defined Dial-Up Network Connection Objects

Defines a highly secure connection object Defines a package that launches a dial-up and

VPN connection Creates a package that can be deployed to

most Microsoft Windows operating systems. Removes saved password vulnerabilities Deploys preset security configurations Uses a standard phone book

Making the Decision: Designing CMAK Packages to Secure Remote Access

Provide local access numbers. Simplify the dial-up process when VPNs are

deployed. Prevent the modification of security

configuration parameters set in a dial-up connection.

Prevent remote access connections by unauthorized personnel.

Meet multiple dial-up configuration requirements.

Applying the Decision: Designing CMAK Packages to Secure Remote Access for Hanson Brothers CMAK package for dial-up clients

Configure the phone book to provide local access numbers for the Calgary, Boise, and Warroad offices.

Configure the dial-up connections to use only MS-CHAPv2 to ensure mutual authentication of remote access client and remote access server.

Configure the dial-up connections to require the strongest encryption settings.

Restrict access to the Security tab to prevent users from modifying data encryption or authentication settings.

Applying the Decision: Designing CMAK Packages to Secure Remote Access for Hanson Brothers (Cont.) CMAK package for VPN clients

Configure the phone book to provide host names for the remote access servers at the Calgary, Boise, and Warroad offices, or configure separate CMAK packages for each office.

Configure the VPN connections to only use MS-CHAPv2 to ensure mutual authentication of remote access client and remote access server.

Configure the VPN connections to require the strongest encryption settings.

Configure the VPN connection to use only PPTP. Deploy computer certificates to all remote access client

computers before implementing L2TP/IPSec connections. Prevent access to the Security tab so users cannot modify

data encryption or authentication settings.

Designing Remote Access Security for Networks

Choosing remote office connectivity solutions Securing dedicated WAN connections Designing VPN solutions

Private WAN Links

VPN Over a Public Network

Making the Decision: Choosing a Remote Office Connectivity Solution

Reasons to choose a dedicated WAN Link Restricts network traffic over the WAN link

exclusively to traffic between the two offices Guarantees bandwidth between the two sites Cost of a dedicated link is not prohibitive International boundaries or local laws do not prevent

the establishment of a dedicated network link

Making the Decision: Choosing a Remote Office Connectivity Solution (Cont.)

Reasons to choose a VPN over a public network

Leverages existing Internet links to provide network connectivity between sites

Provides connectivity between hardware from different network vendors over public networks

Reduces the costs associated with connecting offices across international boundaries

Applying the Decision: Remote Office Connectivity Solution for Hanson Brothers

Hanson Brothers plans to implement a VPN solution to reduce the high cost associated with a dedicated WAN link between Canada and the United States.

All data exchanged between the Montreal office and the Warroad office must be encrypted as it is transmitted over the Internet.

Securing Dedicated WAN Connections

Ensuring security of transmitted data over a WAN link

Limit the types of data that can be transmitted. Limit which computers can transmit data over the

WAN link. Encrypt all traffic that is transmitted over the WAN

link. Require mutual authentication of routers.

Making the Decision: Designing Security for Dedicated WAN Links

Limit which protocols can traverse the network link.

Limit which computers can transmit data over the WAN link.

Ensure that confidential data cannot be inspected as it is transmitted.

Limit which routers can connect to another router.

Applying the Decision: Designing Security for Dedicated WAN Links for Hanson Brothers A VPN solution will be used for connecting the

Montreal office to the corporate network in Warroad.

Because a third-party firewall will be used at the Montreal office, design decisions for dedicated network connections should be applied at the firewall.

Configure the firewall to accept connections only from the remote access server at the Warroad office.

This ensures that no other routers, remote access servers, or firewalls can establish connections to the firewall.

Designing VPN Solutions

VPNs allow an organization to leverage existing network links to a public network and use those links to connect remote offices.

VPNs ensure that data is protected during transmission over the public network.

VPN solutions between offices can use PPTP, L2TP/IPSec, and IPSec tunneling mode.

Choosing the best solution depends on The remote access devices deployed at each office The availability of a Public Key Infrastructure (PKI) The placement of remote access devices

VPN Deployment in a DMZ Using Private Network Addressing

VPN Deployment in a DMZ Not Using Private Network Addressing

Tunnel Server Performing NAT

Making the Decision: Determining When to Deploy Tunneling Protocols

Deploy PPTP when Either tunnel server is located in a network segment

where NAT is performed Creating VPNs with Windows NT 4.0 RAS servers Only user authentication is required for the VPN

connection Deploy L2TP/IPSec when

Stronger encryption is required for the connection between sites

Authentication of both a user account and machine account is required

The tunnel servers are not located behind a firewall or perimeter server that performs NAT

Making the Decision: Determining When to Deploy Tunneling Protocols (Cont.)

Deploy IPSec tunnel mode when The tunnel servers are not located behind a firewall

or perimeter server that performs NAT Connecting to a third-party firewall or firewall that

does not support PPTP or L2TP/IPSec Machine authentication is required only between the

two tunnel endpoints

Applying the Decision: Tunneling Protocol Choices for Hanson Brothers

Designing Remote Access Policy

Designing remote access policy condition attributes

Designing remote access policy profiles Planning remote access policy application

Designing Remote Access Policy Condition Attributes

Define remote access policies to grant or deny remote access.

The remote access server evaluates the existing conditions of the remote access request and compares it to the conditions defined in the remote access policy.

If all conditions are matched, the remote access policy is applied to the request.

Condition Attributes

Called-Station-ID Calling-Station-ID Client-Friendly-Name Client-IP Address Client-Vendor Day-And-Time-

Restrictions Framed Protocol

NAS-Identifier NAS-IP-Address NAS-Port-Type Service-Type Tunnel-Type Windows-Groups

Making the Decision: Designing Conditions for Remote Access Policy

Minimize conditions in the remote access policy definition.

Remote access policies are processed from the top of the list to the bottom.

Remote access policies can be defined to both allow and deny remote access to the network.

If no remote access policies exist, all remote access is denied.

Do not define a remote access policy condition that cannot be met.

Applying the Decision: Designing Conditions for Remote Access Policy at Hanson Brothers Design remote access policies for

Employees Administrators Adventure Works Montreal office VPN

Designing Remote Access Policy Profiles

The profile defines the security settings that the remote access connection must implement.

These security settings can include the authentication method and the encryption level required to proceed with the connection.

Remote Access Policy Profile Settings

Dial-In Constraints IP Multilink Authentication Encryption Advanced

Making the Decision: Restricting Remote Access Connections

Prevent idle remote access connections from using up the available remote access ports.

Restrict remote access connections to a specific phone number.

Restrict a remote access connection to a single computer or to specific computers.

Restrict a remote access connection to specific protocols.

Require a specific authentication mechanism. Require a specific level of encryption.

Applying the Decision: Configuring Remote Access Profiles for Hanson Brothers Employees Administrators Adventure Works Montreal office VPN

Remote Access Policy Application in Mixed Mode

The Control Access Through Remote Access Policy option is not available in a user’s account properties.

By default, every user account is set to Allow Access, but remote access policy is still applied.

The default remote access policy grants access to all users if left unmodified.

When a connection attempt occurs, the remote access policy evaluates the remote access policy profile to determine whether to allow the connection.

Remote Access Policy Application in Native Mode

User accounts are configured to Control Access Through Remote Access Policy in the user account property pages.

With this setting, all remote access permissions are determined through Remote Access Policy settings.

Making the Decision: Planning for Remote Access to the Network

In mixed mode, delete or modify the default remote access policy.

Disallow dial-in permissions for all users in a mixed mode domain.

Prevent specific connection attempts in a native mode domain.

In either mixed mode or native mode, remote access policy is evaluated to determine whether remote access should be granted to the network.

Prevent all remote access to the network in mixed mode or native mode.

Applying the Decision: Implementing Remote Access Policy for Hanson Brothers

Ensure that the domain is in native mode to take advantage of remote access policy for dial-up access determination.

Verify that each user account that requires dial-up access to the network is set to Control Access Through Remote Access Policy.

All other accounts should be set to Deny Access.

Planning RADIUS Security

Introducing RADIUS authentication Designing RADIUS deployment Planning centralized application of Remote

Access Policy

Introducing RADIUS Authentication

RADIUS allows single sign-on capabilities to remote users by allowing them to authenticate with the domain account and password.

Single sign-on allows access to all resources on a network with a single user account and password.

This single user account and password can be used at any remote access server or network device that is configured as a RADIUS client to the IAS server.

Designing RADIUS Deployment

RADIUS Authentication Process for a VPN Client

Making the Decision: Planning RADIUS Components

RADIUS servers RADIUS clients RADIUS proxies

Applying the Decision: Centralized Management of Authentication at Hanson Brothers Configure remote access servers at the

Warroad, Boise, and Calgary offices as RADIUS clients to a RADIUS server at the Warroad office.

The RADIUS server allows all users to authenticate by using their domain account and password.

The RADIUS server allows centralized management of remote access policy and centralized collection of accounting information for all remote access connectivity.

Decentralized Application of Remote Access Policy

Results in inconsistent configurations at each remote access server.

Inconsistent application of remote access policy can result in authorized users being denied access and unauthorized users gaining access to the network.

Centralization of Remote Access Policy

RADIUS servers allow the centralization of remote access policy.

When configured as RADIUS clients, remote access servers no longer configure remote access policy locally.

Remote access policy is obtained instead from the RADIUS server, which acts as the repository for Remote Access Policy.

Remote users gain access to the network no matter which remote access server they access.

All remote access servers have the same remote access policy, which is stored locally at the RADIUS server.

Servers Running RRAS Configured as a RADIUS Client

These servers receive their remote access policy from the RADIUS server.

Remote access policy does not appear in the Routing And Remote Access console.

Configuration requirements: Prevent the deployment of new remote access

servers that are not configured as RADIUS clients. Use Group Policy to either enable or disable RRAS for

Windows 2000–based computers. Change the permissions for the service to restrict

who can start, stop, or pause the service.

Ensure That Approved Remote Access Servers are Running RRAS

Place the remote access servers in a dedicated organizational unit (OU).

Create a Group Policy object that enables RRAS.

Configure the Default Domain Policy to disable RRAS.

Group Policy inheritance applies the service setting to all other OUs in the domain.

Making the Decision: Ensuring Centralized Application of Remote Access Policy

Ensure that a server on the network is configured with the IAS service.

Configure all authorized remote access servers as RADIUS clients.

Ensure that RRAS is disabled on all unauthorized remote access servers.

Applying the Decision: Centralized Remote Access Policies at Hanson Brothers Requires centralized management of remote

access policies from the Warroad office. Configure the Default Domain Group Policy to

disable RRAS on all domain computers. Place the remote access servers for each office

in an OU where Group Policy enables RRAS. The remote access servers must be configured

as RADIUS clients to the RADIUS server located at the Warroad office.

Chapter Summary

Choosing between dial-up and VPN solutions Planning remote access authentication Planning dial-up protocols Planning VPN protocols Planning integration with Windows NT 4.0 RAS

servers Planning user settings for dial-up networking

security Authorizing dial-up connections Securing client configuration

Chapter Summary (Cont.)

Choosing remote office connectivity solutions Securing dedicated WAN connections Designing VPN solutions Designing remote access policy condition

attributes Designing remote access policy profiles Planning remote access policy application Introducing RADIUS authentication Designing RADIUS deployments Planning centralized application of remote

access policy