NetBIOS — The Service That Wouldn't Die

With the slow but steady migration to Windows 2000, NetBIOS receives another stay of execution. So, how does this collective pet peeve affect you?

• By Michael Chacon
• February 01, 2001

The most power and function you can get from Microsoft just might be in Windows 2000 Datacenter Server — the strongest server operating system we’ve ever offered. Whether you’re an MCP in a corporate-technology department or with a Solution Provider company, the newest Windows operating system may provide the best business investment that your organization — or your customer — can make for mission-critical computing.

We’re now close to our second year of Windows 2000, and there are reported to be more than 2 million outstanding licenses. Besides the obvious implication of millions of dollars flowing into Microsoft, the number also implies that the migration process to Win2K is well under way around the world. It also means there are still many more sites to go and that it’ll take quite awhile for the process to be completed in any given company. As much as we’d like to wave a magic wand and have a simple, immediate process, the reality is that interoperability issues will continue to be center stage for quite some time.

It’s Following Us
This is having the unintended effect of dragging out the lifespan of one of my personal pet peeves with Windows NT, LAN Manager before that, and MS-Net-based products before that. This well-festered irritant is still stalking us under the name of NetBIOS. Oh, I know its days are numbered, but I remember when its days were numbered in the late 1980s. I’m not sure if a stake through the heart is required to rid us of this scourge, but I’m beginning to wonder. I’ve covered the details of how NetBIOS works before so I won’t go into too much detail here, but I do want to cover some of the continuing implications it raises for Win2K and Active Directory.

NetBIOS has a long history. It was developed in the early 1980s by a company called Sytec (now a part of Hughes LAN Systems) under contract by IBM to connect those pesky personal computers at the end of SNA-connected large computers, which of course were going to be the future of enterprise computing. Well, things have changed a bit, but you’re still left with the architectural limitations of NetBIOS as long as you have Windows 9x and NT clients attached to your Win2K network.

The main limitation is that — while all movement in the management of resources on networks today is toward a hierarchical, enterprise-wide namespace — NetBIOS was initially designed for a flat namespace with a maximum of 72 named devices. This, of course, has been corrected over the years through enhancements in its ability to uniquely identify many more devices and with tools such as WINS that trick NetBIOS into thinking it’s on a flat network even though it may reside on a routed network.

Character Counts
The other main limitation of NetBIOS, which hasn’t been extended, is that for any device to be recognized on the network, the name can’t be more than 16 characters long. This limitation is practically lowered to 15 characters because the 16th character is reserved by the operating system to identify the various services that exist on the device. Since Microsoft recognizes that there won’t be any overnight migration implementations and that its previous success has created multiple millions of NetBIOS nodes on existing networks, it’s built a strong level of support for backward compatibility into the Win2K platform. For this reason, continued NetBIOS support is part of the default configuration for Win2K machines.

The first implication NetBIOS has for a mixed Microsoft environment is in the naming conventions that you may have considered with a hierarchical directory in mind. The Active Directory name follows the DNS requirements for supported names and provides up to 64 characters for the host name, which would be joined with the DNS suffix. These two name components comprise the fully qualified domain name (FQDN). The suffix isn’t important for the discussion, but the host name is critical. Best practices would recommend that you keep your host name well shorter than 64 characters, but you could make a case for a name that exceeds the 15-character practical namespace limitation length of NetBIOS. However, by default, if you add a workstation with a name longer than 15 characters, it’ll be truncated to fit into the NetBIOS namespace. This can wreak havoc with any name standard you may have designed — regardless of the character length.

What’s in a Name?
If you choose to keep NetBIOS naming conventions for interoperability considerations while you’re migrating a system, you may want to take some immediate initial steps. The legal characters that are supported in NetBIOS and DNS are — for the most part — comparable except for one major annoyance. Since the NetBIOS namespace doesn’t allow spaces, it’s been common practice for people to use underscores. The DNS namespace uses the hyphen for the same reason. There’s been a proposal to use the underscore for the names of services advertised in DNS, but it’s still not a standard.

