2002-08-07 16:28:04 +02:00
|
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
|
|
<head>
|
|
|
|
|
|
<meta http-equiv="Content-Language" content="en-us">
|
|
|
|
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
|
|
|
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
|
|
|
|
<title>Shorewall Firewall Structure</title>
|
|
|
|
|
|
</head>
|
|
|
|
|
|
|
2002-08-22 23:33:54 +02:00
|
|
|
|
<body>
|
2002-08-07 16:28:04 +02:00
|
|
|
|
|
2002-08-22 23:33:54 +02:00
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td width="100%">
|
|
|
|
|
|
<h1 align="center"><font color="#FFFFFF">Firewall Structure</font></h1>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
</table>
|
2002-08-07 16:28:04 +02:00
|
|
|
|
<p>
|
2002-08-22 23:33:54 +02:00
|
|
|
|
Shorewall views the network in which it is running as a set of
|
2002-08-07 16:28:04 +02:00
|
|
|
|
<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>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<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>
|
2002-08-22 23:33:54 +02:00
|
|
|
|
<p>While zones are normally disjoint (no two zones have a host in common),
|
|
|
|
|
|
there are cases where nested or overlapping zone definitions are appropriate.</p>
|
2002-08-27 00:17:49 +02:00
|
|
|
|
<p>For a general picture of how packets traverse a Netfilter firewall, see
|
|
|
|
|
|
<a href="http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES">
|
|
|
|
|
|
http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.</a><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Packets entering the firewall first pass through the <i>mangle </i>table's
|
2002-08-22 23:33:54 +02:00
|
|
|
|
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, then the packet is sent down the <b>man1918</b> 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.</p>
|
|
|
|
|
|
<p>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
|
2002-08-27 00:17:49 +02:00
|
|
|
|
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 <i>interface_</i>in 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
|
|
|
|
|
|
<i>interface_</i>in chain then the packet enters a chain called <i>sourcezone</i>_dnat
|
|
|
|
|
|
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 <i>
|
|
|
|
|
|
interface_</i>in and <i>sourcezone</i>_dnat is reversed.</p>
|
2002-08-07 16:28:04 +02:00
|
|
|
|
<p>
|
2002-08-27 00:17:49 +02:00
|
|
|
|
Traffic is next sent to an<i> input </i>chain in the mail Netfilter table
|
|
|
|
|
|
(called 'filter'). If the traffic is destined for the
|
2002-08-07 16:28:04 +02:00
|
|
|
|
firewall itself, the name of the input 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 input 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 input chains <i>ppp_in</i> and <i>ppp_fwd</i>. In other words, "+" is
|
|
|
|
|
|
deleted from the name before forming the input chain names.</p>
|
|
|
|
|
|
<p>
|
|
|
|
|
|
While the use of input chains may seem wasteful in simple environments, in
|
|
|
|
|
|
complex setups it substantially reduces the number of rules that each packet
|
|
|
|
|
|
must traverse. </p>
|
|
|
|
|
|
<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 <i>fw2loc.</i>
|
|
|
|
|
|
<font face="Century Gothic, Arial, Helvetica">
|
|
|
|
|
|
<20></font></p>
|
|
|
|
|
|
<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
|
|
|
|
|
|
again will be expressed using the source system's real IP address.</p>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<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>
|
2002-08-27 00:17:49 +02:00
|
|
|
|
<p><font size="2">Last modified 8/22/2002 - <a href="support.htm">Tom
|
2002-08-07 16:28:04 +02:00
|
|
|
|
Eastep</a></font><p><font face="Trebuchet MS"><a href="copyright.htm">
|
2002-08-22 23:33:54 +02:00
|
|
|
|
<font size="2">Copyright</font> <20> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></body></html>
|
