8.5 Firewalls

In motivating the need for security in Chapter 7, we noted that the Internet is not a very "safe" place - ne'er-do wells are "out there" breaking into networks at an alarming rate (For a summary of reported attacks, see the CERT Coordination Center [CERT 1999]; for a discussion of nearly 300 known attacks, that firewalls, the topic we consider here, are designed to thwart, see [Newman 1998]). As a result, network administrators must not only be concerned with keeping the bits flowing smoothly through their network, but also with securing their network infrastructure from outside threats.

We've seen that SNMPv3 provides authentication, encryption and access control in order to secure network management functions. While this is important (certainly, the network administrator does not want others to gain access to network management functionality), it is only a small part of the network administrator's security concerns. In addition to monitoring and controlling the components of one's network, a network administrator also wants to exclude unwanted traffic (i.e., intruders) from the managed network. This is where firewalls come in. A firewall is a combination of hardware and software that isolates an organization's internal network from the Internet at large, allowing specific connections to pass and blocking others. Organizations employ firewalls for one or more of the following reasons:

To prevent intruders from interfering with the daily operation of the internal network. An organization's competitor -- or just some Internet prankster looking for a good time -- can reek havoc on an unsecured network. In the denial-of-service attack, an intruder monopolizes a critical network resource, bring the internal network (at its network administrator) to its knees. An example of a denial of service attack is so-called SYN flooding, in which a the attacker sends forged TCP connection-establishment segments to a particular host. The host sets aside buffer for each connection, and within minutes there is no TCP buffer space left for "honest" TCP connections.
To prevent intruders from deleting or modifying information stored within the internal network. For example, an attacker can attempt to meddle with an organization's public presence on a Web server -- a successful attack may be seen by thousands of people in a matter of minutes. Attackers may also be able to obtain customer purchase card information from Web servers that provide Internet commerce (see Section 7.7).
To prevent intruders from obtaining secret information. Most organizations have secret information that is stored on computers. This information includes trade secrets, product development plans, marketing strategies, personal employee records, and financial analysis.

The simplest firewall consists of a packet filter. More sophisticated firewalls consist of combinations of packet filters and application gateways.

8.5.1 Packet Filtering

An organization typically has a router that connects its internal network to its ISP (and hence to the Internet). All traffic leaving and entering the internal network passes through this router. Most router manufacturers provide options for filtering; when these options are turned on, the router becomes a filter in addition to a router. As the name implies, a filter lets some datagrams pass through the router and filters out other datagrams. Filtering decisions are typically based on:

The IP address the data is (supposedly) coming from.
IP destination address.
TCP or UDP source and destination port.
ICMP message type.
Connection initialization datagrams using the TCP ACK bit.

As a simple example, a filter can be set to block all UDP segments and all Telnet connections. Such a configuration prevents outsiders from logging onto internal hosts using Telnet, insiders from logging onto external hosts using Telnet, and "weird" UDP traffic from entering or leaving the internal network. The router filters the UDP traffic by blocking all datagrams whose IP protocol field is set to 17 (corresponding to UDP); it filters all Telnet connections by blocking all TCP segments (each encapsulated in a datagram) whose source or destination port number is 23 (corresponding to Telnet). Filtering of UDP traffic is a popular policy for corporations -- causing much chagrin to leading audio and video streaming vendors, whose products stream over UDP in the default mode. Filtering Telnet connections is also popular, as it prevents outside intruders from logging onto internal machines.

A filtering policy can also be based on the combination of addresses and port numbers. For example, the router can forward all Telnet packets (port 23) except those going to and coming from a list of specific IP addresses. This policy permits Telnet connections to and from hosts on the list. It is highly recommended to reject all datagrams that have internal source IP addresses -- i.e., packets that claim to be coming from internal hosts but are actually coming in from the outside. These packets are part of address spoofing attacks, whereby the attacker is pretending to be coming from an internal machine. Unfortunately, basing the policy on external addresses provides no protection from an external host claiming to be a different external host.

Filtering can also be based on whether or not the TCP ACK bit is set. This trick is quite useful if an organization wants to let its internal clients connect to external servers, but wants to prevent external clients from connecting to internal servers. Recall from Section 3.4 that the first segment in every TCP connection has the ACK bit set to 0 whereas all the other segments in the connection have the ACK bit set to 1. Thus, if an organization wants to prevent external clients from initiating connections to internal servers, it simply filters all incoming segments with the ACK bit set to 0. This policy kills all TCP connections originating from the outside, but permits connections originating internally.

Now suppose an organization doesn't want to block all connections originating from outside; instead it just wants to block only the Telnet connections originating from outside. How can filtering accomplish this task? To see how filters handle this, let's look at how the fields are set for Telnet connections originating internally and Telnet connections originating externally (Table 8.5.1):