While Microsoft’s DNS supports Unicode characters, including the underscore, you can’t count on the underscore to be recognized by other DNS implementations, which is problematic in the enterprise. The best practice is to change all of the NetBIOS names that will be in place for any extended period of time to support the overlapping NetBIOS and DNS characters, which means avoiding both the underscore and the hyphen. This will take some work, but it’ll be time well spent if you plan a protracted migration.

You can have a different NetBIOS name and DNS name for the same workstation. However, this approach introduces questionable complexity. One of the backward-compatibility features of Win2K is the interoperability between WINS and DNS, where WINS can be listed in the DNS server to help resolve names. If a particular machine has a DNS name and a different NetBIOS name, there’ll be unpredictable results depending on the source of any queries.

Another issue is that if you’ve decided to support client names larger than 15 characters you’ll have to make administrative modifications to the Access Control Entries (ACEs) in the directory, which make up the Access Control List (ACL). DNS names longer than the standard 15 characters will be different from the SAM account name and can cause directory confusion. The SAM name, designed to support the NetBIOS-based NT technology, is used when adding a client name to the directory. The administrator needs to modify the ACE security properties in the directory security properties to map the names and allow client names of more than 15 characters to be written by the system to the ACE in the directory.

A Matter of Security
Beyond some of the administrative issues that need to be considered, there are security concerns associated with NetBIOS. They mostly revolve around the fact that security wasn’t a consideration when NetBIOS was developed. Greater security has been developed over the years to surround the services that rely on NetBIOS, but NetBIOS still behaves in a predictable manner when interrogated. That behavior is to reply with its own information when challenged and also assume the best intentions when provided with a service that knows its name. While the services themselves are, for the most part, effectively protected through access control, NetBIOS is a particularly vulnerable target for Denial of Service attacks.

NetBIOS is based on names rather than addresses. It resolves naming conflicts by following a standard procedure when it’s confronted with a challenge that the name it’s using is claimed by another device. One version of this vulnerability is manifested by a potential attack generated by a bogus NetBIOS name server that’s used to send a name-release datagram to the target machine. When the target machine responds to the request, it becomes unavailable to legitimate users. Another way to obtain the same effect is to send the target machine a NetBIOS name-conflict datagram to get the target machine to relinquish its name. Now, there are ways to prevent this from happening, such as closing the NetBIOS ports 137, 138 and 139 from the outside world through your firewall. However, that won’t stop internal attacks on system resources from disgruntled employees. There’s also a patch that protects a machine from responding to spoofed NetBIOS commands, but this could also have the unintended result of preventing legitimate name-conflict resolution.

Another broad security issue with leaving the NetBIOS backward-compatibility feature enabled is that the NBTSTAT command can send useful information — such as the Active User, services running, workstation name, and even the MAC address — back to a requester. This is useful information when it comes to building a map of a targeted system for future hacking or other nefarious objectives.

This is not to say that Win2K is a fundamentally unsecured platform — far from it. With Kerberos as the default authentication protocol you can verify the client as well as the server, so both sides of a connection are authenticated. However, until you’ve completed a Win2K migration and removed all the clients who need NetBIOS to advertise their presence, establish sessions and access resources, you need to maintain and design security enforcement points that include NetBIOS considerations.

Somebody, Get me a Stake
I certainly haven’t covered all of the issues surrounding NetBIOS, but I hope I’ve reminded you to keep your eye on the past as you move forward. Bottom line: If you’re serious about moving to a Win2K enterprise information system, you need to have the removal of NetBIOS clearly outlined in your plan. Even if you have all your workstations and servers on Win2K, you may have left NetBIOS and NTLM authentication support still enabled. When you build your project plan, set a milestone at which NetBIOS finally succumbs to the stake through the heart. I’m sure there’ll be little mourning from the bleachers.