Table of Contents
Previous Section Next Section

14.3. Firewall Protection

There are three basic kinds of firewalls: stateful, nonstateful, and proxy4. Stateful firewall solutions, as the name implies, track the state of network traffic (such as connections) and compare it against a policy. Some stateful firewalls, such as Cisco PIX, also can inspect some application-level protocols to see whether only regular commands are used on some known protocols, such as SMTP. If your SMTP server receives non-SMTP commands, the firewall will pretend to the sender that the bogus commands were accepted.

Nonstateful firewalls do not keep track of connections and thus are unable to correlate protocol information.

Proxy firewalls are closer to the actual protocols and can provide better security because they are more application-context-specific. Firewall implementations can vary according to the specific needs of each corporation and individual.

Firewalls can prevent worm infections and other attacks on your network in a number of ways. Typically, the most effective firewall feature against worms is simply to use your firewall to block any ports that you do not need to use on the systems behind it. You also can control the flow that goes back outside of your network. Corporations often allow their Web servers to initiate port 80/tcp access. This is not a good practice, however, for a number of reasons. You do not want to let your Web servers become Web browsers. If you do, a worm such as CodeRed might get into your network, and it will also be able to leave on port 80, as it came in. Select a firewall that allows you to control such flow, controlling the situation both ways.

Be sure to prepare your firewall in advance and maintain it continuously. By maintenance I don't mean blocking a port each time a worm targets a new port, but changing the firewall according to your changing requirements.

Table 14.1 illustrates some infamous worms that can be denied access by simply blocking ports on one of your firewalls (making sure not to block any ports that are used by actual services behind the firewall).

Table 14.1. In-the-Wild Worms, Related Vulnerabilities, and Ports to Block

Name of Threat

Exploited Vulnerabilities

Ports to Block

W32/CodeRed worm

MS01-033 ("IIS")

TCP 80

W32/Blaster worm

MS03-026 ("RPC/DCOM")

TCP 135, TCP 4444 (and if not used UDP 69)

W32/Slammer worm

MS02-039 and MS02-061 ("MS-SQL")

UDP 1434

W32/Sasser worm

MS04-011 ("LSASS")

TCP 445, 5554, and 9996

W32/Dabber worm

Exploits vulnerability in "FTP Server" of the Sasser worm

TCP 5554 (Sasser)

TCP 8967, 9898-9999

W32/Korgo worm

MS04-011 ("LSASS")

TCP 445, 113, 3067-3076, and 6667

W32/Welchia worm

MS03-026 ("RPC/DCOM")

MS03-007 ("WebDav")

TCP 135 and TCP 80 when not used

W32/Welchia.D worm

MS03-026 ("RPC/DCOM")

MS03-007 ("WebDav")

MS03-049 ("Workstation")

MS03-001 ("Locator")

+Mydoom backdoor

TCP 80, 135, 445 (when not used)

TCP 3127 (Mydoom)

Linux/Slapper worm


OpenSSL vulnerability

TCP 80, 443, and UDP 2002

W32/Witty worm

ISSSA ICQ parsing vulnerability

Source port UDP 4000

Another common pitfall is when corporations rely on a single perimeter firewall on their network. Such protection might be bypassed in a number of ways by computer worms and other malicious attacks. For example, an infected home system will easily tunnel the infection in your network via a VPN (virtual private network) connection. It is imperative to use personal firewalls on workstations; once the attack is inside, it will have less chance to blow up internally. Personal firewalls can control malicious ICMP traffic and network sharing, just to name a few.

As you can see in the preceding examples, most attacks can be blocked by denying access to certain destination network ports; however, the Witty worm demonstrated that in some cases, port blocking might need to be done on the source port because the actual vulnerability in BlackIce can be exploited via any destination port. Witty also demonstrates very clearly that firewalls with vulnerabilities are increasingly becoming a target for attackers (in fact, exploitable vulnerabilities have been found in several Firewall implementations). Thus firewall software is just as likely to be exploitable as any other software, so it is mandatory to implement patches for it.

A proxy-based firewall, such as Raptor, can reduce a CodeRed worm attack to a minor DoS attack against the vulnerable IIS server. This is because an appropriately configured firewall cuts the request body of a GET request (and the worm), given that it is not valid in GET requests. (But, well, what if the attacker is using a POST request?)

It is of vital importance to use personal firewalls on workstations to prevent worm, backdoor, and spyware attacks. After a computer worm is running on your system, however, it might have the opportunity to kill your personal firewall software with a retro attackreducing your protection. This is why the combination of appropriate protections is crucial.

Another increasingly common risk of personal firewalls is a backdoor that implements an HTTP tunneling attack. When such a backdoor is executed on a target system (for instance, via a downloader kit that exploits a Web browser vulnerability as you surf the Web), the backdoor might inject code into the process address space of your browser.

In their normal operations, personal firewalls alert on network access, so each time you run your Web browser, you get an alert from your personal firewall. It is a common option to allow a particular application to proceed with a default option set by the user. The danger in this is that the registered, legitimate Web browser application will be allowed to communicate with the network after this option has been selected, and an HTTP tunneling backdoor could easily inject code into the already registered application. This would allow the backdoor to use the privileges of the Web browser to tunnel information back to an attacker without any notification from your personal firewall. For that reason, modern personal firewalls must protect themselves from such attacks, which are possible in a number of different ways.

As with all security solutions, firewalls come with a performance penalty. Although stateful firewalls typically have better performance, they do not have the ability to deal with all application-level security concerns, which proxy firewalls can provide with a little slower performance. Unfortunately proxy firewalls are typically more susceptible to vulnerabilities caused by the introduced complexity of protocol parsing in which most vulnerability resides. This is a general problem for network-intrusion detection systems as well, however, which are discussed in the next section.

    Table of Contents
    Previous Section Next Section