Understand and eliminate Win2K vulnerabilities

To make remote work tolerable, most telecommuters have a permanent cable modem or Digital Subscriber Line (DSL) connection to the Internet. Although a permanent connection is a great convenience, it also makes your small office/home office (SOHO) more vulnerable to Internet-based probing and potential attacks. When you have a permanent connection, your Internet system is always listening for and responding to incoming connections—legitimate and otherwise. If your permanent connection has a static TCP/IP address, your Internet system is a known and registered entity on the Internet. A static TCP/IP address is similar to having a listed phone number. As a known entity, your system becomes a target for intrusion in the same way your listed number is fair game for telemarketers. If you routinely work at home, your home system is an extension of your employer's network. Your system probably contains sensitive information that you need to safeguard—for your sake and for your employer's sake.

Securing a SOHO involves a combination of two approaches: preventing unwanted access and detecting and preventing attempts at unwanted access. You can use several techniques to reduce Windows 2000's inherent vulnerabilities. You can set stringent controls for account lockout, disable services that announce your system's presence on the Internet, and disable services that have a track record of successful exploitation. You can enable security auditing to monitor logon and logoff, account management, policy management, privilege use, and system events. (For more information about hardening Win2K, see "Related Articles.")

These native Win2K techniques reduce the vulnerability of your Internet-connected machine, but they deter and monitor intrusion attempts only at the Win2K service level. Below each native service is a second layer of vulnerability in the form of TCP and UDP ports—the primary target of innumerable Internet-based Trojan horses and of attackers' attempts to probe for security holes. Although you can implement port and address filtering in Win2K as part of an IP Security (IPSec) implementation, not many SOHO systems are sophisticated enough to support IPSec connections. A personal firewall is the only software you can install to tightly monitor and control activity to and from your Internet system. When you implement a firewall, you can control incoming and outgoing traffic by port number, permit or deny connections based on source and destination address, and deter unwanted access in realtime.

I suggest two simple exposure tests to identify your SOHO's current vulnerabilities. After you run the tests, read on to learn how and where Win2K is vulnerable to accidental or purposeful intrusion—through NetBIOS, native services, and ports—and how to eliminate these open doors. Although what follows doesn't guarantee that your Internet-connected system won't experience problems, these Win2K techniques will significantly reduce your exposure and minimize the risk of attack. In Part 2 of this series, I'll cover how to select and install a personal firewall to address the remaining vulnerabilities.

Evaluating Your SOHO Exposure
Let's start by evaluating your SOHO's security vulnerabilities. If you're not convinced you have a problem, this test might be a sobering experience. Find a Web site that probes a system for common vulnerabilities. One such site is the Gibson Research Corporation Web site (http://grc.com), at which you can evaluate Windows-specific NetBIOS (i.e., NetBIOS over TCP/IP—NetBT) exposure and port-level exposure.

Test your NetBIOS exposure. At Gibson Research's site, click the Shields UP! link and scroll down the Shields UP! page until you see the Test My Shields! and Probe My Ports! buttons. Click Test My Shields!, and wait until the test finishes. If your system is like most systems, you'll see a display similar to Figure 1, which shows that NetBIOS port 139 is open and accessible and that the test can retrieve your username, your computer name, and your local share name information from this port. Because of its insecure nature, NetBIOS is the most common target for intruders. Save the results of this test so that you can compare them with the report you get when you run the test again after you implement the Win2K settings I recommend in the section "Eliminating NetBIOS Exposure."

Test your port exposure. Next, run the Probe My Ports! test. This tool is a port scanner that asks each Win2K sevice whether it's listening to and responding to incoming connections. The Gibson Research site explains that a port can be open, closed, or stealth, depending on how you configure and protect your system. An open port means that the associated service accepts incoming connections, which presents an opportunity for access. A closed port means that the service is available but doesn't accept incoming connections. A stealth port is an invisible port that gives no indication that the service is loaded and running. Figure 2 shows the results of the port test on an unprotected system that's wide open to NetBIOS and Telnet access. If you follow the instructions I provide in the section "Reducing Win2K Service Exposure" and then run this test again, you'll see how easy it is to remove these ports as targets.

