By the late 1980s, the internet was a very busy international network, with thousands of private and commercial users, as well as government and educational ones. This yielded a major shift in the assets visible on the internet. Numerous incidents illustrated its vulnerability and its promise. For careful sites, this led to major shifts in internet policy. The policy issues revolved around the following two questions:

1. How do our employees use the internet to get their jobs done?

2. What services do we offer to internet users that aid us in achieving our enterprise objectives?

Some organizations essentially unplugged themselves from the internet, concluding that it served no business purpose. More often, a site might retain email service and block most other services, except perhaps to selected research and development groups. Other organizations took a more selective approach, allowing email and perhaps web surfing, and blocking less-essential activities like ping and the troublesome “finger” service.

As internet services evolved, especially the World Wide Web, so did the problems and concerns of internet-connected sites. The web provided access to vast quantities of important and useful information, but it also provided a trove of entertainments and distractions. Some organizations tried to restrict or control the sites that users visited through various filtering and monitoring techniques. (See Section 15.2.) The evolution of spam and email viruses also encouraged enterprises to take extra steps in filtering internet traffic.

Let’s develop a simple policy for the Amalgamated Widget enterprise network. The enterprise has a website, and it exchanges email with a few other internet sites. In order to avoid spam, the MTA accepts only email that is forwarded from its ISP and from the local university. Here’s a list of risks that Amalgamated, in particular, may avoid through close management of its internet connection:

1. Attacks on its internal file servers from hackers on the internet

2. Commercial embarrassment of not having a company website

3. Poor customer communication without ease of having email

4. Poor email service, as a result of spam

5. Ineffective marketing, purchasing, and R&D staff caused by a lack of internet browser access

These risks yield the internet access policy shown in TABLE 14.2.

We implement this policy by controlling internet traffic as it enters and leaves the site. Because all traffic goes through the site gateway, the gateway must implement the controls.

Packet filtering was used on the earliest Ethernet LANs in the 1970s, partly to distinguish a host’s incoming traffic from the rest of the LAN activity. We filter packets one at a time. We look at the fields of each packet individually and either accept or reject the packet based on its contents (FIGURE 14.11).

The firewall may enforce host control, service control, and some degree of content control using a packet filter. The IP header identifies source and destination hosts, and the port number identifies the service being performed. Many sites filter traffic to allow DNS, SMTP, and the Hypertext Transfer Protocol (HTTP) used for web traffic, as well as to reject most other services. Content control is limited to data that is visible in a single packet; packet filtering won’t detect unauthorized content that spans multiple packets. Many firewalls ignore the link header because the header would have been replaced if the packet passed through a router.

In session filtering, we keep track of packets exchanged between pairs of sockets, that is, between a pair of hosts using a particular pair of port numbers (FIGURE 14.12). Some implementations perform “circuit filtering” in which the firewall creates a proxy TCP connection to carry the packets through the firewall. Circuit filters make the filtering decision when establishing the connection; if the filter accepts the connection, then all of its data will pass through the firewall. It’s easy to filter on the connection’s direction, because the firewall receives and processes the three-way handshake that opens the connection.

Other firewalls implement session filtering with a stateful packet filter that maintains connection and session state information, instead of actually establishing a connection through the firewall. Stateful filtering bases its decisions on state information developed from previously received packets. The firewall uses this information to make filtering decisions on subsequent packets. In practice, a stateful filter behaves the same as a circuit filter when handling connections: It will allow traffic to flow if it allows the connection to open.

For example, we have a firewall that blocks incoming connections and only allows its clients to open outbound connections to internet hosts. Here’s how the stateful filter might handle a TCP connection:

• ■   A packet from an internal host arrives at the firewall with its SYN flag set. The filter allows this connection, so it will forward all of its packets after examining them. The filter records the socket information (IP addresses and port numbers) and notes that the socket’s session is opening.

• ■   A packet arrives from the internet for that socket with its SYN and ACK flags set. The filter notes that the session is almost open.

• ■   A packet arrives from the internal host on that socket with its ACK flag set. The filter notes that the socket’s session is fully open.

• ■   When subsequent packets arrive in either direction for that session, the filter lets them pass.

• ■   A packet arrives on that socket’s session with the FIN flag set. The filter notes that the session is closing.

• ■   More packets are exchanged to close the connection. The filter discards the session.

• ■   If additional packets arrive from the internet after the session is closed, the filter discards those packets. They do not belong to an open session.

A benefit of stateful filtering is that it handles UDP traffic as well as TCP traffic. Because UDP has no notion of a connection, the firewall must infer the session relationship based on the UDP traffic.

