The main goal of networking is the sharing of information and resources. However, sharing is usually done on a limited basis. One of the most challenging aspects of designing network security is balancing how easy it is for an authorized user to gain access to a resource versus how difficult it is for an unauthorized person to do the same.
The protocols and services that are designed to legitimately provide identification and communication can be manipulated to provide unauthorized access to the network. The best way to begin securing your network is to divide it into manageable sections and then document each area that is potentially vulnerable. After you have a good idea of the number and potential severity of risks, you can begin the process of securing the network.
The documentation is also useful after a successful attack. You’ll immediately know the other areas where you’ll be susceptible to the same vulnerability. Thorough documentation allows network administrators to learn from past mistakes and to explain to management exactly what went wrong. If you know what happened and why, you’re more likely to keep your job after a security disaster. This section will concentrate on the networking services that are likely to be present in a Windows 2000 environment.
The traditional Domain Name Service (DNS) that is commonly used on the Internet has been modified for use with Windows 2000. Normally, DNS zone files are manually updated text files that contain a lookup table of a resource’s fully qualified domain name (FQDN) and its Internet Protocol (IP) address. In Windows 2000, these DNS files can be dynamically updated. As is usually the case, this added functionality also adds a security risk.
Most of the modifications to the Windows 2000 version of DNS are to allow it to integrate with Active Directory. Following is a summary of the major changes that are included with Windows 2000 DNS:
- Service (SRV) records
Windows 2000 domain controllers often run many services that other computers need, such as DHCP. SRV records allow Windows services to be registered in the DNS zone file, so client computers can find services located on other machines via DNS.
- Dynamic Host Configuration Protocol (DHCP)
A DHCP server can automatically assign a network identification configuration to a client computer. This process can now be used in conjunction with Dynamic DNS (DDNS) to also automatically update a DNS zone file to include the newly configured client computer’s settings.
- Dynamic DNS (DDNS)
Dynamic DNS is the process of automatically updating zone files.
DNS can be used to look up the IP address for a given FQDN or find an FQDN based on a given IP address. The process of finding an IP address for a given FQDN is called a forward lookup and uses a DNS A record (host record). The process of finding an FQDN given an IP address is called a reverse lookup and uses a DNS pointer (PTR) record.
Not all threats to the security and functionality of your network are from malicious attacks. Sometimes a simple configuration error can have a domino effect throughout your network. It’s difficult enough to find and fix changes that people make to the network. When computers configure themselves and don’t keep track of what they’ve done, there is potential for mass confusion.
It’s too expensive and time consuming for a network administrator to make every single change manually. Usually, software can be written to perform mundane configuration tasks, such as the assignment and tracking of IP addresses. You can maximize the benefits of automation and minimize its risks with careful planning. To be able to plan for Dynamic DNS, you should know the information contained in Table 33-4.
Table 33-4. DHCP and Dynamic DNS
|
Client OS |
With DHCP |
Without DHCP |
|---|---|---|
|
Windows 9x |
DHCP server updates both the A and PTR records. |
No dynamic updating is available. |
|
Windows NT |
DHCP server updates both the A and PTR records. |
No dynamic updating is available. |
|
Windows 2000 |
Client updates A record only, DHCP server updates PTR record. |
Client updates both the A and PTR records. |
The default behavior is that the DHCP server updates both the A and the PTR records for all Windows client computers, except for Windows 2000. Security and documentation are easier to maintain if you can be sure that all DNS updates came from the DHCP server. You can prevent Windows 2000 clients from updating their A records and offload that responsibility to the DHCP server by performing the following steps:
Right-click on My Network Places and choose Properties.
Right-click on the local-area connection you wish to configure and choose Properties.
Choose TCP/IP and click Properties.
Click the Advanced button and choose the DNS tab, shown in Figure 33-2.
Uncheck Register this connection’s addresses in DNS.
Click OK.
You may be surprised to know that the default behavior of Windows 2000 is to allow computers to change existing IP/FQDN mappings without question. This means that if my computer were configured to have the FQDN of mcse.oreilly.com and the IP address of 10.10.1.1 and mcse.oreilly.com was already assigned to the IP address of 10.10.1.7, my computer would overwrite the previous IP address and assume its identity. Luckily, you can disable this behavior in the registry by doing the following:
Now that you’ve narrowed legitimate DNS changes to the DHCP server, you have another serious security issue to deal with: Windows 2000 doesn’t automatically prevent unauthorized DHCP servers from assigning configurations and updating DNS. It’s fairly easy to prevent other Windows-based DHCP servers from running on your network, but it’s much more difficult to prevent non-Windows based DHCP attacks. An unauthorized DHCP server is called a rogue DHCP server . Here’s how to prevent unauthorized Windows-based DHCP servers from operating on your network:
Open the DHCP Microsoft Management Console (MMC) snap-in by selecting DHCP from the Administrative Tools menu.
Right-click DHCP and choose Manage Authorized Servers. A list of authorized servers is displayed, as shown in Figure 33-3.
Click Authorize and fill in the name and IP address of the authorized DHCP server. Click OK to save the entry.
Although DNS might already seem to be rife with security holes, there are at least two more areas you’ll want to secure. Earlier, I discussed how to prevent Windows 2000 clients from modifying their A record. Now, you’ll find out another reason that I like to prevent client A record modification.
DHCP servers will only remove records they modified when the DHCP lease expires. This means they’ll delete the PTR record, but leave the orphaned A record. If a Windows 2000 client created the A record, it stays in the DNS table, even though it has expired. If you still want to let Windows 2000 clients register their own A records, be sure to configure DHCP to remove expired A records that it didn’t create. You can do this by performing the following steps:
Open the Microsoft Management Console (MMC).
Under the DHCP server section, right-click on Scope and choose Properties.
Under the DNS tab, choose Discard Forward Lookups When Leases Expire.
If Dynamic DNS seems like its more trouble than its worth, you can disable its use altogether. This can be done on a zone-by-zone basis. To disable Dynamic DNS for a particular zone, use the following steps:
Open the Microsoft Management Console (MMC).
Under the DNS section, right-click on the proper zone and choose Properties.
Under General, you’ll see a pull-down box to the right of Allow Dynamic Updates ? ; choose No.
Windows 2000 Professional Edition can be installed and restored on remote client computers automatically, using Remote Installation Services (RIS). This is a great time-saver if you have to create or maintain a large number of Windows 2000 Professional clients. You can create a pre-configured disk image of the Windows 2000 operating system, its settings, and additional software and use RIS to copy the files to the client and register its computer account in Active Directory.
Just as with Dynamic DNS, the added convenience also adds some potential security holes. Before you can create an RIS environment, a few other services have to be present and running, along with the client hardware requirements. Following is a list of the requirements for an RIS environment (all these devices must be members of the same Active Directory domain):
Because RIS can automatically install and configure a large number of client computers, it’s a good idea to have RIS name these clients in a systematic and understandable fashion. If your network spans multiple buildings, floors, or geographic locations, you’ll probably want to create a simple code to determine where the client is by its name. A computer name of B3F7D5 may sound no better than R2D2, but it could mean the client computer is in building number three, on the seventh floor, on desk number five. You can easily and instantly locate thousands of computers by name, and RIS can be configured to allow a similar naming scheme by using the following steps:
Some of the same security issues involving rogue DHCP servers are present with rogue RIS servers. An unauthorized RIS server could hijack legitimate client configuration requests and configure those clients with less than optimal settings. You can take almost the same steps as with DHCP to make sure only authorized RIS servers are able to operate on your network. Following is a list of steps necessary to ensure RIS server authorization, assuming you’re logged in as a member of the Enterprise Administrators security group:
Open the Microsoft Management Console (MMC).
Choose the DHCP Management snap-in.
In the scope (right) pane, right-click on DCHP root description and choose Manage Authorized Servers.
Choose Authorize, then type in the name and IP address for the authorized RIS server.
Click OK and then click Yes.
Windows 2000 Terminal Services is now included as a standard feature of Windows 2000 Server. Terminal Services allow for a thin-client network, which means much of the processing and storage needed to run applications is handled remotely on the server. This is especially useful and economical if you already have a large base of older client hardware that is incapable of running Windows 2000 Professional locally. Because the RAM and storage needs are provided by the server, the client can be relatively low powered and still perform well in a Windows 2000 environment.
Terminal Services can be run in two modes, remote administration mode and application sharing mode. These modes are selected during the installation and cannot be changed afterwards without reinstalling Terminal Services:
- Remote administration mode
Only members of the Administrators group can log on locally. This mode is used mainly to provide remote configuration and maintenance for system administrators.
- Application sharing mode
This mode allows access to programs and services stored and run on the server. Client computers run programs on the server as if they were running locally.
There are a few security issues that you should be very careful with when using Terminal Services:
Don’t install Terminal Services in application sharing mode on a Windows 2000 domain controller. If you do, all the permissions you grant users on that particular domain controller are valid on every domain controller in Active Directory.
Terminal Services traffic uses port 3389 by default. Be sure to disable that port if you want to block traffic with a firewall or router.
Smart card authentication is incompatible with Terminal Services.
Be sure that your normal NTFS, Group Policies, user permissions, and user profiles are in order before you allow Terminal Services to be run.