Eliminating NetBIOS Exposure
Each time you install a network adapter, Win2K automatically installs and binds two NetBIOS components to each network card: Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. These components provide backward-compatibility for Windows NT 4.0 and Windows 9x systems that use Microsoft's proprietary and nonsecure NetBIOS (i.e., WINS) name registration and name resolution. Under the hood, Win2K and NT implement NetBIOS by using TCP/IP as a transport, an implementation the documentation refers to as NetBT. However, you don't need these functions on your Internet connection, and here's why.

Client for Microsoft Networks sends out NetBIOS name-resolution broadcast requests to locate computers and share names on your LAN (i.e., the names that appear in the My Network Places browse list). These unsolicited broadcasts announce your system and its internal resources and draw unnecessary attention to your Internet connection. Because NetBIOS name resolution is proprietary to Microsoft, few Internet-connected systems require this function. You can stop a system from broadcasting NetBIOS name-resolution requests on the Internet by unbinding the Client for Microsoft Networks on the network adapter connected to the Internet.

File and Printer Sharing for Microsoft Networks is the counterpart to Client for Microsoft Networks. This component publishes NetBIOS names for local shares and, more important, manages incoming connections to local shares. Regardless of whether your machine has shares, you certainly don't want to publish their NetBIOS names on the Internet. Likewise, you probably don't want unknown Internet systems connecting to your private shares. You can stop a system from publishing NetBIOS names and you can disable incoming connections to NetBIOS resources by unbinding File and Printer Sharing on the network adapter connected to the Internet.

Unbinding both clients effectively closes several NetBIOS ports (ports 137,138, and 139*139 is the most well known) that are a standard target for intruders. To disable these components and eliminate NetBT traffic, open Network and Dial-up Connections (click Start, Programs, Accessories, Communications, Network and Dial-up Connections). Choose Advanced Settings from the Advanced menu to bring up the dialog box you see in Figure 3. Click the network adapter for your Internet connection (e.g., the WAN adapter in Figure 3), and clear the check boxes of both components. The changes apply immediately, without a reboot.

In a pure Win2K environment, DNS replaces proprietary NetBIOS name resolution, and Win2K systems don't need these components to successfully browse a network and connect to shares. When you disable these components, you stop announcing your Internet presence with NetBIOS broadcasts, disable incoming NetBIOS connections, and, as a side benefit, also eliminate a great deal of unnecessary network traffic. If your SOHO consists of Win2K systems and you're running Win2K DNS, you can safely disable these components on all your systems to eliminate NetBIOS vulnerabilities.

Reducing Win2K Service Exposure
Win2K installs many services that support local and network communication. You can view all the services Win2K loads and starts automatically by running the Administrative Tools Services applet. Because running services listen for and respond to incoming requests, typically on a specific port, they're a common target of attacks.

For example, when you install any Win2K platform, the OS by default installs and starts the Telnet service. Telnet listens to incoming requests and responds with a command prompt to each incoming connection. When Telnet responds to an incoming request, it verifies that your system supports remote command-line activity. Intruders that detect this service on your system know the service is listening to and accepting connections with a valid username and password. If you forget to rename the Administrator and Guest accounts and permit blank passwords (the system default), you give a potential intruder an easy way to log on and access your system. When you disable Telnet, you disable the listening port and guarantee that the service won't respond to incoming connection requests.

The Indexing, IIS, FTP Publishing, and Remote Registry services present similar opportunities for unsolicited remote connections. If your system doesn't host a Web site, you can safely disable the IIS and the FTP Publishing services, and if you're not publishing thousands of documents, you can disable the Indexing service, too. Randy Franklin Smith's "Dangerous Services" series of articles (which "Related Articles" references) explains the type of exposure each service presents. You might end up disabling many services to tighten up the security on your system.

