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.
