mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-12 17:30:44 +01:00
136 lines
7.5 KiB
HTML
136 lines
7.5 KiB
HTML
|
<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>
|
|||
|
<meta name="Microsoft Theme" content="radial 011, default">
|
|||
|
</head>
|
|||
|
|
|||
|
<body background="_themes/radial/radbkgnd.gif" bgcolor="#FFFFFF" text="#000000" link="#6666FF" vlink="#993333" alink="#66CCCC"><!--mstheme--><font face="arial, Arial, Helvetica">
|
|||
|
|
|||
|
<h1 align="center"><!--mstheme--><font face="times new roman, Times New Roman, Times" color="#666666">Firewall Structure<!--mstheme--></font></h1>
|
|||
|
<p>
|
|||
|
Shorewall views the network in which it is running as a set of disjoint
|
|||
|
<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>
|
|||
|
<p>
|
|||
|
Traffic entering the
|
|||
|
firewall is sent to an<i> input </i>chain. If the traffic is destined for the
|
|||
|
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>
|
|||
|
<p><font size="2">Last modified 7/26/2002 - <a href="support.htm">Tom
|
|||
|
Eastep</a></font><p><font face="Trebuchet MS"><a href="copyright.htm">
|
|||
|
<font size="2">Copyright</font> <20> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><!--mstheme--></font></body></html>
|