Host-Based Firewalls

The firewalls we have been discussing in this book so far are network based. We placed them on the borders between subnets to regulate how network traffic crosses from one segment to another. Similar processes can be applied at the host level to control how packets enter and leave the system that the host-based firewall is protecting.

Most host-based firewalls enforce access policies bidirectionally by monitoring packets that enter and leave the system. Controlling network access at the host level is effective, whether the host is located behind layers of traffic-screening devices or is directly connected to the Internet. Host-based firewalls reinforce the system's defenses by addressing threats that antivirus products don't cover:

• Unrestricted access to the system's file shares

• Anonymous access to the system

• Undetected malicious code

• Port scans and other types of reconnaissance probes

• Vulnerable network services running on the system

Host-based firewalls are often referred to as personal firewalls because they aim to protect individual systems instead of whole networks. We would like to use the term personal firewall solely when discussing traffic-screening functionality on workstations. Although such software can be installed on servers, referring to it as "personal" might be misleading because server systems are rarely used just for personal computing.

In this section, we examine a number of popular host-based firewall software choices, some of which are available for free. To help you plan and deploy appropriate host-level defenses, we discuss the capabilities of firewalls that are optimized to run on workstations and compare them to the features of products that are more suited to protect individual servers.

Firewalls for Workstations

Host-based firewalls are often geared to run on workstations and are particularly critical for roaming laptops that do not always enjoy the protection of network firewalls and other network-based security controls. The number of products that fit into the category of such personal firewalls has been increasing, and in this section, we discuss only a few of them to illustrate important concepts. Some of the more popular products in this sector are listed next:

