The Ins and Outs of Packet Filtering
Arthur Donkers [This is the first of Sys Admin's regular column on security issues. To reflect the reality that security matters often have different points of view, we will be alternating between two authors: Arthur Donkers and Robert Owen Thomas. On occasion, they may present point/counterpoint opinions on the same topic, but they also will be covering a variety of topics based on their own environment and experience. Readers are encouraged to send security-related questions for the columnists to answer or simply comment on the positions they take. Editor] When configuring or building a firewall, packet filtering is often the first level of defense against an attack. By setting the proper filters, you can specify which traffic is allowed through your firewall, and which is blocked. Once the network traffic has passed through your filter, it will arrive at the next level of defense (you have installed multiple levels of defense on your firewall, haven't you?), often an application level proxy and/or authentication. In this article, I will show you the intricacies of packet filters. The other levels of defense are beyond the scope of this column. For a packet filtering system a number of criteria can be defined for specifying which packets are accepted and which are not. But before we come to these criteria, a clear picture has to be drawn in your mind. Packets can be categorized into three directions: In, out, and forward. All packets that go into the firewall are considered to have the direction "in". All packets that come out of the firewall are considered to have the direction "out", and packets that are sent from one interface to another have the direction "forward". In most firewalls, a number of filter rules can be defined for each of these directions, and each of these rules specifies which packets are accepted, forwarded, and sent by the firewall. All rules for all directions must be set correctly for a connection to be established through the firewall. Filter Criteria For each of the abovementioned directions, a number of criteria can be applied to a packet before it is accepted. Source IP Address - The source IP address simply describes the source the address is coming from. In most cases, a netmask can be applied to this address to mask out certain bits of the address. This enables you to define one rule for a complete C class IP address range. You should consider, however, whether applying one rule for a complete range of addresses is not "too broad" and might lead to enabling the firewall for unused addresses in the range. Destination IP Address - This is the address the packet is destined for. When connecting to the Internet, the destination address may be any address (normally 0.0.0.0 with a mask of 0 bits). The same considerations apply to the destination address as to the source address. Interface - This is the interface the packet is received on or transmitted from. The interface is most often combined with the source address criteria. This combination can be used to prevent most IP spoofing cases. In most instances of spoofing, an IP packet is received on an interface with an address that fits in the range of another interface. For example, if the internal interface falls in the range 192.9.200.x, and the external interface is within the range 192.168.1.x, all packets with source address 192.9.200.1 can only be received on the internal interface. If they are received on the external interface, someone is trying to spoof his or her way in. When combining the interface and source address, packets with "illegal" source addresses are rejected. Protocol Numerous protocols are layered on top of IP, including ICMP, UDP, and TCP. Some protocols should be blocked completely, and only specific services should be allowed for others. Below is a short list of protocol specific items that could be allowed through the firewall. ICMP - The functions echo, request, and reply are the so-called ping-related function codes of ICMP. Some ISPs require you to enable ping on your firewall to test whether your firewall is reachable from the Internet. These function codes are also used by the traceroute utility to determine which routers are present between you and your destination. When enabling ping on your firewall, make sure you have installed the proper patches to avoid the "ping of death". All other function codes, especially the ICMP redirect, should be blocked by the packet filters for both input and output. UDP - UDP is a connectionless protocol. On the Internet, UDP is mainly used for nameserver requests. On internal networks, it is also used for Remote Procedure Calls and NFS. Neither of these should be available over the Internet, and you should block them on your firewall. All other UDP-related services should be blocked as well. TCP - This is the most widely used protocol on the Internet. TCP is used for exchanging email, Web information, telnet, and many other services. You should enable only the services that you strictly need. Service - Within each of these protocols, various services are present. Which services are present and how they are specified depends on the protocol. For UDP and TCP, services are specified as the port numbers you connect to or from, either on client or server side. State - When using the TCP protocol, a connection between a client and server can be in a number of states. The most important states are open and established. The best situation would be to allow only established traffic into your firewall. This means that only traffic from the Internet would be allowed in over an already active connection. No one on the Internet would be allowed to make a connection to your firewall. For other protocols, this "established" state is not present. The best example is UDP, where each packet is sent stateless. All of these criteria can be combined in a filter rule, which also specifies an action to be taken when a packet meets these criteria. Normally, this action is one of the following:
Now that I've discussed the building blocks of these packet filters, I will show how to create real filter rules with these criteria. Building a working set of filter rules requires in-depth knowledge of your network and services. I suggest making a rough drawing of your network. In this drawing, place your internal net on the left-hand side, the Internet on the right-hand side, and your firewall in the middle. By drawing the flow of traffic from your internal network, through your firewall, to the Internet (and back), you will see the places where the filter rules of your firewall will be applied to your traffic. By setting up the proper rules for each of these places, you can make sure you build a safe firewall. For example, let us look at the way a Web page is requested and retrieved. In this example, we assume that no proxy is installed, and that all users connect straight to the Web server on the Internet. All communications are done via the TCP protocol, using the Web service (normally located on port 80 of the server). First, the browser on the client machine creates a temporal socket for the connection to the Web server. The number of this port is not predictable, but normally lies in the range of 1024 and higher. Next, the browser then will attempt to connect, via this socket, to the Web service on the server (port 80). This connection request will flow through the firewall, which is where the first intersection takes place. The firewall should accept traffic that has originated on the internal net, and that is destined for the Web service on any Web server on the Internet. So, a possible solution for this input rule could be:
accept -source localnet/24 -destination
Once the packet has been accepted by the input rule, it runs into the forward rules. The specific rule for this service would be:
accept -source localnet/24 -destination Once the packet has been forwarded, it needs to go through the output rules. The specific rule would look like:
accept -source localnet/24 -destination Once the packet has made it through this first set of rules, it is loose on the Internet, finding its way to the Web server. As it arrives on the Web server, a connection will be established, and the Web server will send back an acknowledgement. This acknowledgement will arrive at the firewall and run into an input rule on the external interface. This input rule will look like:
accept -source 0.0.0.0/0 -destination localnet/24 If the acknowledgement makes it through this input rule, it will encounter the forwarding rules. An example could look like:
accept -source 0.0.0.0/0 -destination localnet/24 Finally, the acknowledgement will meet an output rule that allows it out on the internal network. An example of this output rule would be:
accept -source 0.0.0.0/0 -destination localnet/24 You can see that for a relatively simple protocol, you may need to define at least six different filter rules. And keep in mind that the filter rules in this example are not as tight as they could be, since we ignored the source port from which Web server traffic is sent. Masquerading There is one feature that will make this setup both a bit easier and safer. This feature is called masquerading. This means that all packets sent by the firewall to the Internet have a different source address, namely the IP address of the external interface. It looks as if all traffic to the Internet originates from the firewall itself, and not from an internal machine. Once an answer is received from the Internet, the original address is restored, and the packet is sent to its original sender. This masquerading feature is normally covered by a forwarding rule. This special rule then applies to the traffic in both directions. In our example, the first forwarding rule would become:
accept -source localnet/24 -destination 0.0.0.0/0 The second forwarding rule could be removed, because it is covered by this masquerading rule. Service-Specific Features Most TCP-based services work like the Web service, that is, a connection is built from an internal machine to an external server. If all services worked like this, things would be relatively simple and secure. However, there are a number of services that make things more complicated. Most notorious is the ftp protocol, normally used for transferring files. When making a connection to an ftp server, a so-called control connection is established between the client and the server. Commands and status reports are exchanged over this connection. When the user enters the DIR command in his or her ftp client, the LIST command is sent to the server. This is where the fun begins. The LIST command leads to the transfer of data (the directory listing itself). The data are transferred not over the control connection, but over a separate, dedicated data connection. In normal ftp (not using passive mode), this data connection is initiated by the server (not the client). So, you will have to allow for incoming connections by the ftp server. The only thing you know for sure is that these data connections are initiated from port 20 on the server, to a port on the client with number 1024 or higher. Although you can specify filters for these connections, they remain a security risk. By using passive ftp, you make sure that the data connection is also initiated by the client. However, not all servers and clients support passive mode yet. Conclusion Building a proper set of filter rules for a firewall is not a simple task. However, by following the flow of the traffic, you can make sure you do not forget a rule. Furthermore, by using these rules, you can accurately specify which traffic is accepted and which traffic is rejected. About the Author
Arthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering, and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments.
|