2003-05-28 21:20:23 +02:00
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<html>
|
|
|
|
|
|
<head>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<meta http-equiv="Content-Language" content="en-us">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<meta http-equiv="Content-Type"
|
|
|
|
|
|
content="text/html; charset=windows-1252">
|
|
|
|
|
|
<title>Shorewall Firewall Structure</title>
|
2002-08-13 22:45:21 +02:00
|
|
|
|
</head>
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<body>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0"
|
|
|
|
|
|
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
|
2003-07-16 20:59:33 +02:00
|
|
|
|
id="AutoNumber1" bgcolor="#3366ff" height="90">
|
|
|
|
|
|
<tbody>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td width="100%">
|
|
|
|
|
|
<h1 align="center"><font color="#ffffff">Firewall Structure (Under
|
|
|
|
|
|
Construction)</font></h1>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
|
|
|
|
|
|
</tbody>
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</table>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> Shorewall views the network in which it is running as a set of
|
|
|
|
|
|
<i> zones. </i>Shorewall itself defines exactly one zone called "fw" which
|
|
|
|
|
|
refers to the firewall system itself . The /etc/shorewall/zones file
|
|
|
|
|
|
is used to define additional zones and the example file provided with
|
|
|
|
|
|
Shorewall defines the zones:</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li> net -- the (untrusted) internet.</li>
|
|
|
|
|
|
<li> dmz - systems that must be accessible from the internet
|
|
|
|
|
|
and from the local network.<2E> These systems cannot be trusted completely
|
|
|
|
|
|
since their servers may have been compromised through a security exploit.</li>
|
|
|
|
|
|
<li> loc - systems in your local network(s). These systems
|
|
|
|
|
|
must be protected from the internet and from the DMZ and in some
|
|
|
|
|
|
cases, from each other.</li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall
|
|
|
|
|
|
zone</a>. For ease of description in this documentation, it is assumed
|
|
|
|
|
|
that the firewall zone is named "fw".</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>It can't be stressed enough that with the exception of the firewall zone,
|
|
|
|
|
|
Shorewall itself attaches no meaning to zone names. Zone names are simply
|
|
|
|
|
|
labels used to refer to a collection of network hosts.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>While zones are normally disjoint (no two zones have a host in common),
|
2003-07-07 16:18:52 +02:00
|
|
|
|
there are cases where nested or overlapping zone definitions are appropriate.</p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the purpose
|
|
|
|
|
|
of this document, we will consider Netfilter to have three tables:</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li>Filter table -- this is the main table for packet filtering and
|
|
|
|
|
|
can be displayed with the command "shorewall show".</li>
|
|
|
|
|
|
<li>Nat table -- used for all forms of Network Address Translation (NAT);
|
2003-07-07 16:18:52 +02:00
|
|
|
|
SNAT, DNAT and MASQUERADE.</li>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li>Mangle table -- used to modify fields in the packet header.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p>Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
|
|
|
|
|
|
FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
|
2003-07-07 16:18:52 +02:00
|
|
|
|
as shown in this table.<br>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<div align="center">
|
2003-07-07 16:18:52 +02:00
|
|
|
|
<table cellpadding="2" cellspacing="2" border="1">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<tbody>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">CHAIN<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">Filter<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">Nat<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">Mangle<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">PREROUTING<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">INPUT<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">OUTPUT<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">FORWARD<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td valign="top">POSTROUTING<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td valign="top">X<br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
|
|
|
|
|
|
</tbody>
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</table>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Shorewall doesn't create rules in all of the builtin chains. In the large
|
|
|
|
|
|
diagram below are boxes such as <20>shown below.<2E> This box represents in INPUT
|
|
|
|
|
|
chain and shows that packets first flow through the INPUT chain in the Mangle
|
|
|
|
|
|
table followed by the INPUT chain in the Filter table. The parentheses around
|
|
|
|
|
|
"Mangle" indicate that while the packets will flow through the INPUT chain
|
2003-07-07 16:18:52 +02:00
|
|
|
|
in the Mangle table, Shorewall does not create any rules in that chain.<br>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<div align="center"><img src="images/Legend.png" alt="(Box Legend)"
|
|
|
|
|
|
width="145" height="97" align="middle">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<p></p>
|
2003-07-07 16:18:52 +02:00
|
|
|
|
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<p>Here is a picture of how packets traverse the various chains and tables
|
|
|
|
|
|
in Netfilter. In that diagram, "Local Process" refers to a process running
|
|
|
|
|
|
on the Firewall itself (in the 'fw' zone).</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<div align="center"><img src="images/Netfilter.png"
|
|
|
|
|
|
alt="Netfilter Flow Diagram" width="541" height="767">
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<p><br>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
In the text that follows, the paragraph numbers correspond to the box
|
|
|
|
|
|
number in the diagram above.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
|
|
|
|
|
|
PREROUTING chain (you can see the mangle table by typing "shorewall show
|
|
|
|
|
|
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
|
|
|
|
|
|
option and if iptables/netfilter doesn't support the connection tracking
|
|
|
|
|
|
match extension, then the packet is sent down the <b>man1918</b> chain which
|
|
|
|
|
|
will drop the packet if its destination IP address is reserved (as specified
|
|
|
|
|
|
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
|
|
|
|
|
|
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
|
|
|
|
|
|
file. Finally, if traffic control/shaping is being used, the packet is
|
|
|
|
|
|
sent through the<b> tcpre</b> chain to be marked for later use in policy
|
|
|
|
|
|
routing or traffic control.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Next, if the packet isn't part of an established connection, it passes
|
|
|
|
|
|
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
|
|
|
|
|
|
by typing "shorewall show nat"). If you are doing both static nat and
|
|
|
|
|
|
port forwarding, the order in which chains are traversed is dependent on
|
|
|
|
|
|
the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
|
|
|
|
|
|
on then packets will ender a chain called<b> <i>interface_</i>in</b> where
|
|
|
|
|
|
<i>interface</i> is the name of the interface on which the packet entered.
|
|
|
|
|
|
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP
|
|
|
|
|
|
addresses from /etc/shorewall/nat that correspond to this interface; if
|
|
|
|
|
|
there is a match, DNAT is applied and the packet header is modified to
|
|
|
|
|
|
the IP in the <i>INTERNAL</i> column of the nat file record. If the destination
|
|
|
|
|
|
address doesn't match any of the rules in the <b><i>interface_</i>in</b>
|
|
|
|
|
|
chain then the packet enters a chain called <b><i>sourcezone</i>_dnat</b>
|
|
|
|
|
|
where <i>sourcezone</i> is the source zone of the packet. There it is compared
|
|
|
|
|
|
for a match against each of the DNAT records in the rules file that specify
|
|
|
|
|
|
<i> sourcezone </i>as the source zone. If a match is found, the
|
|
|
|
|
|
destination IP address (and possibly the destination port) is modified based
|
|
|
|
|
|
on the rule matched. If NAT_BEFORE_RULES is off, then the order of traversal
|
|
|
|
|
|
of the <b><i> interface_</i>in</b> and <b><i>sourcezone</i>_dnat</b> is
|
|
|
|
|
|
reversed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li>Depending on whether the packet is destined for the firewall itself
|
|
|
|
|
|
or for another system, it follows either the left or the right path. Traffic
|
|
|
|
|
|
going to the firewall goes through chain called INPUT in the mangle table.
|
2003-07-07 16:18:52 +02:00
|
|
|
|
Shorewall doesn't add any rules to that chain.<br>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li>Traffic that is to be forwarded to another host goes through the chains
|
|
|
|
|
|
called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf,
|
|
|
|
|
|
all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are
|
2003-07-07 16:18:52 +02:00
|
|
|
|
processed in a chain called <br>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li>Traffic is next sent to an<i> interface </i>chain in the main Netfilter
|
|
|
|
|
|
table (called 'filter'). If the traffic is destined for the firewall
|
|
|
|
|
|
itself, the name of the interface chain is formed by appending "_in" to
|
|
|
|
|
|
the interface name. So traffic on eth0 destined for the firewall will
|
|
|
|
|
|
enter a chain called <i>eth0_in</i>. The interface chain for traffic
|
|
|
|
|
|
that will be routed to another system is formed by appending "_fwd" to
|
|
|
|
|
|
the interface name. So traffic from eth1 that is going to be forwarded
|
|
|
|
|
|
enters a chain called<i> eth1_fwd</i>. Interfaces described with the wild-card
|
|
|
|
|
|
character ("+") in /etc/shorewall/interfaces, share input chains. if <i>ppp+
|
|
|
|
|
|
</i>appears in /etc/shorewall/interfaces then all PPP interfaces (ppp0,
|
|
|
|
|
|
ppp1, ...) will share the interface chains <i>ppp_in</i> and <i>ppp_fwd</i>.
|
|
|
|
|
|
In other words, "+" is deleted from the name before forming the input chain
|
|
|
|
|
|
names.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
While the use of interfacechains may seem wasteful in simple environments,
|
|
|
|
|
|
in complex setups it substantially reduces the number of rules that each
|
|
|
|
|
|
packet must traverse.<2E> </li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> Traffic directed from a zone to the firewall itself is sent through
|
|
|
|
|
|
a chain named <<i>zone name></i>2fw. For example, traffic inbound from
|
|
|
|
|
|
the internet and addressed to the firewall is sent through a chain named
|
|
|
|
|
|
net2fw. Similarly, traffic originating in the firewall and being sent
|
|
|
|
|
|
to a host in a given zone is sent through a chain named fw2<i><zone
|
|
|
|
|
|
name>. </i>For example, traffic originating in the firewall and
|
|
|
|
|
|
destined for a host in the local network is sent through a chain named
|
2003-07-07 16:18:52 +02:00
|
|
|
|
<i>fw2loc.</i> <font face="Century Gothic, Arial, Helvetica"> <20></font></p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> Traffic being forwarded between two zones (or from one interface to
|
|
|
|
|
|
a zone to another interface to that zone) is sent through a chain named <i>
|
|
|
|
|
|
<source zone></i>2<i> <destination zone></i>. So for example,
|
|
|
|
|
|
traffic originating in a local system and destined for a remote web server
|
|
|
|
|
|
is sent through chain <i>loc2net. </i>This chain is referred to
|
|
|
|
|
|
as the <i>canonical</i> chain from <source zone> to <destination
|
|
|
|
|
|
zone>. Any destination NAT will have occurred <u>before</u> the packet
|
|
|
|
|
|
traverses one of these chains so rules in /etc/shorewall/rules should
|
|
|
|
|
|
be expressed in terms of the destination system's real IP address as opposed
|
|
|
|
|
|
to its apparent external address. Similarly, source NAT will occur <u>after</u>
|
|
|
|
|
|
the packet has traversed the appropriate forwarding chain so the rules
|
2003-07-07 16:18:52 +02:00
|
|
|
|
again will be expressed using the source system's real IP address.</p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> For each record in the /etc/shorewall/policy file, a chain is created.
|
|
|
|
|
|
Policies in that file are expressed in terms of a source zone and destination
|
|
|
|
|
|
zone where these zones may be a zone defined in /etc/shorewall/zones,
|
|
|
|
|
|
"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
|
|
|
|
|
|
zones and "fw". These chains are referred to as <i>Policy Chains.</i><EFBFBD>Notice
|
|
|
|
|
|
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
|
|
|
|
|
|
may also be the policy chain for the pair or the policy chain may be
|
|
|
|
|
|
a different chain (za2all, for example). Packets from one zone to another
|
|
|
|
|
|
will traverse chains as follows:</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li> If the canonical chain exists, packets first traverse
|
|
|
|
|
|
that chain.</li>
|
|
|
|
|
|
<li> If the canonical chain and policy chain are different
|
|
|
|
|
|
and the packet does not match a rule in the canonical chain, it then
|
|
|
|
|
|
is sent to the policy chain.</li>
|
|
|
|
|
|
<li> If the canonical chain does not exist, packets are sent
|
|
|
|
|
|
immediately to the policy chain.</li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> The canonical chain from zone za to zone zb will be created only if
|
|
|
|
|
|
there are exception rules defined in /etc/shorewall/rules for packets going
|
|
|
|
|
|
from za to zb.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
|
|
|
|
|
|
implements connection tracking function that allow what is often referred
|
|
|
|
|
|
to as "statefull inspection" of packets. This statefull property allows
|
|
|
|
|
|
firewall rules to be defined in terms of "connections" rather than in
|
|
|
|
|
|
terms of "packets". With Shorewall, you:</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<li> Identify the client's zone.</li>
|
|
|
|
|
|
<li> Identify the server's zone.</li>
|
|
|
|
|
|
<li> If the POLICY from the client's zone to the server's zone
|
|
|
|
|
|
is what you want for this client/server pair, you need do nothing further.</li>
|
|
|
|
|
|
<li> If the POLICY is not what you want, then you must add
|
|
|
|
|
|
a rule. That rule is expressed in terms of the client's zone and
|
|
|
|
|
|
the server's zone.</li>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
</ol>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p> Just because connections of a particular type are allowed between zone
|
|
|
|
|
|
A and the firewall and are also allowed between the firewall and zone
|
|
|
|
|
|
B <font color="#ff6633"><b><u> DOES NOT mean that these connections
|
|
|
|
|
|
are allowed between zone A and zone B</u></b></font>. It rather means
|
|
|
|
|
|
that you can have a proxy running on the firewall that accepts a connection
|
|
|
|
|
|
from zone A and then establishes its own separate connection from the
|
|
|
|
|
|
firewall to zone B.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> If you adopt the default policy of ACCEPT from the local zone to the
|
|
|
|
|
|
internet zone and you are having problems connecting from a local client
|
|
|
|
|
|
to an internet server, <font color="#ff6633"><b><u> adding a rule won't
|
|
|
|
|
|
help</u></b></font> (see point 3 above).</p>
|
|
|
|
|
|
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<p><font size="2">Last modified 5/22/2003 - <a href="support.htm">Tom Eastep</a></font></p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
<p><font face="Trebuchet MS"><a href="copyright.htm"> <font size="2">Copyright</font>
|
|
|
|
|
|
<20> <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
2003-07-07 16:18:52 +02:00
|
|
|
|
<br>
|
2003-05-28 21:20:23 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
