8 Steps to a Secure SOHO

Securing a small office/home office (SOHO) requires a two-pronged approach of preventing unwanted access and detecting such access when it occurs. To achieve a high level of protection on your SOHO network, you need to be aware of several procedures that you can perform on your Windows 2000 machines. You also need to understand the importance of installing a personal firewall to close any remaining holes. The eight steps that follow don't, by any means, guarantee that your Internet-connected system won't experience problems, but these techniques will significantly reduce your vulnerabilities.

1. SOHO Configuration

For this discussion, I assume you want to protect a LAN rather than a standalone system. I also assume that you aren't hosting a Web site and that you aren't supporting VPN connections. If you are, you'll need to extend the techniques I describe in this article to properly secure Web access, VPN connections, and other custom services you provide with Microsoft or third-party applications.

Two common SOHO configurations exist: one that maximizes your exposure to potentially malicious actions and one that isolates exposure to a single system. If you connect a cable or DSL modem directly to a hub and your other systems connect to the same hub, every system has a direct Internet connection. This configuration, which Figure 1 illustrates, maximizes your vulnerability and requires that you implement security deterrents on every system.

The more secure alternative is to pick one system to connect directly to the Internet, then buy and install a second network adapter on this system. Connect one adapter to the hub (LAN connection), and connect the second adapter to the modem, as Figure 2, page 18, shows. You've now centralized all your Internet traffic on the Win2K system with two network adapters. With centralized traffic, you can manage and protect your SOHO much more effectively.

Of course, you'll need to implement Internet Connection Sharing (ICS) or RRAS to let LAN clients communicate with the Internet. Installing RRAS to perform LAN routing for your system is easy. If you don't want your Internet machine to accept incoming connections, when you configure RRAS, select the Router and Local area network (LAN) routing only options and leave the Remote access server check box cleared, as Figure 3, page 18, shows.

You can also install freeware or shareware routing applications or implement routing directly in the DSL modem, depending on your technical expertise. With two network adapters, you can isolate and manage the LAN and Internet connections independently, which lets you implement tighter security on the Internet side than on the LAN side.

2. Dynamic vs. Static TCP/IP Addresses

Although ISPs manage Internet-connected systems in various ways, most ISPs follow two fairly common practices. When you set up a permanent connection, you typically contract with a service provider to manage the connection. Service providers assign either a dynamic address or a static TCP/IP address to the Internet machine.

When your system has a dynamic address, the ISP renews your address every time you power off your modem or reboot your machine. With a dynamic address, only your ISP knows that the address www.xxx.yyy.zzz refers to your specific system. Without a registered domain name such as myoffice.com that maps to address www.xxx.yyy.zzz, your system's identity doesn't extend beyond your ISP's network infrastructure.

When the ISP assigns a static address, the machine has a permanent identity. If the ISP also registers a domain name for the static address, the machine becomes a known and verifiable entity on the Internet. A registered system is much more likely to become a target that intruders attempt to scan, probe, and invade on a regular basis.

3. Network Address Translation

When you have two or more static addresses, you can reduce intrusion opportunities by implementing Network Address Translation (NAT) on a Win2K system or on NAT-compatible DSL or cable modems. Win2K supports two versions of NAT: a slimmed-down version in ICS and a full implementation in RRAS.

A system running NAT accepts Internet traffic from a LAN client and repackages the request with its address instead of the client's address. NAT then forwards the outgoing message to the requested destination. When the destination responds, NAT uses a mapping table to route incoming responses to the correct client. When a system running NAT receives an incoming message for a specific LAN address (as opposed to a response to an existing connection), the system refuses the request. This effective deterrent prevents LAN clients from directly interacting with any Internet destination and thus prevents intruders from interacting with the clients. For instructions about how to configure NAT, see the Microsoft article "HOW TO: Configure the NAT Service in Windows 2000" (Q310357, http://support.microsoft.com).

NAT has a couple of drawbacks. You'll need to fine-tune NAT rules to permit clients to FTP to or from an Internet site, to enable a client application to directly access the Internet, or to enable Internet-based game playing. NAT isn't compatible with Layer Two Tunneling Protocol (L2TP) or IP Security (IPSec) or other protocols that embed client IP addresses within their packets, so if you support encrypted L2TP connections, NAT isn't an option.