Connection
Origination Packet Direction Source IP
Address Destination
IP Address Source
Port Destination
Port

Internal Outbound Internal External p 23

Internal Inbound External Internal 23 p

External Inbound External Internal q 23

External Outbound Internal External 23 q

Table 8.5-1: Header fields for inbound and outbound Telnet connections

The p and q in the above table are the port numbers (> 1023) assigned to the client machines (see Section 3.1). From this chart we see that the filter can block Telnet connections originating from outside by blocking inbound packets (external source address and internal destination address) with destination port 23; or by blocking outbound packets (internal source address and external destination address) with source port 23.

8.5.2 Application Gateways

Filters allow an organization to perform coarse-grain filtering on IP and TCP/UDP headers, including IP addresses, port numbers and acknowledgment bits. For example, filtering based on a combination of IP addresses and port numbers can allow internal clients to Telnet outside while preventing external clients from Telneting inside. But what if an organization wants to provide the Telnet service to a restricted set of internal users? Such a task is beyond the capabilities of a filter. Indeed, information about the identity of the internal users is not included in the IP/TCP/UDP headers, but is instead in the application-layer data.

In order to have a finer level security, firewalls must combine packet filters with application gateways. Application gateways look beyond the IP/TCP/UDP headers and actually make policy decisions based on application data. An application gateway is an application-specific server through which all application data (inbound and outbound) must pass. Multiple application gateways can run on the same host, but each gateway is a separate server with its own processes.

To get some insight into application gateways, let us design a firewall that allows only a restricted set of internal users to Telnet outside and prevents all external clients from Telneting inside. Such a policy can be accomplished by implementing a combination of a packet filter (in a router) and a Telnet application gateway, as shown in Figure 8.5-1. The filter is configured to block all Telnet connections except those that originate form the IP address of the application gateway. Such a filter configuration forces all outbound Telnet connections to pass through the application gateway. When a internal user wants to Telnet to the the outside world, it first sets up a Telnet session with the gateway. The gateway prompts the user for its user id and password; when the user supplies this information, the gateway checks to see if the user has permission to Telnet to the outside world. If not, the gateway terminates the Telnet session. If the user has permission, then the gateway (1) prompts the user for the hostname of the external host to which the user wants to connect, (2) sets up a Telnet session between the gateway and the external host, (3) relays to the external host all data arriving from the user, and relays to the user all data arriving from the external host. Thus the Telnet application gateway not only performs user authorization but also acts as a Telnet server and a Telnet client. Note that the filter will permit step (2) because the application gateway initiates the Telnet connection.

Figure 8.5-1: Firewall consisting of an application gateway and a filter.

Internal networks often have multiple application gateways, for example, gateways for Telnet, HTTP, FTP and e-mail. In fact, an organization's mail server (see Section 2.4) and Web cache (see Section 2.9) are application gateways.

Application gateways do not come without their disadvantages. First, you need a different application gateway for each application, which requires installing and configuring a new server for each application. Second, either:

the client software must know how to contact the gateway instead of the external server when the user makes a request, and must know how to tell the gateway what external server to connect to;
or the user must explicitly connect to the external server through the gateway.

We conclude this section by mentioning that firewalls are by no means a panacea for all security problems. They introduce a tradeoff between the degree of communication with the outside world and level of security. Because filters can't stop spoofing of IP addresses and port numbers, filters often use an all or nothing policy (for example, banning all UDP traffic). Gateways can have software bugs, allowing attackers to penetrate them. Also, firewalls or even less effective if the internal users have wireless communication with the external world. For these reasons and others, firewalls remain controversial, with many security experts and network administrators being reluctant to use them.

References

Two excellent references are [Chapman 1995][Cheswick 1994]. Readers are also encouraged to read white papers in the Web sites for major manufacturers of firewalls (e.g., [Checkpoint 1999]).

[Cert 1999] CERT, "CERT Summaries," http://www.cert.org/summaries/
[Chapman 1995] D.E. Chapman and E.D. Zwicky, "Building Internet Firewalls," O'Reilly and Associates, Sebastopol, CA, 1995
[Cheswick 1994] W.R. Cheswick and S. M. Bellovin, "Firewalls and Internet Security," Addison-Wesley, Reading, MA, 1994.
[Checkpoint 1999] Checkpoint Software Technologies Ltd. homepage, http://www.checkpoint.com
[Newman 1998] D. Newman, H. Holzbar, M. Carter, "Firewalls: Tough Enough", Data Communications Magazine, April, 1998.

Connection Origination	Packet Direction	Source IP Address	Destination IP Address	Source Port	Destination Port
Internal	Outbound	Internal	External	p	23
Internal	Inbound	External	Internal	23	p
External	Inbound	External	Internal	q	23
External	Outbound	Internal	External	23	q