IP filtering is simply a mechanism that decides which types of IP datagrams will be processed normally and which will be discarded. By discarded we mean that the datagram is deleted and completely ignored, as if it had never been received. You can apply many different sorts of criteria to determine which datagrams you wish to filter; some examples of these are:
Protocol type: TCP, UDP, ICMP, etc.
Socket number (for TCP/UPD)
Datagram type: SYN/ACK, data, ICMP Echo Request, etc.
Datagram source address: where it came from
Datagram destination address: where it is going to
It is important to understand at this point that IP filtering is a network layer facility. This means it doesn’t understand anything about the application using the network connections, only about the connections themselves. For example, you may deny users access to your internal network on the default telnet port, but if you rely on IP filtering alone, you can’t stop them from using the telnet program with a port that you do allow to pass trhough your firewall. You can prevent this sort of problem by using proxy servers for each service that you allow across your firewall. The proxy servers understand the application they were designed to proxy and can therefore prevent abuses, such as using the telnet program to get past a firewall by using the World Wide Web port. If your firewall supports a World Wide Web proxy, their telnet connection will always be answered by the proxy and will allow only HTTP requests to pass. A large number of proxy-server programs exist. Some are free software and many others are commercial products. The Firewall-HOWTO discusses one popular set of these, but they are beyond the scope of this book.
The IP filtering ruleset is made up of many combinations of the criteria listed previously. For example, let’s imagine that you wanted to allow World Wide Web users within the Virtual Brewery network to have no access to the Internet except to use other sites’ web servers. You would configure your firewall to allow forwarding of:
datagrams with a source address on Virtual Brewery network, a destination address of anywhere, and with a destination port of 80 (WWW)
datagrams with a destination address of Virtual Brewery network and a source port of 80 (WWW) from a source address of anywhere
Note that we’ve used two rules here. We have to allow our data to go out, but also the corresponding reply data to come back in. In practice, as we’ll see shortly, Linux simplifies this and allows us to specify this in one command.