Iptables is an extremely knowledge intensive tool. This means that iptables
takes quite a bit of knowledge to be able to use iptables to it's full extent.
Among other things, you must have a very good understanding of the TCP/IP
protocol.
This chapter aims at explaining the pure "must understands" of TCP/IP before you
can go on and work with iptables. Among the things we will go through are the
IP,TCP, UDP and ICMP protocols and their headers, and general usages of each of
these protocols and how they correlate to each other. Iptables works inside
Internet and Transport layers, and because of that, this chapter will focus
mainly on those layers as well.
Iptables is also able to work on higher layers, such as the Application layer.
However, it was not built for this task, and should not be used for that kind of
usage. I will explain more about this in the IP filtering introduction chapter.
TCP/IP is, as already stated, multi-layered. This means that we have one
functionality running at one depth, and another one at another level, etcetera.
The reason that we have all of these layers is actually very simple.
The biggest reason is that the whole architecture is very extensible. We can
add new functionality to the application layers, for example, without having to
reimplement the whole TCP/IP stack code, or to include a complete TCP/IP stack
into the actual application. Just the same way as we don't need to rewrite every
single program, every time that we make a new network interface card. Each layer
should need to know as little as possible about each other, to keep them
separated.
| When we are talking about the programming code of TCP/IP which resides inside
the kernel, we are often talking about the TCP/IP stack. The TCP/IP stack
simply means all of the sublayers used, from the Network access layer and all
the way up to the Application layer.
|
There are two basic architectures to follow when talking about layers. One of
them is the OSI (Open Systems Interconnect) Reference Model and consists of 7
layers. We will only look at it superficially here since we are more
interested in the TCP/IP layers. However, from an historical point, this is
interesting to know about, especially if you are working with lots of
different types of networks. The layers are as follows in the OSI Reference Model list.
Application layer
Presentation layer
Session layer
Transport layer
Network layer
Data Link layer
Physical layer
A packet that is sent by us, goes from the top and to the bottom of this list,
each layer adding its own set of headers to the packet in
what we call the encapsulation phase. When the packet finally reaches it's
destination the packet goes backwards through the list and the headers are
stripped out of the packet, one by one, each header giving the destination host
all of the needed information for the packet data to finally reach the
application or program that it was destined for.
The second and more interesting layering standard that we are more interested in
is the TCP/IP protocol architecture, as shown in the TCP/IP architecture list. There is no
universal agreement among people on just how many layers there are in the
TCP/IP architecture. However, it is generally considered that there are 3
through 5 layers available, and in most pictures and explanations, there will
be 4 layers discussed. We will, for simplicities sake, only consider those
four layers that are generally discussed.
Application layer
Transport layer
Internet layer
Network Access layer
As you can see, the architecture of the TCP/IP protocol set is very much like
the OSI Reference Model, but yet not. Just the same as with the OSI Reference
Model, we add and subtract headers for each layer that we enter or leave.
For example, lets use one of the most common analogies to modern computer
networking, the snail-mail letter. Everything is done in steps, just as
is everything in TCP/IP.
You want to send a letter to someone asking how they are, and what they are
doing. To do this, you must first create the data, or questions. The actual
data would be located inside the Application layer.
After this we would put the data written on a sheet of paper inside an envelope
and write on it to whom the letter is destined for within a specific company or
household. Perhaps something like the example below:
Attn: John Doe
This is equivalent to the the Transport layer, as it is known in TCP/IP. In the
Transport layer, if we were dealing with TCP, this would have been equivalent
to some port most likely though.
At this point we write the address on the envelope of the recipient, such as
this:
V. Andersgardsgatan 2
41715 Gothenburg
This would in the analogy be the same as the Internet layer. The internet layer
contains information telling us where to reach the recipient, or host, in a
TCP/IP network. Just the same way as the recipient on an envelope.
The final step is to put the whole letter in a postbox. Doing this would
approximately equal to putting a packet into the Network Access Layer. The
network access layer contains the functions and routines for accessing the
actual physical network that the packet should be transported over.
When the receiver finally receives the letter, he will open the whole letter
from the envelope and address etc (decapsulate it). The letter he receives may
either require a reply or not. In either case, the letter may be replied upon by
the receiver, by reversing the receiver and transmitter addresses on the
original letter he received, so that receiver becomes transmitter, and
transmitter becomes receiver.
| It is very important to understand that iptables was and is specifically built
to work inside the headers of the Internet and the Transport layers. It is
possible to do some very basic filtering with iptables in the Application and
Network access layers as well, but it was not designed for this, nor is it very
suitable for those purposes.
For example, if we use a string match and match for a specific string inside the
packet, lets say get /index.html. Will that work? Normally,
yes. However, if the packet size is very small, it will not. The reason is that
iptables is built to work on a per packet basis, which
means that if the string is split into several separate packets, iptables will
not see that whole string. For this reason, you are much, much better off using
a proxy of some sort for filtering in the application layer. We will discuss
these problems in more detail later on in the IP filtering introduction.
|
As iptables and netfilter mainly operate in the Internet and Transport layers,
that is the layers that we will put our main focus in, in the upcoming sections
of this chapter. Under the Internet layer, we will almost exclusively see the
IP protocol. There are a few additions to this, such as, for example, the GRE
protocol, but they are very rare. Also, iptables is (as the name implies) not
focused around these protocols very well either. Because of all these factors
we will mainly focus around the IP protocol of the Internet layer, and TCP,
UDP and ICMP of the Transport layer.
| The ICMP protocol is actually sort of a mix between the two layers. It runs in
the Internet layer, but it has the exact same headers as the IP protocol, but
also a few extra headers, and then directly inside that encapsulation, the data.
We will discuss this in more detail further on, in the ICMP characteristics.
|