Implementing IPSec

IPSec is a security protocol included in the Windows 2000 TCP/IP stack. Its function is simple – to secure TCP/IP communications within or between networks according to the parameters and rules that you lay out. While the concept itself is simple enough, the actual implementation of policies that will do what you want actually requires a deeper understanding of TCP/IP. Not only must you understand how communication takes place on the network, but you must also be able to translate your security needs into specific explicit policies. That requires knowledge of protocols, port numbers, and more, as well as a plan for how and where you need to encrypt or confirm the integrity of traffic. While it might immediately seem like a good idea to encrypt all traffic on your network, that isn’t necessarily practical or a good idea. Understand that you pay a price for encryption in the form of higher CPU utilization. This might not be a big deal for an individual workstation with a high-speed processor, but consider also the load on the server that it handling (and encrypting) multiple simultaneous encrypted connections. Instead, focus on using encryption where required for security purposes, creating a setup that meets the needs of your organization. It will seldom be a one-size-fits-all scenario.

If you are considering using IPSec, you first need to understand a bit about how it works. First of all, IPSec encryption / authentication differs from what you may already be familiar with in terms of security products. Most people have worked or are familiar with application-level encryption, where a program (such as PGP or similar) actually handles the encryption/decryption/signing processes. In contrast, IPSec actually resides in the protocol stack, independent of applications. Because of this, you are able to encrypt the data from any application prior to transmitting it over the network. Imagine that a client application on computer 1 wants to send encrypted data to a server application on computer 2. While there certainly needs to be some coordination between the two systems (we’ll get to that in a bit), the applications on either side actually have nothing to do with the encryption process. The client application would simply begin passing data down the protocol stack like normal, where it would be ‘intercepted’ by IPSec, encrypted, and sent to the server system. On the server, the data moves up the stack, and is decrypted by IPSec prior to being passed to the application. For all intents and purposes, the encryption is transparent to the person on the client side – something very favorable indeed.

WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of.

WINS Proxy – Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so you’ll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling – At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server.

Manual Tombstoning – The manual tombstoning feature in Windows 2000 exists to help ensure the consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency – Be careful with this one. WINS in Windows 2000 has a feature available called ‘Verify Database Consistency’ which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments – it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup – In order to have the WINS database backed up automatically, you need to specify a backup path on the server’s General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below.

Persistent Connections – Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group – This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

NetBIOS Name Resolution

Many people assume that NetBIOS name resolution is no longer necessary in Windows 2000 due to the heightened importance of DNS as the primary name resolution facility in the OS. Although Microsoft is certainly moving away from a reliance on NetBIOS as a network protocol, you simply cannot ignore the fact that programs exist that rely on NetBIOS. Yes, Windows 2000 does support resolving NetBIOS names in a variety of ways, including the use of DNS and related hostname-resolution techniques, but this is not necessarily efficient. Since so many products still use NetBIOS as their primary protocol, and since so many networks now run TCP/IP, it is still a good idea to run WINS on the network. If nothing else, it is impractical not to have it for the purpose of supporting downlevel clients such as Windows NT and Windows 98, who complete many important processes (such as logon) via NetBIOS.

A NetBIOS name is a 16-byte address that uniquely identifies a host on the network. This address is 15 characters long, with a 16th character that uniquely identifies a service that the system is running, such as the Server or Workstation services. A NetBIOS name is often referred to as a Computer name, although the line is blurring as Windows 2000 moves to a more integrated support of TCP/IP and DNS naming. Don’t forget that the purpose of WINS is mainly to resolve NetBIOS names to IP addresses. In the past, NetBIOS was the primary communication protocol used on Microsoft networks. The move to TCP/IP as the primary transport of choice has necessitated the ability to map NetBIOS names to IP addresses, and the ability to ‘piggyback’ NetBIOS over TCP/IP. However, WINS is not the only way to resolve these names to IP addresses. The official NetBIOS name resolution techniques in Windows 2000 include:

Local Broadcast – In this traditional method, a host will broadcast onto the local subnet trying to find the IP address associated with a given name. Obviously this method is restrictive, since it is limited in terms of reach on the network (as well as being inefficient)

NetBIOS Name Server – In most networks, a NetBIOS name server (such as WINS) is set up to handle name registration and queries directly. Clients systems (and servers) register their NetBIOS name to IP address mapping with WINS. When queried by a client, the NetBIOS name server replies with the requested IP address associated with the requested name.

NetBIOS Name Cache – Upon resolving a NetBIOS name to an IP address, the client stores this information in its NetBIOS name cache. By default, entries remain in cache for 600 seconds, and the cache holds only 16 names (configurable via the Registry). This makes the network more efficient, in that a client does not need to contact the network for every name resolution request. The reason for the low timeout is the fact that IP addresses may change due to the use of DHCP on the network. To view the NetBIOS name cache, use the nbtstat –c command.

LMHOSTS – This text file products a static way of mappings host names to IP addresses. A deeper look at LMHOSTS files follows later in this section.

DHCP Superscopes

Windows 2000 DHCP also has the ability to create 2 other types of scopes, one of which you may be familiar with, the other which is probably new to you. Superscopes were first introduced in Windows NT 4 SP2. Essentially, a superscope is used in situations where we run out of IP addresses on a subnet. For example, a network might be subnetted to allow only 254