In application filtering, the gateway examines the data in application-layer elements when deciding to let data pass (FIGURE 14.13).

The simplest form is the application proxy, a small firewall software component that applies relatively simple tests to smaller application data items. For example, a proxy can apply a blacklist to web URLs or to servers accessed via the file transfer protocol (FTP).

Proxies also provide an effective way to pass complicated protocols through the firewall; FTP, for example, negotiates the port numbers to use for its data connection. An FTP proxy allows the firewall to pass FTP service through while keeping unnecessary FTP ports disabled.

Firewall proxies can easily filter application data that fits into one or two packets. This approach does not allow filtering of arbitrarily large email messages that may contain arbitrarily large attachments. We perform such operations by redirecting the data to a special process that collects the entire message and analyzes it.

Firewalls often redirect all email to a special MTA that handles inbound email. The MTA applies spam and virus filtering software like SpamAssassin (Section 14.3.1) and IronPort (Figure 14.5). All incoming email arrives at the filtering MTA, which filters the email and then forwards it to another MTA for delivery inside the site.

Our example is based on the security policy that Amalgamated Widget uses, shown in Table 14.2. The example makes certain assumptions about Amalgamated Widget’s enterprise network. We assume that the network has been assigned a block of global internet addresses in the range 30.40.*.*. In other words, the site may assign any internet address whose upper half contains 30.40 and may use the lower 16 bits for individual host addresses. This allows Amalgamated to assign a global internet address to every one of its hosts. It does not have to use NAT and private addresses. The firewall security controls in TABLE 14.4 enforce the Amalgamated policy.

TABLE 14.4 Firewall Controls to Enforce Amalgamated’s Internet Policy

When a packet arrives, the firewall applies the rules in order. If the packet, or its connection, matches one of the rules, the firewall applies the rule. If the rule allows the traffic, the firewall delivers the packet. If the rule denies the traffic, the firewall discards the packet.

This particular firewall implements Deny by Default and then applies the rules in the table. If the firewall does not implement Deny by Default and our policy requires Deny by Default, then the final firewall rule should deny any remaining connections.

Rules 1 and 2 allow DNS packets to enter and leave the site. Standard internet protocols won’t work without DNS. The first rule allows internet sites to visit the amawig DNS server. The second rule allows any host on the enterprise network to visit any DNS server on the internet.

Rules 3, 4, and 5 allow email connections between the amawig MTA and other MTAs. Rules 3 and 4 allow the two approved MTAs to connect to the amawig server. Rule 5 allows the amawig MTA to connect to any other MTA. Clients on the enterprise LAN must connect to their own MTA to send email; the firewall doesn’t allow access to other MTAs except by the enterprise MTA. In practice, the MTA itself may be configured to talk only to those other two MTAs. We could tighten security by restricting its connections to the other two MTAs.

The next three rules allow outbound HTTP for the three favored groups. The IP addresses with subnets 50, 60, and 70 (the third byte of each address) correspond to host addresses for the three groups allowed to surf the internet.

The final rule grants internet visitors access to the enterprise website. Note that neither inbound nor outbound rules permit SSL connections. These require additional rules.

The previous discussion notes a few specific cases for which we could improve the rule set by adding rules. Notably, no one can surf the web with SSL. In fact, the sample rule set here falls far short of providing typical internet access, even to the privileged groups. There is no FTP support or access to remote mailboxes via POP3 or IMAP. The firewall also blocks all routing and network management protocols, which may make it difficult for the enterprise to interact with the rest of the internet.

On the positive side, the rule set implements Deny by Default. The firewall should not allow traffic that we haven’t specifically allowed. This also means that we must add rules piecemeal that grant access for every internet application protocol we need to allow. Thus, we add rules as we add capabilities for our users.

It is challenging to manage a firewall rule set. Smaller sites may require only a few—or a few dozen—firewall rules. Larger and more complex sites require a larger and more complex rule set. To some extent, the number of rules depends on the size of the site and the arrangement of its point of presence (See Section 14.5). It also depends on the firewall design itself; some firewall models may describe a complex policy requirement in a single rule, while other models may require several rules to express the same restriction.

In practice, firewall rule sets may range in size from a handful to tens of thousands. Many enterprise firewalls carry 200 or fewer rules, while many others carry a thousand or more. Firewalls that support hundreds of users typically have a couple of thousand rules; the largest sites may have tens of thousands of rules.

Firewall rule sets pose an administrative challenge. The system administrators must be able to change rules reliably in response to changes in network organization or changes in security policies. Effective changes must not open vulnerabilities or block needed services.