Today many companies are enjoying the cost savings inherent in allowing some employees to work from home, while those employees benefit from the convenience of telecommuting. In addition, executives, salespeople and others need to connect to the company network when they go on the road, and/or need to access network resources in the evenings or on the weekends from home.
All this adds up to a lot of remote access connections to the organization’s network. These connections may be made over the phone lines by directly dialing into a remote access server on the network, or they may be made by virtual private networking (VPN), using the Internet to “tunnel” into the corporate network. Either way, security is always an issue when you have people connecting to the network from the outside, because you have less control over offsite computers.
There are a number of things you can do, however, to make remote access connections more secure. In this article, we will discuss how to prevent remote connections from creating a security nightmare on your network.
Assessing Remote Connectivity Needs
Your first step in providing for secure remote access is to carefully evaluate employees’ need to connect remotely, and grant access on a per-user basis only to those who have a bona fide need to access the network remotely. Always keep in mind that unless restrictions are put in place, a user connecting to the LAN via remote access can do everything that he/she could do from an onsite computer.
In a Windows 2000 domain, you can set user properties to allow or deny remote access, or control access through remote access policies (which we’ll discuss in more detail later). To set user properties to allow dial-in or VPN access, configure the properties sheet for each user account, on the Dial-in tab (accessed from the Active Directory Users and Computers MMC), as shown in Figure A.
Figure A: Setting remote access permissions in user properties
You can also provide better security for users who work from home or another static location by implementing caller ID verification or setting callback security. To use the former, check the Verify Caller ID box and specify a phone number from which the user must dial in. To use the latter, check the Always Callback to option button and enter the phone number from which the remote user will connect. The server will hang up and call the user back at that number. Either way, if an unauthorized user manages to discover a legitimate user’s password, he/she still won’t be able to access the network remotely unless doing so from the legitimate user’s location.
Although the two features accomplish the same security objectives, there are a couple of situations in which you would use Callback instead of Caller ID verification: 1) when the caller’s or server’s phone systems don’t support Caller ID and 2) when the remote user is dialing in from a long distance location and you want the server to call back so the company will pay the telephone charges for the session.
After assessing who needs remote access, determine whether you will allow remote users to dial in, connect via VPN, or both. A dialup connection has the security advantage of being a direct connection between the user and the dialup server, so no information is going across the public Internet. VPNs use encryption to protect the confidentiality of information that travels through the public network and provide the “private” aspect. The policies you set in implementing your dialup server or VPN server will determine, to a large extent, the level of security.
For VPN connections, you’ll want to consider the protocols your VPN server will support. L2TP tunneling with IPSec encryption is more secure than PPTP (which uses MPPE for encryption); however, not all clients can use L2TP. If all your remote access clients use Windows 2000 or XP (as they should, for best security), your policies can specify L2TP VPN connections only. If you have Windows 9x clients, you may have to allow PPTP connections.
Authentication Considerations
One of your most important security considerations is how remote clients will be authenticated. Authentication, of course, involves verifying the identity of the client computer or user. Remote access authentication protocols are not all created equal.
Windows supports a variety of remote access authentication protocols, ranging from PAP (password authentication protocol), which transmits passwords in plain text and is not secure, to sophisticated authentication methods such as EAP-RADIUS, which relies on a separate authentication server, or EAP-TLS, requiring that the user provide a smart card with a digital certificate.
PAP is disabled by default on the Windows 2000 remote access server, and for best security, you should use only strong authentication. If you use MS-CHAP, use version 2, and set password length and complexity policies to force the use of strong passwords.
Windows 2000/2003 also supports use of security hosts for remote access. This is a device that sits between the remote access client and the remote access server, and provides supplemental authentication (in addition to that of the RAS server). You may have to edit the modem.inf file on the server to link the security host to the server’s modem.
Windows Remote Access Security Policies
Unlike NT, which used only the remote access permissions in the user properties to control access, Windows 2000 and 2003 take both the user properties and remote access policies into account. The policies allow you granular control. You can grant remote access only during certain times of the day, or certain days of the week. You can grant VPN access but deny dial-in (or vice versa). You can limit the duration of each remote access session, allow connections only with specified authentication methods, and so forth.
Remote access policies can be set on the remote access server, or the policies for multiple dial-in and VPN servers can be managed through an IAS (Internet Authentication Service) server. To set policies on the remote access server, you use the RRAS MMC (accessed from Administrative Tools), as shown in Figure B.
Figure B: Creating new remote access policies using the RRAS console
Using Encryption to Secure Dialup Remote Access Connections
The security of remote access connections can be increased by encrypting the data that flows across the phone lines. There are a couple of ways to accomplish this with Windows:
- Use Microsoft Point to Point Encryption (MPPE) with MS-CHAP or EAP-TLS authentication. This is called link encryption, because the data is encrypted only between the routers (gateways) connecting the two networks.
- Use IPSec to encrypt the data all the way from the sending computer to the destination computer. This is called end-to-end encryption.
To encrypt the data and configure the encryption settings, select the remote access policy in the RRAS console tree, right click it and select Properties. In the properties box, click the Edit Profile button at the bottom, as shown in Figure C.
Figure C: Edit the remote access policy profile to enable data encryption
In the Edit Profile dialog box, click the Encryption tab and check the encryption levels to be allowed by the profile, as shown in Figure D.
Figure D: Encryption levels are set via the Encryption tab when editing the Dial-in profile
By clearing the No Encryption checkbox, you can require that connections be encrypted.
You can also set the allowed authentication methods for the policy by clicking the Authentication tab. This is where you can configure the policy to allow only smart card or certificate-based authentication, for example. At a minimum, you should ensure that the checkboxes labeled Unencrypted Authentication (PAP, SPAP) and Unauthenticated Access are unchecked, as shown in Figure E.
Figure E: Set the allowed authentication methods to disallow unencrypted authentication and unauthenticated access
Restrictions on dial-in connections can be set by clicking the Dial-in Constraints tab. Here you can set idle time limitations, limit the maximum session time, or define the days and times when remote access is allowed, as shown in Figure F.
Figure F: You can set a variety of constraints on Dial-in connections
You can also restrict dial-in connections to a particular phone number and/or restrict the dial-in media type (for instance, to ISDN, modem, or VPN).
Summary
Windows 2000 and 2003 servers include the ability to function as dial-in or VPN servers. Allowing remote access can benefit both your organization and your employees, giving workers the flexibility to access the network from home or when on the road. However, this poses special security risks. Windows provides a number of ways to secure your remote access connections, but you will need to be familiar with RAS security configuration in order to put them into practice. In this article, we’ve provided an overview of some of the security considerations you’ll encounter when you set up a Windows remote access server.
If you would like us to email you when Deb Shinder releases another article on WindowSecurity.com, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!
DEBRA LITTLEJOHN SHINDER, MCSE, is a technology consultant, trainer and writer who has authored a number of books on networking, including Scene of the Cybercrime: Computer Forensics Handbook, published by Syngress, and Computer Networking Essentials, published by Cisco Press. She is co-author, with her husband, Dr. Thomas Shinder, of Troubleshooting Windows 2000 TCP/IP, the best-selling Configuring ISA Server 2000, and ISA Server and Beyond. Deb is also a tech editor and contributor to books on subjects such as the CompTIA Security+ exam and TruSecure’s ICSA certification. She edits the Brainbuzz A+ Hardware News and Sunbelt Software’s WinXP News and is regularly published in TechRepublic’s TechProGuild. Deb currently specializes in security issues and Microsoft products. She lives and works in the Dallas-Ft Worth area and can be contacted at [email protected] or via the website at www.shinder.net.
