Secure Your SOHO, Part 2

A personal firewall is the best deterrent

In "Secure Your SOHO, Part 1," May 2001, I discussed how you can evaluate your small office/home office (SOHO) vulnerabilities, and I gave you techniques to close common security holes. Let's follow up with an explanation of how you implement a personal firewall to monitor and protect your system in realtime at the TCP/UDP port level. If you run common Windows 2000 services, such as Microsoft IIS or Telnet, for remote access to your SOHO, you should use a personal firewall to implement rules that accept or reject connections based on the address (and thus the identity) of incoming and outgoing requests.

Many personal firewalls include predefined rules that defend against known Internet attacks on TCP/UDP ports in the dynamic or private port-number range. These attacks are similar to computer viruses in that, after an attack occurs, a security analyst can document the attack method and create an effective deterrent. To ensure that your systems are protected, it's important to update firewall rules regularly; as with virus software, many vendors provide an automatic update feature to help. Some personal firewall packages can also prevent unauthorized transmission of personal information, such as your name, credit card number, or recent Web sites that you've visited.

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 Personal Firewall Guide Software page at http://www.firewallguide.com/software.htm. This site tracks personal firewall software and provides current descriptions of each product, recent high-quality technical evaluations, and links to vendor sites from which you can download free evaluation or personal copies.

How Personal Firewalls Work
Most vendors ship their products with three levels of default protection: low, medium, and high security. You can activate one of the predefined security levels as soon as you install the software. The security levels are sets of rules that permit or deny access to specific ports. More-sophisticated products let you customize protection based on source and destination TCP/IP addresses and by restricting or enabling a specific inbound or outbound service's access to a port. The section "Defining custom rules" provides an overview of creating firewall rules.

Adaptive learning. When you first install a personal firewall, the software must learn about applications that access the Internet and about Internet systems that respond to connections you initiate. A firewall tracks inbound and outbound connections by port number instead of at the service or application level. For example, when you send email, the firewall asks you whether it should permit this connection. If you answer yes, the firewall transparently creates a rule to permit the connection from a specific application (e.g., Microsoft Outlook) to a specific destination through a specific port (e.g., SMTP port 25). Likewise, when you start an application that connects to the Internet, such as a Web browser or a streaming media player, the firewall prompts you to enable or disable the Internet connection for each application.

A firewall also prompts you in the reverse situation, when a remote application responds to a connection request, such as when you watch a streaming video from CNN or listen to a live broadcast of your favorite radio station. After a few days of prompts, the firewall creates a comprehensive set of rules to describe the typical usage patterns on your SOHO. Because you initiate and supervise these connections, you can easily set up rules that protect connection activity that originates from your SOHO.

Protection from unsolicited connections. The primary strength of a firewall is its ability to protect your systems from two forms of unsolicited connections—outbound connections you don't initiate and unsolicited incoming connections. Examples of outbound connections you don't initiate include Web bugs, viruses, and Trojan horses. If an HTML-based email message or a Web page contains a Web bug, you activate the associated Web bug script when you preview the message or browse the Web page. Web bugs forward information about your computer, OS, browser version, and browser history to, for example, a vendor's Web site, or they email text to an unknown destination without your knowledge—a new technique for surreptitiously collecting private information. A virus or Trojan horse on your system can initiate outbound connections to infect or invade other systems.

Most unsolicited inbound connections signal an attempt to snoop or intrude on your system. Examples of such connections include port scanners and Trojan horses, which attempt to invade by hammering on a specific TCP or UDP port number. Most firewall vendors include rules that turn away such attacks, but you might need to extend an existing rule or add a new one to fully cover access to TCP and UDP ports.

Selecting a Personal Firewall Package
Consider three evaluation criteria when you select a personal firewall: the ability to disable automatic rule creation—which I call "learn mode"—the ease with which you can monitor and evaluate intrusion attempts, and the ability to define custom rules.

Learn mode. If you want to understand exactly how a firewall works, select a product that lets you disable automatic rule creation. When you disable automatic rule creation, you must interact with the firewall every time you initiate an outbound connection as well as when your system detects an unsolicited inbound connection. You can permit or deny the connection based on the requesting (i.e., source) application or service, the port the service requests, the source system's TCP/IP address, the destination service, the destination port, and the destination TCP/IP address.

If you're prepared to sit through several days of learn mode, you'll find the continuous firewall prompts a great teaching tool. Whenever you start an application for the first time, the firewall prompts you to permit or deny the connection. To respond correctly, you must figure out which application caused the prompt and what it's trying to do. In the process, you learn to associate a protocol with a specific service or application, a specific port number, and an Internet destination address.

Figure 1 shows Symantec's Norton Personal Firewall in learn mode asking whether the firewall should permit an outbound connection that a Web bug initiated when I previewed an HTML-formatted email message. The Alert prompt has three options: configure a rule, block the connection one time, or permit the connection one time. I chose to block the connection one time to prevent the Web bug from sending personal information to the HTTP port at 213.34.225.82.

On several other occasions, the firewall prompted me to respond to an unsolicited inbound connection to sunrpc on TCP port 111. The first few times, I chose the block-one-time option, but after repeated connection attempts to this port, I decided to configure a rule to permanently block the connection attempts. When you choose the option to configure a rule, a friendly rule wizard guides you through the process of defining a rule. I constructed a rule to block any inbound connection to the sunrpc port from any service originating from any Internet address.

Intrusion detection and logging. Many firewalls maintain an event log of firewall activity. Some firewall products let you enable logging on a rule-by-rule basis, such as when an in-bound connection matches a specific rule (e.g., a well-known Trojan horse). Figure 2 shows an example of the Trojan horse rules that Symantec includes with Norton Personal Firewall. Each rule has a check box that you select to instruct the firewall to record an event when an incoming connection matches the rule.