• ZoneAlarm (http://www.zonelabs.com/)

• Tiny Firewall (http://www.tinysoftware.com/)

• Norton Personal Firewall (http://www.symantec.com/)

• Sygate Personal Firewall Pro (http://www.sygate.com/)

• Windows Firewall (http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfintro.mspx)

Many of these products are inexpensive, and ZoneAlarm is available free of charge for personal use. Also, Windows Firewall is provided as part of Windows XP starting with Service Pack 2. (Earlier versions of Windows XP offer the Internet Connection Firewall, which lacks many of the features of Windows Firewall.) Many other products provide host-based firewall functionality for the workstation. Some of these can be used on servers as well. For example, firewall functionality is often combined with host-based intrusion detection systems (IDSs), which we discuss in the "Host-Based Intrusion Detection" section of this chapter.

Most personal firewalls that run on Windows-based workstations are capable of imposing access restrictions based on the local application attempting to send or receive packets. Before an application is allowed to connect to another host, or before the application is allowed to accept a network connection from another host, the personal firewall must consult its rule set to determine whether access should be granted. Figure 10.1 shows an excerpt of the application rule configuration for Norton Personal Firewall. By default, the firewall uses the vendor's knowledge of applications to determine which actions should be permitted or denied. You may also override the default settings by manually setting the appropriate action for each application. As Figure 10.1 shows, the alternatives are to permit all, block all, or create custom settings.

Figure 10.1. Norton Personal Firewall allows users to define permitted and denied activity for specific applications.

In addition to application-specific rules, many personal firewalls also allow you to define access restrictions using the same parameters as traditional network firewalls: protocol, destination IP, and port number. Figure 10.2 shows an excerpt of the default general rule set for Norton Personal Firewall, which includes dozens of types of network traffic. Note that each rule permits you to specify which network interfaces it applies to, and whether the rule should apply to inbound and/or outbound traffic.

Figure 10.2. Norton Personal Firewall offers a default set of filter rules for network and application protocols.

Others products, such as ZoneAlarm Pro, take a different approach that might not be as intuitive for firewall administrators, but are aimed at simplifying firewall configuration for less tech-savvy users. As you can see in Figure 10.3, ZoneAlarm Pro allows users to group external systems into those that are trusted and those that are not. Each of the two zones can have its own set of access restrictions, which are applied depending on the remote host's category. For example, you can allow file and print protocols such as NetBIOS/SMB going to, and possibly from, systems in the Trusted zone. By placing the internal subnet into the Trusted zone, you allow the workstation to connect to Windows-based file and print services on the internal network. Other networks would be placed in the Internet zone, which is generally much more restrictive and does not allow NetBIOS connections.

Figure 10.3. ZoneAlarm Pro groups network resources into two zones, depending on how trustworthy the resources are.

Most personal firewalls ship with a default rule set that improves the security of the workstation compared to its state without a firewall, but is still overly permissive. We suggest customizing the default firewall policy by backing it up and then clearing the original rule set. Personal firewalls that do not have a rule set usually default to prompting the user for every new communication attempt to or from the host. Figure 10.4 shows such a prompt as presented by Norton Personal Firewall, asking whether Mozilla Firefox should be allowed to access the Internet. This allows you to build the rule set by letting the firewall "remember" your responses to communication attempts. When going through the initial "learning" period, you might become frustrated by a seemingly unending stream of questions regarding applications that seem to want to initiate network connections. Don't worry; the rule set tends to reach a stable state after a couple of days.

Figure 10.4. Norton Personal Firewall can be configured to prompt the user if an unfamiliar application attempts to initiate a network connection.

Keep in mind that although you might be willing to answer the firewall's questions while it "gets to know" your system, other users at your organization might not be as patient or might not know how to answer some of the firewall's questions. Incorrect answers could inadvertently block legitimate activity or allow unauthorized activity to pass through the firewall. This is a major obstacle to the adoption of host-based firewalls by the general population of users. As we discuss in the section "Controlling Distributed Host Defense Components" at the end of this chapter, personal firewall vendors offer software that centralizes the creation and distribution of the firewall policy across the organization's workstations. Deploying host-based firewalls on servers is not as dependent on the product's user friendliness and carries its own set of advantages and challenges.

Firewalls for Servers

Host-based firewalls are also effective at helping to protect individual servers; they function similarly to firewalls that run on workstations. Although servers are often located behind traffic-screening devices, the critical nature of their data and services might warrant this additional layer of protection that does not usually come at a large expense. Host-based firewalls are also useful for protecting servers that cannot be located on a screened subnet or a DMZ, or that are at an increased risk of insider attacks. In many cases, the same software used to protect workstations could be used for servers. The major differences in requirements between firewalls for workstations and for servers are as follows:

• The performance impact of installing the host-based firewall is more critical for servers. Network latency is generally not as high of a concern on a workstation as it is on a server.

• The need to focus on inbound connections to the system is more critical for servers. Outbound connections made by servers are usually not as unpredictable as those exhibited by workstation users; in fact, many servers only initiate outbound connections for standard maintenance activities, such as downloading patches. Accordingly, it is typically much simpler to control outbound activity for servers on a per-application basis than workstations.

• The need to eliminate interactions between the firewall software and the system's user is more critical for servers. Host-based firewalls installed on servers cannot be expected to prompt the user with rule set questions or alerts because most of the time, no one is logged in to the server locally to answer the questions.

Because you have already seen host-based firewalls that are optimized to protect workstations, this section examines products that address server-specific requirements. Instead of focusing on protecting whole networks, host-based firewalls are tuned to provide protection for a single system. This section provides two examples of methods to protect individual servers: the PF firewall and packet filtering via IPSec on Windows.

As you may recall, in Chapter 9 we mentioned TCP Wrappers as one of the tools used for controlling inbound connections to individual systems. TCP Wrappers is an effective way to control access to the server's network services, especially those that were started through inetd. However, TCP Wrappers lacks some of the features available in full-fledged firewalls that we can install on the network as well as on a host. One such "true" firewall, which we discuss next, is PF. It is available for free and runs on numerous UNIX platforms.

PF

In Chapter 3, "Stateful Firewalls," we discussed IPTables, which is a stateful firewall designed for Linux hosts. Many BSD systems use a firewall with similar capabilities called PF (http://www.openbsd.org/faq/pf/). PF is an excellent firewall for protecting whole networks, as well as individual hosts. The syntax of PF is based on another popular firewall, IPFilter. Let us see how to use PF for implementing some of the tasks typical for host-centric firewalls that run on servers.

PF obtains its rule set from a plain-text configuration file, pf.conf. By default, PF reads through all entries in the file before making a final decision about whether to block a packet. This differs from the default behavior of most firewalls we encountered, which stop processing the rule set after locating the first rule applicable to the packet in question. To force PF to stop iterating through the rule set as soon as it makes a match, we need to use the quick keyword in the rule's definition. For example, when a system receives an undesired attempt to initiate an SMTP connection, PF stops processing the rule set after encountering the following rule:

 block in quick proto tcp from any to any port 25 

Like most modern firewall packages, PF is a stateful firewall. It can monitor the state of TCP sessions and, to a limited extent, the "state" of UDP and ICMP connections. Use the keep state keyword in the rule to specify that PF should keep track of a session's state. For example, when running PF on a web server, you could use the following statements to allow inbound HTTP and HTTPS traffic in a stateful manner:

 pass in quick on fxp0 proto tcp from any to host.ip.addr port = 80 keep state pass in quick on fxp0 proto tcp from any to host.ip.addr port = 443 keep state 

In this case, fxp0 is the server's NIC where inbound requests will be originating, and host.ip.addr represents the web server's IP address. Of course, these web server rules assume that at the end of the rule set, you have specified the following rule, which blocks (and probably logs) all traffic that has not matched any other rule in the policy:

 block in quick on fxp0 log all 

We can fine-tune HTTP and HTTPS rules presented previously by ensuring that PF creates a state table entry only for TCP packets that have a SYN flag set. Packets with any other TCP flags should not be allowed to initiate a connection, and they could constitute attempts to mangle the system's state table. To account for such packets, we would use the flags keyword like this:

 pass in quick on fxp0 proto tcp from any to host.ip.addr port = 80 flags S keep state pass in quick on fxp0 proto tcp from any to host.ip.addr port = 443 flags S keep state 

If PF isconfigured to block and log all inbound packets that are not explicitly allowed, then the preceding web server rules can help detect port scans against the server that manipulate TCP flags in an attempt to avoid detection.

Note

PF offers "scrub" capabilities, which means that it can reassemble packet fragments and perform sanity checks on certain aspects of packets to identify anomalous ones. For more information on PF scrubbing, see the documentation at http://www.openbsd.org/faq/pf/scrub.html.

Even though UDP packet exchanges are effectively stateless, a UDP request is expected to have a reply with inverse port and IP address parameters. This can allow PF to offer basic stateful protection for UDP packets that are targeting a DNS server:

 pass in quick on fxp0 proto udp from any to host.ip.addr port = 53 keep state 

To control outbound connections made by the server, you could use the following rule, which blocks and logs outbound traffic that has not been explicitly allowed:

 block out log quick on fxp0 all 

Because inbound traffic is controlled through the use of stateful rules, it is wise to keep outbound connections made by the server to a minimum. This is more challenging on a workstation, which tends to make outbound connections much more often than it accepts inbound traffic. As a result, host-based firewalls that are optimized for workstation usage generally pay more attention to offering a granular and user-friendly approach to controlling outbound connections.

Responding to Ident Requests

By default, when blocking a connection, PF does not return a response to the sender to let it know that the packet was not allowed through. As mentioned in Chapter 3, this behavior is often advantageous for defending the system against reconnaissance probes. In some cases, however, lack of a response from your server might introduce delays as the peer's system waits for the timeout or attempts to re-send the packet. For example, if your server is configured to send outbound email, the recipient's mail server might try to connect back to your ident daemon in an attempt to confirm the identity of the user who is connecting from your system. If your server is hardened, it is probably not running the ident daemon and blocks all packets destined to ident's port 113. However, the delivery of your outbound email is likely to be suspended until the recipient's mail server's ident request times out.

To speed up this process, you could configure your server to respond with a TCP RST packet to all connection attempts to ident's TCP port, or with an ICMP "port-unreachable" packet to its UDP port. (UDP connections rely on ICMP for the equivalent of a TCP RST.) The following PF rules cause your server to block connections to TCP and UDP port 113 and respond with an appropriate "error" packet:

[View full width]
 block return-rst in quick on fxp0 proto tcp from any to host.ip .addr port = 113 block in quick on fxp0 return-icmp(port-unr) proto udp from any  to host.ip.addr port = 113 

PF is effective at protecting networks when it is installed on a gateway system. When installed on an individual server, it offers robust protection against network-based attacks that target the individual host. This can also be said for other UNIX firewalls in PF's class, such as IPTables, which we covered in Chapter 3.

We have numerous choices when it comes to installing firewalls on servers. We can use products marketed for use on workstations, as well as software that is not as user friendly and is catered more toward the needs of a server. As the last mechanism in the discussion of host-based firewalls for servers, let's examine an inexpensive way of achieving packet-filtering functionality on Windows servers through the use of IPSec policies.

Packet Filtering via IPSec on Windows

One of the most powerful network security components built in to Windows servers is IPSec. In Chapter 7, "Virtual Private Networks," we described how to use IPSec to secure communications between remote systems. We used the Microsoft Management Console (MMC) to define IPSec policies on VPN endpoints. IPSec policies can also be configured to filter out unwanted network traffic that is targeting the Windows server. Built-in packet-filtering capabilities allow us to specify which local ports can be accessed without authentication and encryption, which should be limited to valid Authentication Header (AH) or Encapsulating Security Payload (ESP) peers, and which should be blocked altogether. This technique allows us to mimic basic functionality offered by many host-based firewalls for servers, without deploying additional products.

For example, we can use built-in IPSec filtering capabilities to permit administrative traffic from authenticated remote systems. We could create a new IPSec rule that accepts ESP-protected administration traffic from specific hosts. If worried about the added load on the server, we could use AH instead of ESP to remotely authenticate the host without encrypting the administrative traffic. Of course, we would need to configure IPSec policies on administrative workstations to match IPSec connection parameters on the hardened server. Environments that have deployed Active Directory can use Group Policy to centrally distribute IPSec policies, avoiding the time-consuming and error-prone process of manually configuring policies on numerous systems.

Tip

Remotely administrating a Windows-based bastion host is often a challenge because it frequently opens the server to attacks on native Windows protocols. One of the ways to address such concerns is to configure the Windows server to block all administrative connections that are not secured with ESP. This provides an easy way to tunnel traffic across the firewall without using native and potentially vulnerable Windows protocols if the server is located on a screened subnet.

IPSec-based filtering is based on basic packet filtering, and accordingly it is prone to similar limitations as other non-stateful traffic-filtering devices that we described in Chapter 2, "Packet Filtering." IPSec-based filtering should not be used as the only firewall protection for a system; instead, it can best be used to add an extra layer of defense to Windows servers with relative ease.

So far, we have discussed two primary defense components that we can use to reinforce the security of individual systems: antivirus software and host-based firewalls. As we have shown, each component category, as well as each tool within the categories, is optimized for different environments and is best at mitigating different risks. In the next section, we examine host-based IDS products, which are optimized for detecting and investigating malicious behavior on the host.