Windows

Demand Dial Routing for Windows 2000, part 2: Security

Demand Dial Routing is a great temporary fix for primary connection failures, but it can leave you with some security problems. In this Daily Drill Down, Brien Posey discusses these problems and some of the methods Win2K uses to counter them.

In part one of this series, I discussed Demand Dial Routing, the method by which a server can automatically initiate a temporary dial-up route to another server when the primary connection becomes unavailable for some reason. Of course, having a server on standby waiting for someone to dial-in opens up all kinds of security holes. In this article, I’ll explain the security problems caused by Demand Dial Routing. I’ll also discuss the methods Windows 2000 uses to counter potential problems.

Implementing Demand Dial Routing
As with many other Windows 2000 features, Demand Dial Routing’s security is best implemented during the initial setup. I’ll walk you through the complete setup process, and I’ll discuss the security issues along the way.

To enable Demand Dial Routing, open the server’s Routing And Remote Access console. To do this, click the Start button and select Programs | Administrative Tools | Routing And Remote Access. Before you can continue, the Routing And Remote Access services must be installed and running. If your server is already configured as a router or as an RRAS server, this should already be done. If the service isn’t installed, you can install it by expanding the console’s tree and right-clicking the server onto which you want to install the service. When you see the server’s context menu, select the Configure And Enable Routing And Remote Access command, and follow the prompts. Since I’m about to walk you through the process, don’t install Demand Dial Routing at this time.

Once the Routing And Remote Access Service is running, right-click the server for which you want to enable Demand Dial Routing, and select the Properties command from the resulting context menu. When you do, you’ll see the server’s properties sheet. Now, navigate to the properties sheet’s General tab and make sure the Router check box is selected. After doing so, select the LAN And Demand Dial Routing radio button, and click OK to return to the main console screen. At this point, you’ll see a message that indicates the router must be restarted. Windows 2000 can restart the router without having to reboot the computer.

Once the router has restarted, you’ll need to set up the calling router. Begin by right-clicking the Routing Interfaces object in the console tree and selecting the New Demand Dial Interface command from the resulting context menu. Then, Windows 2000 will launch the Demand Dial Interface Wizard. Click Next to begin the wizard.

The wizard’s first screen asks for an interface name. The interface name is a name Windows will use to identify the route. It’s a common practice to name the interface after the routes it connects. For example, you might call it Dial-Up Route From Server A To Server B. Once you’ve entered an interface name, click Next to continue.

The next screen you’ll see asks for the type of Demand Dial interface you want to create. For the purposes of this article, and since the majority of Demand Dial implementations seem to be dial-up, I’ll use a modem. So, select the Connect Using A Modem, ISDN Adapter, Or Other Physical Device radio button and click Next to continue.

At this point, you’ll see a screen that asks which device you want to use to make the connection. For example, on my system the choices are Direct Parallel (LPT1) or Standard 56000 bps X2 Modem (COM2). Select the device you plan to use for your Direct Dial Routing connection and click Next to continue.

Now, you’ll see a screen that allows you to enter the phone number of the answering router. You can also use the Alternates button to enter additional phone numbers to try should the first number fail. When you’ve entered the necessary phone number or numbers, click Next.

You’ll now see a screen that gives you some choices as to how the router should behave. First, you can select whether you want to route IP packets, IPX packets, or both across the interface. Unless you have a compelling reason to route IPX packets, I recommend routing only IP packets. The fewer protocols you use, the less chance there is of having a security breach through the use of some obscure feature on an unused protocol.

This screen contains several other options. Most of these options pertain to the answering router. However, there’s an option for using a plain text password. Since you’re connecting two Windows 2000 machines together, there shouldn’t be a need to send a plain text password. Sending a plain text password is insecure and anyone with a protocol analyzer can easily intercept it as it flows down the line. The option for plain text passwords is more appropriate for situations in which you’re dialing into a foreign type of server (such as a RADIUS server) for authentication.

Click Next to continue. Now, you’ll see a screen that allows you to enter your dial-out credentials. You must enter a username, password, and domain name that is valid on the network to which you’ll be dialing. Once you’ve entered this information, click Next. On the following screen, you’ll see a summary of what you’ve done and a Finish button. Click Finish to complete the process.

As you might have guessed, the process I’ve just explained can be applied to either one router or to two routers, depending on whether you’re using a one-way or a two-way connection. Setting up the answering router works a bit differently than setting up the calling router, however.

I mentioned your system should be set up for RRAS before starting. An RRAS server is essentially an answering router. There’s little more to setting up an answering router than setting up any other type of RRAS session. When it comes to setting up an answering router, the most important thing you can do is to implement good security. The first step toward good security is to implement logging so you know what’s going on. To implement logging, navigate through the Routing And Remote Access console tree to your server | Remote Access Logging. Select Remote Access Logging and then double-click the file name specified in the column on the right. Doing this will display the log file’s properties sheet. As you can see in Figure A, there are three different options you can log. I recommend logging accounting requests and authentication requests, as shown.

Figure A
You should log accounting and authentication requests.


You’ll also notice the log file’s properties sheet contains a Local File tab. This tab allows you to set such attributes as the maximum log file size, the log file’s format, and the directory that should contain the log file.

As important as it is to set up a log file, it’s just as important to establish some basic safeguards. To do so, right-click on Remote Access Policies in the Routing And Remote Access console tree and select the New Remote Access Policy command from the resulting context menu. Then, you’ll be prompted to provide a name for the new policy.

After providing this name, you’ll be taken to a blank screen containing a window that allows you to add conditions to the newly created policy. Click the Add button to begin adding these conditions. As you can see in Figure B, there are quite a few conditions you can set. Some of these conditions are helpful in most situations, while others only pertain to specific types of network configurations.

Figure B
You can assign many different conditions to your newly created policy.


After clicking on the Add button, you can set the individual attributes by double-clicking on them. Then, you’ll be asked to provide some piece of information about the particular attribute. For example, if you double-click on Calling Station ID, you’ll be asked to provide the name displayed on a caller ID box when the calling router makes a call. After you enter this information, click OK, and you’ll see the condition Calling Station ID Matches added to the list of conditions.

Setting the caller ID information of the stations that are allowed to call is a great way to prevent unauthorized access from PCs other than the designated server. However, there are also some other good precautions you can take by using items from the list. For example, if your business doesn’t have employees working 24 hours a day, you could block nighttime access to prevent someone from sneaking in during the middle of the night and hacking your system.

Another precaution you can and should take is to use the Framed Protocol option to limit which protocols can be used for dial-in access. As I mentioned, the fewer protocols you permit, the more secure your network will be.

Perhaps one of the most innovative security options falls under the Service Type option. Under this option, you can limit access based on what type of service the client is trying to gain. For example, you could use this option to restrict access to users who are requesting administrative service.

Finally, you can use the Windows Groups option to limit access to accounts that are members of certain groups within the Windows security structure. For example, you could create a group called Service Accounts and make the account the calling router uses for authentication a member of the group. By restricting access to anyone who isn’t a member of the Service Accounts group, you can make sure no one except for the account you’ve chosen can access the server through the dial-in port.

Conclusion
In this article, I’ve discussed some security issues you’ll face if you implement Demand Dial Routing. I walked you through the Demand Dial Routing implementation process and explained some methods Windows 2000 implements to safeguard your network against those potential threats.
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.
0 comments

Editor's Picks