In the Daily Drill Down entitled “Dial-up networking security in Windows NT,” I discussed some of the basic RAS server security settings. As I showed in that article, there really aren’t a lot of security settings that are specific to RAS. That doesn’t mean, however, that this is where RAS security ends. There are actually a number of ways to enhance RAS security. In this article, I’ll discuss some of those methods.
When designing an RAS Security system, it’s important to remember that RAS offers an open door to your system. Your goal must therefore be to set up your security system in such a way that it allows legitimate users to remotely access the necessary network resources, while keeping out all others. This is a pretty tall requirement for a service that’s protected by little more than a password in many situations.
Fortunately, even though RAS itself doesn’t offer many security features, there are a lot of other ways that you can enhance RAS security. Often the methods that I use offer the added benefit of simultaneously enhancing the security on your local network, as well as on your RAS ports.
Limit RAS access
One of the best ways that you can protect your network from dial-in users is to limit who has dial-in access. There are several ways to do this. One technique you can use is to hook up your RAS modems to a phone line that has an unlisted number. This number should be distributed only to the people who have a legitimate business requirement for RAS access. One company I used to work for required remote users to sign a confidentiality agreement before they were provided with the phone number. In this organization, the RAS phone numbers were as closely guarded a secret as passwords.
The next step in limiting RAS access is to control who is granted dial-in permissions. You can easily grant and revoke dial-in access to individual users by going into User Manager For Domains and double-clicking on a user. When you see the user’s properties sheet, click the Dialin button. When you do, you’ll see the Dialin Information dialog box, which allows you to enable or disable dial-in permissions for the user by simply selecting a check box.
I recommend using a variation of this technique instead. If you assign dial-in permissions to individual users, it’s easy to lose track of who does and doesn’t have dial-in permissions, especially in large organizations. Unfortunately, Windows NT doesn’t allow you to set dial-in permissions on a group basis. You can, however, use groups to help you keep track of who has dial-in permissions. I suggest creating a global group whose sole purpose is to help you keep track of dial-in permissions. Although you can’t assign dial-in permissions directly to this group, you can use the group to contain a list of users with dial-in permissions. By doing so, there will never be a question about who has dial-in permissions. A simple glance at the group’s membership list will tell you who has the ability to dial in to the network.
Other types of precautions you can take will depend on the needs of your users. For example, if your users don’t require 24-hour access to the network, you could limit remote users to logging in during certain hours and forcibly disconnect remote users who are still logged in when time runs out. Again, there are no RAS-specific settings for these options, but the settings that are found in User Manager For Domains apply to normal network logins as well as RAS logins.
Don’t hard code phone numbers
One of the biggest threats to RAS security is notebook computer theft. I’ve seen countless administrators hard code RAS phone numbers and passwords into a user’s notebook. Doing this is a bad idea, because if a notebook were to be stolen, the thief could very easily access your RAS server using the information that was preset in the machine.
Isolate your RAS server
One of the most effective security techniques that you can use is to isolate your RAS server from the rest of the network. You can isolate the server physically or through protocol manipulation. For example, suppose that you wanted your dial-in users to be able to only access resources that are found on the RAS server. If this were the case, you could set up RAS to use a protocol that’s different from the rest of your network. If the rest of your network uses TCP/IP, you might load the IPX / SPX or NetBEUI protocol on the RAS server. Of course, you’d also want to load TCP/IP on the RAS server so you can access the server locally (for administrative purposes), but you’d configure the RAS portion to only accept the alternate protocol you’ve chosen. For an added measure of protection, you could set up your RAS server to allow users who use the alternate protocol to access only the RAS server.
To control the protocol that remote users are allowed to dial in with, open the Control Panel on the server and double-click on the Network icon. When you do, you’ll see the Network Properties sheet. When the Network Properties sheet appears, select the Services tab. On the Services tab, select the Remote Access Service and click the Properties button. Finally, click the Network button on the resulting dialog box and you’ll see the Network Configuration dialog box (as shown in Figure A).
|The Network Configuration dialog box allows you to control which protocols that RAS will accept.|
As you can see in the figure, the Network Configuration dialog box allows you to control which protocols you’ll allow for dial-in and dial-out sessions. When you enable a protocol, you’ll see a dialog box similar to the one that’s shown in Figure A. This dialog box asks if you want to limit remote users to using only the RAS server or if you want them to be able to access the entire network.
Building a system policy
Another technique that you can use to help control RAS security is to create a system policy that controls some of the RAS settings. There are settings available through the system policies that you can’t control anywhere else except for the registry. Unfortunately, space limitations prevent me from going into detail about using the System Policy Editor. However, I will show you the RAS settings that you can control through the System Policy Editor.
Before you begin creating or manipulating system policies, I strongly recommend reading up on the system policy editor. That’s because by editing the system policies, you’re making changes to the registry that affect the user’s capabilities. It’s easy to accidentally lock down the Administrator account. Therefore, make sure that you have a thorough understanding of system policies and the system policy editor before enabling any of the settings that I’ll cover in this section. For more information about the System Policy Editor, see the Daily Drill Down titled “Using the System Policy Editor”.
When you open a policy or the registry in the System Policy Editor, you’ll see a tree-type structure that divides the policies into various categories. If you expand the Windows NT Remote Access section, you’ll see four settings that can be applied to the RAS server. Each of these options can be enabled or disabled by selecting the check box beside it.
As you select each option, there are parameters that appear below the list, which you can set. For example, in Figure B you can see the Max Number Of Unsuccessful Authentication Retries selected. If you look at the bottom of the dialog box, you’ll see that by default, this value is set to two. You can also set the Max Time Limit For Authentication, Wait Interval For Callback, and the Time Period For Auto Disconnect.
|You can control which protocols are valid for RAS sessions.|
Keep track of RAS use
So far, I’ve discussed security techniques that limit what dial-in users are allowed to access. Limitation, however, is only half of the battle. After all, security is a proactive process. You don’t want to set up a security system and then just turn your back on it. Instead, it’s a good idea to check up on things once in a while. There are a couple of tools available for doing this.
First, you can occasionally spot check the RAS usage by looking at the Remote Access Admin tool. This tool allows you to see which servers have active remote access sessions and which ports are in use. You can also use the tool to start and stop the remote access services on the server. Finally, you can look at which users have active sessions and the permissions that were assigned to those users.
Another valuable tool is the Security Log, which can be seen through the Event Viewer. You can configure Windows NT to audit various security-related events and make a record of those events in the security log. Although this article isn’t intended to be a comprehensive discussion of auditing, I do recommend that if you’re running a RAS server that you audit login failures. When you review your security logs, check for multiple failed access attempts in the middle of the night. Such activity often points to a hack attempt.
In this article, I explained that although there are a limited number of RAS-specific security settings, there are many other ways to enhance RAS security. As I did, I explained some of these methods in detail.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.