4. Exposure Evaluation

The next step is to evaluate your SOHO's exposure to the Internet. If you're not convinced you have a problem, this experience will be sobering. You can easily find an Internet site that probes systems for commonly exploited Windows-specific vulnerabilities. If you don't have a specific site in mind, I suggest you visit the popular Gibson Research site (http://grc.com/default.htm). At this site, you can evaluate two types of exposure: NetBIOS exposure and service-based port exposure. Many firewall vendors also provide online-security and port-scanning analysis tools.

NetBIOS exposure. At the Gibson Research Web site, scroll down and click the ShieldsUP! option. Scroll down the ShieldsUP! page until you see the Test My Shields! and Probe My Ports! buttons. Click Test My Shields! and wait for the test to finish. If your system is typical, you'll see that NetBIOS port 139 is open and accessible and that the test can easily retrieve your username, computer name, and local share name from this port. Because of its nonsecure nature, NetBIOS is the most common target for intruders. (To learn how to eliminate this vulnerability, see Step 5.) Save the results of this test so that you'll be able to compare before and after reports. After you implement this article's tips, you can run this report again to verify that you've successfully reduced your vulnerability.

Port exposure. International standards associate a specific port number with each Win2K or third-party service that supports network communication. A total of 65,535 ports exist, and to maintain some semblance of order for worldwide communication, many of the ports below 1024 (called well-known ports) are associated with a specific protocol (e.g., FTP, HTTP) and with the service that uses the protocol. When a service is running, it listens for requests and responds to requests according to port number.

For example, the FTP service responds to incoming and outgoing requests on TCP port 21; the SMTP service you activate when you send mail listens on TCP port 25; the POP3 service you activate when you receive mail listens on TCP port 110; and the HTTP service listens for nonsecure connections on port 80 and secure connections on port 443. NetBIOS broadcasts names on port 137 and creates connections to local shares on port 139. If you're interested in determining which protocol is associated with a certain port, you can download a definition file for all 65,535 ports from http://www.iana.org/assignments/port-numbers or http://www.sockets.com/services.htm.

Run the Probe My Ports! test. This port scanner asks each Win2K service whether it's listening to and responding to incoming connections. A port can be open, closed, or invisible, depending on how you configure and protect your system. An open port means that the associated service will accept incoming connections—an opportunity for both authorized and unauthorized access. A closed port means the service is available but won't accept an incoming connection. An invisible (stealth) port gives no indication that the service is loaded and running. (In Step 8, you'll learn how to use a personal firewall to implement port-level protection.) Read the Probe My Ports! report to learn about your system's port exposure.

5. Secure Your Internet Connection

Next, I want to provide Win2K configuration tips that can eliminate potential vulnerabilities. Microsoft includes NetBIOS components in Win2K for backward compatibility with Windows NT 4.0 and Windows 9x platforms, but you don't need NetBIOS to browse or communicate with systems on the Internet. When you install TCP/IP (but not NetBIOS), you can always connect to LAN shares with the IP address and share name (e.g., \www.xxx
.yyy.zzzshare), but you can't connect with Universal Naming Convention (UNC) share names (e.g, \servershare). You should install only TCP/IP on the Internet network adapter. If you don't need to share resources on the Internet machine with other internal systems, you should also disable NetBIOS on the LAN adapter. The fewer the network protocols and services, the fewer the opportunities you present for a malicious user to exploit. Fewer network protocols also make your system run more efficiently.

Eliminating NetBIOS vulnerabilities. Each time you install a network adapter, Win2K automatically installs and binds two NetBIOS components to each NIC: Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. These components provide backward compatibility for NT 4.0 and Win9x systems that use Microsoft's propri-
etary and nonsecure NetBIOS (WINS) name resolution. However, you don't need either of these functions on your Internet connection. Here's why.

To locate computers and share names on your LAN (i.e., the names that appear in the My Network Places browse list), Client for Microsoft Networks sends out NetBIOS name-resolution broadcast requests. 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. When you disable Client for Microsoft Networks, you close the associated NetBIOS ports (e.g., ports 137 and 139) that are standard targets for intruders.

