firewall tutorial in linux

1. Firewalls and Linux
1 03/06/2003

2. What is a Firewall?
A set of programs residing on a "gateway server" that
protect the resources of an internal network
A network device or an host that connect 2 or more
networks
A device able to monitor each packet to determine
whether to forward it toward its destination
A device able to evaluates packets with the objective to
Control, Modify and Filter network traffic
2 03/06/2003

3. Firewall types
Hardware: Cisco Pix
Software
Tiny Personal Firewall
Norton Personal Firewall
...
With Netfilter is possible to use a “Linux Box” as Firewall based on IPTABLES.
3 03/06/2003

4. Example: What you need to build a
Linux Firewall?
1 PC with (Pentium II 300, 64MB RAM, 1GB HD)
enought network interfaces to manage your topology
A Linux distribution with Iptables (like RedHat 7.3, 8.0
or 9.0, Mandrake 9.1)
or
Smoothwall distribution (http://www.smoothwall.org),
requires Pentium 100 with 16Mb RAM and 512Mb hard
disk
4 03/06/2003

5. Case Study: I want to share my
Dialup/ADSL connection to my lab. (I)
5 03/06/2003

6. Case Study: I want to share my
Dialup/ADSL connection to my lab. (II)
6 03/06/2003

7. Simple network configuration with
MASQUERADING (I)
Public IP Addresses are not infinites. Masquerading
allows to use only one IP public address (also if
dynamically assigned) to connect a lot of hosts using
private addresses
Is very usefull with all kind of internet connections
The gateway “masquerade” the internal private
addresses using it’s own ip address as source ip
address for packets going outside the private network
7 03/06/2003

8. Public and Private IP Addresses
Some IP addresses (like 192.168.0.0/16, 10.0.0.0/8
and subnetworks) are “declared” (by IANA) “private”
and cannot be used to send packet to Internet
Make possible to use the same IP addresses in
different local networks. Allow (with masquerading)
more that 232-1 hosts to be connected to the internet
with IPv4 addresses.
8 03/06/2003

9. Simple network
configuration with
MASQUERADING (II)
Host1 with IP 192.168.0.10 try to open the Web-page
http://217.58.102.76
Gateway G1 receive from Host1 (source 192.168.0.10) a packet
with destination 217.58.102.76 port 80
G1 change 217.58.102.76 with it’s own public IP (ex:
213.110.140.18) and forward it to Internet using 33120 as source
port
G1 receive the reply from 213.110.140.18 to port 33120. G1
knows that this packet, coming from port 33120 has as real
destination Host1
G1 change the destination IP address from 213.11.140.18 to
192.168.0.10 and forward the packet to the Trusted private
network
Host1 is now able to send and receive packets to external servers
9 03/06/2003

10. MASQUERADING
Connection from trusted networks to other hosts on
Internet can be established only from Host in our LAN
An external Host cannot send a packet directly to an
Host inside our Trusted network (because they have
no public addresses)
We miss the possibility to have a reachable server
(reachable from the all internet) inside our network
10 03/06/2003

11. Why we need to publish services?
We need another network reachable from Internet to publish our
services
Manage a domain with DNS
– DNS Requests from other networks must reach internal DNSs (port
53)
Allow remote clients to upload/download from an ftp (or sftp)
server
– Setup an ftp server to share files with clients outside your local private
network (port 21)
Publish a Website
– Allow the whole Internet users to visit your Institute or company
website (port 80)
Manage hosts remotely
– Activate ssh (port 22) to allow remote administration
11 03/06/2003

12. Firewall: Common topology for
small networks
Trusted network(s): Include end-user workstations
DMZ network(s): Include servers giving services to the Internet
Internet connection(s): Internet Service Provider (ISP) connection
12 03/06/2003

13. Trusted Network
Connect end-user hosts
Every host has a private IP address (like 192.168.0.0/16 and
subnets)
Every host can send packet to internet but cannot receive packets
not related to previously established connections
A lot of Trusted networks can be created under the same firewall
13 03/06/2003

14. Demilitarized (DMZ) Network
Hosts with services (these kind of hosts are
usually called servers) for external networks
are inside DMZ network
Servers inside DMZ have private IP addresses
(ex: 10.0.0.0/8 and subnetworks)
Firewall use NAT/PAT to allow external
networks to use internal services
14 03/06/2003

15. Internet connection
Allow one or more LANs to connect to Internet
A Linux box used as firewall is also the
gateway interconnecting:
Trusted networks with Internet
DMZ networks with Internet
Trusted networks with DMZ networks if needed
15 03/06/2003

16. Netfilter and Iptables
With kernel 2.4 you can run Netfilter. This allow us to
setup, maintain and analyze packet filtering rules. Is an
evolution of previous tools, ipchains and ipfwadm.
Netfilter supports:
– Standard packet filtering
– Statfull inspection
– Maquerading
– Complete address translation (NAT/PAT)
– Load balancing
– Traffic shaping
– Allow user-level module creation
16 03/06/2003

17. Standard packet filtering
With previous solution (ipchains and ipfwadm)
packet filtering was stateless. Each packet
was forwarded or dropped depending only on
source and destionation addresses and source
and destination ports.
This approach does not allow some protocol to
traverse the firewall without all port >1024
open.
17 03/06/2003

18. An example: Ports >1024! (I)
Objective: allow a network application (based on sockets), to be accessible
by hosts outside your local LAN:
– The software is made by a main process that receive connection requests on
port 999.
– Then the main process create a new process for each new connection. New
processes waits for client data on ports from 40001 to 41000.
– The main process send a reply to the client (in the payload of an UDP packet)
with port to use to connect to the dedicate process
– The client receive the packet, read the port (ex:40001) and send the next
packet to port 40001 of the same server
– A statless firewall REJECT the packet cause port>1024 are closed
With a stateless firewall, if you want to allow your server to work properly
with hosts outside your LAN you must open all port>1024
A statfull Firewall allow to leave ports >1024 closed
18 03/06/2003

19. Mastering IPTABLES mini Howto
Learn basics about TCP/IP
Undestand connection tacking system
Learn iptables chains and tables scheme
Learn iptables syntax
Use a simple network and test it many times
Enjoy iptables
19 03/06/2003

20. Good thinks about IPTABLES
Connection tracking
– A mechanism that monitor packet, storing information about
connections. This allow to undestand if a packet is relative to a
known connection
Additional modules
– Is possible to load a module and use it’s feature to add a rule
to a table
– New modules can be developed to introduce new
functionalities
Optional userland modules
– Everyone can develop a module to be not in kernel mode to
match specific needs
20 03/06/2003

21. Different set of packets
To undestand how iptables works is important to
undestand the different types of packets the firewall will
manage:
Forwarded: coming from other hosts, destinated to
other hosts
Input: destinated for localhost
Output: generated by localhost
How IPTABLES works on them?
21 03/06/2003

22. Chains and Tables (I)
A packet passes through Tables and Chains
before to be:
– forwarded, sent to destination
– passed to a local process
– dropped, rejected
– ...
Depending on packet type (forwarded, input,
output) it traverse different chains.
22 03/06/2003

23. Chains and Tables (II)
IPTABLES uses 5 default chains:
– PREROUTING: packet coming from other hosts
– FORWARD: packet to be forwarded
– INPUT: packet destinated to localhost
– OUTPUT: packet generated by localhost
– POSTROUTING: packet going out to other hosts
23 03/06/2003

24. Chains and Tables (III)
Every chain “contains” one or more tables.
New custom chains can be created
Every packet goes into some chains, depending on it’s
type (forwarded, input, output)
To traverse a chain, a packet traverse all default tables
inside the specified chain
Tables are:
– Mangle
– Filter
– NAT
24 03/06/2003

25. The big picture:
traversing of tables
and chains
25 03/06/2003

26. Forwarded packets path:
1. On the wire
2. Firewall interface
3. PREROUTING chain
Mangle table
NAT table
4. Routing decision
5. FORWARD chain
Filter table
6. POSTROUTING chain
NAT chain
7. Outgoing interface on the wire again
26 03/06/2003

27. Input packets path:
1. On the wire
2. Firewall interface
3. PREROUTING chain
Mangle table
NAT table
4. Routing decision
5. INPUT chain
FILTER table
6. Local application/process
27 03/06/2003

28. Output packets path:
1. Local application/process
2. OUTPUT chain
Mangle table
NAT table
FILTER table
3. Routing decision
4. POSTROUTING chain
NAT table
5. Correct local interface on the wire
28 03/06/2003

29. MANGLE table
Allow to change parameters
– TOS: Type Of Service, allow to implement routing policies
using iptables
– TTL: Time To Live. Send packet to the Internet Service
Provider with the same TTL (making more difficult for some
ISP to check if you are using the connecti
– MARK: used by iproute2 to make different routing decision
(bandwidth limiting and class based queuing)
29 03/06/2003

30. Network Address Translation (NAT)
table (I)
Destination NAT (DNAT): Allow to change destination
address. Usefull to receive packets from Internet
redirecting them to Internal LAN services (like services
running on servers inside DMZ network)
Source NAT (SNAT): Allow to hide internal DMZ
network. The Firewall change the source addess of
outgoing packets using it’s own internet IP address (a
public one)
NOTE: This allow DMZ and Trusted networks to use
private Internet addresses like 10.0.0.0/8 and
192.168.0.0/16.
30 03/06/2003

31. Network Address Translation (NAT)
table (II)
MASQUERADING: Firewall hide all hosts
inside Trusted network, using it’s own internet
address (a public one). This allow you to
connect many hosts using only one Public
Internet address. In the opposite direction you
hide hosts inside Trusted network. With
Masquerading is not possible for hosts from
Internet to start a new (not RELATED)
connection to the Trusted network.
31 03/06/2003

32. Statefull vs. Stateless Firewalls
Statless firewalls can make filter decision
based only on:
– source/destination addresses and ports
Statfull firewall associate a packet to a state
and can make decision base on:
– source/destination addesses and ports
– state of the packet
32 03/06/2003

33. Connection tracking (I)
IPTABLES with connection tracking
Use your Linux box become a statfull Firewall
“ALLOW TO WRITE TIGHTER RULES”
“YOU DON’T NEED TO OPEN ALL PORTS > 1024”
33 03/06/2003

34. Connection tracking (II)
PREROUTING chain make decision about packet
states, possible states are:
– NEW: the packet is new in the connection
– ESTABLISHED: the packet is part of an established
connection
– RELATED: the packet is NEW in the connection but the
connection is related to an already ESTABLISHED connection
ex: ICMP message are related to the relative connection
ex: FTP-DATA stream is related to the FTP-CONTROL one
ex: More complicated TCP/UDP protocols needs additional
modules to be undestood as related
– INVALID: Packet that cannot be identified and does not have a
valid state. Is good practice to always DROP INVALID packets
34 03/06/2003

35. TCP connections (I)
The client send a SYN packet, the firewall catalog it as relative
to a new connection. The server sends the SYN/ACK reply,
and the connection become ESTABLISHED.
35 03/06/2003

36. UDP connections
UDP is a connectionless protocol, but the kernel can maintain
information about connection status. This allow to see the
UDP connection like for TCP. The Server reply the first
packet, so the connection is considered ESTABLISHED
36 03/06/2003

37. ICMP connections (I)
When the Client reply to the Echo Request the packet is
considered ESTABLISHED. After that the connection tracking
system delete info about this connection, because we expect
no more legal traffic relative to this ICMP request.
37 03/06/2003

38. ICMP connections (II)
An ICMP can be relative to another UDP or TCP connection.
Connection tracking allow to see the ICMP Net Unreachable
as related to another connection.
38 03/06/2003

39. Other connections, active FTP (I)
FTP has a ftp-control channel (port 21) and a ftp-data channel
(port 20).
For active FTP the client connect to the server on ftp-control port,
then in the payload sends information about IP and port to connect
to
A firewall should allow the server to connect to this client using
information about IP and port
Connection tracking use a special module that scans through the
data in the control connection allowing the server connection
(SYN) to the client to be RELATED
39 03/06/2003

40. Other connections, active FTP (II)
40 03/06/2003

41. Other connections, passive FTP (I)
In passive FTP the client asks for data
The server sends (inside ftp-control channel) information about IP
and port to connect to
The client open a connection to this IP and port from it’s data port
(20) and then retrieve the requested data
Again the connection tracking module allow to see the new
connection SYN as RELATED to the ftp-control channel
41 03/06/2003

42. Other connections, passive FTP (II)
42 03/06/2003

43. New Tables and Jumps
A new custom chain can be created:
#iptables –N custom_chain
With a “Jump” a packet can be sent to a chain:
#iptables –A INPUT –p UDP –j custom_chain
All UDP packets will pass throught custom_chain
Allow to parse only specific packets with a specific set
of rules
After traversing a chain the packet comes back to the
originating chain, starting from the rule that follows the
Jump
43 03/06/2003

44. Command line and Shorewall (I)
44 03/06/2003

45. Command line and Shorewall (II)
APPEND
#iptables –A FORWARD –p ALL –d 10.0.0.1 –j ACCEPT
DELETE
#iptables -D INPUT --dport 80 -j DROP, iptables -D INPUT 1
REPLACE
#iptables -R INPUT 1 -s 192.168.0.1 -j DROP
POLICY
#iptables -P INPUT DROP
CREATE CHAIN
#iptables -N allowed
FLUSH
#iptables -F INPUT
LIST
#iptables -L INPUT
45 03/06/2003

46. TARGETS
A rule checks a packet by protocol, source/destination
addresses, source/destination ports, state and many
other parameters. If it matches, the TARGET specify
an action to take
TARGETS are:
– ACCEPT, DROP, REJECT
– DNAT, SNAT, MASQUERADE
– LOG, ULOG, MARK
– MIRROR, QUEUE, REDIRECT, RETURN
– TOS, TTL
46 03/06/2003

47. ACCEPT
“As soon as the match specification for a packet has been
fully satisfied, the rule is accepted and will not continue
traversing the current chain or any other ones in the
same table. Note however, that a packet that was
accepted in one chain might still travel through chains
within other tables, and could still be dropped there.
There is nothing special about this target whatsoever,
and it does not require, nor have the possibility of,
adding options to the target. To use this target, we
simply specify -j ACCEPT” (iptables tutorial 1.1.18).
47 03/06/2003

48. Case Study: PING (I)
[root@firewall]#iptables –F
[root@firewall]#iptables –P INPUT DROP
[root@firewall]#iptables –P OUTPUT DROP
[root@firewall]#iptables –P FORWARD DROP
[root@firewall]#iptables –A FORWARD –p icmp
--icmp-type echo-request –d 192.168.0.10 –j ACCEPT
[user@192.168.1.1]#ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=0.360 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=0.319ms
[user@192.168.0.10]#tcpdump –n
12:07:00.061966 192.168.1.1 > 192.168.0.10: icmp: echo request
12:07:00.062148 192.168.0.10>192.168.1.1: icmp: echo reply
48 03/06/2003

49. DROP
“The DROP target does just what it says, it drops packets dead and
will not carry out any further processing. A packet that matches a
rule perfectly and is then Dropped will be blocked. Note that this
action might in certain cases have an unwanted effect, since it
could leave dead sockets around on either host. A better solution
in cases where this is likely would be to use the REJECT target,
especially when you want to block port scanners from getting too
much information, such on as filtered ports and so on. Also note
that if a packet has the DROP action taken on it in a subchain, the
packet will not be processed in any of the main chains either in the
present or in any other table. The packet is in other words totally
dead. As we've seen previously, the target will not send any kind
of information in either direction, nor to intermediaries such as
routers.” (iptables tutorial 1.1.18).
49 03/06/2003

50. Case study: PING (II)
[fw]#iptables –P INPUT ACCEPT
[fw]#iptables –P OUTPUT ACCEPT
[fw]#iptables –P FORWARD ACCEPT
[fw]#iptables –F
[fw]#iptables –A FORWARD –p icmp --icmp-type echo-request –d 192.168.0.10 –j DROP
[user@192.168.1.1]#ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data.
CTRL^C
[user@192.168.0.10]#tcpdump –n
CTRL^C
50 03/06/2003

51. REJECT
“The REJECT target works basically the same as the DROP target,
but it also sends back an error message to the host sending the
packet that was blocked. The REJECT target is as of today only
valid in the INPUT, FORWARD and OUTPUT chains or their sub
chains. After all, these would be the only chains in which it would
make any sense to put this target. Note that all chains that use the
REJECT target may only be called by the INPUT, FORWARD,
and OUTPUT chains, else they won't work. There is currently only
one option which controls the nature of how this target works,
though this may in turn take a huge set of variables. Most of them
are fairly easy to understand, if you have a basic knowledge of
TCP/IP.” (iptables tutorial 1.1.18).
51 03/06/2003

52. Case study: REJECT
[fw]#iptables –P INPUT ACCEPT
[fw]#iptables –P OUTPUT ACCEPT
[fw]#iptables –P FORWARD ACCEPT
[fw]#iptables –F
[fw]#iptables –A FORWARD –p icmp
--icmp-type echo-request –d 192.168.0.10 –j REJECT
[user@192.168.1.1]#ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data.
From 192.168.0.254 icmp_seq=1 Destination port Ureachable
From 192.168.0.254 icmp_seq=1 Destination port Ureachable
[user@192.168.0.10]#tcpdump –n
CTRL^C
52 03/06/2003

53. DNAT
“The DNAT target is used to do Destination Network Address
Translation, which means that it is used to rewrite the Destination
IP address of a packet. If a packet is matched, and this is the
target of the rule, the packet, and all subsequent packets in the
same stream will be translated, and then routed on to the correct
device, host or network. This target can be extremely useful, for
example, when you have an host running your web server inside a
LAN, but no real IP to give it that will work on the Internet. You
could then tell the firewall to forward all packets going to its own
HTTP port, on to the real web server within the LAN. We may also
specify a whole range of destination IP addresses, and the DNAT
mechanism will choose the destination IP address at random for
each stream. Hence, we will be able to deal with a kind of load
balancing by doing this.” (iptables tutorial 1.1.18).
53 03/06/2003

54. Case Study: DNAT (I)
213.178.208.130
54 03/06/2003

55. Case Study: DNAT (II)
“DNAT to HTTP”
[root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.74
- -dport 80 -j DNAT --to-destination 10.0.0.10
“DNAT to DNS”
[root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.75
- -dport 53 -j DNAT --to-destination 10.0.0.11
[root@firewall]# iptables –t nat –A PREROUTING –p UDP –i eth1 -d 217.58.102.75
- -dport 80 -j DNAT --to-destination 10.0.0.11
“DNAT to SMTP”
[root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.76
- -dport 25 -j DNAT --to-destination 10.0.0.12
“DNAT to POP3”
[root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.75
- -dport 113 -j DNAT --to-destination 10.0.0.12
55 03/06/2003

56. Case Study: DNAT (III)
[213.178.208.130]#telnet 217.58.102.74 80
Trying 217.58.102.74...
Connected to host74-102.pool21758.interbusiness.it (217.58.102.74).
Escape character is ' .
^]'
[fw]# tcpdump -i eth1 dst host 10.0.0.10
tcpdump: listening on eth1
21:59:05.665687 213.178.208.130.37795 > 10.0.0.10.http: S 1475560217:1475560217(0) win 5840 <mss
1460,sackOK,timestamp 87998393 0,nop,wscale 0> (DF) [tos 0x10]
21:59:05.749653 213.178.208.130.37795 > 10.0.0.10.http: . ack 1855920720 win 5840 <nop,nop,timestamp
87998402 126118625> (DF) [tos 0x10]
[10.0.0.10]#tcpdump -n host 213.178.208.130
tcpdump: listening on eth0
22:06:13.467533 213.178.208.130.37795 > 10.0.0.10.http: S 1475560217:1475560217(0) win 5840 <mss
1460,sackOK,timestamp 87998393 0,nop,wscale 0> (DF) [tos 0x10]
22:06:13.467587 10.0.0.10.http > 213.178.208.130.37795: S 1855920719:1855920719(0) ack 1475560218 win 5792
<mss 1460,sackOK,timestamp 126118625 87998393,nop,wscale 0> (DF)
22:06:13.551483 213.178.208.130.37795 > 10.0.0.10.http: . ack 1 win 5840 <nop,nop,timestamp 87998402
126118625> (DF) [tos 0x10]
56 03/06/2003

57. SNAT
“The SNAT target is used to do Source Network Address Translation, which
means that this target will rewrite the Source IP address in the IP header of
the packet. This is what we want, for example, when several hosts have to
share an Internet connection. We can then turn on ip forwarding in the
kernel, and write an SNAT rule which will translate all packets going out from
our local network to the source IP of our own Internet connection. Without
doing this, the outside world would not know where to send reply packets,
since our local networks mostly use the IANA specified IP addresses which
are allocated for LAN networks. If we forwarded these packets as is, no one
on the Internet would know that they where actually from us. The SNAT
target does all the translation needed to do this kind of work, letting all
packets leaving our LAN look as if they came from a single host, which
would be our firewall.”
“The SNAT target is only valid within the nat table, within the POSTROUTING
chain. This is in other words the only chain in which you may use SNAT.
Only the first packet in a connection is mangled by SNAT, and after that all
future packets using the same connection will also be SNATted.” (iptables
tutorial 1.1.18).
57 03/06/2003

58. MASQUERADE
“The MASQUERADE target is used basically the same as the SNAT target,
but it does not require any --to-source option. The reason for this is that the
MASQUERADE target was made to work with, for example, dial-up
connections, or DHCP connections, which gets dynamic IP addresses when
connecting to the network in question.”
“This means that you should only use the MASQUERADE target with
dynamically assigned IP connections, which we don't know the actual
address of at all times. If you have a static IP connection, you should instead
use the SNAT target”.
“When you masquerade a connection, it means that we set the IP address
used on a specific network interface instead of the --to-source option, and
the IP address”
“Is automatically grabbed from the information about the specific interface.
The MASQUERADE target also has the effect that connections are forgotten
when an Interface goes down, which is extremely good if we, for example,
kill a specific interface” (iptables tutorial 1.1.18).
58 03/06/2003

59. Case Study: SNAT or
MASQUERADING (I)
[fw]#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT
--to-source 217.58.102.77 SNAT
[fw]#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE MASQUERADING
[root@192.168.0.10]# telnet 140.105.16.57 80
Trying 140.105.16.57...
Connected to 140.105.16.57.
Escape character is ' .
^]'
[root@140.105.16.57]# tcpdump -n host 217.58.102.77
tcpdump: listening on eth0
09:40:44.405824 217.58.102.77.32947 > 140.105.16.57.http: S 3222243845:3222243845(0) win 5840
<mss 1460,sackOK,timestamp 1968354 0,nop,wscale 0> (DF) [tos 0x10]
59 03/06/2003

60. LOG, ULOG
“The LOG target is specially designed for logging detailed information about
packets. These could for example be considered as illegal. Or, logging can
be used purely for bug hunting and error finding.”
“The LOG target will return specific information on packets, such as most of
the IP headers and other information considered interesting. It does this via
the kernel logging facility, normally syslogd. This information may then be
read directly with dmesg, or from the syslogd logs, or with other programs
or applications.”
“This is an excellent target to use in debug your rule-sets, so that you can
see what packets go where and what rules are applied on what packets. Note
as well that it could be a really great idea to use the LOG target instead of the
DROP target while you are testing a rule you are not 100% sure about on a
production firewall, since a syntax error in the rule-sets could otherwise
cause severe connectivity problems for your users.”
“Also note that the ULOG target may be interesting if you are using really
extensive logging, since the ULOG target has support direct logging to
MySQL databases and suchlike” (iptables tutorial 1.1.18).
60 03/06/2003

61. MARK
“The MARK target is used to set Netfilter mark values that are associated
with specific packets. This target is only valid in the mangle table, and will
not work outside there.”
“The MARK values may be used in conjunction with the advanced routing
capabilities in Linux to send different packets through different routes and
to tell them to use different queue disciplines (qdisc), etc.”
“Note that the mark value is not set within the actual package, but is a
value that is associated within the kernel with the packet. In other words,
you can not set a MARK for a packet and then expect the MARK still to
be there on another host. If this is what you want, you will be better off
with the TOS target which will mangle the TOS value in the IP header.”
(iptables tutorial 1.1.18).
61 03/06/2003

62. QUEUE, REDIRECT, RETURN
“The QUEUE target is used to queue packets to User-land programs and
applications. It is used in conjunction with programs or utilities that are extraneous
to iptables and may be used, for example, with network accounting, or for specific
and advanced applications which proxy or filter packets.”
“The REDIRECT target is used to redirect packets and streams to the machine
itself. This means that we could for example REDIRECT all packets destined for
the HTTP ports to an HTTP proxy like squid, on our own host. Locally generated
packets are mapped to the 127.0.0.1 address. In other words, this rewrites the
destination address to our own host for packets that are forwarded, or something
alike. The REDIRECT target is extremely good to use when we want, for example,
transparent proxying, where the LAN hosts do not know about the proxy at all.”
“The RETURN target will cause the current packet to stop traveling through the
chain where it hit the rule. If it is the subchain of another chain, the packet will
continue to travel through the superior chains as if nothing had happened. If the
chain is the main chain, for example the INPUT chain, the packet will have the
default policy taken on it. The default policy is normally set to ACCEPT, DROP or
similar.” (iptables tutorial 1.1.18).
62 03/06/2003

63. TOS, TTL
“The TOS target is used to set the Type of Service field within the IP header. The
TOS field consists of 8 bits which are used to help in routing packets. This is one of
the fields that can be used directly within iproute2 and its subsystem for routing
policies. Worth noting, is that that if you handle several separate firewalls and
routers, this is the only way to propagate routing information within the actual
packet between these routers and firewalls. As previously noted, the MARK target
- which sets a MARK associated with a specific packet - is only available within the
kernel, and can not be propagated with the packet. If you feel a need to propagate
routing information for a specific packet or stream, you should therefore set the
TOS field, which was developed for this.”
The TTL target is used to modify the Time To Live field in the IP header. One
useful application of this is to change all Time To Live values to the same value on
all outgoing packets. One reason for doing this is if you have a bully ISP which
don't allow you to have more than one machine connected to the same Internet
connection, and who actively pursue this. Setting all TTL values to the same value,
will effectively make it a little bit harder for them to notify that you are doing this.
We may then reset the TTL value for all outgoing packets to a standardized value,
such as 64 as specified in Linux kernel. (iptables tutorial 1.1.18).
63 03/06/2003

64. Bibliography
Iptables tutorial 1.1.18, Oskar Andreasson
“Firewall con Linux” – poletti@niscent.com
64 03/06/2003