[ Pobierz całość w formacie PDF ]

doing filtering here
since certain packets
might pass this chain
without ever hitting
it. This is also where
Masquerading is
done.
8 Goes out on the
outgoing interface
(ie, eth1).
9 Out on the wire
again (ie, LAN).
As you can see, there s quite a lot of steps to pass through. The packet can be stopped
at any of the iptables chains, or anywhere else in case it s malformed, however, we re
mainly interested in the iptables aspect of this lot. However, do note that there is no
specific chains or tables for different interfaces or anything like that. FORWARD is
always passed by all packets that s being forwarded over this firewall/router. Now,
let s have a look at a packet that s destined for our own localhost. It would pass
through the following steps before actually being delivered to our application to re-
ceive it:
Table 4-2. Destination localhost
Step Table Chain Comment
1 On the wire (ie,
Internet)
2 Comes in on the
interface(ie, eth0)
3 mangle PREROUTING This chain is
normally used for
mangling packets,
ie, changing TOS
and so on.
4 nat PREROUTING This chain is used
for Destination
Network Address
Translation mainly.
Avoid filtering in
this chain since it
will be passed
through in certain
cases.
29
Chapter 4. Traversing of tables and chains
Step Table Chain Comment
5 Routing decision, ie,
is the packet
destined for our
localhost or to be
forwarded and
where.
6 filter INPUT This is where we do
filtering for all
incoming traffic
destined for our
localhost. Note that
all incoming packets
destined for this host
passes through this
chain, no matter
what interface and
so on it came from.
7 Local
process/application
(ie, server/client
program)
Note that this time the packet was passed through the INPUT chain instead of the
FORWARD chain. Quite logical. Most probably the only thing that s really logical
about the traversing of tables and chains in your eyes in the beginning, but if you
continue to dig in it, I think it gets clearer with time. I think. Finally we look at the
outgoing packets from our own localhost and what steps they go through.
Table 4-3. Source localhost
Step Table Chain Comment
1 Local
process/application
(ie, server/client
program)
2 Mangle OUTPUT This is where we
mangle packets, it is
suggested that you
don t do filtering in
this chain since it
can have sideeffects.
3 Nat OUTPUT This is currently
broken, could
someone tell me
when this will be
fixed? Please?
4 Filter OUTPUT This is where we
filter packets going
out from localhost.
5 Routing decision.
This is where we
decide where the
packet should go.
30
Chapter 4. Traversing of tables and chains
Step Table Chain Comment
6 Nat POSTROUTING This is where we do
Source Network
Address Translation
as described earlier.
It is suggested that
you don t do
filtering here since it
can have sideeffects,
and certain packets
might slip through
even though you set
a default policy of
DROP.
7 Goes out on some
interface (ie, eth0)
8 On the wire (ie,
Internet)
We ve now seen how the different chains are traversed in 3 separate scenarios. If we
would figure out a good map of all this, it would look something like this:
31
Chapter 4. Traversing of tables and chains
Hopefully you got a clearer picture of how the packets traverses the built in
chains now. All comments welcome, this might still be wrong or it might
change in the future. For more information use this script available at
http://people.unix-fu.org/andreasson/iptables-tutorial/rc.test-iptables.txt1.
Mangle table
This table should as we ve already noted mainly be used for mangling packets. In
other words, you may freely use the mangle matches etc that could be used to change
32
Chapterstrongly adviced that and
4. Traversing of tables
TOS (Type Of Service) fields and so on. However, it s youchains
don t
use this table to do any filtering in, nor will any DNAT, SNAT or Masquerading work
in this table. Target s that only valid in the mangle table:
TOS
TTL
MARK
The TOS target is used to set and/or change the Type of Service field in the packet.
This could be used for setting up policies on the network regarding how a packet
should be routed and so on. Note that this isn t really used on the internet and most
of the routers don t care about the value in this field, and sometimes, they act faulty
on what they get. Don t set this in other words for packets going to the internet unless
you want to do routing decisions on it with iproute2.
The TTL target is used to change the TTL (Time To Live) field of the packet. We could
tell packets to only have a specific TTL and so on. One good reason for this could be
that we don t want to give ourself away to nosy ISP s. Some ISP s does not like users
running multiple computers on one single connection, and in there are some ISP s
known to look for a single host generating many different TTL values, and takes this
as one of many signs of multiple computers connected to a single connection.
The MARK target is used to set special mark values to the packet. These marks could
then be recognised by the iproute2 programs to do different routing on the packet
depending on what mark they have, or if they don t have any. We could also do
bandwidth limiting and Class Based Queuing with this target.
Nat table
This table should only be used for NAT (Network Address Translation) on different
packets. In other words, it should only be used to translate packets source field or
destination field. Note that, as we have said before, only the first packet in a stream
will hit this chain. After this, the rest of the packets will automatically have the same
action taken on them as the first packet. The actual targets that does these kind of
things are
DNAT
SNAT
MASQUERADE
The DNAT (Destination Network Address Translation) target is mainly used in cases
such as when you have one IP and want to redirect accesses to the firewall to some
other host on a DMZ for example. In other words, we change the destination address
of the packet and reroute it to some other host.
SNAT (Source Network Address Translation) is mainly used for changing the source
address of packets. This is mainly done to hide our local networks or DMZ etc. A
good example when this is very good is when we have a firewall that we know the
outside IP address of, but need to change our local networks IP numbers to the same
of the IP of our firewall. The firewall will with this target automatically De-SNAT
and SNAT the packets, hence making it possible to make connections from the LAN
to the Internet. If you re network uses 192.168.x.x netmask for example, the packets
would never get back from the Internet because these networks are regulated to be
used in LAN s by IANA and RFC s.
The MASQUERADE target is used in exactly the same way as SNAT, but the MAS-
QUERADE target takes a little bit more overhead to compute. The reason for this is
that each time that the MASQUERADE target gets hit by a packet, it automatically
checks for the IP address to use, instead of doing as the SNAT target does and just
use an IP address submitted while the rule was parsed. The MASQUERADE target
will on the other hand work properly with Dynamic IP addresses that you may be
provided when you connect to the Internet with, for example ppp, slip or dhcp.
33
Chapter 4. Traversing of tables and chains
Filter table
The filter table is, of course, mainly used for filtering packets. We can match pack-
ets and filter them however we want, and there s nothing special to this chain or
special packets that might slip through because they re malformed, etc. This is the
place that we actually take action against packets and look at what they contain and
DROP/ACCEPT depending on their payload. Of course we may do filtering earlier
too, however, this is the place that was designed for it. Almost all targets are usable
in this chain, however, the targets discussed previously in this chapter are only us-
able in their respective tables. We will not go into deeper discussion about this chain
though, as you already know, this is where we (should) do the main filtering.
Notes [ Pobierz całość w formacie PDF ]