File and Printer Sharing, a counterpart of Client for Microsoft Networks, publishes NetBIOS names for local shares. Regardless of whether your Internet machine has shares, you don't want to publish their NetBIOS names on the Internet. To disable these components and eliminate NetBIOS over TCP/IP (NetBT) traffic, open Network and Dial-up Connections, click Advanced on the menu bar, and click Advanced Settings to bring up the window that Figure 4 shows. Highlight the network adapter for your Internet connection, and clear the check boxes for both components. The changes take effect immediately, without requiring a reboot.

In a pure Win2K environment, DNS replaces proprietary NetBIOS name resolution, and Win2K systems don't need either of these networking components to successfully browse the network and connect to shares. When you disable them, you stop announcing your Internet presence with NetBIOS broadcasts, and you also eliminate a lot of unnecessary network traffic. If your SOHO consists of Win2K systems and you're running Win2K DNS, you can safely disable Client for Microsoft Networks and File and Printer Sharing on all your systems to eliminate NetBIOS vulnerabilities.

6. Reduce Service-Based Exposure

You can further protect your Internet machine by disabling (and optionally removing) five services that you don't need.

Telnet. All Win2K platforms install a Telnet server and set the service to start up automatically. This vulnerability is fairly obvious because Telnet permits users with valid logon credentials to connect through a TCP/IP address or port number and enter unrestricted commands at a command prompt. You can't remove this service, but you should disable it.

Indexing Service. By periodically building a catalog of documents on the system, the Indexing Service provides fast full-text searching of documents. On Win2K Server, this service is a component of Microsoft IIS, but on Win2K Professional, the Indexing Service is a standalone component. You might have heard of several publicized exploits in which attackers viewed confidential information through the Indexing Service. If you're not running a Web server or managing gigabytes of documents on the Internet machine, you should also disable this service.

IIS. If your Internet system is running Win2K Advanced Server, you might not be aware that setup always installs IIS, which provides Web and FTP access to the system. If you don't need a Web server on your Internet machine, disable the World Wide Publishing Service and the companion FTP Publishing Service. To permanently eliminate these access oppor-
tunities, you can uninstall IIS by clicking Add/Remove Windows Components in Add/Remove Programs.

Remote Registry Service. Because a consistent registry is absolutely essential to a happy, healthy Win2K system, you should eliminate the registry as a target for remote modification. However, remember that when you disable the Remote Registry Service, you'll have to make registry modifications by logging on locally or by applying changes with group or local policies.

UPnP. If you've installed MSN Explorer or Windows Messenger (Windows XP always installs MSN Explorer), you should also disable the two services that support these applications: Universal Plug and Play (UPnP) and the Simple Service Discovery Protocol (SSDP Discovery) service. Contrary to your expectations, the UPnP service has nothing to do with detecting Plug and Play (PnP)—compatible devices. Instead, UPnP comprises a set of protocols that enable TCP/IP devices to announce their presence to and interact with other UPnP-compatible devices on a network. UPnP broadcasts a constant flow of packets announcing that the machine will accept incoming TCP and UDP connections. In many cases, these services send UPnP queries every 25 seconds, 24 hours per day, in an attempt to locate other compatible devices on the network. In addition to announcing the machine's availability for incoming connections, these packets consume valuable bandwidth. Attackers have taken advantage of this service's inherent security weaknesses to mount widespread Denial of Service (DoS) and Distributed DoS (DDos) attacks.

Disabling Win2K services requires two steps: Stop the service if it's running, then set the startup type to either Manual or Disabled. First, start the Services applet from Administrative Tools to display the status of all services. You'll see a list of services in the right pane. Right-click Telnet and select Stop. Doing so effectively disables the service—but only until the next reboot. During system restart, Win2K automatically starts each service that has a startup type of Automatic.

Second, to permanently disable the service, you need to change its startup type. Double-click the Telnet entry to bring up the configuration window that Figure 5 shows. You can change the Automatic startup type to Manual or Disabled. When you set the startup type to Manual, you can start the service by right-clicking it or by entering the Net Start Telnet command at a command prompt. When you set the service to Disabled, Win2K shades the Start, Stop, and Resume options, which means the service can't run until you change its startup type back to Manual or Automatic. Repeat this procedure for the FTP Publishing Service, the Indexing Service, and the Remote Registry Service.