The log maintains a history of surreptitious access attempts by date and time, source IP address, and port number. My log filled up weekly with a record of port scans and a variety of Trojan horse attacks. In theory, the log data provides enough information to identify the intruder's source address, as long as the attacker isn't spoofing the source address. With the log data, I can contact the ISP or site responsible for the incoming TCP/IP address to initiate corrective action. Further, an event log is a great sales tool for vendors—with such a long list of intrusion attempts, the firewall justifies and validates its existence.

When the firewall detects an intrusion, initially you'll want to know where the connection originated. Some packages, such as Zone Labs' ZoneAlarm, connect you to a Web site that translates the source IP address into a registered Internet domain name and provides an explanation of the access. Norton Personal Firewall logs the event in a pop-up window and lets you figure out the origin of the incoming connection. Figure 3 shows an excerpt from Symantec's event log to illustrate four common Trojan horse attacks: Stealth Spy, NetBus, Back-Orifice-2000-1, and Backdoor/SubSeven. As you can see in the log file, some Trojan horses probe all addresses on a subnet, and others restrict their access to one address. Port scans are a similar invasion in that they typically interrogate a well-known port number between 0 and 1024 on all systems on a subnet. If the firewall product that you select doesn't automatically translate the source TCP/IP address to a registered name, you can use a Web site (e.g., the Arin Whois database at http://www.arin.net/whois) that lets you manually cross-reference the incoming address with the registered domain name.

Defining custom rules. If your Internet machine serves as a Web, FTP, or mail server or if you're protecting a network instead of a single system, the ability to add custom rules to your personal firewall is essential. You can manually add rules, such as Win2K Active Directory (AD) Lightweight Directory Access Protocol (LDAP), that enable mail-server connections. You can also add any other rules that let your systems perform their duties securely. When you create a custom rule, you can apply the rule to one system, multiple systems, or all systems on a subnet—an easy method for protecting all SOHO systems, not just the Internet-connected machine.

Firewall rules are an arcane and exacting science that you master slowly, with practice and great attention to detail. However, here's an overview of how a rule works. In the simplest case, a personal firewall rule acts as a packet filter. Each rule has two parts—a source and a destination—and each part has an application or service, a protocol, and a TCP/IP address. When you enumerate the combinations, you see the parameters that Table 1, page 10, shows. You further refine each rule by specifying a direction for the connection (i.e., inbound or outbound) and whether you want to permit or deny the connection.

An FTP example illustrates the difference between a source application and a protocol. You can initiate an outbound FTP connection from several applications, such as Microsoft Internet Explorer (IE), a third-party browser, and a third-party FTP utility. All three applications require FTP, which makes FTP the common denominator. When you define a rule that permits any application to initiate outbound FTP connections, this one rule effectively controls all three applications. This method is easier and more efficient than creating three rules, each of which permits outbound FTP for one application.

Figure 4, page 10, illustrates how you define an outbound-FTP rule. Although different firewall packages express rules differently, the text in Figure 4 is an English-like equivalent that describes how you enable any source application to initiate an FTP connection to any destination application on any system on the Internet. Several situations exist in which you might want to further restrict the outbound-FTP rule. If you permit outbound FTP connections from only one system, you can restrict the out-bound connection to that system's TCP/IP address only. Likewise, if you trust only specific FTP destinations, you can instruct the outbound FTP rule to connect to only the TCP/IP addresses of the trusted systems (e.g., Web servers you maintain and update regularly).

Figure 5 illustrates the reverse situation, creating a rule to permit incoming FTP connections. To reduce exposure, you create more-restrictive rules for incoming connections than outgoing connections because the connection originates from an unknown source. Instead of permitting any application at any address on the Internet to initiate inbound FTP connections, you can restrict inbound connections to the TCP/IP addresses of systems you trust (e.g., systems that belong to business partners, branch offices, or vendors with whom you have an ongoing relationship). If you support inbound FTP service on only one of your SOHO systems, you can limit the inbound connection to that system's address.

Firewalls implement protection based on the order in which the rules appear in the list; therefore, you must organize the rules effectively. For the best protection and the fastest processing, place rules that deny access ahead of rules that permit access. If you select a firewall that supports custom-rule creation, consult the product documentation to ensure that you follow the vendor-specific guidelines.

The "After" Snapshot: Evaluating Your Exposure
I recommend downloading and installing two or three firewall packages so that you can compare their features. Use the Personal Firewall Guide Software page to help you find a firewall package that matches your technical acumen, the sophistication of your LAN, and the services that you support. After you make your final selection, install the firewall software and create the base set of firewall rules by running all the applications that access the Internet.

To verify that you've minimized or eliminated your system's exposure, return to the Gibson Research page (http://grc.com) I mentioned in "Secure Your SOHO, Part 1," and run the Test My Shields! and Probe My Ports! tests again. If you've followed the instructions in "Secure Your SOHO, Part 1" (i.e., eliminated NetBIOS exposure and reduced Win2K service exposure), your systems won't have any NetBIOS vulnerability. If you've installed a personal firewall, your port-level exposure will be either minimal or nonexistent. Your goal is to get as close as possible to the Probe My Ports! test results that Figure 6 shows. I ran this test after I installed the firewall and configured custom rules to control both outbound and inbound connections.

After watching the intrusion event log for a month, I'm amazed that my SOHO survived intact for so long. I discovered attempts to FTP into my system from systems in Asia and Europe, an attempt to set the time back to 1995 from a now-defunct Network Time Protocol (NTP) server, port scans, and Trojan horse intrusion attempts. I'm still learning which port supports what type of activity, but my confidence in my SOHO's security has grown immensely.