| Each network packet handled by a Linux computer passes a number of distinctive points within the network implementation on its way through the Linux kernel before it either is delivered to a local process or leaves the computer for further routing. Direct access to the packet stream in the kernel opens up a large number of ways to manipulate packets, which are also suitable for implementing a security strategy in the network. For example, functions were built into the routing code early in the course of the Linux development. These functions allow the system administrator to influence how packets are handled, depending on their source and destination addresses. In addition to the pure filtering function, which lets you drop certain packets completely, this also includes more complex manipulations, including address-conversion mechanisms (Network Address Translation NAT) or the support of transparent proxies. After its introduction in the form of ipfwadm in Linux Version 1.2, this packet-filter code later underwent two complete revisions to ensure better manageability, extension of the control options, and better integration of additional functionality (e.g., NAT). This chapter discusses the differences between the packet-filter architecture of the current Linux Version 2.4 and that of the previous Linux Version 2.2. 19.1.1 The Functional Principle of a Firewall In its original meaning, the term firewall denotes a fire-resistant wall constructed to prevent the spread of fire. In connection with computer networks, a firewall is a protection mechanism used in a specific and exactly limited network (e.g., a corporate intranet) at a transition point from a neighboring network (generally to the Internet) to protect the intranet against dangers from the outside. A firewall consists normally of two types of components: Packet filters are normally implemented in routers and monitor the entire network traffic flowing through these routers. These routers use a well-defined set of rules (e.g., address information contained in a packet header) to decide which packets can pass and which will be dropped. In the case of IP networks, packet-filter rules normally refer at least to the IP source and destination addresses, the transport protocol (TCP or UDP), the TCP or UDP source and destination ports, and some TCP flags (for TCP; particularly the SYN flag, which can be used to see whether a packet is a connection-establishment request). Application gateways or proxies (e.g., mail relays and HTTP proxies) act as mediators between the communicating application processes and can implement fine-grained, application-specific access control.
A complete firewall configuration (see Figure 19-1) normally consists of an inner router with packet-filtering functionality, which forms the transition to the network to be protected; an outer router with packet-filtering functionality, which forms the transition to the external network; and a number of application gateways located in an independent local area network between these routers. This network within the firewall is normally called a demilitarized zone (DMZ) or screened subnet. If gateways are available for all required application protocols, then the packet filters can be configured so that no packets are forwarded directly between the internal and the external networks. Instead, exclusive communication is between the internal network and the DMZ and between the external network and the DMZ. Figure 19-1. Structure of a firewall. 
In the most frequent case, that in which the network to be protected has only this single connection to the Internet and so represents an edge network from the topological view, the most fundamental firewall functionality is to limit packet forwarding to packets with topologically correct addresses. This means that only packets with a source address outside of the network and a destination address within the network are permitted into the network (so-called ingress filtering). In opposite direction, for a packet to be able to leave the network, the packet's source address has to be within the network and its destination address has to be outside the network (egress filtering). If all edge networks would strictly implement this functionality, this would effectively protect computers against attacks where hackers use falsified source addresses to hide their origin. This is the reason why the IETF explicitly recommends this approach in RFC 2827 [FeSe00]. Because the number of available IP addresses is extremely limited in IP Version 4, many firewalls in networks implement the Network Address Translation (NAT) mechanism. In this case, the internal network uses private addresses not visible from the outside. Chapter 21 discusses the NAT implementation in Linux 2.4. 19.1.2 Protocol-specific Particularities: TCP, FTP, and others In practice, it often is insufficient to filter individual packets exclusively by addresses, protocol numbers, and port numbers. For example, the connection-oriented TCP transport protocol groups many IP packets to a logical connection. If we want to implement address translation (NAT), these packets have to be seen as a group, of course, and they have to be handled equally. The connection-tracking mechanism discussed in Chapter 20 is responsible for this task. Special treatment of some packets is not only important for NAT, but it is also important for a pure filter functionality. For example, it often is desirable to permit only outgoing connections on specific TCP ports. To achieve this, we can utilize the fact that the SYN flag is set and the ACK flag is cleared in the TCP header of the first packet only in a TCP connection (connection-establishment request). To block TCP connections incoming on a specific port, all we have to do is to filter out all incoming packets that have the SYN flag set and the ACK flag cleared in their headers. More serious problems arise in connection with some application protocols that use dynamically assigned port numbers. One of the best known examples is the File Transfer Protocol (FTP). In FTP, the client initially establishes a control connection to TCP port 21 in the server, and then uses this connection to transmit FTP commands and replies. As soon as a file has to be transmitted or a directory has to be displayed, FTP opens an additional data connection in the "reverse direction": from TCP port 20 in the server to a dynamically selected client port, where the client-side port number is sent over the control connection. For a firewall that wants to permit outgoing FTP sessions only, either it would have to accept all incoming connections originating from TCP port 20 or a stateful filter would have to be installed to eavesdrop on and analyze all commands and replies from the FTP control connection and then permit only selected incoming FTP data connections. The first method is not optimal from the security perspective, and the second method causes considerable additional cost. However, to solve these problems for the FTP protocol, there is an additional method that prevents firewall problems by selecting the "passive" mode of operation. Unfortunately, this operation mode, which establishes data connections from a client to a server, is not supported in all FTP implementations. The problem is even more difficult when filtering is used for some other protocols (e.g., the H.323 multimedia conference protocol, which is used in many applications, including the popular Microsoft NetMeeting; a number of control and data connections with dynamically assigned TCP and UDP port numbers belong to one single H.323 session, so that a stateful filter would become very complex). Independent of the application protocol, we cannot use stateful filters when the control connections are encrypted. In this case, the only feasible method is to employ specially adapted client and server software that uses an appropriate protocol, such as SOCKS [LGLK+96], to let the firewall dynamically and selectively permit traffic on specific ports. 19.1.3 Quality Criteria for Packet-Filter Implementations To be able to evaluate the quality of a packet-filter architecture, [ChBe94] formulates the following criteria: Filtering is done both for incoming and for outgoing packets. There is an option to distinguish connection-establishment requests from other packets within one single connection. Filter options for protocols other than IP, TCP, and UDP either are available or can be added easily. There are filter options for arbitrary bit patterns within packets. There are filter options for routing information at both the input and the output. There is an option to reject data packets, if the destination address of these packets was changed by source routing. The set of rules is clearly represented, and there is an option to control the sequence in which rules are applied to a packet. Dropped data packets can be logged.
We will see in our discussion in the following sections that the new netfilter architecture of Linux Version 2.4 meets all those criteria. 19.1.4 Limits of the Firewall Principle Though a properly configured firewall is an important component for protecting a network, we have to understand that a firewall can never be a panacea. All packet filters operate on the basis of information contained in the protocol headers of incoming data packets. This information can be tampered with easily. For example, an adapted TCP/IP implementation makes it very easy for an intruder to send IP packets whose source address in the IP header is not the address of the actual sender (so-called IP spoofing). To achieve tamper-proof identification of a packet's origin as a prerequisite for effective filtering of incoming data traffic, it is recommended that one use cryptographic mechanisms (e.g., the IP security architecture of IPsec). In Linux, we can use FreeS/WAN, which is an IPsec implementation. |