To eliminate UPnP attacks, you need to disable two separate services: the SSDP Discovery service and the partner UPNP DH service. First, stop the UPNP DH service (if it's running) and set the startup type to Disabled. Then, repeat this procedure for the SSDP Discovery service.

7. Basic Intrusion Detection

Now is the time to implement security-auditing techniques so that you can log the success and failure of access attempts to your Win2K system. Security auditing is an intrusion-detection method you can employ to monitor the effectiveness of deterrent techniques.

To access the Win2K Audit Policy window, go to Administrative Tools and select Local Security Policy. Local Security Policy encompasses four aspects of local system operation: Account Policies, Local Policies, Public Key Policies, and IP Security Policies on Local Machine. All four of these options appear in the left pane of the Local Security Settings window, as Figure 6 shows. To display Win2K's audit categories in the right pane, expand the Local Policies node, then expand the Audit Policy node. The right pane's title bar, which is new in Win2K, has three columns: Policy, Local Setting, and Effective Setting. The Local Setting column shows the audit options you want to change, and the Effective Setting shows the audit options that are currently active. When you view audit settings for the first time, both columns should show the No auditing status for all nine categories.

To achieve a basic level of monitoring, consider auditing four categories of events: Audit logon events, Audit account management, Audit policy change, and Audit system events. Audit logon events records an event each time someone attempts to authenticate with the local SAM database. When you enable both Success and Failure of logon events, you'll see a record in the Security log each time someone authenticates successfully, as well as each time an authentication fails. If your Internet machine is a Win2K domain controller (DC), enable Audit account logon events instead.

If you need a log of who changes local system accounts and when (e.g., when someone adds, renames, or removes a user or changes a password), enable Audit account management. You might also want to enable Audit policy change. This category records an event in the security log when someone changes the audit settings, assigns or removes user rights, or changes the settings for any of the options in the Security Options folder. When you enable Audit system events, Win2K writes a record each time someone shuts down and reboots a system. Security auditing for these four categories, collectively, will give you a good overall picture of what's happening on your Internet machine.

To enable auditing, double-click each of the four categories, select the Success and Failure check boxes, and click OK. When you return to the Audit Policy window, you'll see that the Local Setting column has changed to Success, Failure, but the Effective Setting still shows No auditing. To activate your changes, you must manually force a Local Security Policy refresh. Go to a command prompt and enter

secedit /refreshpolicy machine_policy.

If you keep the Local Security Settings window open as you run the Secedit command, then return to the Local Security Settings window, you'll see that the Effective Setting hasn't changed. Unfortunately, a bug in this utility prevents it from properly displaying the new settings, and it won't refresh even if you collapse and expand the Local Policies node or Security Settings node. To update the display to reflect the true settings, you'll need to exit and restart Local Security Policy.

8. Adding Personal Firewall Protection

In an ideal world, Win2K would provide realtime detection and prevention techniques. Unfortunately, even when you restrict services and implement security auditing, several weaknesses remain. First, Win2K can audit only activity that's specific to the OS—events tied directly to the operation of a specific system service. Second, security auditing won't prevent unauthorized or well-known attacks to your system when they're in progress. Third, each Win2K service uses one or more ports to support its activities, and each port is a potential target for intrusion or abuse. Although security auditing tracks major events, it can't detect intrusion attempts at this low level.

Fortunately, a personal firewall compensates for these weaknesses. Depending on the software you select, a personal firewall can also prevent stealth transmission of personal information such as your name, credit card number, and recently visited Web sites. Many personal firewall vendors let you download and run their products in a SOHO configuration at no charge or for a minimal fee. To explore your options, check out the Firewall Guide Software Reviews site (http://www.firewallguide.com/software.htm). This Web site tracks personal firewall software on an ongoing basis and provides current descriptions of each product, recent technical evaluations, and links to vendor sites at which you can download free evaluation or personal copies.

Don't Worry, Be Happy

After you install and configure a personal firewall, return to the Gibson Research site and run the tests a second time. If you've followed this article's procedures, you'll find that you've eliminated NetBIOS vulnerability, as well as numerous service-based exploit opportunities. The personal firewall should reduce—and in the best case, eliminate—port-level exposure. Now you don't need to worry about shutting down your Internet machine or powering off the modem when you leave town for work or play.