Disabling a Win2K service requires two steps. First, you stop the service if it's running, then you set the startup type to Manual or to Disabled. Start the Administrative Tools Services applet to display all the services Win2K installs. Each service and its status appear in the right pane, as Figure 4 shows. To disable a service, right-click it, then click Stop. This disables the service, but only until the next reboot. During system restart, Win2K automatically starts each service that has a startup type of Automatic. To permanently disable a service, you need to change its startup type. To change a service's startup type, double-click the service to bring up its Properties dialog box, which Figure 5 shows. You can change the startup type from Automatic to Manual or Disabled by choosing an option from the Startup type drop-down list. When you set the startup type to Manual, you can start the service by right-clicking it. When you set the startup type to Disabled, Win2K disables the Start, Stop, and Restart options, which means that the service can't run until you change its status back to Manual or Automatic. Repeat this procedure for each service you want to disable.

Understanding Port Exposure
Each Win2K service uses one or more protocols to implement network connections. When a service is running, it listens for incoming requests on the port associated with the protocol. Because 65,535 ports exist, to maintain order for worldwide communication, international standards associate a specific port number with a specific protocol (e.g., FTP, HTTP) and thus, with the service that uses the protocol. You can see the port assignments at http://www.isi.edu/in-notes/iana/assignments/port-numbers. (For information about the two types of ports that exist, see the Web-exclusive sidebar "TCP vs. UDP Ports.")

The standards further divide these 65,535 ports into three groups: well-known ports (0 to 1023), user-registered ports (1024 to 49,151), and dynamic or private ports (49,152 to 65,535). Well-known ports facilitate common network communication between similar and disparate network operating systems. So, for example, the Telnet service uses the Telnet protocol, which listens on port 23 for incoming connections. Likewise, the FTP service responds to incoming and outgoing requests on port 21, the SMTP service you activate when you send mail listens on port 25, the POP3 service you activate when you receive mail listens on port 110, and the HTTP service listens for nonsecure connections (i.e., http:// requests) on port 80 and secure connections (i.e., https://) on port 443. NetBIOS broadcasts names on port 137 and creates connections to local shares on port 139.

When you stop a Win2K service, you must be aware of two important concerns. First, when you stop a service, you stop responses to incoming requests on the companion port. When the service doesn't respond to an incoming request, you eliminate intrusive and legitimate attempts to access your system. When you disable the FTP service on your Internet system, you can no longer store or retrieve files from your machine when you're at a remote location, and you might not be able to live with this restriction. Second, even when you stop multiple services, you don't deter access to higher-numbered ports. Most personal firewalls, however, let you filter or restrict incoming connections for standard services such as Telnet and FTP so that you can permit legitimate connections from known addresses as well as deny connections to unknown addresses. Firewalls also have built-in rules that stop known Trojan-horse attacks by prohibiting access to ports in the user-registered and dynamic port ranges.

Closing the Gaps with a Personal Firewall
In Part 2, I'll discuss how you can significantly reduce remaining vulnerabilities by installing a personal firewall. I'll explain how firewalls implement realtime protection with a set of port rules that permit or deny access, and I'll review three important features that you should evaluate before you select a personal firewall product. I'll also discuss intrusion alerts and show you logs of known Trojan-horse and port-scanner attacks. I have lengthy logs of repeated attempts to invade my network, launched from places as far away as Asia and as near as Silicon Valley. If you don't think Internet intrusion is a reality, these examples will convince you that a firewall is a mandatory component of a well-protected SOHO network.

Related Articles in Previous Issues
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com/articles.

RANDY FRANKLIN SMITH
"Audit Account Logon Events," March 2001, InstantDoc ID 19677

You can obtain the following articles from the Windows IT Security Web site at http://www.WindowsITsecurity.com.

RANDY FRANKLIN SMITH
"Dangerous Services, Part 3," January 2001, InstantDoc ID 16476
"Dangerous Services, Part 2," December 2000, InstantDoc ID 16363
"Dangerous Services, Part 1," December 2000, InstantDoc ID 16301Lab Guys, "Thin Client