forked from extern/shorewall_code
Shorewall 1.4.5
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@612 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
8683295810
commit
d99bf6942c
@ -1,15 +1,15 @@
|
||||
Changes since 1.4.3a
|
||||
Changes since 1.4.4b
|
||||
|
||||
1. Implement REDIRECT-.
|
||||
1) The command "shorewall debug try <directory>" now correctly traces
|
||||
the attempt.
|
||||
|
||||
2. Change LOGMARKER to a printf mask and allow embedded spaces. Renamed
|
||||
it LOGFORMAT to avoid confusion.
|
||||
2) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
|
||||
contain a list of addresses. If the list begins with "!' then the
|
||||
rule will take effect only if the original destination address in
|
||||
the connection request does not match any of the addresses listed.
|
||||
|
||||
3. DNAT and REDIRECT logging is moved from the filter table to the nat
|
||||
table.
|
||||
|
||||
4. Don't include log rule number when LOGFORMAT doesn't include "%d".
|
||||
|
||||
5. Add --log-level to LOG rules.
|
||||
3) Enhanced processing of the zones file to allow the INCLUDE
|
||||
directive.
|
||||
|
||||
4) Fix processing of the routestopped file's second column.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -28,15 +28,15 @@
|
||||
<h2><font color="#660066">Configuring FreeS/Wan</font></h2>
|
||||
There is an excellent guide to configuring IPSEC tunnels at<a
|
||||
href="http://www.geocities.com/jixen66/"> http://www.geocities.com/jixen66/</a>
|
||||
. I highly recommend that you consult that site for information about confuring
|
||||
FreeS/Wan.
|
||||
. I highly recommend that you consult that site for information about configuring
|
||||
FreeS/Wan.
|
||||
<p><font color="#ff6633"><b>Warning: </b></font>Do not use Proxy ARP and
|
||||
FreeS/Wan on the same system unless you are prepared to suffer the consequences.
|
||||
If you start or restart Shorewall with an IPSEC tunnel active, the proxied
|
||||
IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX)
|
||||
rather than to the interface that you specify in the INTERFACE column of
|
||||
/etc/shorewall/proxyarp. I haven't had the time to debug this problem so
|
||||
I can't say if it is a bug in the Kernel or in FreeS/Wan. </p>
|
||||
rather than to the interface that you specify in the INTERFACE column
|
||||
of /etc/shorewall/proxyarp. I haven't had the time to debug this problem
|
||||
so I can't say if it is a bug in the Kernel or in FreeS/Wan. </p>
|
||||
|
||||
<p>You <b>might</b> be able to work around this problem using the following
|
||||
(I haven't tried it):</p>
|
||||
@ -115,9 +115,9 @@ I can't say if it is a bug in the Kernel or in FreeS/Wan.
|
||||
</blockquote>
|
||||
|
||||
<p align="left"><b>Note: </b>If either of the endpoints is behind a NAT gateway
|
||||
then the tunnels file entry on the <u><b>other</b></u> endpoint should specify
|
||||
a tunnel type of <i>ipsecnat</i> rather than <i>ipsec</i> and the GATEWAY
|
||||
address should specify the external address of the NAT gateway.<br>
|
||||
then the tunnels file entry on the <u><b>other</b></u> endpoint should
|
||||
specify a tunnel type of <i>ipsecnat</i> rather than <i>ipsec</i> and the
|
||||
GATEWAY address should specify the external address of the NAT gateway.<br>
|
||||
</p>
|
||||
|
||||
<p align="left">You need to define a zone for the remote subnet or include
|
||||
@ -199,8 +199,353 @@ created a zone called "vpn" to represent the remote subnet.</p>
|
||||
shorewall restart); you are now ready to configure the tunnel in <a
|
||||
href="http://www.xs4all.nl/%7Efreeswan/"> FreeS/WAN</a> .</p>
|
||||
|
||||
<h2><font color="#660066"><a name="RoadWarrior"></a> Mobile System (Road
|
||||
Warrior)</font></h2>
|
||||
<h2><a name="VPNHub"></a>VPN Hub</h2>
|
||||
Shorewall can be used in a VPN Hub environment where multiple remote networks
|
||||
are connected to a gateway running Shorewall. This environment is shown in
|
||||
this diatram.<br>
|
||||
|
||||
<div align="center"><img src="images/ThreeNets.png"
|
||||
alt="(Three networks linked with IPSEC)" width="750" height="781">
|
||||
<br>
|
||||
</div>
|
||||
|
||||
<p align="left">We want systems in the 192.168.1.0/24 sub-network to be able
|
||||
to communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks
|
||||
and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate.</p>
|
||||
|
||||
<p align="left">To make this work, we need to do several things:</p>
|
||||
|
||||
<p align="left">a) Open the firewall so that two IPSEC tunnels can be established
|
||||
(allow the ESP and AH protocols and UDP Port 500). </p>
|
||||
|
||||
<p align="left">b) Allow traffic through the tunnels two/from the local zone
|
||||
(192.168.1.0/24).<br>
|
||||
</p>
|
||||
|
||||
<p align="left">c) Deny traffic through the tunnels between the two remote
|
||||
networks.<br>
|
||||
</p>
|
||||
|
||||
<p align="left">Opening the firewall for the IPSEC tunnels is accomplished
|
||||
by adding two entries to the /etc/shorewall/tunnels file.</p>
|
||||
|
||||
<p align="left">In /etc/shorewall/tunnels on system A, we need the following </p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong> TYPE</strong></td>
|
||||
<td><strong> ZONE</strong></td>
|
||||
<td><strong> GATEWAY</strong></td>
|
||||
<td><strong> GATEWAY ZONE</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ipsec<br>
|
||||
</td>
|
||||
<td>net</td>
|
||||
<td>134.28.54.2</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top">ipsec<br>
|
||||
</td>
|
||||
<td valign="top">net<br>
|
||||
</td>
|
||||
<td valign="top">130.152.100.14<br>
|
||||
</td>
|
||||
<td valign="top"><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">In /etc/shorewall/tunnels on systems B and C, we would have:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong> TYPE</strong></td>
|
||||
<td><strong> ZONE</strong></td>
|
||||
<td><strong> GATEWAY</strong></td>
|
||||
<td><strong> GATEWAY ZONE</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ipsec</td>
|
||||
<td>net</td>
|
||||
<td>206.161.148.9</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left"></p>
|
||||
|
||||
<p align="left"><b>Note: </b>If either of the endpoints is behind a NAT gateway
|
||||
then the tunnels file entry on the <u><b>other</b></u> endpoint should
|
||||
specify a tunnel type of <i>ipsecnat</i> rather than <i>ipsec<br>
|
||||
</i> and the GATEWAY address should specify the external address of the
|
||||
NAT gateway.<br>
|
||||
</p>
|
||||
|
||||
<p align="left">On each system, we will create a zone to represent the remote
|
||||
networks. On System A:<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>ZONE</strong></td>
|
||||
<td><strong>DISPLAY</strong></td>
|
||||
<td><strong>COMMENTS</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn1</td>
|
||||
<td>VPN1</td>
|
||||
<td>Remote Subnet on system B</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top">vpn2<br>
|
||||
</td>
|
||||
<td valign="top">VPN2<br>
|
||||
</td>
|
||||
<td valign="top">Remote Subnet on system C<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">On systems B and C:<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>ZONE</strong></td>
|
||||
<td><strong>DISPLAY</strong></td>
|
||||
<td><strong>COMMENTS</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn</td>
|
||||
<td>VPN</td>
|
||||
<td>Remote Subnet on system A</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">At system A, ipsec0 represents two zones so we have the following
|
||||
in /etc/shorewall/interfaces:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong> ZONE</strong></td>
|
||||
<td><strong> INTERFACE</strong></td>
|
||||
<td><strong> BROADCAST</strong></td>
|
||||
<td><strong> OPTIONS</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-<br>
|
||||
</td>
|
||||
<td>ipsec0</td>
|
||||
<td> </td>
|
||||
<td><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">The /etc/shorewall/hosts file on system A defines the two
|
||||
VPN zones:<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong> ZONE</strong></td>
|
||||
<td><strong> HOSTS</strong><br>
|
||||
</td>
|
||||
<td><strong> OPTIONS</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn1<br>
|
||||
</td>
|
||||
<td>ipsec0:10.0.0.0/16</td>
|
||||
<td><br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top">vpn2<br>
|
||||
</td>
|
||||
<td valign="top">ipsec0:10.1.0.0/16<br>
|
||||
</td>
|
||||
<td valign="top"><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">At systems B and C, ipsec0 represents a single zone so we
|
||||
have the following in /etc/shorewall/interfaces:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong> ZONE</strong></td>
|
||||
<td><strong> INTERFACE</strong></td>
|
||||
<td><strong> BROADCAST</strong></td>
|
||||
<td><strong> OPTIONS</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn<br>
|
||||
</td>
|
||||
<td>ipsec0</td>
|
||||
<td> </td>
|
||||
<td><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
<br>
|
||||
</blockquote>
|
||||
<p align="left">On systems A, you will need to allow traffic between the "vpn1"
|
||||
zone and the "loc" zone as well as between "vpn2" and the "loc" zone
|
||||
-- if you simply want to admit all traffic in both directions, you
|
||||
can use the following policy file entries on all three gateways:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>SOURCE</strong></td>
|
||||
<td><strong>DEST</strong></td>
|
||||
<td><strong>POLICY</strong></td>
|
||||
<td><strong>LOG LEVEL</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>loc</td>
|
||||
<td>vpn1</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn1</td>
|
||||
<td>loc</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top">loc<br>
|
||||
</td>
|
||||
<td valign="top">vpn2<br>
|
||||
</td>
|
||||
<td valign="top">ACCEPT<br>
|
||||
</td>
|
||||
<td valign="top"><br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top">vpn2<br>
|
||||
</td>
|
||||
<td valign="top">loc<br>
|
||||
</td>
|
||||
<td valign="top">ACCEPT<br>
|
||||
</td>
|
||||
<td valign="top"><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p align="left">On systems B and C, you will need to allow traffic between
|
||||
the "vpn" zone and the "loc" zone -- if you simply want to admit all
|
||||
traffic in both directions, you can use the following policy file entries
|
||||
on all three gateways:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>SOURCE</strong></td>
|
||||
<td><strong>DEST</strong></td>
|
||||
<td><strong>POLICY</strong></td>
|
||||
<td><strong>LOG LEVEL</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>loc</td>
|
||||
<td>vpn</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn</td>
|
||||
<td>loc</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<p align="left">Once you have the Shorewall entries added, restart Shorewall
|
||||
on each gateway (type shorewall restart); you are now ready to configure
|
||||
the tunnels in <a href="http://www.xs4all.nl/%7Efreeswan/"> FreeS/WAN</a>
|
||||
.</p>
|
||||
Note that to allow traffic between the networks attached to systems B and
|
||||
C, it is necessary to simply add two additional entries to the /etc/shorewall/policy
|
||||
file on system A.<br>
|
||||
<blockquote>
|
||||
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>SOURCE</strong></td>
|
||||
<td><strong>DEST</strong></td>
|
||||
<td><strong>POLICY</strong></td>
|
||||
<td><strong>LOG LEVEL</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn1<br>
|
||||
</td>
|
||||
<td>vpn2</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn2</td>
|
||||
<td>vpn1<br>
|
||||
</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
<br>
|
||||
</blockquote>
|
||||
|
||||
<h2><font color="#660066"><a name="RoadWarrior"></a> </font>Mobile System
|
||||
(Road Warrior)</h2>
|
||||
|
||||
<p>Suppose that you have a laptop system (B) that you take with you when you
|
||||
travel and you want to be able to establish a secure connection back to your
|
||||
@ -266,9 +611,9 @@ system.</p>
|
||||
</p>
|
||||
|
||||
<h2><a name="Dynamic"></a>Dynamic RoadWarrior Zones</h2>
|
||||
Beginning with Shorewall release 1.3.10, you can define multiple VPN zones
|
||||
and add and delete remote endpoints dynamically using /sbin/shorewall. In
|
||||
/etc/shorewall/zones:<br>
|
||||
Beginning with Shorewall release 1.3.10, you can define multiple VPN
|
||||
zones and add and delete remote endpoints dynamically using /sbin/shorewall.
|
||||
In /etc/shorewall/zones:<br>
|
||||
<br>
|
||||
|
||||
<blockquote>
|
||||
@ -342,15 +687,15 @@ system.</p>
|
||||
</table>
|
||||
<br>
|
||||
</blockquote>
|
||||
When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall
|
||||
will issue warnings to that effect. These warnings may be safely ignored.
|
||||
FreeS/Wan may now be configured to have three different Road Warrior connections
|
||||
with the choice of connection being based on X-509 certificates or some
|
||||
other means. Each of these connectioins will utilize a different updown
|
||||
script that adds the remote station to the appropriate zone when the connection
|
||||
comes up and that deletes the remote station when the connection comes down.
|
||||
For example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of
|
||||
the script will issue the command":<br>
|
||||
When Shorewall is started, the zones vpn[1-3] will all be empty and
|
||||
Shorewall will issue warnings to that effect. These warnings may be safely
|
||||
ignored. FreeS/Wan may now be configured to have three different Road Warrior
|
||||
connections with the choice of connection being based on X-509 certificates
|
||||
or some other means. Each of these connectioins will utilize a different
|
||||
updown script that adds the remote station to the appropriate zone when the
|
||||
connection comes up and that deletes the remote station when the connection
|
||||
comes down. For example, when 134.28.54.2 connects for the vpn2 zone the
|
||||
'up' part of the script will issue the command":<br>
|
||||
<br>
|
||||
|
||||
<blockquote>/sbin/shorewall add ipsec0:134.28.54.2 vpn2<br>
|
||||
@ -359,13 +704,15 @@ the script will issue the command":<br>
|
||||
|
||||
<blockquote>/sbin/shorewall delete ipsec0:134.28.54.2 vpn<br>
|
||||
<br>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<h3>Limitations of Dynamic Zones</h3>
|
||||
If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added
|
||||
hosts are not excluded from the rule.<br>
|
||||
<br>
|
||||
Example with dyn=dynamic zone:<br>
|
||||
<br>
|
||||
If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added
|
||||
hosts are not excluded from the rule.<br>
|
||||
<br>
|
||||
Example with dyn=dynamic zone:<br>
|
||||
<br>
|
||||
|
||||
<blockquote>
|
||||
<table cellpadding="2" cellspacing="2" border="1">
|
||||
<tbody>
|
||||
@ -381,10 +728,10 @@ Example with dyn=dynamic zone:<br>
|
||||
<td valign="top"><u><b>PORT(S)<br>
|
||||
</b></u></td>
|
||||
<td valign="top"><u><b>CLIENT<br>
|
||||
PORT(S)<br>
|
||||
PORT(S)<br>
|
||||
</b></u></td>
|
||||
<td valign="top"><u><b>ORIGINAL<br>
|
||||
DESTINATION<br>
|
||||
DESTINATION<br>
|
||||
</b></u></td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -403,19 +750,18 @@ DESTINATION<br>
|
||||
<td valign="top"><br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
Dynamic changes to the zone <b>dyn</b> will have no effect on the above rule.
|
||||
|
||||
<p><font size="2">Last updated 5/3//2003 - </font><font size="2"> <a
|
||||
</blockquote>
|
||||
Dynamic changes to the zone <b>dyn</b> will have no effect on the above
|
||||
rule.
|
||||
<p><font size="2">Last updated 6/10//2003 - </font><font size="2"> <a
|
||||
href="support.htm">Tom Eastep</a></font> </p>
|
||||
|
||||
<p><a href="copyright.htm"><font size="2"> Copyright</font> © <font
|
||||
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -16,7 +16,6 @@
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="100%">
|
||||
|
||||
<h1 align="center"><font color="#ffffff">MAC Verification</font><br>
|
||||
</h1>
|
||||
<br>
|
||||
@ -27,9 +26,9 @@
|
||||
</table>
|
||||
<br>
|
||||
All traffic from an interface or from a subnet on an interface
|
||||
can be verified to originate from a defined set of MAC addresses. Furthermore,
|
||||
each MAC address may be optionally associated with one or more IP addresses.
|
||||
<br>
|
||||
can be verified to originate from a defined set of MAC addresses. Furthermore,
|
||||
each MAC address may be optionally associated with one or more IP addresses.
|
||||
<br>
|
||||
<br>
|
||||
<b>Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
|
||||
- module name ipt_mac.o).</b><br>
|
||||
@ -43,11 +42,11 @@ this option is specified, all traffic arriving on the interface is subjet
|
||||
to MAC verification.</li>
|
||||
<li>The <b>maclist </b>option in <a
|
||||
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>. When this option
|
||||
is specified for a subnet, all traffic from that subnet is subject to MAC
|
||||
verification.</li>
|
||||
is specified for a subnet, all traffic from that subnet is subject to
|
||||
MAC verification.</li>
|
||||
<li>The /etc/shorewall/maclist file. This file is used to associate
|
||||
MAC addresses with interfaces and to optionally associate IP addresses
|
||||
with MAC addresses.</li>
|
||||
with MAC addresses.</li>
|
||||
<li>The <b>MACLIST_DISPOSITION </b>and <b>MACLIST_LOG_LEVEL </b>variables
|
||||
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
|
||||
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
|
||||
@ -64,9 +63,9 @@ not logged.<br>
|
||||
<ul>
|
||||
<li>INTERFACE - The name of an ethernet interface on the Shorewall
|
||||
system.</li>
|
||||
<li>MAC - The MAC address of a device on the ethernet segment connected
|
||||
by INTERFACE. It is not necessary to use the Shorewall MAC format in
|
||||
this column although you may use that format if you so choose.</li>
|
||||
<li>MAC - The MAC address of a device on the ethernet segment
|
||||
connected by INTERFACE. It is not necessary to use the Shorewall MAC format
|
||||
in this column although you may use that format if you so choose.</li>
|
||||
<li>IP Address - An optional comma-separated list of IP addresses
|
||||
for the device whose MAC is listed in the MAC column.</li>
|
||||
|
||||
@ -78,35 +77,44 @@ this column although you may use that format if you so choose.</li>
|
||||
<pre> MACLIST_DISPOSITION=REJECT<br> MACLIST_LOG_LEVEL=info<br></pre>
|
||||
<b>/etc/shorewall/interfaces:</b><br>
|
||||
|
||||
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,maclist<br> dmz eth1 192.168.2.255<br> net eth3 206.124.146.255 blacklist<br> - texas 192.168.9.255<br> loc ppp+<br></pre>
|
||||
<blockquote>
|
||||
<pre>#ZONE INTERFACE BROADCAST OPTIONS<br>net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags<br>loc eth2 192.168.1.255 dhcp<br>dmz eth1 192.168.2.255<br>wap eth3 192.168.3.255 dhcp,maclist<br>- texas 192.168.9.255</pre>
|
||||
</blockquote>
|
||||
<b>/etc/shorewall/maclist:</b><br>
|
||||
|
||||
<pre> #INTERFACE MAC IP ADDRESSES (Optional)<br> eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie<br> eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry<br> eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa<br> eth2 00:A0:CC:DB:31:C4 192.168.1.128/26 #PPTP Clients to server on Ursa<br> eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)<br> eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap<br></pre>
|
||||
As shown above, I use MAC Verification on my local zone.<br>
|
||||
<blockquote>
|
||||
<pre>#INTERFACE MAC IP ADDRESSES (Optional)<br>eth3 00:A0:CC:A2:0C:A0 192.168.3.7 #Work Laptop<br>eth3 00:04:5a:fe:85:b9 192.168.3.250 #WAP11<br>eth3 00:06:25:56:33:3c #WET11<br>eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIPPER</pre>
|
||||
</blockquote>
|
||||
As shown above, I use MAC Verification on my wireless zone.<br>
|
||||
<br>
|
||||
<b>Note: </b>The WET11 is a somewhat curious device; when forwarding DHCP
|
||||
traffic, it uses the MAC address of the host (TIPPER) but for other forwarded
|
||||
traffic it uses it's own MAC address. Consequently, I don't assign the WET11
|
||||
a fixed IP address in /etc/shorewall/maclist.<br>
|
||||
|
||||
<h3>Example 2: Router in Local Zone</h3>
|
||||
Suppose now that I add a second ethernet segment to my local zone
|
||||
and gateway that segment via a router with MAC address 00:06:43:45:C6:15
|
||||
and IP address 192.168.1.253. Hosts in the second segment have IP addresses
|
||||
in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
|
||||
Suppose now that I add a second wireless segment to my wireless
|
||||
zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15
|
||||
and IP address 192.168.3.253. Hosts in the second segment have IP addresses
|
||||
in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist
|
||||
file:<br>
|
||||
|
||||
<pre> eth2 00:06:43:45:C6:15 192.168.1.253,192.168.2.0/24<br></pre>
|
||||
This entry accomodates traffic from the router itself (192.168.1.253)
|
||||
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
|
||||
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
|
||||
by the router so that traffic's MAC address will be that of the router
|
||||
(00:06:43:45:C6:15) and not that of the host sending the traffic.
|
||||
|
||||
<p><font size="2"> Updated 2/21/2002 - <a href="support.htm">Tom Eastep</a>
|
||||
<pre> eth3 00:06:43:45:C6:15 192.168.3.253,192.168.4.0/24<br></pre>
|
||||
This entry accomodates traffic from the router itself (192.168.3.253)
|
||||
and from the second wireless segment (192.168.4.0/24). Remember that
|
||||
all traffic being sent to my firewall from the 192.168.4.0/24 segment
|
||||
will be forwarded by the router so that traffic's MAC address will be
|
||||
that of the router (00:06:43:45:C6:15) and not that of the host sending
|
||||
the traffic.
|
||||
<p><font size="2"> Updated 6/10/2002 - <a href="support.htm">Tom Eastep</a>
|
||||
</font></p>
|
||||
|
||||
|
||||
|
||||
<p><a href="copyright.htm"><font size="2">Copyright</font> ©
|
||||
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -41,9 +41,10 @@
|
||||
height="60" alt="Caution" align="middle">
|
||||
Please observe the following general requirements:<br>
|
||||
<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
|
||||
</b>In all cases, Squid should be configured to
|
||||
run as a transparent proxy as described at <a
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
</b>In all cases, Squid should be configured
|
||||
to run as a transparent proxy as described at <a
|
||||
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
|
||||
<b><br>
|
||||
</b><b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
@ -52,19 +53,22 @@
|
||||
/etc/shorewall/start and /etc/shorewall/init -- if you don't have those
|
||||
files, siimply create them.<br>
|
||||
<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
</b> When the Squid server is in the DMZ zone
|
||||
or in the local zone, that zone must be defined ONLY by its interface
|
||||
-- no /etc/shorewall/hosts file entries. That is because the packets being
|
||||
or in the local zone, that zone must be defined ONLY by its interface --
|
||||
no /etc/shorewall/hosts file entries. That is because the packets being
|
||||
routed to the Squid server still have their original destination IP addresses.<br>
|
||||
<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
</b> You must have iptables installed on your
|
||||
Squid server.<br>
|
||||
<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
|
||||
</b> You must have NAT and MANGLE enabled in your
|
||||
/etc/shorewall/conf file<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
</b> You must have NAT and MANGLE enabled in
|
||||
your /etc/shorewall/conf file<br>
|
||||
<br>
|
||||
<b><font color="#009900"> NAT_ENABLED=Yes<br>
|
||||
</font></b> <font
|
||||
@ -74,11 +78,11 @@ Squid server.<br>
|
||||
|
||||
<ol>
|
||||
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running
|
||||
on the Firewall.</a></li>
|
||||
on the Firewall.</a></li>
|
||||
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in
|
||||
the local network</a></li>
|
||||
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the
|
||||
DMZ</a></li>
|
||||
the local network</a></li>
|
||||
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in
|
||||
the DMZ</a></li>
|
||||
|
||||
</ol>
|
||||
|
||||
@ -86,9 +90,9 @@ the local network</a></li>
|
||||
You want to redirect all local www connection requests EXCEPT
|
||||
those to your own
|
||||
http server (206.124.146.177)
|
||||
to a Squid
|
||||
transparent proxy running on the firewall and listening on port
|
||||
3128. Squid will of course require access to remote web servers.<br>
|
||||
to a Squid transparent
|
||||
proxy running on the firewall and listening on port 3128. Squid
|
||||
will of course require access to remote web servers.<br>
|
||||
<br>
|
||||
In /etc/shorewall/rules:<br>
|
||||
<br>
|
||||
@ -134,12 +138,20 @@ transparent proxy running on the firewall and listening on port
|
||||
</table>
|
||||
<br>
|
||||
</blockquote>
|
||||
|
||||
There may be a requirement to exclude additional destination hosts
|
||||
or networks from being redirected. For example, you might also want requests
|
||||
destined for 130.252.100.0/24 to not be routed to Squid. In that case, you
|
||||
must add a manual rule in /etc/shorewall/start:<br>
|
||||
<blockquote>
|
||||
<pre>run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN<br></pre>
|
||||
</blockquote>
|
||||
To exclude additional hosts or networks, just add additional similar
|
||||
rules.<br>
|
||||
<h2><a name="Local"></a>Squid Running in the local network</h2>
|
||||
You want to redirect all local www connection requests to a Squid
|
||||
transparent proxy
|
||||
running in your local zone at 192.168.1.3 and listening on port 3128.
|
||||
Your local interface is eth1. There may also be a web server running
|
||||
You want to redirect all local www connection requests to a
|
||||
Squid transparent
|
||||
proxy running in your local zone at 192.168.1.3 and listening on port
|
||||
3128. Your local interface is eth1. There may also be a web server running
|
||||
on 192.168.1.3. It is assumed that web access is already enabled from the
|
||||
local zone to the internet.<br>
|
||||
|
||||
@ -169,8 +181,8 @@ local zone to the internet.<br>
|
||||
</blockquote>
|
||||
|
||||
<ul>
|
||||
<li>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
|
||||
upgrade to Shorewall 1.4.2 or later.<br>
|
||||
<li>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a,
|
||||
please upgrade to Shorewall 1.4.2 or later.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:<br>
|
||||
@ -305,8 +317,8 @@ following policy in place of the above rule:<br>
|
||||
|
||||
<h2><a name="DMZ"></a>Squid Running in the DMZ (This is what I do)</h2>
|
||||
You have a single Linux system in your DMZ with IP address 192.0.2.177.
|
||||
You want to run both a web server and Squid on that system. Your DMZ
|
||||
interface is eth1 and your local interface is eth2.<br>
|
||||
You want to run both a web server and Squid on that system. Your DMZ interface
|
||||
is eth1 and your local interface is eth2.<br>
|
||||
|
||||
<ul>
|
||||
<li>On your firewall system, issue the following command<br>
|
||||
@ -487,8 +499,8 @@ interface is eth1 and your local interface is eth2.<br>
|
||||
</blockquote>
|
||||
|
||||
<ul>
|
||||
<li>On 192.0.2.177 (your Web/Squid server), arrange for the following
|
||||
command to be executed after networking has come up<br>
|
||||
<li>On 192.0.2.177 (your Web/Squid server), arrange for the
|
||||
following command to be executed after networking has come up<br>
|
||||
|
||||
<pre><font color="#009900"><b>iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></font><br></pre>
|
||||
</li>
|
||||
@ -508,11 +520,12 @@ interface is eth1 and your local interface is eth2.<br>
|
||||
|
||||
<blockquote> </blockquote>
|
||||
|
||||
<p><font size="-1"> Updated 4/7/2003 - <a href="support.htm">Tom Eastep</a>
|
||||
<p><font size="-1"> Updated 5/29/2003 - <a href="support.htm">Tom Eastep</a>
|
||||
</font></p>
|
||||
|
||||
<a href="copyright.htm"><font size="2">Copyright</font> ©
|
||||
<font size="2">2003 Thomas M. Eastep.</font></a><br>
|
||||
<font size="2">2003 Thomas M. Eastep.</font></a><br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -13,6 +13,7 @@
|
||||
<title>Shorewall Index</title>
|
||||
|
||||
<base target="main">
|
||||
|
||||
<meta name="Microsoft Theme" content="none">
|
||||
</head>
|
||||
<body>
|
||||
@ -24,12 +25,14 @@
|
||||
<tr>
|
||||
<td width="100%"
|
||||
height="90">
|
||||
|
||||
<h3 align="center"><font color="#ffffff">Shorewall</font></h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="100%"
|
||||
bgcolor="#ffffff">
|
||||
|
||||
<ul>
|
||||
<li> <a
|
||||
href="seattlefirewall_index.htm">Home</a></li>
|
||||
@ -46,16 +49,18 @@
|
||||
<li> <a
|
||||
href="shorewall_quickstart_guide.htm">QuickStart Guides (HOWTOs)</a><br>
|
||||
</li>
|
||||
<li> <b><a
|
||||
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a></b></li>
|
||||
<li>
|
||||
<b><a href="shorewall_quickstart_guide.htm#Documentation">Documentation
|
||||
Index</a></b></li>
|
||||
<li> <a
|
||||
href="Documentation.htm">Reference Manual</a></li>
|
||||
<li> <a href="FAQ.htm">FAQs</a></li>
|
||||
<li> <a
|
||||
href="FAQ.htm">FAQs</a></li>
|
||||
<li><a
|
||||
href="useful_links.html">Useful Links</a><br>
|
||||
</li>
|
||||
<li> <a
|
||||
href="troubleshoot.htm">Troubleshooting</a></li>
|
||||
href="troubleshoot.htm">Things to try if it doesn't work</a></li>
|
||||
<li> <a
|
||||
href="errata.htm">Errata</a></li>
|
||||
<li> <a
|
||||
@ -65,26 +70,28 @@
|
||||
<li><a href="http://lists.shorewall.net">Mailing Lists</a><a
|
||||
href="http://lists.shorewall.net"> </a><br>
|
||||
</li>
|
||||
<li><a href="1.3" target="_top">Shorewall
|
||||
1.3 Site</a></li>
|
||||
<li><a href="1.3"
|
||||
target="_top">Shorewall 1.3 Site</a></li>
|
||||
<li><a
|
||||
href="http://www1.shorewall.net/1.2/index.htm" target="_top">Shorewall
|
||||
1.2 Site</a></li>
|
||||
href="http://www1.shorewall.net/1.2/index.htm" target="_top">Shorewall 1.2
|
||||
Site</a></li>
|
||||
<li><a href="shorewall_mirrors.htm">Mirrors</a>
|
||||
|
||||
|
||||
<ul>
|
||||
<li><a target="_top"
|
||||
href="http://slovakia.shorewall.net">Slovak Republic</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://shorewall.infohiiway.com">Texas, USA</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://germany.shorewall.net">Germany</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://shorewall.correofuego.com.ar">Argentina</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://slovakia.shorewall.net">Slovak Republic</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://shorewall.infohiiway.com">Texas, USA</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://germany.shorewall.net">Germany</a></li>
|
||||
|
||||
<li><a target="_top"
|
||||
href="http://france.shorewall.net">France</a></li>
|
||||
<li><a href="http://shorewall.syachile.cl" target="_top">Chile</a></li>
|
||||
<li><a href="http://shorewall.greshko.com" target="_top">Taiwan</a><br>
|
||||
<li><a href="http://shorewall.syachile.cl"
|
||||
target="_top">Chile</a></li>
|
||||
<li><a href="http://shorewall.greshko.com"
|
||||
target="_top">Taiwan</a><br>
|
||||
</li>
|
||||
<li><a
|
||||
href="http://www.shorewall.net" target="_top">Washington State, USA</a><br>
|
||||
@ -94,8 +101,10 @@
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
<li> <a
|
||||
href="News.htm">News Archive</a></li>
|
||||
@ -103,11 +112,20 @@
|
||||
href="Shorewall_CVS_Access.html">CVS Repository</a></li>
|
||||
<li> <a
|
||||
href="quotes.htm">Quotes from Users</a></li>
|
||||
<li>GSLUG Presentation</li>
|
||||
|
||||
<ul>
|
||||
<li><a href="GSLUG.htm">HTML</a></li>
|
||||
<li><a href="GSLUG.ppt">PowerPoint</a><br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<li> <a
|
||||
href="shoreline.htm">About the Author</a></li>
|
||||
<li> <a
|
||||
href="seattlefirewall_index.htm#Donations">Donations</a></li>
|
||||
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -13,6 +13,7 @@
|
||||
<title>Shorewall Index</title>
|
||||
|
||||
<base target="main">
|
||||
|
||||
<meta name="Microsoft Theme" content="none">
|
||||
</head>
|
||||
<body>
|
||||
@ -24,12 +25,14 @@
|
||||
<tr>
|
||||
<td width="100%"
|
||||
height="90">
|
||||
|
||||
<h3 align="center"><font color="#ffffff">Shorewall</font></h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="100%"
|
||||
bgcolor="#ffffff">
|
||||
|
||||
<ul>
|
||||
<li> <a
|
||||
href="seattlefirewall_index.htm">Home</a></li>
|
||||
@ -46,17 +49,20 @@
|
||||
<li> <a
|
||||
href="shorewall_quickstart_guide.htm">QuickStart Guides (HOWTOs)</a><br>
|
||||
</li>
|
||||
<li> <b><a
|
||||
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a></b></li>
|
||||
<li>
|
||||
<b><a href="shorewall_quickstart_guide.htm#Documentation">Documentation
|
||||
Index</a></b></li>
|
||||
<li> <a
|
||||
href="Documentation.htm">Reference Manual</a></li>
|
||||
<li> <a href="FAQ.htm">FAQs</a></li>
|
||||
<li> <a
|
||||
href="FAQ.htm">FAQs</a></li>
|
||||
<li><a
|
||||
href="useful_links.html">Useful Links</a><br>
|
||||
</li>
|
||||
<li> <a
|
||||
href="troubleshoot.htm">Troubleshooting</a></li>
|
||||
<li> <a href="errata.htm">Errata</a></li>
|
||||
href="troubleshoot.htm">Things to try if it doesn't work</a></li>
|
||||
<li> <a
|
||||
href="errata.htm">Errata</a></li>
|
||||
<li> <a
|
||||
href="upgrade_issues.htm">Upgrade Issues</a></li>
|
||||
<li> <a
|
||||
@ -67,45 +73,59 @@
|
||||
</li>
|
||||
<li><a href="1.3" target="_top">Shorewall 1.3 Site</a></li>
|
||||
<li><a
|
||||
href="http://www1.shorewall.net/1.2/index.htm" target="_top">Shorewall 1.2
|
||||
Site</a></li>
|
||||
href="http://www1.shorewall.net/1.2/index.htm" target="_top">Shorewall
|
||||
1.2 Site</a></li>
|
||||
<li><a href="shorewall_mirrors.htm">Mirrors</a>
|
||||
|
||||
|
||||
<ul>
|
||||
<li><a target="_top"
|
||||
href="http://slovakia.shorewall.net">Slovak Republic</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://shorewall.infohiiway.com">Texas, USA</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://germany.shorewall.net">Germany</a></li>
|
||||
<li><a target="_top"
|
||||
href="http://shorewall.correofuego.com.ar">Argentina</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://slovakia.shorewall.net">Slovak Republic</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://shorewall.infohiiway.com">Texas, USA</a></li>
|
||||
<li><a
|
||||
target="_top" href="http://germany.shorewall.net">Germany</a></li>
|
||||
|
||||
<li><a target="_top"
|
||||
href="http://france.shorewall.net">France</a></li>
|
||||
<li><a href="http://shorewall.syachile.cl" target="_top">Chile</a></li>
|
||||
<li><a href="http://shorewall.greshko.com" target="_top">Taiwan</a><br>
|
||||
<li><a href="http://shorewall.syachile.cl"
|
||||
target="_top">Chile</a></li>
|
||||
<li><a href="http://shorewall.greshko.com"
|
||||
target="_top">Taiwan</a><br>
|
||||
</li>
|
||||
<li><a
|
||||
href="http://www.shorewall.net" target="_top">Washington State, USA</a><br>
|
||||
</li>
|
||||
|
||||
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
<li> <a href="News.htm">News
|
||||
Archive</a></li>
|
||||
<li> <a
|
||||
href="News.htm">News Archive</a></li>
|
||||
<li> <a
|
||||
href="Shorewall_CVS_Access.html">CVS Repository</a></li>
|
||||
<li> <a href="quotes.htm">Quotes
|
||||
from Users</a></li>
|
||||
<li>GSLUG Presentation</li>
|
||||
|
||||
<ul>
|
||||
<li><a href="GSLUG.htm">HTML</a></li>
|
||||
<li><a href="GSLUG.ppt">PowerPoint</a><br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<li> <a
|
||||
href="quotes.htm">Quotes from Users</a></li>
|
||||
<li> <a
|
||||
href="shoreline.htm">About the Author</a></li>
|
||||
<li> <a
|
||||
href="seattlefirewall_index.htm#Donations">Donations</a></li>
|
||||
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
@ -114,11 +134,7 @@ Site</a></li>
|
||||
</table>
|
||||
|
||||
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
|
||||
size="2">2001-2003 Thomas M. Eastep.</font></a><a
|
||||
href="http://www.shorewall.net" target="_top"> </a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
size="2">2001-2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -20,6 +20,7 @@
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="100%">
|
||||
|
||||
<h1 align="center"><font color="#ffffff">Shorewall Download</font></h1>
|
||||
</td>
|
||||
</tr>
|
||||
@ -29,7 +30,7 @@
|
||||
|
||||
<p><b>I strongly urge you to read and print a copy of the <a
|
||||
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide</a>
|
||||
for the configuration that most closely matches your own.<br>
|
||||
for the configuration that most closely matches your own.<br>
|
||||
</b></p>
|
||||
|
||||
<p>The entire set of Shorewall documentation is available in PDF format at:</p>
|
||||
@ -40,8 +41,8 @@
|
||||
<a href="rsync://slovakia.shorewall.net/shorewall/pdf/">rsync://slovakia.shorewall.net/shorewall/pdf/</a>
|
||||
</p>
|
||||
|
||||
<p>The documentation in HTML format is included in the .rpm and in the .tgz
|
||||
packages below.</p>
|
||||
<p>The documentation in HTML format is included in the .rpm and in the
|
||||
.tgz packages below.</p>
|
||||
|
||||
<p> Once you've printed the appropriate QuickStart Guide, download <u>
|
||||
one</u> of the modules:</p>
|
||||
@ -61,7 +62,8 @@ packages below.</p>
|
||||
copy of the documentation).</li>
|
||||
<li>If you run <a href="http://www.debian.org"><b>Debian</b></a>
|
||||
and would like a .deb package, Shorewall is included in both
|
||||
the <a href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
||||
the <a
|
||||
href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
||||
Testing Branch</a> and the <a
|
||||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian Unstable
|
||||
Branch</a>.</li>
|
||||
@ -72,8 +74,8 @@ copy of the documentation).</li>
|
||||
|
||||
<p>The documentation in HTML format is included in the .tgz and .rpm files
|
||||
and there is an documentation .deb that also contains the documentation. The
|
||||
.rpm will install the documentation in your default document directory which
|
||||
can be obtained using the following command:<br>
|
||||
.rpm will install the documentation in your default document directory
|
||||
which can be obtained using the following command:<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
@ -82,11 +84,11 @@ copy of the documentation).</li>
|
||||
|
||||
<p>Please check the <font color="#ff0000"> <a href="errata.htm"> errata</a></font>
|
||||
to see if there are updates that apply to the version
|
||||
that you have downloaded.</p>
|
||||
that you have downloaded.</p>
|
||||
|
||||
<p><font color="#ff0000"><b>WARNING - YOU CAN <u>NOT</u> SIMPLY INSTALL
|
||||
THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION IS
|
||||
REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
|
||||
THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
|
||||
IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
|
||||
of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.</b></font></p>
|
||||
|
||||
<p><b></b></p>
|
||||
@ -133,14 +135,6 @@ REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
|
||||
href="http://germany.shorewall.net/pub/shorewall/">Browse</a></td>
|
||||
<td><a target="_blank"
|
||||
href="ftp://germany.shorewall.net/pub/shorewall">Browse</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Martinez (Zona Norte - GBA), Argentina</td>
|
||||
<td>Correofuego.com.ar</td>
|
||||
<td><a
|
||||
href="http://shorewall.correofuego.com.ar/pub/mirrors/shorewall">Browse</a></td>
|
||||
<td> <a target="_blank"
|
||||
href="ftp://shorewall.correofuego.com.ar/pub/mirrors/shorewall"> Browse</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>France</td>
|
||||
@ -195,5 +189,6 @@ REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -34,28 +34,33 @@
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
|
||||
<p align="left"> <b><u>I</u>f you use a Windows system to download
|
||||
a corrected script, be sure to run the script through <u>
|
||||
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
|
||||
a corrected script, be sure to run the script through
|
||||
<u> <a
|
||||
href="http://www.megaloman.com/%7Ehany/software/hd2u/"
|
||||
style="text-decoration: none;"> dos2unix</a></u> after you have moved
|
||||
it to your Linux system.</b></p>
|
||||
</li>
|
||||
<li>
|
||||
<p align="left"> <b>If you are installing Shorewall for the
|
||||
first time and plan to use the .tgz and install.sh script, you can
|
||||
untar the archive, replace the 'firewall' script in the untarred directory
|
||||
|
||||
<p align="left"> <b>If you are installing Shorewall for the first
|
||||
time and plan to use the .tgz and install.sh script, you can untar
|
||||
the archive, replace the 'firewall' script in the untarred directory
|
||||
with the one you downloaded below, and then run install.sh.</b></p>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<p align="left"> <b>When the instructions say to install a corrected
|
||||
firewall script in /usr/share/shorewall/firewall, you
|
||||
may rename the existing file before copying in the new file.</b></p>
|
||||
may rename the existing file before copying in the new file.</b></p>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
|
||||
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
|
||||
For example, do NOT install the 1.3.9a firewall script if you are
|
||||
running 1.3.7c.</font></b><br>
|
||||
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER
|
||||
BELOW. For example, do NOT install the 1.3.9a firewall script if
|
||||
you are running 1.3.7c.</font></b><br>
|
||||
</p>
|
||||
</li>
|
||||
|
||||
@ -76,15 +81,19 @@ running 1.3.7c.</font></b><br>
|
||||
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
|
||||
on RH7.2</a></font></b></li>
|
||||
<li> <b><a
|
||||
href="#Debug">Problems with kernels >= 2.4.18 and
|
||||
RedHat iptables</a></b></li>
|
||||
href="#Debug">Problems with kernels >= 2.4.18 and RedHat
|
||||
iptables</a></b></li>
|
||||
<li><b><a href="#SuSE">Problems installing/upgrading
|
||||
RPM on SuSE</a></b></li>
|
||||
<li><b><a href="#Multiport">Problems with
|
||||
iptables version 1.2.7 and MULTIPORT=Yes</a></b></li>
|
||||
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
|
||||
and NAT</a></b><br>
|
||||
</li>
|
||||
iptables version 1.2.7 and MULTIPORT=Yes</a></b></li>
|
||||
<li><b><a href="#NAT">Problems with RH Kernel
|
||||
2.4.18-10 and NAT</a></b></li>
|
||||
<li><b><a href="#REJECT">Problems with RH Kernels after 2.4.20-9 and REJECT
|
||||
(also applies to 2.4.21-RC1) <img src="images/new10.gif" alt="(New)"
|
||||
width="28" height="12" border="0">
|
||||
</a><br>
|
||||
</b></li>
|
||||
|
||||
</ul>
|
||||
|
||||
@ -93,32 +102,52 @@ iptables version 1.2.7 and MULTIPORT=Yes</a></b></li>
|
||||
|
||||
<h3></h3>
|
||||
|
||||
<h3>1.4.4b</h3>
|
||||
|
||||
<ul>
|
||||
<li>Shorewall is ignoring records in /etc/shorewall/routestopped that
|
||||
have an empty second column (HOSTS). This problem may be corrected by installing
|
||||
<a
|
||||
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.4b/firewall"
|
||||
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
|
||||
described above.</li>
|
||||
<li>The INCLUDE directive doesn't work when placed in the /etc/shorewall/zones
|
||||
file. This problem may be corrected by installing <a
|
||||
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.4b/functions"
|
||||
target="_top">this functions script</a> in /usr/share/shorewall/functions.<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>1.4.4-1.4.4a</h3>
|
||||
|
||||
<ul>
|
||||
<li>Log messages are being displayed on the system console even though
|
||||
the log level for the console is set properly according to <a
|
||||
the log level for the console is set properly according to <a
|
||||
href="FAQ.htm#faq16">FAQ 16</a>. This problem may be corrected by installing
|
||||
<a
|
||||
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.4a/firewall"
|
||||
target="_top">this firewall script</a> in /usr/share/shorewall/firewall
|
||||
as described above.<br>
|
||||
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
|
||||
described above.<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>1.4.4<br>
|
||||
</h3>
|
||||
|
||||
<ul>
|
||||
<li> If you have zone names that are 5 characters long, you may experience
|
||||
problems starting Shorewall because the --log-prefix in a logging rule is
|
||||
too long. Upgrade to Version 1.4.4a to fix this problem..</li>
|
||||
problems starting Shorewall because the --log-prefix in a logging rule
|
||||
is too long. Upgrade to Version 1.4.4a to fix this problem..</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>1.4.3</h3>
|
||||
|
||||
<ul>
|
||||
<li>The LOGMARKER variable introduced in version 1.4.3 was intended to
|
||||
allow integration of Shorewall with Fireparse (http://www.firewparse.com).
|
||||
<li>The LOGMARKER variable introduced in version 1.4.3 was intended
|
||||
to allow integration of Shorewall with Fireparse (http://www.firewparse.com).
|
||||
Unfortunately, LOGMARKER only solved part of the integration problem. I
|
||||
have implimented a new LOGFORMAT variable which will replace LOGMARKER which
|
||||
has completely solved this problem and is currently in production with fireparse
|
||||
@ -137,8 +166,8 @@ has completely solved this problem and is currently in production with firepars
|
||||
created in /tmp is not being removed. This problem may be corrected by
|
||||
installing <a
|
||||
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.2/firewall"
|
||||
target="_top">this firewall script</a> in /usr/share/shorewall/firewall
|
||||
as described above. <br>
|
||||
target="_top">this firewall script</a> in /usr/share/shorewall/firewall as
|
||||
described above. <br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@ -146,9 +175,9 @@ as described above. <br>
|
||||
<h3>1.4.1a, 1.4.1 and 1.4.0</h3>
|
||||
|
||||
<ul>
|
||||
<li>Some TCP requests are rejected in the 'common' chain with an ICMP
|
||||
port-unreachable response rather than the more appropriate TCP RST response.
|
||||
This problem is corrected in <a
|
||||
<li>Some TCP requests are rejected in the 'common' chain with an
|
||||
ICMP port-unreachable response rather than the more appropriate TCP RST
|
||||
response. This problem is corrected in <a
|
||||
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1a/common.def"
|
||||
target="_top">this updated common.def file</a> which may be installed in
|
||||
/etc/shorewall/common.def.<br>
|
||||
@ -159,11 +188,11 @@ as described above. <br>
|
||||
<h3>1.4.1</h3>
|
||||
|
||||
<ul>
|
||||
<li>When a "shorewall check" command is executed, each "rule" produces
|
||||
the harmless additional message:<br>
|
||||
<li>When a "shorewall check" command is executed, each "rule"
|
||||
produces the harmless additional message:<br>
|
||||
<br>
|
||||
/usr/share/shorewall/firewall: line 2174: [: =: unary operator
|
||||
expected<br>
|
||||
expected<br>
|
||||
<br>
|
||||
You may correct the problem by installing <a
|
||||
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.4.1/firewall"
|
||||
@ -176,9 +205,9 @@ expected<br>
|
||||
<h3>1.4.0</h3>
|
||||
|
||||
<ul>
|
||||
<li>When running under certain shells Shorewall will attempt to
|
||||
create ECN rules even when /etc/shorewall/ecn is empty. You may either
|
||||
just remove /etc/shorewall/ecn or you can install <a
|
||||
<li>When running under certain shells Shorewall will attempt
|
||||
to create ECN rules even when /etc/shorewall/ecn is empty. You may either
|
||||
just remove /etc/shorewall/ecn or you can install <a
|
||||
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
|
||||
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
|
||||
</li>
|
||||
@ -202,19 +231,19 @@ just remove /etc/shorewall/ecn or you can install <a
|
||||
|
||||
<p align="left"> I have built a <a
|
||||
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
|
||||
corrected 1.2.3 rpm which you can download here</a> and I
|
||||
have also built an <a
|
||||
corrected 1.2.3 rpm which you can download here</a> and
|
||||
I have also built an <a
|
||||
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
|
||||
iptables-1.2.4 rpm which you can download here</a>. If you are currently
|
||||
iptables-1.2.4 rpm which you can download here</a>. If you are currently
|
||||
running RedHat 7.1, you can install either of these RPMs
|
||||
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
|
||||
|
||||
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
|
||||
has released an iptables-1.2.4 RPM of their own which you can
|
||||
download from<font color="#ff6633"> <a
|
||||
has released an iptables-1.2.4 RPM of their own which you
|
||||
can download from<font color="#ff6633"> <a
|
||||
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
|
||||
</font>I have installed this RPM on my firewall and it works
|
||||
fine.</p>
|
||||
</font>I have installed this RPM on my firewall and it
|
||||
works fine.</p>
|
||||
|
||||
<p align="left">If you would like to patch iptables 1.2.3 yourself,
|
||||
the patches are available for download. This <a
|
||||
@ -233,8 +262,8 @@ iptables-1.2.4 rpm which you can download here</a>. If you are currently
|
||||
</ul>
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="Debug"></a>Problems with kernels >= 2.4.18
|
||||
and RedHat iptables</h3>
|
||||
<h3><a name="Debug"></a>Problems with kernels >= 2.4.18 and
|
||||
RedHat iptables</h3>
|
||||
|
||||
<blockquote>
|
||||
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
|
||||
@ -270,15 +299,15 @@ and RedHat iptables</h3>
|
||||
|
||||
<p>The iptables 1.2.7 release of iptables has made an incompatible
|
||||
change to the syntax used to specify multiport match rules;
|
||||
as a consequence, if you install iptables 1.2.7 you must
|
||||
as a consequence, if you install iptables 1.2.7 you must
|
||||
be running Shorewall 1.3.7a or later or:</p>
|
||||
|
||||
<ul>
|
||||
<li>set MULTIPORT=No
|
||||
in /etc/shorewall/shorewall.conf; or
|
||||
</li>
|
||||
<li>if you are
|
||||
running Shorewall 1.3.6 you may
|
||||
in /etc/shorewall/shorewall.conf;
|
||||
or </li>
|
||||
<li>if you
|
||||
are running Shorewall 1.3.6 you may
|
||||
install <a
|
||||
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
|
||||
this firewall script</a> in /var/lib/shorewall/firewall
|
||||
@ -289,7 +318,7 @@ as a consequence, if you install iptables 1.2.7 you must
|
||||
<h3><a name="NAT"></a>Problems with RH Kernel 2.4.18-10 and NAT<br>
|
||||
</h3>
|
||||
/etc/shorewall/nat entries of the following form
|
||||
will result in Shorewall being unable to start:<br>
|
||||
will result in Shorewall being unable to start:<br>
|
||||
<br>
|
||||
|
||||
<pre>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL<br>192.0.2.22 eth0 192.168.9.22 yes yes<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
||||
@ -297,17 +326,27 @@ will result in Shorewall being unable to start:<br>
|
||||
|
||||
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
|
||||
The solution is to put "no" in the LOCAL column.
|
||||
Kernel support for LOCAL=yes has never worked properly and 2.4.18-10
|
||||
has disabled it. The 2.4.19 kernel contains corrected support under
|
||||
a new kernel configuraiton option; see <a
|
||||
Kernel support for LOCAL=yes has never worked properly and 2.4.18-10
|
||||
has disabled it. The 2.4.19 kernel contains corrected support
|
||||
under a new kernel configuraiton option; see <a
|
||||
href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
|
||||
<br>
|
||||
|
||||
<p><font size="2"> Last updated 5/29/2003 - <a href="support.htm">Tom
|
||||
Eastep</a></font> </p>
|
||||
<h3><a name="REJECT"></a><b> Problems with RH Kernels after 2.4.20-9 and REJECT
|
||||
(also applies to 2.4.21-RC1)</b></h3>
|
||||
Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset"
|
||||
is broken. The symptom most commonly seen is that REJECT rules act just like
|
||||
DROP rules when dealing with TCP. A kernel patch and precompiled modules to
|
||||
fix this problem are available at <a
|
||||
href="ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel"
|
||||
target="_top">ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel</a>.<br>
|
||||
|
||||
<hr>
|
||||
<p><font size="2"> Last updated 6/13/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
</p>
|
||||
|
||||
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
|
||||
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -23,6 +23,7 @@
|
||||
<tr>
|
||||
<td width="33%" valign="middle"
|
||||
align="left">
|
||||
|
||||
<h1 align="center"><a
|
||||
href="http://www.centralcommand.com/linux_products.html"><img
|
||||
src="images/Vexira_Antivirus_Logo.gif" alt="Vexira Logo" width="78"
|
||||
@ -34,7 +35,10 @@
|
||||
height="35" alt="">
|
||||
</a>
|
||||
|
||||
<p align="right"><font color="#ffffff"><b> </b></font> </p>
|
||||
<p align="right"><font color="#ffffff"><b> </b></font><a
|
||||
href="http://razor.sourceforge.net/"><img src="images/razor.gif"
|
||||
alt="(Razor Logo)" width="100" height="22" align="left" border="0">
|
||||
</a> </p>
|
||||
</td>
|
||||
<td valign="middle" width="34%" align="center">
|
||||
|
||||
@ -42,8 +46,8 @@
|
||||
</td>
|
||||
<td valign="middle" width="33%">
|
||||
<a href="http://www.postfix.org/"> <img
|
||||
src="images/postfix-white.gif" align="right" border="0" width="124"
|
||||
height="66" alt="(Postfix Logo)">
|
||||
src="images/postfix-white.gif" align="right" border="0" width="158"
|
||||
height="84" alt="(Postfix Logo)">
|
||||
</a><br>
|
||||
|
||||
<div align="left"><a href="http://www.spamassassin.org"><img
|
||||
@ -52,9 +56,8 @@
|
||||
</a> </div>
|
||||
<br>
|
||||
|
||||
<div align="right"><br>
|
||||
<b><font color="#ffffff"><br>
|
||||
</font></b><br>
|
||||
<div align="right"><b><font color="#ffffff"><br>
|
||||
</font></b><br>
|
||||
</div>
|
||||
</td>
|
||||
</tr>
|
||||
@ -83,45 +86,51 @@ incoming mail:<br>
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>against <a href="http://spamassassin.org">Spamassassin</a>
|
||||
(including <a href="http://razor.sourceforge.net/">Vipul's Razor</a>).<br>
|
||||
<li>against <a
|
||||
href="http://spamassassin.org">Spamassassin</a> (including <a
|
||||
href="http://razor.sourceforge.net/">Vipul's Razor</a>).<br>
|
||||
</li>
|
||||
<li>to ensure that the sender address is fully
|
||||
qualified.</li>
|
||||
<li>to verify that the sender's domain has an A
|
||||
or MX record in DNS.</li>
|
||||
qualified.</li>
|
||||
<li>to verify that the sender's domain has an
|
||||
A or MX record in DNS.</li>
|
||||
<li>to ensure that the host name in the HELO/EHLO
|
||||
command is a valid fully-qualified DNS name that resolves.</li>
|
||||
<li>to ensure that the client system has a valid PTR record in DNS.<br>
|
||||
</li>
|
||||
<li>to ensure that the sending system has a valid PTR record in DNS.</li>
|
||||
|
||||
</ol>
|
||||
<big><font color="#cc0000"><b>This last point is important. If you run your
|
||||
own outgoing mail server and it doesn't have a valid DNS PTR record, your
|
||||
email won't reach the lists unless/until the postmaster notices that your
|
||||
posts are being rejected. To avoid this problem, you should configure your
|
||||
MTA to forward posts to shorewall.net through an MTA that <u>does</u> have
|
||||
a valid PTR record (such as the one at your ISP). </b></font></big><br>
|
||||
|
||||
<h2>Please post in plain text</h2>
|
||||
A growing number of MTAs serving list subscribers are rejecting
|
||||
all HTML traffic. At least one MTA has gone so far as to blacklist
|
||||
shorewall.net "for continuous abuse" because it has been my policy
|
||||
to allow HTML in list posts!!<br>
|
||||
A growing number of MTAs serving list subscribers are
|
||||
rejecting all HTML traffic. At least one MTA has gone so far as to
|
||||
blacklist shorewall.net "for continuous abuse" because it has been my
|
||||
policy to allow HTML in list posts!!<br>
|
||||
<br>
|
||||
I think that blocking all HTML is a Draconian way to control
|
||||
spam and that the ultimate losers here are not the spammers but the
|
||||
list subscribers whose MTAs are bouncing all shorewall.net mail. As
|
||||
one list subscriber wrote to me privately "These e-mail admin's need
|
||||
to get a <i>(explitive deleted)</i> life instead of trying to rid the
|
||||
planet of HTML based e-mail". Nevertheless, to allow subscribers to receive
|
||||
list posts as must as possible, I have now configured the list server
|
||||
at shorewall.net to strip all HTML from outgoing posts. This means that
|
||||
HTML-only posts will be bounced by the list server.<br>
|
||||
I think that blocking all HTML is a Draconian way to
|
||||
control spam and that the ultimate losers here are not the spammers
|
||||
but the list subscribers whose MTAs are bouncing all shorewall.net
|
||||
mail. As one list subscriber wrote to me privately "These e-mail admin's
|
||||
need to get a <i>(explitive deleted)</i> life instead of trying to rid
|
||||
the planet of HTML based e-mail". Nevertheless, to allow subscribers
|
||||
to receive list posts as must as possible, I have now configured the
|
||||
list server at shorewall.net to strip all HTML from outgoing posts.
|
||||
This means that HTML-only posts will be bounced by the list server.<br>
|
||||
|
||||
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
|
||||
</p>
|
||||
|
||||
<h2>Other Mail Delivery Problems</h2>
|
||||
If you find that you are missing an occasional list post,
|
||||
your e-mail admin may be blocking mail whose <i>Received:</i> headers
|
||||
contain the names of certain ISPs. Again, I believe that such policies
|
||||
hurt more than they help but I'm not prepared to go so far as to start
|
||||
stripping <i>Received:</i> headers to circumvent those policies.<br>
|
||||
your e-mail admin may be blocking mail whose <i>Received:</i> headers
|
||||
contain the names of certain ISPs. Again, I believe that such policies
|
||||
hurt more than they help but I'm not prepared to go so far as to start
|
||||
stripping <i>Received:</i> headers to circumvent those policies.<br>
|
||||
|
||||
<h2 align="left">Mailing Lists Archive Search</h2>
|
||||
|
||||
@ -162,8 +171,8 @@ stand the traffic. If I catch you, you will be blacklisted.<br>
|
||||
|
||||
<h2 align="left">Shorewall CA Certificate</h2>
|
||||
If you want to trust X.509 certificates issued
|
||||
by Shoreline Firewall (such as the one used on my web site), you
|
||||
may <a href="Shorewall_CA_html.html">download and install my CA certificate</a>
|
||||
by Shoreline Firewall (such as the one used on my web site),
|
||||
you may <a href="Shorewall_CA_html.html">download and install my CA certificate</a>
|
||||
in your browser. If you don't wish to trust my certificates
|
||||
then you can either use unencrypted access when subscribing to
|
||||
Shorewall mailing lists or you can use secure access (SSL) and
|
||||
@ -173,8 +182,8 @@ accept the server's certificate when prompted by your browser.<br>
|
||||
|
||||
<p align="left">The Shorewall Users Mailing list provides a way for users
|
||||
to get answers to questions and to report problems. Information
|
||||
of general interest to the Shorewall user community is also posted
|
||||
to this list.</p>
|
||||
of general interest to the Shorewall user community is also
|
||||
posted to this list.</p>
|
||||
|
||||
<p align="left"><b>Before posting a problem report to this list, please see
|
||||
the <a href="http://www.shorewall.net/support.htm">problem
|
||||
@ -228,7 +237,7 @@ list may be found at <a
|
||||
|
||||
<p align="left">The Shorewall Development Mailing list provides a forum for
|
||||
the exchange of ideas about the future of Shorewall and for
|
||||
coordinating ongoing Shorewall Development.</p>
|
||||
coordinating ongoing Shorewall Development.</p>
|
||||
|
||||
<p align="left">To subscribe to the mailing list:<br>
|
||||
</p>
|
||||
@ -257,18 +266,21 @@ coordinating ongoing Shorewall Development.</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
||||
<p align="left">Follow the same link above that you used to subscribe
|
||||
to the list.</p>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<p align="left">Down at the bottom of that page is the following text:
|
||||
" To <b>unsubscribe</b> from <i><list name></i>, get
|
||||
a password reminder, or change your subscription options enter
|
||||
a password reminder, or change your subscription options enter
|
||||
your subscription email address:". Enter your email address
|
||||
in the box and click on the "<b>Unsubscribe</b> or edit options"
|
||||
button.</p>
|
||||
button.</p>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<p align="left">There will now be a box where you can enter your password
|
||||
and click on "Unsubscribe"; if you have forgotten your password,
|
||||
there is another button that will cause your password to be
|
||||
@ -282,14 +294,11 @@ emailed to you.</p>
|
||||
|
||||
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
|
||||
|
||||
<p align="left"><font size="2">Last updated 5/29/2003 - <a
|
||||
<p align="left"><font size="2">Last updated 6/14/2003 - <a
|
||||
href="http://www.shorewall.net/support.htm">Tom Eastep</a></font></p>
|
||||
|
||||
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
|
||||
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -7,8 +7,8 @@
|
||||
content="text/html; charset=windows-1252">
|
||||
<title>Shoreline Firewall (Shorewall) 1.4</title>
|
||||
|
||||
<base
|
||||
target="_self">
|
||||
|
||||
<base target="_self">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
@ -20,41 +20,24 @@
|
||||
|
||||
<tr>
|
||||
|
||||
<td width="100%" height="90">
|
||||
<td width="33%" height="90" valign="middle"
|
||||
align="left"><a href="http://www.cityofshoreline.com"><img
|
||||
src="images/washington.jpg" alt="" width="97" height="80" hspace="4"
|
||||
border="0">
|
||||
</a></td>
|
||||
<td valign="middle" width="34%" align="center">
|
||||
|
||||
|
||||
|
||||
<h1 align="center"> <font size="4"><i> <a
|
||||
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
|
||||
alt="Shorwall Logo" height="70" width="85" align="left"
|
||||
src="images/washington.jpg" border="0">
|
||||
|
||||
</a></i></font><a href="http://www.shorewall.net"
|
||||
target="_top"><img border="1" src="images/shorewall.jpg" width="119"
|
||||
<h1><font color="#ffffff">Shorewall 1.4</font><i><font
|
||||
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i></h1>
|
||||
</td>
|
||||
<td valign="middle">
|
||||
<h1 align="center"><a href="http://www.shorewall.net"
|
||||
target="_top"><img border="0" src="images/shorewall.jpg" width="119"
|
||||
height="38" hspace="4" alt="(Shorewall Logo)" align="right" vspace="4">
|
||||
</a></h1>
|
||||
<small><small><small><small><a
|
||||
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
|
||||
|
||||
|
||||
|
||||
<div align="center">
|
||||
|
||||
|
||||
|
||||
<h1><font color="#ffffff"> Shorewall 1.4</font><i><font
|
||||
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i><a
|
||||
href="1.3" target="_top"><font color="#ffffff"><br>
|
||||
</font></a><br>
|
||||
|
||||
|
||||
</h1>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
<p><a href="http://www.shorewall.net" target="_top"> </a> </p>
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -80,9 +63,9 @@
|
||||
|
||||
|
||||
|
||||
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
|
||||
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
|
||||
firewall that can be used on a dedicated firewall system, a multi-function
|
||||
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
|
||||
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
|
||||
that can be used on a dedicated firewall system, a multi-function
|
||||
gateway/router/server or on a standalone GNU/Linux system.</p>
|
||||
|
||||
|
||||
@ -91,26 +74,26 @@ firewall that can be used on a dedicated firewall system, a multi-functio
|
||||
<p>This program is free software; you can redistribute it and/or modify
|
||||
it
|
||||
under the terms of <a
|
||||
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
|
||||
GNU General Public License</a> as published by the Free Software
|
||||
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
|
||||
General Public License</a> as published by the Free Software
|
||||
Foundation.<br>
|
||||
|
||||
<br>
|
||||
|
||||
This program is distributed in the hope
|
||||
that it will be useful, but WITHOUT ANY
|
||||
WARRANTY; without even the implied warranty
|
||||
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
|
||||
PURPOSE. See the GNU General Public License
|
||||
for more details.<br>
|
||||
This program is distributed in the
|
||||
hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied
|
||||
warranty of MERCHANTABILITY or FITNESS
|
||||
FOR A PARTICULAR PURPOSE. See the GNU General
|
||||
Public License for more details.<br>
|
||||
|
||||
<br>
|
||||
|
||||
You should have received a copy of the
|
||||
GNU General Public License along
|
||||
with this program; if not, write to the Free
|
||||
Software Foundation, Inc., 675 Mass
|
||||
Ave, Cambridge, MA 02139, USA</p>
|
||||
You should have received a copy of
|
||||
the GNU General Public License
|
||||
along with this program; if not, write to
|
||||
the Free Software Foundation, Inc.,
|
||||
675 Mass Ave, Cambridge, MA 02139, USA</p>
|
||||
|
||||
|
||||
|
||||
@ -125,11 +108,12 @@ GNU General Public License</a> as published by the Free Software
|
||||
|
||||
|
||||
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
|
||||
If so, almost <b>NOTHING </b>on this site will apply directly to
|
||||
your setup. If you want to use the documentation that you find here, it
|
||||
is best if you uninstall what you have and install a setup that matches
|
||||
the documentation on this site. See the <a href="two-interface.htm">Two-interface
|
||||
QuickStart Guide</a> for details.<br>
|
||||
If so, almost <b>NOTHING </b>on this site will apply directly
|
||||
to your setup. If you want to use the documentation that you find here,
|
||||
it is best if you uninstall what you have and install a setup that
|
||||
matches the documentation on this site. See the <a
|
||||
href="two-interface.htm">Two-interface QuickStart Guide</a> for details.<br>
|
||||
|
||||
|
||||
<h2> Getting Started with Shorewall</h2>
|
||||
New to Shorewall? Start by selecting the <a
|
||||
@ -137,131 +121,177 @@ the documentation on this site. See the <a href="two-interface.htm">Two-inter
|
||||
match your environment and follow the step by step instructions.<br>
|
||||
|
||||
|
||||
|
||||
<h2>News</h2>
|
||||
|
||||
|
||||
|
||||
|
||||
<p><b>5/29/2003 - Shorewall-1.4.4b</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
<p><b>6/17/2003 - Shorewall-1.4.5</b><b> </b><b><img
|
||||
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
</b></p>
|
||||
|
||||
<p>Groan -- This version corrects a problem whereby the --log-level
|
||||
was not being set when logging via syslog. The most commonly reported symptom
|
||||
was that Shorewall messages were being written to the console even though
|
||||
console logging was correctly configured per <a href="FAQ.htm#faq16">FAQ
|
||||
16</a>.<br>
|
||||
<p>Problems Corrected:<br>
|
||||
</p>
|
||||
|
||||
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
<ol>
|
||||
<li>The command "shorewall debug try <directory>" now correctly
|
||||
traces the attempt.</li>
|
||||
<li>The INCLUDE directive now works properly in the zones file; previously,
|
||||
INCLUDE in that file was ignored.</li>
|
||||
<li>/etc/shorewall/routestopped records with an empty second column
|
||||
are no longer ignored.<br>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>New Features:<br>
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may
|
||||
now contain a list of addresses. If the list begins with "!' then the rule
|
||||
will take effect only if the original destination address in the connection
|
||||
request does not match any of the addresses listed.</li>
|
||||
</ol>
|
||||
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
|
||||
</b><b><img border="0" src="images/new10.gif" width="28"
|
||||
height="12" alt="(New)">
|
||||
</b></p>
|
||||
|
||||
<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
|
||||
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
|
||||
have been encountered with this set of software. The Shorewall version is
|
||||
1.4.4b plus the accumulated changes for 1.4.5.<br>
|
||||
</p>
|
||||
|
||||
<p><b>6/8/2003 - Updated Samples</b><b> </b></p>
|
||||
|
||||
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
|
||||
version 1.4.4.</p>
|
||||
|
||||
<p><b>5/29/2003 - Shorewall-1.4.4b</b><b> </b></p>
|
||||
|
||||
<p>Groan -- This version corrects a problem whereby the --log-level
|
||||
was not being set when logging via syslog. The most commonly reported symptom
|
||||
was that Shorewall messages were being written to the console even though
|
||||
console logging was correctly configured per <a href="FAQ.htm#faq16">FAQ
|
||||
16</a>.<br>
|
||||
</p>
|
||||
|
||||
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b></p>
|
||||
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed
|
||||
out that the code in 1.4.4 restricts the length of short zone names to
|
||||
4 characters. I've produced version 1.4.4a that restores the previous
|
||||
5-character limit by conditionally omitting the log rule number when
|
||||
the LOGFORMAT doesn't contain '%d'.
|
||||
|
||||
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b>
|
||||
</b></p>
|
||||
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out
|
||||
that the code in 1.4.4 restricts the length of short zone names to 4 characters.
|
||||
I've produced version 1.4.4a that restores the previous 5-character limit
|
||||
by conditionally omitting the log rule number when the LOGFORMAT doesn't
|
||||
contain '%d'.
|
||||
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
</b><b> </b></p>
|
||||
I apologize for the rapid-fire releases but since there is a potential
|
||||
configuration change required to go from 1.4.3a to 1.4.4, I decided to
|
||||
make it a full release rather than just a bug-fix release. <br>
|
||||
make it a full release rather than just a bug-fix release. <br>
|
||||
<br>
|
||||
<b> Problems corrected:</b><br>
|
||||
<b> Problems corrected:</b><br>
|
||||
|
||||
<blockquote>None.<br>
|
||||
</blockquote>
|
||||
<b> New Features:<br>
|
||||
<b> New Features:<br>
|
||||
</b>
|
||||
|
||||
<ol>
|
||||
<li>A REDIRECT- rule target has been added. This target behaves
|
||||
for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
|
||||
nat table REDIRECT rule is added but not the companion filter table ACCEPT
|
||||
rule.<br>
|
||||
<li>A REDIRECT- rule target has been added. This target
|
||||
behaves for REDIRECT in the same way as DNAT- does for DNAT in that the
|
||||
Netfilter nat table REDIRECT rule is added but not the companion filter
|
||||
table ACCEPT rule.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
|
||||
been changed to a 'printf' formatting template which accepts three arguments
|
||||
(the chain name, logging rule number and the disposition). To use LOGFORMAT
|
||||
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
|
||||
<li>The LOGMARKER variable has been renamed LOGFORMAT and
|
||||
has been changed to a 'printf' formatting template which accepts three
|
||||
arguments (the chain name, logging rule number and the disposition).
|
||||
To use LOGFORMAT with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
|
||||
set it as:<br>
|
||||
<br>
|
||||
LOGFORMAT="fp=%s:%d a=%s "<br>
|
||||
<br>
|
||||
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the LOGFORMAT
|
||||
string (up to but not including the first '%') to find log messages in the
|
||||
'show log', 'status' and 'hits' commands. This part should not be omitted
|
||||
(the LOGFORMAT should not begin with "%") and the leading part should be
|
||||
sufficiently unique for /sbin/shorewall to identify Shorewall messages.<br>
|
||||
<br>
|
||||
LOGFORMAT="fp=%s:%d a=%s "<br>
|
||||
<br>
|
||||
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the
|
||||
LOGFORMAT string (up to but not including the first '%') to find log
|
||||
messages in the 'show log', 'status' and 'hits' commands. This part should
|
||||
not be omitted (the LOGFORMAT should not begin with "%") and the leading
|
||||
part should be sufficiently unique for /sbin/shorewall to identify Shorewall
|
||||
messages.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
|
||||
the logging now takes place in the nat table rather than in the filter table.
|
||||
This way, only those connections that actually undergo DNAT or redirection
|
||||
will be logged.<br>
|
||||
<li>When logging is specified on a DNAT[-] or REDIRECT[-]
|
||||
rule, the logging now takes place in the nat table rather than in the
|
||||
filter table. This way, only those connections that actually undergo DNAT
|
||||
or redirection will be logged.<br>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
|
||||
<p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
|
||||
</p>
|
||||
This version primarily corrects the documentation included in the .tgz
|
||||
and in the .rpm. In addition: <br>
|
||||
This version primarily corrects the documentation included in
|
||||
the .tgz and in the .rpm. In addition: <br>
|
||||
|
||||
|
||||
<ol>
|
||||
<li>(This change is in 1.4.3 but is not documented) If you
|
||||
are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return
|
||||
reject replies as follows:<br>
|
||||
a) tcp - RST<br>
|
||||
b) udp - ICMP port unreachable<br>
|
||||
c) icmp - ICMP host unreachable<br>
|
||||
d) Otherwise - ICMP host prohibited<br>
|
||||
If you are running earlier software, Shorewall will follow it's traditional
|
||||
convention:<br>
|
||||
a) tcp - RST<br>
|
||||
b) Otherwise - ICMP port unreachable</li>
|
||||
<li>(This change is in 1.4.3 but is not documented) If
|
||||
you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will
|
||||
return reject replies as follows:<br>
|
||||
a) tcp - RST<br>
|
||||
b) udp - ICMP port unreachable<br>
|
||||
c) icmp - ICMP host unreachable<br>
|
||||
d) Otherwise - ICMP host prohibited<br>
|
||||
If you are running earlier software, Shorewall will follow it's
|
||||
traditional convention:<br>
|
||||
a) tcp - RST<br>
|
||||
b) Otherwise - ICMP port unreachable</li>
|
||||
<li>UDP port 135 is now silently dropped in the common.def
|
||||
chain. Remember that this chain is traversed just before a DROP or REJECT
|
||||
policy is enforced.<br>
|
||||
chain. Remember that this chain is traversed just before a DROP or REJECT
|
||||
policy is enforced.<br>
|
||||
</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
|
||||
</p>
|
||||
<b>Problems Corrected:<br>
|
||||
<b>Problems Corrected:<br>
|
||||
</b>
|
||||
|
||||
<ol>
|
||||
<li>There were several cases where Shorewall would fail to
|
||||
remove a temporary directory from /tmp. These cases have been corrected.</li>
|
||||
<li>The rules for allowing all traffic via the loopback interface
|
||||
have been moved to before the rule that drops status=INVALID packets.
|
||||
This insures that all loopback traffic is allowed even if Netfilter connection
|
||||
tracking is confused.</li>
|
||||
<li>There were several cases where Shorewall would fail
|
||||
to remove a temporary directory from /tmp. These cases have been corrected.</li>
|
||||
<li>The rules for allowing all traffic via the loopback
|
||||
interface have been moved to before the rule that drops status=INVALID
|
||||
packets. This insures that all loopback traffic is allowed even if
|
||||
Netfilter connection tracking is confused.</li>
|
||||
|
||||
|
||||
</ol>
|
||||
<b>New Features:<br>
|
||||
<b>New Features:<br>
|
||||
</b>
|
||||
|
||||
<ol>
|
||||
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a>
|
||||
now supported in the /etc/shorewall/tunnels file.</li>
|
||||
<li> <a href="6to4.htm">IPV6-IPV4 (6to4) tunnels are</a>
|
||||
now supported in the /etc/shorewall/tunnels file.</li>
|
||||
<li>You may now change the leading portion of the --log-prefix
|
||||
used by Shorewall using the LOGMARKER variable in shorewall.conf. By default,
|
||||
"Shorewall:" is used.<br>
|
||||
used by Shorewall using the LOGMARKER variable in shorewall.conf. By
|
||||
default, "Shorewall:" is used.<br>
|
||||
</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
|
||||
</p>
|
||||
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
|
||||
Ed Greshko has established a mirror in Taiwan -- Thanks
|
||||
Ed!
|
||||
|
||||
|
||||
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b> </b></p>
|
||||
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b> </b></p>
|
||||
|
||||
|
||||
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.<br>
|
||||
@ -271,10 +301,12 @@ now supported in the /etc/shorewall/tunnels file.</li>
|
||||
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
|
||||
|
||||
|
||||
|
||||
<p>The list server will be down this morning for upgrade to RH9.0.<br>
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
|
||||
</b></p>
|
||||
|
||||
@ -290,17 +322,18 @@ now supported in the /etc/shorewall/tunnels file.</li>
|
||||
|
||||
|
||||
|
||||
|
||||
<blockquote>This morning, I gave <a href="GSLUG.htm" target="_top">a
|
||||
Shorewall presentation to GSLUG</a>. The presentation
|
||||
is in HTML format but was generated from Microsoft PowerPoint and
|
||||
is best viewed using Internet Explorer (although Konqueror also seems
|
||||
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor
|
||||
Netscape work well to view the presentation.<br>
|
||||
is in HTML format but was generated from Microsoft PowerPoint and
|
||||
is best viewed using Internet Explorer (although Konqueror also seems
|
||||
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor
|
||||
Netscape work well to view the presentation.<br>
|
||||
</blockquote>
|
||||
|
||||
|
||||
|
||||
<p><b></b></p>
|
||||
|
||||
|
||||
<blockquote>
|
||||
|
||||
@ -309,6 +342,7 @@ Netscape work well to view the presentation.<br>
|
||||
|
||||
|
||||
|
||||
|
||||
</ol>
|
||||
</blockquote>
|
||||
|
||||
@ -325,12 +359,12 @@ Netscape work well to view the presentation.<br>
|
||||
border="0" src="images/leaflogo.gif" width="49" height="36"
|
||||
alt="(Leaf Logo)">
|
||||
|
||||
</a>Jacques Nilo and Eric Wolzak have
|
||||
a LEAF (router/firewall/gateway on a floppy,
|
||||
CD or compact flash) distribution called
|
||||
<i>Bering</i> that features Shorewall-1.3.14
|
||||
and Kernel-2.4.20. You can find their
|
||||
work at: <a
|
||||
</a>Jacques Nilo and Eric Wolzak
|
||||
have a LEAF (router/firewall/gateway on
|
||||
a floppy, CD or compact flash) distribution
|
||||
called <i>Bering</i> that features
|
||||
Shorewall-1.3.14 and Kernel-2.4.20. You
|
||||
can find their work at: <a
|
||||
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
|
||||
|
||||
</a></p>
|
||||
@ -346,15 +380,17 @@ Netscape work well to view the presentation.<br>
|
||||
<td width="88" bgcolor="#4b017c" valign="top"
|
||||
align="center">
|
||||
|
||||
|
||||
<form method="post"
|
||||
action="http://lists.shorewall.net/cgi-bin/htsearch">
|
||||
<strong><br>
|
||||
<font color="#ffffff"><b>Note:
|
||||
</b></font></strong><font color="#ffffff">Search is unavailable
|
||||
Daily 0200-0330 GMT.</font><br>
|
||||
<font
|
||||
color="#ffffff"><b>Note: </b></font></strong><font
|
||||
color="#ffffff">Search is unavailable Daily 0200-0330 GMT.</font><br>
|
||||
<strong></strong>
|
||||
|
||||
|
||||
|
||||
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
|
||||
<font
|
||||
face="Arial" size="-1"> <input type="text" name="words"
|
||||
@ -368,6 +404,7 @@ Netscape work well to view the presentation.<br>
|
||||
value="[http://lists.shorewall.net/pipermail/*]"> </font> </form>
|
||||
|
||||
|
||||
|
||||
<p><font color="#ffffff"><b><a
|
||||
href="http://lists.shorewall.net/htdig/search.html"><font
|
||||
color="#ffffff">Extended Search</font></a></b></font></p>
|
||||
@ -382,33 +419,36 @@ Netscape work well to view the presentation.<br>
|
||||
|
||||
</center>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<table border="0" cellpadding="5" cellspacing="0"
|
||||
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
|
||||
bgcolor="#4b017c">
|
||||
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
|
||||
<td width="100%" style="margin-top: 1px;">
|
||||
<td width="100%" style="margin-top: 1px;"
|
||||
valign="middle">
|
||||
|
||||
|
||||
|
||||
<p align="center"><a href="http://www.starlight.org"> <img
|
||||
border="4" src="images/newlog.gif" width="57" height="100" align="left"
|
||||
hspace="10">
|
||||
hspace="10" alt="(Starlight Logo)">
|
||||
|
||||
</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p align="center"><font size="4" color="#ffffff">Shorewall is free
|
||||
but if you try it and find it useful, please consider making a donation
|
||||
to
|
||||
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
|
||||
Children's Foundation.</font></a> Thanks!</font></p>
|
||||
<p align="center"><font size="4" color="#ffffff"><br>
|
||||
<font size="+2"> Shorewall is free but if you try it and find
|
||||
it useful, please consider making a donation
|
||||
to <a
|
||||
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
|
||||
Foundation.</font></a> Thanks!</font></font></p>
|
||||
|
||||
</td>
|
||||
|
||||
@ -418,7 +458,7 @@ but if you try it and find it useful, please consider making a donation
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p><font size="2">Updated 5/29/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
<p><font size="2">Updated 6/17/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
<br>
|
||||
</p>
|
||||
</body>
|
||||
|
||||
@ -28,11 +28,11 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p align="center"> <img border="3" src="images/TomNTarry.png"
|
||||
alt="Tom on the PCT - 1991" width="316" height="392">
|
||||
<p align="center"> <img border="3" src="images/Tom.jpg"
|
||||
alt="Tom - June 2003" width="640" height="480">
|
||||
</p>
|
||||
|
||||
<p align="center">Tarry & Tom -- August 2002<br>
|
||||
<p align="center">Tom -- June 2003<br>
|
||||
<br>
|
||||
</p>
|
||||
|
||||
@ -46,8 +46,8 @@
|
||||
<li>Burroughs Corporation (now <a
|
||||
href="http://www.unisys.com">Unisys</a> ) 1969 - 1980</li>
|
||||
<li><a href="http://www.tandem.com">Tandem Computers,
|
||||
Incorporated</a> (now part of the <a href="http://www.hp.com">The
|
||||
New HP</a>) 1980 - present</li>
|
||||
Incorporated</a> (now part of the <a
|
||||
href="http://www.hp.com">The New HP</a>) 1980 - present</li>
|
||||
<li>Married 1969 - no children.</li>
|
||||
|
||||
</ul>
|
||||
@ -64,35 +64,34 @@ designed and wrote Shorewall. </p>
|
||||
|
||||
<p>I telework from our <a
|
||||
href="http://lists.shorewall.net/SeattleInTheSpring.html">home</a> in <a
|
||||
href="http://www.cityofshoreline.com">Shoreline, Washington</a>
|
||||
where I live with my wife Tarry. </p>
|
||||
href="http://www.cityofshoreline.com">Shoreline, Washington</a> where
|
||||
I live with my wife Tarry. </p>
|
||||
|
||||
<p>Our current home network consists of: </p>
|
||||
|
||||
<ul>
|
||||
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB
|
||||
& 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows
|
||||
system. Serves as a PPTP server for Road Warrior access. Dual boots <a
|
||||
href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
|
||||
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
|
||||
NIC - My personal Linux System which runs Samba configured as
|
||||
a WINS server. This system also has <a
|
||||
href="http://www.vmware.com/">VMware</a> installed and can run
|
||||
both <a href="http://www.debian.org">Debian Woody</a> and <a
|
||||
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
|
||||
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM,
|
||||
40GB & 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal
|
||||
Windows system. Serves as a PPTP server for Road Warrior access. Dual
|
||||
boots <a href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
|
||||
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD,
|
||||
LNE100TX(Tulip) NIC - My personal Linux System which runs Samba.
|
||||
This system also has <a href="http://www.vmware.com/">VMware</a>
|
||||
installed and can run both <a href="http://www.debian.org">Debian
|
||||
Woody</a> and <a href="http://www.suse.com">SuSE 8.1</a> in virtual
|
||||
machines.</li>
|
||||
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100
|
||||
NIC - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP
|
||||
(Pure_ftpd), DNS server (Bind 9).</li>
|
||||
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD -
|
||||
3 LNE100TX (Tulip) and 1 TLAN NICs - Firewall running Shorewall
|
||||
1.4.4a and a DHCP server.</li>
|
||||
NIC - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache),
|
||||
FTP (Pure_ftpd), DNS server (Bind 9).</li>
|
||||
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD
|
||||
- 3 LNE100TX (Tulip) and 1 TLAN NICs - Firewall running Shorewall
|
||||
1.4.4c, a DHCP server and Samba configured as a WINS server..</li>
|
||||
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139
|
||||
NIC - My wife's personal system.</li>
|
||||
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD,
|
||||
built-in EEPRO100, EEPRO100 in expansion base and LinkSys WAC11 - My
|
||||
work system.</li>
|
||||
<li>XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC and LinkSys
|
||||
WET11 - Our Laptop.<br>
|
||||
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB
|
||||
HD, built-in EEPRO100, EEPRO100 in expansion base - My work system.</li>
|
||||
<li>XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC and
|
||||
LinkSys WET11 - Our Laptop.<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@ -106,13 +105,14 @@ both <a href="http://www.debian.org">Debian Woody</a> and <a
|
||||
|
||||
<p><a href="http://www.redhat.com"><img border="0"
|
||||
src="images/poweredby.png" width="88" height="31">
|
||||
</a><a href="http://www.compaq.com"><img border="0"
|
||||
src="images/poweredbycompaqlog0.gif" hspace="3" width="83" height="25">
|
||||
</a><a href="http://www.compaq.com"><img
|
||||
border="0" src="images/poweredbycompaqlog0.gif" hspace="3" width="83"
|
||||
height="25">
|
||||
</a><a href="http://www.pureftpd.org"><img
|
||||
border="0" src="images/pure.jpg" width="88" height="31">
|
||||
</a><font size="4"><a href="http://www.apache.org"><img
|
||||
border="0" src="images/apache_pb1.gif" hspace="2" width="170"
|
||||
height="20">
|
||||
</a><font size="4"><a
|
||||
href="http://www.apache.org"><img border="0"
|
||||
src="images/apache_pb1.gif" hspace="2" width="170" height="20">
|
||||
</a><a href="http://www.mandrakelinux.com"><img
|
||||
src="images/medbutton.png" alt="Powered by Mandrake" width="90"
|
||||
height="32">
|
||||
@ -125,20 +125,11 @@ both <a href="http://www.debian.org">Debian Woody</a> and <a
|
||||
height="75" border="0">
|
||||
</a><a href="http://www.opera.com"> </a> </font></p>
|
||||
|
||||
<p><font size="2">Last updated 5/8/2003 - </font><font size="2"> <a
|
||||
<p><font size="2">Last updated 6/15/2003 - </font><font size="2"> <a
|
||||
href="support.htm">Tom Eastep</a></font> </p>
|
||||
<font face="Trebuchet MS"><a href="copyright.htm"><font
|
||||
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas
|
||||
M. Eastep.</font></a></font><br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<font face="Trebuchet MS"><a
|
||||
href="copyright.htm"><font size="2">Copyright</font> © <font
|
||||
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -29,8 +29,8 @@
|
||||
|
||||
<p align="left"><b>Remember that updates to the mirrors are often delayed
|
||||
for 6-12 hours after an update to the primary rsync site. For HTML content,
|
||||
the main web site (<a href="http://shorewall.sf.net">http://shorewall.sf.net</a>)
|
||||
is updated at the same time as the rsync site.</b></p>
|
||||
the main web site (<a href="http://shorewall.sf.net">http://shorewall.sf.net</a>)
|
||||
is updated at the same time as the rsync site.</b></p>
|
||||
|
||||
<p align="left">The main Shorewall Web Site is <a
|
||||
href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>
|
||||
@ -43,12 +43,13 @@ is updated at the same time as the rsync site.</b></p>
|
||||
target="_top"> http://shorewall.infohiiway.com</a> (Texas, USA).</li>
|
||||
<li><a target="_top" href="http://germany.shorewall.net"> http://germany.shorewall.net</a>
|
||||
(Hamburg, Germany)</li>
|
||||
<li><a target="_top" href="http://shorewall.correofuego.com.ar">http://shorewall.correofuego.com.ar</a>
|
||||
(Martinez (Zona Norte - GBA), Argentina)</li>
|
||||
<li><a target="_top" href="http://france.shorewall.net">http://france.shorewall.net</a>
|
||||
<li><a target="_top"
|
||||
href="http://france.shorewall.net">http://france.shorewall.net</a>
|
||||
(Paris, France)</li>
|
||||
<li><a href="http://shorewall.syachile.cl" target="_top">http://shorewall.syachile.cl
|
||||
</a>(Santiago Chile)<br>
|
||||
</a>(Santiago Chile)</li>
|
||||
<li><a href="http://shorewall.greshko.com" target="_top">http://shorewall.greshko.com</a>
|
||||
(Taipei, Taiwan)<br>
|
||||
</li>
|
||||
<li><a href="http://www.shorewall.net" target="_top">http://www.shorewall.net</a>
|
||||
(Washington State, USA)<br>
|
||||
@ -69,17 +70,19 @@ is updated at the same time as the rsync site.</b></p>
|
||||
href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall</a>
|
||||
(Hamburg, Germany)</li>
|
||||
<li> <a target="_blank"
|
||||
href="ftp://shorewall.correofuego.com.ar/pub/mirrors/shorewall">ftp://shorewall.correofuego.com.ar/pub/mirrors/shorewall</a>
|
||||
(Martinez (Zona Norte - GBA), Argentina)</li>
|
||||
<li> <a target="_blank"
|
||||
href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
||||
(Paris, France)</li>
|
||||
<li><a href="ftp://shorewall.greshko.com/pub/shorewall" target="_top">ftp://shorewall.greshko.com</a>
|
||||
(Taipei, Taiwan)</li>
|
||||
<li><a href="ftp://ftp.shorewall.net/pub/shorewall" target="_blank">ftp://ftp.shorewall.net
|
||||
</a>(Washington State, USA)<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
Search results and the mailing list archives are always fetched from the
|
||||
site in Washington State.<br>
|
||||
Search results and the mailing list archives are always fetched from
|
||||
the site in Washington State.<br>
|
||||
|
||||
<p align="left"><font size="2">Last Updated 5/8/2003 - <a
|
||||
<p align="left"><font size="2">Last Updated 6/5/2003 - <a
|
||||
href="support.htm">Tom Eastep</a></font></p>
|
||||
|
||||
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
|
||||
@ -89,5 +92,8 @@ site in Washington State.<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -49,7 +49,8 @@
|
||||
</blockquote>
|
||||
|
||||
<p><a href="#DNS">6.0 DNS</a><br>
|
||||
<a href="#StartingAndStopping">7.0 Starting and Stopping the Firewall</a></p>
|
||||
<a href="#StartingAndStopping">7.0 Starting and Stopping the
|
||||
Firewall</a></p>
|
||||
|
||||
<h2><a name="Introduction"></a>1.0 Introduction</h2>
|
||||
|
||||
@ -58,18 +59,18 @@
|
||||
more about Shorewall than is contained in the <a
|
||||
href="shorewall_quickstart_guide.htm">single-address guides</a>. Because
|
||||
the range of possible applications is so broad, the Guide will give
|
||||
you general guidelines and will point you to other resources as necessary.</p>
|
||||
you general guidelines and will point you to other resources as necessary.</p>
|
||||
|
||||
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
|
||||
If you run LEAF Bering, your Shorewall configuration is NOT
|
||||
what I release -- I suggest that you consider installing a stock Shorewall
|
||||
lrp from the shorewall.net site before you proceed.</p>
|
||||
If you run LEAF Bering, your Shorewall configuration is
|
||||
NOT what I release -- I suggest that you consider installing a stock
|
||||
Shorewall lrp from the shorewall.net site before you proceed.</p>
|
||||
|
||||
<p>Shorewall requires that the iproute/iproute2 package be installed (on
|
||||
RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell if
|
||||
this package is installed by the presence of an <b>ip</b> program on your
|
||||
this package is installed by the presence of an <b>ip</b> program on your
|
||||
firewall system. As root, you can use the 'which' command to check for
|
||||
this program:</p>
|
||||
this program:</p>
|
||||
|
||||
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
|
||||
|
||||
@ -82,15 +83,15 @@ this program:</p>
|
||||
|
||||
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
|
||||
If you edit your configuration files on a Windows system,
|
||||
you must save them as Unix files if your editor supports that option
|
||||
you must save them as Unix files if your editor supports that option
|
||||
or you must run them through dos2unix before trying to use them with Shorewall.
|
||||
Similarly, if you copy a configuration file from your Windows hard drive
|
||||
to a floppy disk, you must run dos2unix against the copy before using
|
||||
it with Shorewall.</p>
|
||||
it with Shorewall.</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
|
||||
Version of dos2unix</a></li>
|
||||
Version of dos2unix</a></li>
|
||||
<li><a
|
||||
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
|
||||
of dos2unix</a></li>
|
||||
@ -100,8 +101,8 @@ of dos2unix</a></li>
|
||||
<h2 align="left"><a name="Concepts"></a>2.0 Shorewall Concepts</h2>
|
||||
|
||||
<p>The configuration files for Shorewall are contained in the directory /etc/shorewall
|
||||
-- for most setups, you will only need to deal with a few of these as described
|
||||
in this guide. Skeleton files are created during the <a
|
||||
-- for most setups, you will only need to deal with a few of these as described
|
||||
in this guide. Skeleton files are created during the <a
|
||||
href="Install.htm">Shorewall Installation Process</a>.</p>
|
||||
|
||||
<p>As each file is introduced, I suggest that you look through the actual
|
||||
@ -110,7 +111,7 @@ in this guide. Skeleton files are created during the <a
|
||||
|
||||
<p>Shorewall views the network where it is running as being composed of a
|
||||
set of <i>zones.</i> In the default installation, the following zone
|
||||
names are used:</p>
|
||||
names are used:</p>
|
||||
|
||||
<table border="0" style="border-collapse: collapse;" cellpadding="3"
|
||||
cellspacing="0" id="AutoNumber2">
|
||||
@ -140,23 +141,24 @@ names are used:</p>
|
||||
|
||||
<p>Shorewall also recognizes the firewall system as its own zone - by default,
|
||||
the firewall itself is known as <b>fw</b> but that may be changed in
|
||||
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
|
||||
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
|
||||
file. In this guide, the default name (<b>fw</b>) will be used.</p>
|
||||
|
||||
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
|
||||
to zone names. Zones are entirely what YOU make of them. That means
|
||||
that you should not expect Shorewall to do something special "because
|
||||
this is the internet zone" or "because that is the DMZ".</p>
|
||||
that you should not expect Shorewall to do something special "because
|
||||
this is the internet zone" or "because that is the DMZ".</p>
|
||||
|
||||
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
|
||||
Edit the /etc/shorewall/zones file and make any changes necessary.</p>
|
||||
Edit the /etc/shorewall/zones file and make any changes
|
||||
necessary.</p>
|
||||
|
||||
<p>Rules about what traffic to allow and what traffic to deny are expressed
|
||||
in terms of zones.</p>
|
||||
|
||||
<ul>
|
||||
<li>You express your default policy for connections from one
|
||||
zone to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
|
||||
zone to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
|
||||
</a>file.</li>
|
||||
<li>You define exceptions to those default policies in the
|
||||
<a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
|
||||
@ -168,18 +170,18 @@ zone to another zone in the<a href="Documentation.htm#Policy"> /etc/shorew
|
||||
href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html">connection
|
||||
tracking function</a> that allows what is often referred to as <i>stateful
|
||||
inspection</i> of packets. This stateful property allows firewall rules
|
||||
to be defined in terms of <i>connections</i> rather than in terms of
|
||||
packets. With Shorewall, you:</p>
|
||||
to be defined in terms of <i>connections</i> rather than in terms
|
||||
of packets. With Shorewall, you:</p>
|
||||
|
||||
<ol>
|
||||
<li> Identify the source zone.</li>
|
||||
<li> Identify the destination 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>
|
||||
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>
|
||||
add a rule. That rule is expressed in terms of the client's zone
|
||||
and the server's zone.</li>
|
||||
|
||||
</ol>
|
||||
|
||||
@ -187,9 +189,9 @@ and the server's zone.</li>
|
||||
A to the firewall and are also allowed from the firewall to zone B <font
|
||||
color="#ff6633"><b><u> DOES NOT mean that these connections are allowed
|
||||
from zone A to 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>
|
||||
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>For each connection request entering the firewall, the request is first
|
||||
checked against the /etc/shorewall/rules file. If no rule in that file
|
||||
@ -239,40 +241,40 @@ to zone B.</p>
|
||||
<p>The above policy will:</p>
|
||||
|
||||
<ol>
|
||||
<li>allow all connection requests from your local network to
|
||||
the internet</li>
|
||||
<li>allow all connection requests from your local network
|
||||
to the internet</li>
|
||||
<li>drop (ignore) all connection requests from the internet
|
||||
to your firewall or local network and log a message at the <i>info</i>
|
||||
to your firewall or local network and log a message at the <i>info</i>
|
||||
level (<a href="shorewall_logging.html">here</a> is a description of log
|
||||
levels).</li>
|
||||
<li>reject all other connection requests and log a message at
|
||||
the <i>info</i> level. When a request is rejected, the firewall
|
||||
will return an RST (if the protocol is TCP) or an ICMP port-unreachable
|
||||
packet for other protocols.</li>
|
||||
<li>reject all other connection requests and log a message
|
||||
at the <i>info</i> level. When a request is rejected, the firewall
|
||||
will return an RST (if the protocol is TCP) or an ICMP port-unreachable
|
||||
packet for other protocols.</li>
|
||||
|
||||
</ol>
|
||||
|
||||
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
|
||||
At this point, edit your /etc/shorewall/policy and make any
|
||||
changes that you wish.</p>
|
||||
changes that you wish.</p>
|
||||
|
||||
<h2 align="left"><a name="Interfaces"></a>3.0 Network Interfaces</h2>
|
||||
|
||||
<p align="left">For the remainder of this guide, we'll refer to the following
|
||||
diagram. While it may not look like your own network, it can be used
|
||||
to illustrate the important aspects of Shorewall configuration.</p>
|
||||
to illustrate the important aspects of Shorewall configuration.</p>
|
||||
|
||||
<p align="left">In this diagram:</p>
|
||||
|
||||
<ul>
|
||||
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ
|
||||
is used to isolate your internet-accessible servers from your local
|
||||
is used to isolate your internet-accessible servers from your local
|
||||
systems so that if one of those servers is compromised, you still have
|
||||
the firewall between the compromised system and your local systems. </li>
|
||||
<li>The Local Zone consists of systems Local 1, Local 2 and
|
||||
Local 3. </li>
|
||||
<li>All systems from the ISP outward comprise the Internet Zone.
|
||||
</li>
|
||||
Local 3. </li>
|
||||
<li>All systems from the ISP outward comprise the Internet
|
||||
Zone. </li>
|
||||
|
||||
</ul>
|
||||
|
||||
@ -288,12 +290,12 @@ Local 3. </li>
|
||||
<p align="left">The firewall illustrated above has three network interfaces.
|
||||
Where Internet connectivity is through a cable or DSL "Modem", the <i>External
|
||||
Interface</i> will be the Ethernet adapter that is connected to that
|
||||
"Modem" (e.g., <b>eth0</b>) <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
|
||||
"Modem" (e.g., <b>eth0</b>) <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
|
||||
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
|
||||
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
|
||||
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
|
||||
via a regular modem, your External Interface will also be <b>ppp0</b>.
|
||||
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
|
||||
via a regular modem, your External Interface will also be <b>ppp0</b>.
|
||||
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
|
||||
|
||||
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
|
||||
height="13">
|
||||
@ -304,21 +306,21 @@ If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
|
||||
<p align="left">Your <i>Local Interface</i> will be an Ethernet adapter (eth0,
|
||||
eth1 or eth2) and will be connected to a hub or switch. Your local computers
|
||||
will be connected to the same switch (note: If you have only a single
|
||||
local system, you can connect the firewall directly to the computer using
|
||||
a <i>cross-over </i> cable).</p>
|
||||
local system, you can connect the firewall directly to the computer
|
||||
using a <i>cross-over </i> cable).</p>
|
||||
|
||||
<p align="left">Your <i>DMZ Interface</i> will also be an Ethernet adapter
|
||||
(eth0, eth1 or eth2) and will be connected to a hub or switch. Your
|
||||
DMZ computers will be connected to the same switch (note: If you have
|
||||
only a single DMZ system, you can connect the firewall directly to the
|
||||
computer using a <i>cross-over </i> cable).</p>
|
||||
DMZ computers will be connected to the same switch (note: If you have
|
||||
only a single DMZ system, you can connect the firewall directly to the
|
||||
computer using a <i>cross-over </i> cable).</p>
|
||||
|
||||
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
|
||||
width="60" height="60">
|
||||
</b></u>Do not connect more than one interface to the same hub
|
||||
or switch (even for testing). It won't work the way that you expect it
|
||||
to and you will end up confused and believing that Linux networking doesn't
|
||||
work at all.</p>
|
||||
or switch (even for testing). It won't work the way that you expect
|
||||
it to and you will end up confused and believing that Linux networking
|
||||
doesn't work at all.</p>
|
||||
|
||||
<p align="left">For the remainder of this Guide, we will assume that:</p>
|
||||
|
||||
@ -377,8 +379,8 @@ to and you will end up confused and believing that Linux networking doesn't
|
||||
Edit the /etc/shorewall/interfaces file and define the network
|
||||
interfaces on your firewall and associate each interface with a zone.
|
||||
If you have a zone that is interfaced through more than one interface,
|
||||
simply include one entry for each interface and repeat the zone name as
|
||||
many times as necessary.</p>
|
||||
simply include one entry for each interface and repeat the zone name as
|
||||
many times as necessary.</p>
|
||||
|
||||
<p align="left">Example:</p>
|
||||
|
||||
@ -489,8 +491,8 @@ Know about Addressing & Routing",</i> Thomas A. Maufer, Prentice-Hall,
|
||||
|
||||
<p align="left">You will still hear the terms "Class A network", "Class B
|
||||
network" and "Class C network". In the early days of IP, networks only
|
||||
came in three sizes (there were also Class D networks but they were used
|
||||
differently):</p>
|
||||
came in three sizes (there were also Class D networks but they were
|
||||
used differently):</p>
|
||||
|
||||
<blockquote>
|
||||
<p align="left">Class A - netmask 255.0.0.0, size = 2 ** 24</p>
|
||||
@ -503,17 +505,17 @@ Know about Addressing & Routing",</i> Thomas A. Maufer, Prentice-Hall,
|
||||
<p align="left">The class of a network was uniquely determined by the value
|
||||
of the high order byte of its address so you could look at an IP address
|
||||
and immediately determine the associated <i>netmask</i>. The netmask
|
||||
is a number that when logically ANDed with an address isolates the <i>network
|
||||
is a number that when logically ANDed with an address isolates the <i>network
|
||||
number</i>; the remainder of the address is the <i>host number</i>.
|
||||
For example, in the Class C address 192.0.2.14, the network number is
|
||||
hex C00002 and the host number is hex 0E.</p>
|
||||
For example, in the Class C address 192.0.2.14, the network number is
|
||||
hex C00002 and the host number is hex 0E.</p>
|
||||
|
||||
<p align="left">As the internet grew, it became clear that such a gross partitioning
|
||||
of the 32-bit address space was going to be very limiting (early on, large
|
||||
corporations and universities were assigned their own class A network!).
|
||||
After some false starts, the current technique of <i>subnetting</i> these
|
||||
networks into smaller <i>subnetworks</i> evolved; that technique is referred
|
||||
to as <i>Classless InterDomain Routing</i> (CIDR). Today, any system that
|
||||
of the 32-bit address space was going to be very limiting (early on, large
|
||||
corporations and universities were assigned their own class A network!).
|
||||
After some false starts, the current technique of <i>subnetting</i> these
|
||||
networks into smaller <i>subnetworks</i> evolved; that technique is referred
|
||||
to as <i>Classless InterDomain Routing</i> (CIDR). Today, any system that
|
||||
you are likely to work with will understand CIDR and Class-based networking
|
||||
is largely a thing of the past.</p>
|
||||
|
||||
@ -541,8 +543,8 @@ to as
|
||||
|
||||
<p align="left">As you can see by this definition, in each subnet of size
|
||||
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that
|
||||
can be assigned to hosts). The first and last address in the subnet
|
||||
are used for the subnet address and subnet broadcast address respectively.
|
||||
can be assigned to hosts). The first and last address in the subnet
|
||||
are used for the subnet address and subnet broadcast address respectively.
|
||||
Consequently, small subnetworks are more wasteful of IP addresses than
|
||||
are large ones. </p>
|
||||
|
||||
@ -638,7 +640,7 @@ are used for the subnet address and subnet broadcast address respectively.
|
||||
<p align="left">You will notice that the above table also contains a column
|
||||
for (32 - log2 <b>n</b>). That number is the <i>Variable Length Subnet
|
||||
Mask</i> for a network of size <b>n</b>. From the above table, we
|
||||
can derive the following one which is a little easier to use.</p>
|
||||
can derive the following one which is a little easier to use.</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="1" cellpadding="2" style="border-collapse: collapse;"
|
||||
@ -735,8 +737,8 @@ can derive the following one which is a little easier to use.</p>
|
||||
|
||||
<p align="left">The subnet's mask (also referred to as its <i>netmask) </i>is
|
||||
simply a 32-bit number with the first "VLSM" bits set to one and the
|
||||
remaining bits set to zero. For example, for a subnet of size 64, the
|
||||
subnet mask has 26 leading one bits:</p>
|
||||
remaining bits set to zero. For example, for a subnet of size 64,
|
||||
the subnet mask has 26 leading one bits:</p>
|
||||
|
||||
<blockquote>
|
||||
<p align="left">11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0
|
||||
@ -745,14 +747,14 @@ can derive the following one which is a little easier to use.</p>
|
||||
|
||||
<p align="left">The subnet mask has the property that if you logically AND
|
||||
the subnet mask with an address in the subnet, the result is the subnet
|
||||
address. Just as important, if you logically AND the subnet mask with
|
||||
an address outside the subnet, the result is NOT the subnet address.
|
||||
As we will see below, this property of subnet masks is very useful in
|
||||
routing.</p>
|
||||
address. Just as important, if you logically AND the subnet mask
|
||||
with an address outside the subnet, the result is NOT the subnet address.
|
||||
As we will see below, this property of subnet masks is very useful
|
||||
in routing.</p>
|
||||
|
||||
<p align="left">For a subnetwork whose address is <b>a.b.c.d</b> and whose
|
||||
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork
|
||||
as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>. </p>
|
||||
as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>. </p>
|
||||
|
||||
<p align="left">Example:</p>
|
||||
|
||||
@ -821,8 +823,8 @@ as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.
|
||||
<p align="left">Later in this guide, you will see the notation <b>a.b.c.d/v</b>
|
||||
used to describe the ip configuration of a network interface (the 'ip'
|
||||
utility also uses this syntax). This simply means that the interface
|
||||
is configured with ip address <b>a.b.c.d</b> and with the netmask that
|
||||
corresponds to VLSM <b>/v</b>.</p>
|
||||
is configured with ip address <b>a.b.c.d</b> and with the netmask that
|
||||
corresponds to VLSM <b>/v</b>.</p>
|
||||
|
||||
<p align="left">Example: 192.0.2.65/29</p>
|
||||
|
||||
@ -846,9 +848,10 @@ corresponds to VLSM <b>/v</b>.</p>
|
||||
The first three routes are <i>host routes</i> since they indicate
|
||||
how to get to a single host. In the 'netstat' output this can be seen
|
||||
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the
|
||||
Flags column. The remainder are 'net' routes since they tell the kernel
|
||||
how to route packets to a subnetwork. The last route is the <i>default route</i>
|
||||
and the gateway mentioned in that route is called the <i>default gateway</i>.</p>
|
||||
Flags column. The remainder are 'net' routes since they tell the kernel
|
||||
how to route packets to a subnetwork. The last route is the <i>default
|
||||
route</i> and the gateway mentioned in that route is called the <i>default
|
||||
gateway</i>.</p>
|
||||
|
||||
<p align="left">When the kernel is trying to send a packet to IP address
|
||||
<b>A</b>, it starts at the top of the routing table and:</p>
|
||||
@ -906,8 +909,8 @@ eth2.</p>
|
||||
|
||||
<p align="left">One more thing needs to be emphasized -- all outgoing packet
|
||||
are sent using the routing table and reply packets are not a special
|
||||
case. There seems to be a common mis-conception whereby people think
|
||||
that request packets are like salmon and contain a genetic code that
|
||||
case. There seems to be a common mis-conception whereby people think
|
||||
that request packets are like salmon and contain a genetic code that
|
||||
is magically transferred to reply packets so that the replies follow
|
||||
the reverse route taken by the request. That isn't the case; the replies
|
||||
may take a totally different route back to the client than was taken by
|
||||
@ -956,7 +959,7 @@ to the card itself. </p>
|
||||
<p align="left">In order to avoid having to exchange ARP information each
|
||||
time that an IP packet is to be sent, systems maintain an <i>ARP cache</i>
|
||||
of IP<->MAC correspondences. You can see the ARP cache on your
|
||||
system (including your Windows system) using the 'arp' command:</p>
|
||||
system (including your Windows system) using the 'arp' command:</p>
|
||||
|
||||
<blockquote>
|
||||
<div align="left">
|
||||
@ -979,9 +982,9 @@ system (including your Windows system) using the 'arp' command:</p>
|
||||
Registries</i> (RIRs). For example, allocation for the Americas and for
|
||||
sub-Sahara Africa is delegated to the <i><a
|
||||
href="http://www.arin.net">American Registry for Internet Numbers</a>
|
||||
</i>(ARIN). These RIRs may in turn delegate to national registries. Most
|
||||
of us don't deal with these registrars but rather get our IP addresses
|
||||
from our ISP.</p>
|
||||
</i>(ARIN). These RIRs may in turn delegate to national registries. Most
|
||||
of us don't deal with these registrars but rather get our IP addresses
|
||||
from our ISP.</p>
|
||||
|
||||
<p align="left">It's a fact of life that most of us can't afford as many
|
||||
Public IP addresses as we have devices to assign them to so we end up making
|
||||
@ -996,8 +999,8 @@ ranges for this purpose:</p>
|
||||
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
|
||||
to as <i>non-routable</i> because the Internet backbone routers don't
|
||||
forward packets which have an RFC-1918 destination address. This is
|
||||
understandable given that anyone can select any of these addresses
|
||||
for their private use.</p>
|
||||
understandable given that anyone can select any of these addresses
|
||||
for their private use.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1034,8 +1037,8 @@ more organizations (including ISPs) are beginning to use RFC 1918 addresses
|
||||
<div align="left">
|
||||
<p align="left">The choice of how to set up your network depends primarily
|
||||
on how many Public IP addresses you have vs. how many addressable
|
||||
entities you have in your network. Regardless of how many addresses
|
||||
you have, your ISP will handle that set of addresses in one of two
|
||||
entities you have in your network. Regardless of how many addresses
|
||||
you have, your ISP will handle that set of addresses in one of two
|
||||
ways:</p>
|
||||
</div>
|
||||
|
||||
@ -1067,7 +1070,7 @@ ways:</p>
|
||||
height="13" alt="">
|
||||
If you are using the Debian package, please check your shorewall.conf
|
||||
file to ensure that the following are set correctly; if they are not,
|
||||
change them appropriately:<br>
|
||||
change them appropriately:<br>
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
@ -1084,12 +1087,12 @@ change them appropriately:<br>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Let's assume that your ISP has assigned you the subnet 192.0.2.64/28
|
||||
routed through 192.0.2.65. That means that you have IP addresses 192.0.2.64
|
||||
- 192.0.2.79 and that your firewall's external IP address is 192.0.2.65.
|
||||
Your ISP has also told you that you should use a netmask of 255.255.255.0
|
||||
(so your /28 is part of a larger /24). With this many IP addresses,
|
||||
you are able to subnet your /28 into two /29's and set up your network
|
||||
as shown in the following diagram.</p>
|
||||
routed through 192.0.2.65. That means that you have IP addresses
|
||||
192.0.2.64 - 192.0.2.79 and that your firewall's external IP address is
|
||||
192.0.2.65. Your ISP has also told you that you should use a netmask
|
||||
of 255.255.255.0 (so your /28 is part of a larger /24). With this
|
||||
many IP addresses, you are able to subnet your /28 into two /29's
|
||||
and set up your network as shown in the following diagram.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1109,10 +1112,10 @@ the local network would be 192.0.2.73.</p>
|
||||
<p align="left">Notice that this arrangement is rather wasteful of public
|
||||
IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
|
||||
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses
|
||||
and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
|
||||
and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
|
||||
Nevertheless, it shows how subnetting can work and if we were dealing
|
||||
with a /24 rather than a /28 network, the use of 6 IP addresses out
|
||||
of 256 would be justified because of the simplicity of the setup.</p>
|
||||
of 256 would be justified because of the simplicity of the setup.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1144,7 +1147,7 @@ the connecting of multiple firewall/router interfaces to the same hub
|
||||
or switch. When an ARP request for one of the firewall/router's IP addresses
|
||||
is sent by another system connected to the hub/switch, all of the firewall's
|
||||
interfaces that connect to the hub/switch can respond! It is then
|
||||
a race as to which "here-is" response reaches the sender first.</p>
|
||||
a race as to which "here-is" response reaches the sender first.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1167,14 +1170,14 @@ IP addresses to set up our networks as shown in the preceding example
|
||||
<div align="left">
|
||||
<p align="left"><b>For the remainder of this section, assume that your ISP
|
||||
has assigned you IP addresses 192.0.2.176-180 and has told you to
|
||||
use netmask 255.255.255.0 and default gateway 192.0.2.254.</b></p>
|
||||
use netmask 255.255.255.0 and default gateway 192.0.2.254.</b></p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Clearly, that set of addresses doesn't comprise a subnetwork
|
||||
and there aren't enough addresses for all of the network interfaces.
|
||||
There are four different techniques that can be used to work around
|
||||
this problem.</p>
|
||||
this problem.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1211,18 +1214,18 @@ these will be discussed in the sections that follow.</p>
|
||||
<p align="left">With SNAT, an internal LAN segment is configured using RFC
|
||||
1918 addresses. When a host <b>A </b>on this internal segment initiates
|
||||
a connection to host <b>B</b> on the internet, the firewall/router
|
||||
rewrites the IP header in the request to use one of your public IP
|
||||
addresses as the source address. When <b>B</b> responds and the response
|
||||
is received by the firewall, the firewall changes the destination address
|
||||
back to the RFC 1918 address of <b>A</b> and forwards the response back
|
||||
to <b>A.</b></p>
|
||||
rewrites the IP header in the request to use one of your public IP
|
||||
addresses as the source address. When <b>B</b> responds and the response
|
||||
is received by the firewall, the firewall changes the destination
|
||||
address back to the RFC 1918 address of <b>A</b> and forwards the response
|
||||
back to <b>A.</b></p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Let's suppose that you decide to use SNAT on your local zone
|
||||
and use public address 192.0.2.176 as both your firewall's external
|
||||
IP address and the source IP address of internet requests sent from
|
||||
that zone.</p>
|
||||
that zone.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1238,9 +1241,9 @@ that zone.</p>
|
||||
|
||||
<div align="left"> <img border="0" src="images/BD21298_2.gif"
|
||||
width="13" height="13">
|
||||
The systems in the local zone would be configured with a
|
||||
default gateway of 192.168.201.1 (the IP address of the firewall's
|
||||
local interface).</div>
|
||||
The systems in the local zone would be configured with
|
||||
a default gateway of 192.168.201.1 (the IP address of the firewall's
|
||||
local interface).</div>
|
||||
|
||||
<div align="left"> </div>
|
||||
|
||||
@ -1274,10 +1277,10 @@ local interface).</div>
|
||||
<p align="left">This example used the normal technique of assigning the same
|
||||
public IP address for the firewall external interface and for SNAT.
|
||||
If you wanted to use a different IP address, you would either have
|
||||
to use your distributions network configuration tools to add that IP
|
||||
address to the external interface or you could set ADD_SNAT_ALIASES=Yes
|
||||
in /etc/shorewall/shorewall.conf and Shorewall will add the address for
|
||||
you.</p>
|
||||
to use your distributions network configuration tools to add that
|
||||
IP address to the external interface or you could set ADD_SNAT_ALIASES=Yes
|
||||
in /etc/shorewall/shorewall.conf and Shorewall will add the address for
|
||||
you.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1294,9 +1297,9 @@ you.</p>
|
||||
<div align="left">
|
||||
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
|
||||
height="13">
|
||||
Suppose that your daughter wants to run a web server on
|
||||
her system "Local 3". You could allow connections to the internet to
|
||||
her server by adding the following entry in <a
|
||||
Suppose that your daughter wants to run a web server
|
||||
on her system "Local 3". You could allow connections to the internet
|
||||
to her server by adding the following entry in <a
|
||||
href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
|
||||
</div>
|
||||
|
||||
@ -1335,8 +1338,8 @@ her server by adding the following entry in <a
|
||||
href="http://192.0.2.176"> http://192.0.2.176</a> (the firewall's external
|
||||
IP address) and the firewall will rewrite the destination IP address
|
||||
to 192.168.201.4 (your daughter's system) and forward the request.
|
||||
When your daughter's server responds, the firewall will rewrite the
|
||||
source address back to 192.0.2.176 and send the response back to <b>A.</b></p>
|
||||
When your daughter's server responds, the firewall will rewrite the
|
||||
source address back to 192.0.2.176 and send the response back to <b>A.</b></p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1388,14 +1391,14 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
|
||||
system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned
|
||||
an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface
|
||||
on the firewall. That address and netmask isn't relevant - just be
|
||||
sure it doesn't overlap another subnet that you've defined.</div>
|
||||
sure it doesn't overlap another subnet that you've defined.</div>
|
||||
|
||||
<div align="left"> </div>
|
||||
|
||||
<div align="left"> <img border="0" src="images/BD21298_2.gif"
|
||||
width="13" height="13">
|
||||
The Shorewall configuration of Proxy ARP is done using the
|
||||
<a href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
|
||||
The Shorewall configuration of Proxy ARP is done using
|
||||
the <a href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
|
||||
|
||||
<div align="left">
|
||||
<blockquote>
|
||||
@ -1433,14 +1436,14 @@ sure it doesn't overlap another subnet that you've defined.</div>
|
||||
|
||||
<p align="left">The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
|
||||
to have the IP addresses shown but should have the same default gateway
|
||||
as the firewall itself -- namely 192.0.2.254. In other words, they should
|
||||
be configured just like they would be if they were parallel to the firewall
|
||||
rather than behind it.<br>
|
||||
as the firewall itself -- namely 192.0.2.254. In other words, they should
|
||||
be configured just like they would be if they were parallel to the firewall
|
||||
rather than behind it.<br>
|
||||
</p>
|
||||
|
||||
<p><font color="#ff0000"><b>NOTE: Do not add the Proxy ARP'ed address(es)
|
||||
(192.0.2.177 and 192.0.2.178 in the above example) to the external interface
|
||||
(eth0 in this example) of the firewall.</b></font><br>
|
||||
(192.0.2.177 and 192.0.2.178 in the above example) to the external interface
|
||||
(eth0 in this example) of the firewall.</b></font><br>
|
||||
</p>
|
||||
|
||||
<div align="left"> </div>
|
||||
@ -1454,18 +1457,18 @@ rather than behind it.<br>
|
||||
<div align="left">
|
||||
<p align="left">A word of warning is in order here. ISPs typically configure
|
||||
their routers with a long ARP cache timeout. If you move a system from
|
||||
parallel to your firewall to behind your firewall with Proxy ARP, it
|
||||
will probably be HOURS before that system can communicate with the internet.
|
||||
There are a couple of things that you can try:<br>
|
||||
parallel to your firewall to behind your firewall with Proxy ARP,
|
||||
it will probably be HOURS before that system can communicate with the
|
||||
internet. There are a couple of things that you can try:<br>
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP
|
||||
Illustrated, Vol 1</i> reveals that a <br>
|
||||
<br>
|
||||
"gratuitous" ARP packet should cause the ISP's router to refresh their
|
||||
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
|
||||
MAC address for its own IP; in addition to ensuring that the IP address
|
||||
"gratuitous" ARP packet should cause the ISP's router to refresh
|
||||
their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
|
||||
the MAC address for its own IP; in addition to ensuring that the IP address
|
||||
isn't a duplicate,...<br>
|
||||
<br>
|
||||
"if the host sending the gratuitous ARP has just changed its hardware
|
||||
@ -1473,27 +1476,27 @@ rather than behind it.<br>
|
||||
cache for the old hardware address to update its ARP cache entry accordingly."<br>
|
||||
<br>
|
||||
Which is, of course, exactly what you want to do when you switch
|
||||
a host from being exposed to the Internet to behind Shorewall using proxy
|
||||
ARP (or static NAT for that matter). Happily enough, recent versions of
|
||||
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
|
||||
a host from being exposed to the Internet to behind Shorewall using proxy
|
||||
ARP (or static NAT for that matter). Happily enough, recent versions of
|
||||
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
|
||||
<br>
|
||||
<font color="#009900"><b>arping -U -I <net if> <newly
|
||||
proxied IP></b></font><br>
|
||||
proxied IP></b></font><br>
|
||||
<font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for
|
||||
example</b></font><br>
|
||||
example</b></font><br>
|
||||
<br>
|
||||
Stevens goes on to mention that not all systems respond correctly
|
||||
to gratuitous ARPs, but googling for "arping -U" seems to support the idea
|
||||
that it works most of the time.<br>
|
||||
to gratuitous ARPs, but googling for "arping -U" seems to support the
|
||||
idea that it works most of the time.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>You can call your ISP and ask them to purge the stale ARP
|
||||
cache entry but many either can't or won't purge individual entries.</li>
|
||||
cache entry but many either can't or won't purge individual entries.</li>
|
||||
|
||||
</ol>
|
||||
You can determine if your ISP's gateway ARP cache is stale using
|
||||
ping and tcpdump. Suppose that we suspect that the gateway router has
|
||||
a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump
|
||||
a stale ARP cache entry for 192.0.2.177. On the firewall, run tcpdump
|
||||
as follows:</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1501,12 +1504,12 @@ cache entry but many either can't or won't purge individual entries.</li>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
|
||||
will assume is 130.252.100.254):</p>
|
||||
<p align="left">Now from 192.0.2.177, ping the ISP's gateway (which we
|
||||
will assume is 192.0.2.254):</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> <b><font color="#009900">ping 130.252.100.254</font></b></pre>
|
||||
<pre> <b><font color="#009900">ping 192.0.2.254</font></b></pre>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@ -1521,10 +1524,10 @@ cache entry but many either can't or won't purge individual entries.</li>
|
||||
<div align="left">
|
||||
<p align="left">Notice that the source MAC address in the echo request is
|
||||
different from the destination MAC address in the echo reply!! In
|
||||
this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
|
||||
0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the
|
||||
gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ
|
||||
1 rather than with the firewall's eth0.</p>
|
||||
this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC
|
||||
while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words,
|
||||
the gateway's ARP cache still associates 192.0.2.177 with the NIC
|
||||
in DMZ 1 rather than with the firewall's eth0.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1535,9 +1538,9 @@ gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ
|
||||
<p align="left">With static NAT, you assign local systems RFC 1918 addresses
|
||||
then establish a one-to-one mapping between those addresses and public
|
||||
IP addresses. For outgoing connections SNAT (Source Network Address
|
||||
Translation) occurs and on incoming connections DNAT (Destination Network
|
||||
Address Translation) occurs. Let's go back to our earlier example involving
|
||||
your daughter's web server running on system Local 3.</p>
|
||||
Translation) occurs and on incoming connections DNAT (Destination
|
||||
Network Address Translation) occurs. Let's go back to our earlier example
|
||||
involving your daughter's web server running on system Local 3.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1549,7 +1552,7 @@ gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ
|
||||
<div align="left">
|
||||
<p align="left">Recall that in this setup, the local network is using SNAT
|
||||
and is sharing the firewall external IP (192.0.2.176) for outbound
|
||||
connections. This is done with the following entry in /etc/shorewall/masq:</p>
|
||||
connections. This is done with the following entry in /etc/shorewall/masq:</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -1577,7 +1580,7 @@ connections. This is done with the following entry in /etc/shorewall/masq:
|
||||
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
|
||||
height="13">
|
||||
Suppose now that you have decided to give your daughter
|
||||
her own IP address (192.0.2.179) for both inbound and outbound connections.
|
||||
her own IP address (192.0.2.179) for both inbound and outbound connections.
|
||||
You would do that by adding an entry in <a
|
||||
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
|
||||
</div>
|
||||
@ -1651,6 +1654,82 @@ her own IP address (192.0.2.179) for both inbound and outbound connection
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<div align="left">
|
||||
<div align="left">
|
||||
<p align="left">A word of warning is in order here. ISPs typically configure
|
||||
their routers with a long ARP cache timeout. If you move a system from
|
||||
parallel to your firewall to behind your firewall with static NAT,
|
||||
it will probably be HOURS before that system can communicate with the
|
||||
internet. There are a couple of things that you can try:<br>
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
|
||||
Vol 1</i> reveals that a <br>
|
||||
<br>
|
||||
"gratuitous" ARP packet should cause the ISP's router to refresh
|
||||
their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
|
||||
the MAC address for its own IP; in addition to ensuring that the IP address
|
||||
isn't a duplicate,...<br>
|
||||
<br>
|
||||
"if the host sending the gratuitous ARP has just changed its hardware
|
||||
address..., this packet causes any other host...that has an entry in its
|
||||
cache for the old hardware address to update its ARP cache entry accordingly."<br>
|
||||
<br>
|
||||
Which is, of course, exactly what you want to do when you switch
|
||||
a host from being exposed to the Internet to behind Shorewall using proxy
|
||||
ARP (or static NAT for that matter). Happily enough, recent versions of
|
||||
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
|
||||
<br>
|
||||
<font color="#009900"><b>arping -U -I <net if> <newly
|
||||
proxied IP></b></font><br>
|
||||
<font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for
|
||||
example</b></font><br>
|
||||
<br>
|
||||
Stevens goes on to mention that not all systems respond correctly
|
||||
to gratuitous ARPs, but googling for "arping -U" seems to support the
|
||||
idea that it works most of the time.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>You can call your ISP and ask them to purge the stale ARP cache
|
||||
entry but many either can't or won't purge individual entries.</li>
|
||||
</ol>
|
||||
You can determine if your ISP's gateway ARP cache is stale using
|
||||
ping and tcpdump. Suppose that we suspect that the gateway router has
|
||||
a stale ARP cache entry for 209.0.2.179. On the firewall, run tcpdump
|
||||
as follows:</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Now from the 192.168.201.4, ping the ISP's gateway (which
|
||||
we will assume is 192.0.2.254):</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> <b><font color="#009900">ping 192.0.2.254</font></b></pre>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">We can now observe the tcpdump output:</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> 13:35:12.159321 <u>0:4:e2:20:20:33</u> 0:0:77:95:dd:19 ip 98: 192.0.2.179 > 192.0.2.254: icmp: echo request (DF)<br> 13:35:12.207615 0:0:77:95:dd:19 <u>0:c0:a8:50:b2:57</u> ip 98: 192.0.2.254 > 192.0.2.179 : icmp: echo reply</pre>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Notice that the source MAC address in the echo request is
|
||||
different from the destination MAC address in the echo reply!! In
|
||||
this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC
|
||||
while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words,
|
||||
the gateway's ARP cache still associates 192.0.2.179 with the NIC
|
||||
in the local zone rather than with the firewall's eth0.</p>
|
||||
</div>
|
||||
|
||||
<h3 align="left"><a name="Rules"></a>5.3 Rules</h3>
|
||||
</div>
|
||||
|
||||
@ -1658,11 +1737,11 @@ her own IP address (192.0.2.179) for both inbound and outbound connection
|
||||
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
|
||||
height="13">
|
||||
With the default policies, your local systems (Local 1-3)
|
||||
can access any servers on the internet and the DMZ can't access any
|
||||
other host (including the firewall). With the exception of <a
|
||||
can access any servers on the internet and the DMZ can't access any
|
||||
other host (including the firewall). With the exception of <a
|
||||
href="#DNAT">DNAT rules</a> which cause address translation and allow
|
||||
the translated connection request to pass through the firewall, the
|
||||
way to allow connection requests through your firewall is to use ACCEPT
|
||||
way to allow connection requests through your firewall is to use ACCEPT
|
||||
rules.</p>
|
||||
</div>
|
||||
|
||||
@ -1961,9 +2040,9 @@ I prefer to use NAT only in cases where a system that is part of an RFC
|
||||
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
|
||||
height="13">
|
||||
If you haven't already, it would be a good idea to browse
|
||||
through <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>
|
||||
just to see if there is anything there that might be of interest.
|
||||
You might also want to look at the other configuration files that
|
||||
through <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>
|
||||
just to see if there is anything there that might be of interest.
|
||||
You might also want to look at the other configuration files that
|
||||
you haven't touched yet just to get a feel for the other things that
|
||||
Shorewall can do.</p>
|
||||
</div>
|
||||
@ -2366,11 +2445,11 @@ DNS servers. You can combine the two into a single BIND 9 server using
|
||||
<div align="left">
|
||||
<p align="left">Suppose that your domain is foobar.net and you want the two
|
||||
DMZ systems named www.foobar.net and mail.foobar.net and you want
|
||||
the three local systems named "winken.foobar.net, blinken.foobar.net
|
||||
and nod.foobar.net. You want your firewall to be known as firewall.foobar.net
|
||||
the three local systems named "winken.foobar.net, blinken.foobar.net
|
||||
and nod.foobar.net. You want your firewall to be known as firewall.foobar.net
|
||||
externally and it's interface to the local network to be know as gateway.foobar.net
|
||||
and its interface to the dmz as dmz.foobar.net. Let's have the DNS
|
||||
server on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
|
||||
server on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
@ -2384,7 +2463,7 @@ server on 192.0.2.177 which will also be known by the name ns1.foobar.net.
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre>#<br># This is the view presented to our internal systems<br>#<br><br>view "internal" {<br> #<br> # These are the clients that see this view<br> #<br> match-clients { 192.168.201.0/29;<br> 192.168.202.0/29;<br> 127.0.0/24;<br> 192.0.2.176/32; <br> 192.0.2.178/32;<br> 192.0.2.179/32;<br> 192.0.2.180/32; };<br> #<br> # If this server can't complete the request, it should use outside<br> # servers to do so<br> #<br> recursion yes;<br><br> zone "." in {<br> type hint;<br> file "int/root.cache";<br> };<br><br> zone "foobar.net" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.foobar";<br> };<br><br> zone "0.0.127.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.127.0.0"; <br> };<br><br> zone "201.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.201";<br> };<br><br> zone "202.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.202";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.176";<br> };<br> (or status NAT for that matter)<br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.206.124.146.179";<br> };<br><br>};<br>#<br># This is the view that we present to the outside world<br>#<br>view "external" {<br> match-clients { any; };<br> #<br> # If we can't answer the query, we tell the client so<br> #<br> recursion no;<br><br> zone "foobar.net" in {<br> type master;<br> notify yes;<br> allow-update {none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "ext/db.foobar";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.176";<br> };<br><br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.179";<br> };<br>};</pre>
|
||||
<pre>#<br># This is the view presented to our internal systems<br>#<br><br>view "internal" {<br> #<br> # These are the clients that see this view<br> #<br> match-clients { 192.168.201.0/29;<br> 192.168.202.0/29;<br> 127.0.0.0/8;<br> 192.0.2.176/32; <br> 192.0.2.178/32;<br> 192.0.2.179/32;<br> 192.0.2.180/32; };<br> #<br> # If this server can't complete the request, it should use outside<br> # servers to do so<br> #<br> recursion yes;<br><br> zone "." in {<br> type hint;<br> file "int/root.cache";<br> };<br><br> zone "foobar.net" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.foobar";<br> };<br><br> zone "0.0.127.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.127.0.0"; <br> };<br><br> zone "201.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.201";<br> };<br><br> zone "202.168.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "int/db.192.168.202";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.176";<br> };<br> (or status NAT for that matter)<br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify no;<br> allow-update { none; };<br> file "db.206.124.146.179";<br> };<br><br>};<br>#<br># This is the view that we present to the outside world<br>#<br>view "external" {<br> match-clients { any; };<br> #<br> # If we can't answer the query, we tell the client so<br> #<br> recursion no;<br><br> zone "foobar.net" in {<br> type master;<br> notify yes;<br> allow-update {none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "ext/db.foobar";<br> };<br><br> zone "176.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.176";<br> };<br><br> zone "177.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.177";<br> };<br><br> zone "178.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.178";<br> };<br><br> zone "179.2.0.192.in-addr.arpa" in {<br> type master;<br> notify yes;<br> allow-update { none; };<br> allow-transfer { <i><secondary NS IP></i>; };<br> file "db.192.0.2.179";<br> };<br>};</pre>
|
||||
</div>
|
||||
</blockquote>
|
||||
</div>
|
||||
@ -2497,7 +2576,7 @@ server on 192.0.2.177 which will also be known by the name ns1.foobar.net.
|
||||
<div align="left">
|
||||
<p align="left">The firewall is started using the "shorewall start" command
|
||||
and stopped using "shorewall stop". When the firewall is stopped,
|
||||
routing is enabled on those hosts that have an entry in <a
|
||||
routing is enabled on those hosts that have an entry in <a
|
||||
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
|
||||
running firewall may be restarted using the "shorewall restart" command.
|
||||
If you want to totally remove any trace of Shorewall from your Netfilter
|
||||
@ -2508,36 +2587,27 @@ routing is enabled on those hosts that have an entry in <a
|
||||
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
|
||||
height="13">
|
||||
Edit the /etc/shorewall/routestopped file and configure
|
||||
those systems that you want to be able to access the firewall when
|
||||
it is stopped.</p>
|
||||
those systems that you want to be able to access the firewall when
|
||||
it is stopped.</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
|
||||
the internet, do not issue a "shorewall stop" command unless you have
|
||||
added an entry for the IP address that you are connected from to
|
||||
<a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
|
||||
<a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
|
||||
Also, I don't recommend using "shorewall restart"; it is better to create
|
||||
an <i><a href="Documentation.htm#Configs">alternate configuration</a></i>
|
||||
and test it using the <a href="Documentation.htm#Starting">"shorewall
|
||||
try" command</a>.</p>
|
||||
</div>
|
||||
|
||||
<p align="left"><font size="2">Last updated 5/3/2003 - <a
|
||||
<p align="left"><font size="2">Last updated 6/7/2003 - <a
|
||||
href="support.htm">Tom Eastep</a></font></p>
|
||||
|
||||
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
|
||||
Thomas M. Eastep</font></a></p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
Thomas M. Easte</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -20,23 +20,23 @@
|
||||
|
||||
<tr>
|
||||
|
||||
<td width="100%" height="90">
|
||||
<td width="33%" height="90" valign="middle"
|
||||
align="left"><a href="http://www.cityofshoreline.com"><img
|
||||
src="images/washington.jpg" alt="" width="97" height="80" hspace="4"
|
||||
border="0">
|
||||
</a></td>
|
||||
<td valign="middle" width="34%" align="center">
|
||||
|
||||
|
||||
|
||||
<h1 align="center"> <font size="4"><i> <a
|
||||
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
|
||||
alt="Shorwall Logo" height="70" width="85" align="left"
|
||||
src="images/washington.jpg" border="0">
|
||||
|
||||
</a></i></font><font color="#ffffff">Shorewall 1.4
|
||||
- <font size="4">"<i>iptables made easy"</i></font></font><br>
|
||||
<a target="_top" href="1.3/index.html"><font
|
||||
color="#ffffff"> </font></a><a target="_top"
|
||||
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small><br>
|
||||
</small></small></small></font></a>
|
||||
|
||||
</h1>
|
||||
<h1><font color="#ffffff">Shorewall 1.4</font><i><font
|
||||
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i></h1>
|
||||
</td>
|
||||
<td valign="middle">
|
||||
<h1 align="center"><a href="http://www.shorewall.net"
|
||||
target="_top"><br>
|
||||
</a></h1>
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -80,20 +80,20 @@ GNU General Public License</a> as published by the Free Software
|
||||
|
||||
<br>
|
||||
|
||||
This program is distributed in the hope
|
||||
that it will be useful, but WITHOUT ANY
|
||||
WARRANTY; without even the implied warranty
|
||||
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
|
||||
PURPOSE. See the GNU General Public License
|
||||
for more details.<br>
|
||||
This program is distributed in the
|
||||
hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied
|
||||
warranty of MERCHANTABILITY or FITNESS
|
||||
FOR A PARTICULAR PURPOSE. See the GNU General
|
||||
Public License for more details.<br>
|
||||
|
||||
<br>
|
||||
|
||||
You should have received a copy of the
|
||||
GNU General Public License along
|
||||
with this program; if not, write to the
|
||||
Free Software Foundation, Inc., 675
|
||||
Mass Ave, Cambridge, MA 02139, USA</p>
|
||||
You should have received a copy of
|
||||
the GNU General Public License
|
||||
along with this program; if not, write to
|
||||
the Free Software Foundation, Inc.,
|
||||
675 Mass Ave, Cambridge, MA 02139, USA</p>
|
||||
|
||||
|
||||
|
||||
@ -103,49 +103,88 @@ Free Software Foundation, Inc., 675
|
||||
|
||||
|
||||
|
||||
|
||||
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
|
||||
If so, almost <b>NOTHING </b>on this site will apply directly to
|
||||
your setup. If you want to use the documentation that you find here, it
|
||||
is best if you uninstall what you have and install a setup that matches
|
||||
the documentation on this site. See the <a href="two-interface.htm">Two-interface
|
||||
If so, almost <b>NOTHING </b>on this site will apply directly
|
||||
to your setup. If you want to use the documentation that you find here,
|
||||
it is best if you uninstall what you have and install a setup that matches
|
||||
the documentation on this site. See the <a href="two-interface.htm">Two-interface
|
||||
QuickStart Guide</a> for details.<br>
|
||||
|
||||
|
||||
<h2>Getting Started with Shorewall</h2>
|
||||
New to Shorewall? Start by selecting the <a
|
||||
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
|
||||
match your environment and follow the step by step instructions.<br>
|
||||
|
||||
|
||||
|
||||
<h2><b>News</b></h2>
|
||||
<b> </b>
|
||||
|
||||
|
||||
|
||||
<p><b>5/29/2003 - Shorewall-1.4.4b</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
<p><b>6/17/2003 - Shorewall-1.4.5</b><b> </b><b><img
|
||||
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
</b></p>
|
||||
|
||||
<p>Groan -- This version corrects a problem whereby the --log-level
|
||||
was not being set when logging via syslog. The most commonly reported symptom
|
||||
was that Shorewall messages were being written to the console even though
|
||||
console logging was correctly configured per <a href="FAQ.htm#faq16">FAQ
|
||||
16</a>.<br>
|
||||
<p>Problems Corrected:<br>
|
||||
</p>
|
||||
|
||||
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b><b><img border="0"
|
||||
<ol>
|
||||
<li>The command "shorewall debug try <directory>" now correctly
|
||||
traces the attempt.</li>
|
||||
<li>The INCLUDE directive now works properly in the zones file; previously,
|
||||
INCLUDE in that file was ignored.</li>
|
||||
<li>/etc/shorewall/routestopped records with an empty second column
|
||||
are no longer ignored.<br>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>New Features:<br>
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may
|
||||
now contain a list of addresses. If the list begins with "!' then the rule
|
||||
will take effect only if the original destination address in the connection
|
||||
request does not match any of the addresses listed.</li>
|
||||
</ol>
|
||||
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
|
||||
</b><b><img border="0" src="images/new10.gif" width="28"
|
||||
height="12" alt="(New)">
|
||||
</b></p>
|
||||
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and
|
||||
iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
|
||||
have been encountered with this set of software. The Shorewall version is
|
||||
1.4.4b plus the accumulated changes for 1.4.5.
|
||||
<p><b>6/8/2003 - Updated Samples</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
</b></p>
|
||||
|
||||
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
|
||||
version 1.4.4.</p>
|
||||
|
||||
<p><b>5/29/2003 - Shorewall-1.4.4b</b><b> </b></p>
|
||||
|
||||
<p>Groan -- This version corrects a problem whereby the --log-level
|
||||
was not being set when logging via syslog. The most commonly reported symptom
|
||||
was that Shorewall messages were being written to the console even though
|
||||
console logging was correctly configured per <a href="FAQ.htm#faq16">FAQ
|
||||
16</a>.<br>
|
||||
</p>
|
||||
|
||||
<p><b>5/27/2003 - Shorewall-1.4.4a</b><b> </b></p>
|
||||
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed
|
||||
out that the code in 1.4.4 restricts the length of short zone names to 4
|
||||
characters. I've produced version 1.4.4a that restores the previous 5-character
|
||||
limit by conditionally omitting the log rule number when the LOGFORMAT doesn't
|
||||
contain '%d'.
|
||||
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b><img border="0"
|
||||
src="images/new10.gif" width="28" height="12" alt="(New)">
|
||||
</b><b> </b></p>
|
||||
out that the code in 1.4.4 restricts the length of short zone names to
|
||||
4 characters. I've produced version 1.4.4a that restores the previous 5-character
|
||||
limit by conditionally omitting the log rule number when the LOGFORMAT
|
||||
doesn't contain '%d'.
|
||||
<p><b>5/23/2003 - Shorewall-1.4.4</b><b> </b><b>
|
||||
</b></p>
|
||||
I apologize for the rapid-fire releases but since there is a potential
|
||||
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
|
||||
it a full release rather than just a bug-fix release. <br>
|
||||
configuration change required to go from 1.4.3a to 1.4.4, I decided to
|
||||
make it a full release rather than just a bug-fix release. <br>
|
||||
<br>
|
||||
<b> Problems corrected:</b><br>
|
||||
|
||||
@ -160,24 +199,25 @@ contain '%d'.
|
||||
rule.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
|
||||
been changed to a 'printf' formatting template which accepts three arguments
|
||||
(the chain name, logging rule number and the disposition). To use LOGFORMAT
|
||||
with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
|
||||
<li>The LOGMARKER variable has been renamed LOGFORMAT and
|
||||
has been changed to a 'printf' formatting template which accepts three
|
||||
arguments (the chain name, logging rule number and the disposition). To
|
||||
use LOGFORMAT with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
|
||||
set it as:<br>
|
||||
<br>
|
||||
LOGFORMAT="fp=%s:%d a=%s "<br>
|
||||
<br>
|
||||
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the LOGFORMAT
|
||||
string (up to but not including the first '%') to find log messages in the
|
||||
'show log', 'status' and 'hits' commands. This part should not be omitted
|
||||
(the LOGFORMAT should not begin with "%") and the leading part should be
|
||||
sufficiently unique for /sbin/shorewall to identify Shorewall messages.<br>
|
||||
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the
|
||||
LOGFORMAT string (up to but not including the first '%') to find log messages
|
||||
in the 'show log', 'status' and 'hits' commands. This part should not
|
||||
be omitted (the LOGFORMAT should not begin with "%") and the leading part
|
||||
should be sufficiently unique for /sbin/shorewall to identify Shorewall
|
||||
messages.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule,
|
||||
the logging now takes place in the nat table rather than in the filter table.
|
||||
This way, only those connections that actually undergo DNAT or redirection
|
||||
<li>When logging is specified on a DNAT[-] or REDIRECT[-]
|
||||
rule, the logging now takes place in the nat table rather than in the filter
|
||||
table. This way, only those connections that actually undergo DNAT or redirection
|
||||
will be logged.</li>
|
||||
|
||||
</ol>
|
||||
@ -185,40 +225,44 @@ been changed to a 'printf' formatting template which accepts three arguments
|
||||
<p><b>5/20/2003 - Shorewall-1.4.3a</b><b> </b><b>
|
||||
</b><br>
|
||||
</p>
|
||||
This version primarily corrects the documentation included in the .tgz
|
||||
and in the .rpm. In addition: <br>
|
||||
This version primarily corrects the documentation included in the
|
||||
.tgz and in the .rpm. In addition: <br>
|
||||
|
||||
|
||||
<ol>
|
||||
<li>(This change is in 1.4.3 but is not documented) If you
|
||||
are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return
|
||||
reject replies as follows:<br>
|
||||
<li>(This change is in 1.4.3 but is not documented) If
|
||||
you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will
|
||||
return reject replies as follows:<br>
|
||||
a) tcp - RST<br>
|
||||
b) udp - ICMP port unreachable<br>
|
||||
c) icmp - ICMP host unreachable<br>
|
||||
d) Otherwise - ICMP host prohibited<br>
|
||||
If you are running earlier software, Shorewall will follow it's traditional
|
||||
convention:<br>
|
||||
If you are running earlier software, Shorewall will follow it's
|
||||
traditional convention:<br>
|
||||
a) tcp - RST<br>
|
||||
b) Otherwise - ICMP port unreachable</li>
|
||||
<li>UDP port 135 is now silently dropped in the common.def
|
||||
chain. Remember that this chain is traversed just before a DROP or REJECT
|
||||
policy is enforced.<br>
|
||||
chain. Remember that this chain is traversed just before a DROP or REJECT
|
||||
policy is enforced.<br>
|
||||
</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
|
||||
</p>
|
||||
<b>Problems Corrected:<br>
|
||||
</b>
|
||||
|
||||
<ol>
|
||||
<li>There were several cases where Shorewall would fail to
|
||||
remove a temporary directory from /tmp. These cases have been corrected.</li>
|
||||
<li>The rules for allowing all traffic via the loopback interface
|
||||
have been moved to before the rule that drops status=INVALID packets.
|
||||
This insures that all loopback traffic is allowed even if Netfilter connection
|
||||
tracking is confused.</li>
|
||||
<li>There were several cases where Shorewall would fail
|
||||
to remove a temporary directory from /tmp. These cases have been corrected.</li>
|
||||
<li>The rules for allowing all traffic via the loopback
|
||||
interface have been moved to before the rule that drops status=INVALID
|
||||
packets. This insures that all loopback traffic is allowed even if Netfilter
|
||||
connection tracking is confused.</li>
|
||||
|
||||
|
||||
</ol>
|
||||
<b>New Features:<br>
|
||||
@ -226,18 +270,21 @@ This insures that all loopback traffic is allowed even if Netfilter connectio
|
||||
|
||||
<ol>
|
||||
<li><a href="6to4.htm"> </a><a href="6to4.htm">IPV6-IPV4
|
||||
(6to4) tunnels </a>are now supported in the /etc/shorewall/tunnels file.</li>
|
||||
<li value="2">You may now change the leading portion of the
|
||||
--log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf.
|
||||
By default, "Shorewall:" is used.<br>
|
||||
(6to4) tunnels </a>are now supported in the /etc/shorewall/tunnels
|
||||
file.</li>
|
||||
<li value="2">You may now change the leading portion
|
||||
of the --log-prefix used by Shorewall using the LOGMARKER variable in
|
||||
shorewall.conf. By default, "Shorewall:" is used.<br>
|
||||
</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<p><b>5/10/2003 - Shorewall Mirror in Asia</b><b> </b><br>
|
||||
</p>
|
||||
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
|
||||
|
||||
Ed Greshko has established a mirror in Taiwan -- Thanks
|
||||
Ed!
|
||||
|
||||
<p><b>5/8/2003 - Shorewall Mirror in Chile</b><b> </b></p>
|
||||
|
||||
@ -249,18 +296,22 @@ This insures that all loopback traffic is allowed even if Netfilter connectio
|
||||
<p><b>4/26/2003 - lists.shorewall.net Downtime</b><b> </b></p>
|
||||
|
||||
|
||||
|
||||
<p>The list server will be down this morning for upgrade to RH9.0.<br>
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b><b>
|
||||
</b></p>
|
||||
|
||||
|
||||
|
||||
<p>Thanks to Francesca Smith, the sample configurations are now upgraded
|
||||
to Shorewall version 1.4.2.</p>
|
||||
|
||||
|
||||
|
||||
<p><b>4/12/2002 - Greater Seattle Linux Users Group Presentation</b><b>
|
||||
</b></p>
|
||||
|
||||
@ -268,15 +319,16 @@ This insures that all loopback traffic is allowed even if Netfilter connectio
|
||||
|
||||
<blockquote> This morning, I gave <a href="GSLUG.htm"
|
||||
target="_top">a Shorewall presentation to GSLUG</a>. The presentation
|
||||
is in HTML format but was generated from Microsoft PowerPoint and
|
||||
is best viewed using Internet Explorer (although Konqueror also seems
|
||||
to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor
|
||||
Netscape work well to view the presentation.</blockquote>
|
||||
is in HTML format but was generated from Microsoft PowerPoint
|
||||
and is best viewed using Internet Explorer (although Konqueror also
|
||||
seems to work reasonably well as does Opera 7.1.0). Neither Opera
|
||||
6 nor Netscape work well to view the presentation.</blockquote>
|
||||
|
||||
|
||||
|
||||
<p><b></b></p>
|
||||
|
||||
|
||||
<blockquote>
|
||||
|
||||
<ol>
|
||||
@ -289,6 +341,7 @@ Netscape work well to view the presentation.</blockquote>
|
||||
|
||||
|
||||
|
||||
|
||||
<p><a href="file:///Z:/Shorewall-docs/News.htm"></a></p>
|
||||
<b> </b>
|
||||
|
||||
@ -309,15 +362,16 @@ Netscape work well to view the presentation.</blockquote>
|
||||
alt="(Leaf Logo)">
|
||||
|
||||
</a>Jacques Nilo and Eric Wolzak
|
||||
have a LEAF (router/firewall/gateway on
|
||||
a floppy, CD or compact flash) distribution
|
||||
have a LEAF (router/firewall/gateway
|
||||
on a floppy, CD or compact flash) distribution
|
||||
called <i>Bering</i> that features
|
||||
Shorewall-1.3.14 and Kernel-2.4.20. You
|
||||
can find their work at: <a
|
||||
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
|
||||
|
||||
<b>Congratulations to Jacques and Eric
|
||||
on the recent release of Bering 1.2!!! </b><br>
|
||||
<b>Congratulations to Jacques and
|
||||
Eric on the recent release of Bering 1.2!!!
|
||||
</b><br>
|
||||
|
||||
|
||||
<h1 align="center"><b><a href="http://www.sf.net"><img
|
||||
@ -346,6 +400,7 @@ a floppy, CD or compact flash) distribution
|
||||
<td width="88" bgcolor="#4b017c" valign="top"
|
||||
align="center">
|
||||
|
||||
|
||||
<form method="post"
|
||||
action="http://lists.shorewall.net/cgi-bin/htsearch">
|
||||
|
||||
@ -357,6 +412,7 @@ a floppy, CD or compact flash) distribution
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
|
||||
<font face="Arial" size="-1"> <input
|
||||
type="text" name="words" size="15"></font><font size="-1"> </font><font
|
||||
@ -401,6 +457,7 @@ a floppy, CD or compact flash) distribution
|
||||
|
||||
|
||||
|
||||
|
||||
<p align="center"><a href="http://www.starlight.org"> <img
|
||||
border="4" src="images/newlog.gif" width="57" height="100" align="left"
|
||||
hspace="10">
|
||||
@ -410,11 +467,12 @@ a floppy, CD or compact flash) distribution
|
||||
|
||||
|
||||
|
||||
<p align="center"><font size="4" color="#ffffff">Shorewall is free
|
||||
but if you try it and find it useful, please consider making a donation
|
||||
to
|
||||
<a href="http://www.starlight.org"><font color="#ffffff">Starlight
|
||||
Children's Foundation.</font></a> Thanks!</font></p>
|
||||
<p align="center"><font size="4" color="#ffffff"><br>
|
||||
<font size="+2">Shorewall is free but if you try it and find
|
||||
it useful, please consider making a donation
|
||||
to <a
|
||||
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
|
||||
Foundation.</font></a> Thanks!</font></font></p>
|
||||
|
||||
</td>
|
||||
|
||||
@ -424,7 +482,7 @@ but if you try it and find it useful, please consider making a donation
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p><font size="2">Updated 5/29/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
<p><font size="2">Updated 6/17/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
<br>
|
||||
</p>
|
||||
</body>
|
||||
|
||||
@ -30,8 +30,8 @@
|
||||
<h2>Before Reporting a Problem or Asking a Question<br>
|
||||
</h2>
|
||||
There
|
||||
are a number of sources of Shorewall information. Please try these
|
||||
before you post.
|
||||
are a number of sources of Shorewall information. Please try these
|
||||
before you post.
|
||||
<ul>
|
||||
<li>Shorewall versions earlier
|
||||
that 1.3.0 are no longer supported.<br>
|
||||
@ -46,14 +46,14 @@ before you post.
|
||||
solutions to more than 20 common problems. </li>
|
||||
<li> The
|
||||
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
|
||||
Information contains a number of tips to help
|
||||
you solve common problems. </li>
|
||||
Information contains a number of tips to
|
||||
help you solve common problems. </li>
|
||||
<li> The
|
||||
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
|
||||
to download updated components. </li>
|
||||
<li> The
|
||||
Site and Mailing List Archives search facility can locate
|
||||
documents and posts about similar problems: </li>
|
||||
Site and Mailing List Archives search facility can locate
|
||||
documents and posts about similar problems: </li>
|
||||
|
||||
</ul>
|
||||
|
||||
@ -102,10 +102,10 @@ documents and posts about similar problems: </li>
|
||||
</h2>
|
||||
|
||||
<ul>
|
||||
<li>Please remember we only know what
|
||||
is posted in your message. Do not leave out any information
|
||||
<li>Please remember we only know
|
||||
what is posted in your message. Do not leave out any information
|
||||
that appears to be correct, or was mentioned in a previous
|
||||
post. There have been countless posts by people who were sure
|
||||
post. There have been countless posts by people who were sure
|
||||
that some part of their configuration was correct when it actually
|
||||
contained a small error. We tend to be skeptics where detail
|
||||
is lacking.<br>
|
||||
@ -113,9 +113,9 @@ post. There have been countless posts by people who were sure
|
||||
</li>
|
||||
<li>Please keep in mind that you're
|
||||
asking for <strong>free</strong> technical support.
|
||||
Any help we offer is an act of generosity, not an obligation.
|
||||
Any help we offer is an act of generosity, not an obligation.
|
||||
Try to make it easy for us to help you. Follow good, courteous
|
||||
practices in writing and formatting your e-mail. Provide details that
|
||||
practices in writing and formatting your e-mail. Provide details that
|
||||
we need if you expect good answers. <em>Exact quoting </em> of
|
||||
error messages, log entries, command output, and other output is better
|
||||
than a paraphrase or summary.<br>
|
||||
@ -123,8 +123,8 @@ error messages, log entries, command output, and other output is better
|
||||
</li>
|
||||
<li>
|
||||
Please don't describe your environment and then ask
|
||||
us to send you custom configuration files. We're
|
||||
here to answer your questions but we can't do
|
||||
us to send you custom configuration files. We're
|
||||
here to answer your questions but we can't do
|
||||
your job for you.<br>
|
||||
<br>
|
||||
</li>
|
||||
@ -148,30 +148,32 @@ your job for you.<br>
|
||||
|
||||
<ul>
|
||||
<li>the exact kernel version you
|
||||
are running<br>
|
||||
are running<br>
|
||||
<br>
|
||||
<font color="#009900"><b>uname
|
||||
-a<br>
|
||||
-a<br>
|
||||
<br>
|
||||
</b></font></li>
|
||||
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<li>the complete, exact output of<br>
|
||||
<li>the complete, exact output
|
||||
of<br>
|
||||
<br>
|
||||
<font color="#009900"><b>ip addr
|
||||
show<br>
|
||||
<font color="#009900"><b>ip
|
||||
addr show<br>
|
||||
<br>
|
||||
</b></font></li>
|
||||
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<li>the complete, exact output of<br>
|
||||
<li>the complete, exact output
|
||||
of<br>
|
||||
<br>
|
||||
<font color="#009900"><b>ip route
|
||||
show<br>
|
||||
<font color="#009900"><b>ip
|
||||
route show<br>
|
||||
<br>
|
||||
</b></font></li>
|
||||
|
||||
@ -193,7 +195,7 @@ are running<br>
|
||||
|
||||
<ul>
|
||||
<li><font color="#ff0000"><u><i><big><b>If you are having
|
||||
connection problems of any kind then:</b></big></i></u></font><br>
|
||||
connection problems of any kind then:</b></big></i></u></font><br>
|
||||
<br>
|
||||
1. <b><font color="#009900">/sbin/shorewall reset</font></b><br>
|
||||
<br>
|
||||
@ -219,28 +221,28 @@ connection problems of any kind then:</b></big></i></u></font><br>
|
||||
</b></li>
|
||||
|
||||
</ul>
|
||||
<li>As
|
||||
a general matter, please <strong>do not edit the diagnostic
|
||||
|
||||
<li>As a general matter, please <strong>do not edit the diagnostic
|
||||
information</strong> in an attempt to conceal your IP address,
|
||||
netmask, nameserver addresses, domain name, etc. These aren't
|
||||
secrets, and concealing them often misleads us (and 80% of the time,
|
||||
a hacker could derive them anyway from information contained in
|
||||
the SMTP headers of your post).<br>
|
||||
a hacker could derive them anyway from information contained
|
||||
in the SMTP headers of your post).<br>
|
||||
<br>
|
||||
<strong></strong></li>
|
||||
<li>Do you see any "Shorewall" messages ("<b><font
|
||||
color="#009900">/sbin/shorewall show log</font></b>") when
|
||||
you exercise the function that is giving you problems? If so,
|
||||
include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
|
||||
you exercise the function that is giving you problems? If
|
||||
so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
|
||||
file.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Please include any of the Shorewall configuration
|
||||
files (especially the /etc/shorewall/hosts file
|
||||
if you have modified that file) that you think are
|
||||
if you have modified that file) that you think are
|
||||
relevant. If you include /etc/shorewall/rules, please include
|
||||
/etc/shorewall/policy as well (rules are meaningless unless one
|
||||
also knows the policies).<br>
|
||||
/etc/shorewall/policy as well (rules are meaningless unless
|
||||
one also knows the policies).<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If an error occurs when you try to "<font
|
||||
@ -251,7 +253,7 @@ also knows the policies).<br>
|
||||
</li>
|
||||
<li><b>The list server limits posts to 120kb so don't
|
||||
post GIFs of your network layout, etc.
|
||||
to the Mailing List -- your post will be rejected.</b></li>
|
||||
to the Mailing List -- your post will be rejected.</b></li>
|
||||
|
||||
</ul>
|
||||
|
||||
@ -269,16 +271,23 @@ blacklist shorewall.net "for continuous abuse" because it has been
|
||||
my policy to allow HTML in list posts!!<br>
|
||||
<br>
|
||||
I think that blocking all HTML
|
||||
is a Draconian way to control spam and that the ultimate
|
||||
losers here are not the spammers but the list subscribers
|
||||
whose MTAs are bouncing all shorewall.net mail. As one list subscriber
|
||||
wrote to me privately "These e-mail admin's need to get a <i>(expletive
|
||||
deleted)</i> life instead of trying to rid the planet of HTML based
|
||||
e-mail". Nevertheless, to allow subscribers to receive list posts
|
||||
as must as possible, I have now configured the list server at
|
||||
shorewall.net to strip all HTML from outgoing posts.<br>
|
||||
</blockquote>
|
||||
|
||||
is a Draconian way to control spam and that the ultimate
|
||||
losers here are not the spammers but the list subscribers
|
||||
whose MTAs are bouncing all shorewall.net mail. As one list
|
||||
subscriber wrote to me privately "These e-mail admin's need
|
||||
to get a <i>(expletive deleted)</i> life instead of trying to
|
||||
rid the planet of HTML based e-mail". Nevertheless, to allow
|
||||
subscribers to receive list posts as must as possible, I have now
|
||||
configured the list server at shorewall.net to strip all HTML from
|
||||
outgoing posts.<br>
|
||||
<br>
|
||||
<big><font color="#cc0000"><b>If you run your own outgoing mail server
|
||||
and it doesn't have a valid DNS PTR record, your email won't reach the lists
|
||||
unless/until the postmaster notices that your posts are being rejected. To
|
||||
avoid this problem, you should configure your MTA to forward posts to shorewall.net
|
||||
through an MTA that <u>does</u> have a valid PTR record (such as the one
|
||||
at your ISP). </b></font></big><br>
|
||||
</blockquote>
|
||||
<h2>Where to Send your Problem Report or to Ask for Help</h2>
|
||||
|
||||
<blockquote>
|
||||
@ -287,14 +296,19 @@ shorewall.net to strip all HTML from outgoing posts.<br>
|
||||
to the <a
|
||||
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
|
||||
list</a>.</span></h4>
|
||||
<b>If you run Shorewall under MandrakeSoft
|
||||
Multi Network Firewall (MNF) and you have not purchased
|
||||
an MNF license from MandrakeSoft then you can post non MNF-specific
|
||||
Shorewall questions to the </b><a
|
||||
<b>If you run Shorewall under
|
||||
MandrakeSoft Multi Network Firewall (MNF) and you have
|
||||
not purchased an MNF license from MandrakeSoft then you can
|
||||
post non MNF-specific Shorewall questions to the </b><a
|
||||
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
|
||||
list</a>. <b>Do not expect to get free MNF support on the list.</b><br>
|
||||
|
||||
<p>Otherwise, please post your question or problem to the <a
|
||||
<p>If you have a question, you may post it on the <a
|
||||
href="http://www.developercube.com/forum/index.php?c=8">Shorewall Forum</a>:
|
||||
<font color="#ff6666"><b>DO NOT USE THE FORUM FOR REPORTING PROBLEMS OR
|
||||
ASKING FOR HELP WITH PROBLEMS.<br>
|
||||
</b></font><br>
|
||||
Otherwise, please post your question or problem to the <a
|
||||
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
|
||||
list</a> .</p>
|
||||
|
||||
@ -308,11 +322,10 @@ an MNF license from MandrakeSoft then you can post non MNF-specifi
|
||||
href="http://lists.shorewall.net">http://lists.shorewall.net</a><br>
|
||||
</p>
|
||||
|
||||
<p align="left"><font size="2">Last Updated 5/28/2003 - Tom Eastep</font></p>
|
||||
<p align="left"><font size="2">Last Updated 6/14/2003 - Tom Eastep</font></p>
|
||||
|
||||
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
|
||||
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
|
||||
</p>
|
||||
<br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
# shown below. Simply run this script to revert to your prior version of
|
||||
# Shoreline Firewall.
|
||||
|
||||
VERSION=1.4.4b
|
||||
VERSION=1.4.5
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
151
STABLE/firewall
151
STABLE/firewall
@ -354,11 +354,11 @@ setpolicy() # $1 = name of chain, $2 = policy
|
||||
}
|
||||
|
||||
#
|
||||
# Set a standard chain to enable established connections
|
||||
# Set a standard chain to enable established and related connections
|
||||
#
|
||||
setcontinue() # $1 = name of chain
|
||||
{
|
||||
run_iptables -A $1 -m state --state ESTABLISHED -j ACCEPT
|
||||
run_iptables -A $1 -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
}
|
||||
|
||||
#
|
||||
@ -1000,7 +1000,7 @@ stop_firewall() {
|
||||
|
||||
while read interface host; do
|
||||
expandv interface host
|
||||
[ "x$host" = "x-" -o -z "$hosts" ] && host=0.0.0.0/0
|
||||
[ "x$host" = "x-" -o -z "$host" ] && host=0.0.0.0/0
|
||||
for h in `separate_list $host`; do
|
||||
hosts="$hosts $interface:$h"
|
||||
done
|
||||
@ -1793,19 +1793,13 @@ refresh_tc() {
|
||||
#
|
||||
add_nat_rule() {
|
||||
local chain
|
||||
local excludedests=
|
||||
|
||||
# Be sure we should and can NAT
|
||||
# Be sure we can NAT
|
||||
|
||||
case $logtarget in
|
||||
DNAT|REDIRECT)
|
||||
if [ -z "$NAT_ENABLED" ]; then
|
||||
fatal_error "Rule \"$rule\" requires NAT which is disabled"
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
fatal_error "Only DNAT and REDIRECT rules may specify port mapping; rule \"$rule\""
|
||||
;;
|
||||
esac
|
||||
|
||||
# Parse SNAT address if any
|
||||
|
||||
@ -1827,10 +1821,16 @@ add_nat_rule() {
|
||||
if [ -n "$DETECT_DNAT_IPADDRS" -a "$source" != "$FW" ]; then
|
||||
eval interfaces=\$${source}_interfaces
|
||||
for interface in $interfaces; do
|
||||
addr="`find_interface_address $interface` $addr"
|
||||
addr=${addr:+$addr,}`find_interface_address $interface`
|
||||
done
|
||||
fi
|
||||
;;
|
||||
!*)
|
||||
if [ `list_count $addr` -gt 1 ]; then
|
||||
excludedests="`separate_list ${addr#\!}`"
|
||||
addr=
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
addr=${addr:-0.0.0.0/0}
|
||||
@ -1844,37 +1844,69 @@ add_nat_rule() {
|
||||
target1="REDIRECT --to-port $servport"
|
||||
fi
|
||||
|
||||
if [ $source = $FW ]; then
|
||||
[ -n "$excludezones" ] && fatal_error "Invalid Source in rule \"$rule\""
|
||||
fi
|
||||
|
||||
# Generate nat table rules
|
||||
|
||||
if [ $command != check ]; then
|
||||
if [ "$source" = "$FW" ]; then
|
||||
run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \
|
||||
$multiport $dports -j $target1
|
||||
else
|
||||
chain=`dnat_chain $source`
|
||||
|
||||
if [ -n "$excludezones" ]; then
|
||||
if [ -n "$excludedests" ]; then
|
||||
chain=nonat${nonat_seq}
|
||||
nonat_seq=$(($nonat_seq + 1))
|
||||
createnatchain $chain
|
||||
addnatrule `dnat_chain $source` -j $chain
|
||||
run_iptables -t nat -A OUTPUT $cli $proto $multiport $sports $dports -j $chain
|
||||
|
||||
for adr in $excludedests; do
|
||||
addnatrule $chain -d $adr -j RETURN
|
||||
done
|
||||
|
||||
if [ -n "$loglevel" ]; then
|
||||
log_rule $loglevel $chain $logtarget -t nat
|
||||
fi
|
||||
|
||||
addnatrule $chain -j $target1
|
||||
else
|
||||
for adr in `separate_list $addr`; do
|
||||
run_iptables2 -t nat -A OUTPUT $proto $sports -d $adr \
|
||||
$multiport $dports -j $target1
|
||||
done
|
||||
fi
|
||||
else
|
||||
chain=`dnat_chain $source`
|
||||
|
||||
if [ -n "${excludezones}${excludedests}" ]; then
|
||||
chain=nonat${nonat_seq}
|
||||
nonat_seq=$(($nonat_seq + 1))
|
||||
createnatchain $chain
|
||||
addnatrule `dnat_chain $source` $cli $proto $multiport $sports $dports -j $chain
|
||||
for z in $excludezones; do
|
||||
eval hosts=\$${z}_hosts
|
||||
for host in $hosts; do
|
||||
for adr in $addr; do
|
||||
addnatrule $chain $proto -s ${host#*:} \
|
||||
$multiport $sports -d $adr $dports -j RETURN
|
||||
for adr in `separate_list $addr`; do
|
||||
addnatrule $chain -s ${host#*:} -d $adr -j RETURN
|
||||
done
|
||||
done
|
||||
done
|
||||
|
||||
for adr in $excludedests; do
|
||||
addnatrule $chain -d $adr -j RETURN
|
||||
done
|
||||
|
||||
for adr in `separate_list $addr`; do
|
||||
if [ -n "$loglevel" ]; then
|
||||
log_rule $loglevel $chain $logtarget -t nat -d `fix_bang $adr`
|
||||
fi
|
||||
|
||||
for adr in $addr; do
|
||||
addnatrule $chain -d $adr -j $target1
|
||||
done
|
||||
else
|
||||
for adr in `separate_list $addr`; do
|
||||
if [ -n "$loglevel" ]; then
|
||||
ensurenatchain $chain
|
||||
log_rule $loglevel $chain $logtarget -t nat \
|
||||
`fix_bang $proto $cli $sports -d $adr $multiport $dports`
|
||||
loglevel=
|
||||
fi
|
||||
|
||||
addnatrule $chain $proto $cli $sports \
|
||||
@ -1882,6 +1914,7 @@ add_nat_rule() {
|
||||
done
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
# Replace destination port by the new destination port
|
||||
|
||||
@ -1930,11 +1963,13 @@ add_nat_rule() {
|
||||
#
|
||||
add_a_rule()
|
||||
{
|
||||
# Set source variables
|
||||
local natrule=
|
||||
|
||||
# Set source variables. The 'cli' variable will hold the client match predicate(s).
|
||||
|
||||
cli=
|
||||
|
||||
[ -n "$client" ] && case "$client" in
|
||||
case "$client" in
|
||||
-)
|
||||
;;
|
||||
*:*)
|
||||
@ -1947,16 +1982,16 @@ add_a_rule()
|
||||
cli=`mac_match $client`
|
||||
;;
|
||||
*)
|
||||
cli="-i $client"
|
||||
[ -n "$client" ] && cli="-i $client"
|
||||
;;
|
||||
esac
|
||||
|
||||
# Set destination variables
|
||||
# Set destination variables - 'serv' and 'dest_interface' hold the server match predicate(s).
|
||||
|
||||
dest_interface=
|
||||
serv=
|
||||
|
||||
[ -n "$server" ] && case "$server" in
|
||||
case "$server" in
|
||||
-)
|
||||
;;
|
||||
*.*.*)
|
||||
@ -1966,7 +2001,7 @@ add_a_rule()
|
||||
fatal_error "Rule \"$rule\" - Destination may not be specified by MAC Address"
|
||||
;;
|
||||
*)
|
||||
dest_interface="-o $server"
|
||||
[ -n "$server" ] && dest_interface="-o $server"
|
||||
;;
|
||||
esac
|
||||
|
||||
@ -2032,10 +2067,12 @@ add_a_rule()
|
||||
[ -n "$serv" ] && startup_error "REDIRECT rules cannot"\
|
||||
" specify a server IP; rule: \"$rule\""
|
||||
servport=${servport:=$port}
|
||||
natrule=Yes
|
||||
;;
|
||||
DNAT)
|
||||
[ -n "$serv" ] || fatal_error "DNAT rules require a" \
|
||||
" server address; rule: \"$rule\""
|
||||
natrule=Yes
|
||||
;;
|
||||
LOG)
|
||||
[ -z "$loglevel" ] && fatal_error "LOG requires log level"
|
||||
@ -2044,7 +2081,7 @@ add_a_rule()
|
||||
|
||||
# Complain if the rule is really a policy
|
||||
|
||||
if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" ]; then
|
||||
if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" -a "$logtarget" != LOG ]; then
|
||||
error_message "Warning -- Rule \"$rule\" is a POLICY"
|
||||
error_message " -- and should be moved to the policy file"
|
||||
fi
|
||||
@ -2054,15 +2091,16 @@ add_a_rule()
|
||||
|
||||
# A specific server or server port given
|
||||
|
||||
if [ -n "$addr" -a "$addr" != "$serv" ]; then
|
||||
add_nat_rule
|
||||
elif [ -n "$servport" -a "$servport" != "$port" ]; then
|
||||
if [ -n "$natrule" ]; then
|
||||
add_nat_rule
|
||||
elif [ -n "$addr" -a "$addr" != "$serv" ] || [ -n "$servport" -a "$servport" != "$port" ]; then
|
||||
fatal_error "Only DNAT and REDIRECT rules may specify destination mapping; rule \"$rule\""
|
||||
fi
|
||||
|
||||
if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then
|
||||
serv="${serv:+-d $serv}"
|
||||
if [ -n "$loglevel" ]; then
|
||||
|
||||
if [ -n "$loglevel" -a -z "$natrule" ]; then
|
||||
log_rule $loglevel $chain $logtarget \
|
||||
`fix_bang $proto $sports $multiport $state $cli $serv $dports`
|
||||
fi
|
||||
@ -2126,7 +2164,12 @@ process_rule() # $1 = target
|
||||
logtarget="$target"
|
||||
dnat_only=
|
||||
|
||||
# Convert 1.3 Rule formats to 1.2 format
|
||||
# Tranform the rule:
|
||||
#
|
||||
# - set 'target' to the filter table target.
|
||||
# - make $FW the destination for REDIRECT
|
||||
# - remove '-' suffix from logtargets while setting 'dnat_only'
|
||||
# - clear 'address' if it has been set to '-'
|
||||
|
||||
[ "x$address" = "x-" ] && address=
|
||||
|
||||
@ -2185,9 +2228,7 @@ process_rule() # $1 = target
|
||||
fatal_error "Exclude list only allowed with DNAT or REDIRECT"
|
||||
fi
|
||||
|
||||
if ! validate_zone $clientzone; then
|
||||
fatal_error "Undefined Client Zone in rule \"$rule\""
|
||||
fi
|
||||
validate_zone $clientzone || fatal_error "Undefined Client Zone in rule \"$rule\""
|
||||
|
||||
# Parse and validate destination
|
||||
|
||||
@ -2220,7 +2261,7 @@ process_rule() # $1 = target
|
||||
|
||||
dest=$serverzone
|
||||
|
||||
# Create canonical chain if necessary
|
||||
# Ensure that this rule doesn't apply to a NONE policy pair of zones
|
||||
|
||||
chain=${source}2${dest}
|
||||
|
||||
@ -2229,11 +2270,14 @@ process_rule() # $1 = target
|
||||
[ $policy = NONE ] && \
|
||||
fatal_error "Rules may not override a NONE policy: rule \"$rule\""
|
||||
|
||||
[ $command = check ] || ensurechain $chain
|
||||
# Be sure that this isn't a fw->fw rule.
|
||||
|
||||
if [ "x$chain" = x${FW}2${FW} ]; then
|
||||
case $logtarget in
|
||||
REDIRECT)
|
||||
REDIRECT|DNAT)
|
||||
#
|
||||
# Redirect rules that have the firewall as the source are fw->fw rules
|
||||
#
|
||||
;;
|
||||
*)
|
||||
error_message "WARNING: fw -> fw rules are not supported; rule \"$rule\" ignored"
|
||||
@ -2241,6 +2285,9 @@ process_rule() # $1 = target
|
||||
;;
|
||||
esac
|
||||
else
|
||||
|
||||
# Create the canonical chain if it doesn't already exist
|
||||
|
||||
[ $command = check ] || ensurechain $chain
|
||||
fi
|
||||
|
||||
@ -2252,15 +2299,25 @@ process_rule() # $1 = target
|
||||
`list_count $ports` -le 15 -a \
|
||||
`list_count $cports` -le 15 ]
|
||||
then
|
||||
#
|
||||
# MULTIPORT is enabled, there are no port ranges in the rule and less than
|
||||
# 16 ports are listed - use multiport match.
|
||||
#
|
||||
multioption="-m multiport"
|
||||
for client in `separate_list ${clients:=-}`; do
|
||||
for server in `separate_list ${servers:=-}`; do
|
||||
#
|
||||
# add_a_rule() modifies these so we must set their values each time
|
||||
#
|
||||
port=${ports:=-}
|
||||
cport=${cports:=-}
|
||||
add_a_rule
|
||||
done
|
||||
done
|
||||
else
|
||||
#
|
||||
# MULTIPORT is disabled or the rule isn't compatible with multiport match
|
||||
#
|
||||
multioption=
|
||||
for client in `separate_list ${clients:=-}`; do
|
||||
for server in `separate_list ${servers:=-}`; do
|
||||
@ -2272,7 +2329,9 @@ process_rule() # $1 = target
|
||||
done
|
||||
done
|
||||
fi
|
||||
|
||||
#
|
||||
# Report Result
|
||||
#
|
||||
if [ $command = check ]; then
|
||||
echo " Rule \"$rule\" checked."
|
||||
else
|
||||
@ -3774,9 +3833,11 @@ activate_rules()
|
||||
complete_standard_chain INPUT all $FW
|
||||
complete_standard_chain OUTPUT $FW all
|
||||
complete_standard_chain FORWARD all all
|
||||
|
||||
#
|
||||
# Remove rules added to keep the firewall alive during [re]start"
|
||||
#
|
||||
for chain in INPUT OUTPUT FORWARD; do
|
||||
run_iptables -D $chain -m state --state ESTABLISHED -j ACCEPT
|
||||
run_iptables -D $chain -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
run_iptables -D $chain -p udp --dport 53 -j ACCEPT
|
||||
done
|
||||
}
|
||||
|
||||
@ -83,29 +83,23 @@ find_display() # $1 = zone, $2 = name of the zone file
|
||||
[ "x$1" = "x$z" ] && echo $display
|
||||
done
|
||||
}
|
||||
|
||||
#
|
||||
# This function assumes that the TMP_DIR variable is set and that
|
||||
# its value named an existing directory.
|
||||
#
|
||||
determine_zones()
|
||||
{
|
||||
local zonefile=`find_file zones`
|
||||
|
||||
multi_display=Multi-zone
|
||||
|
||||
if [ -f $zonefile ]; then
|
||||
zones=`find_zones $zonefile`
|
||||
strip_file zones $zonefile
|
||||
zones=`find_zones $TMP_DIR/zones`
|
||||
zones=`echo $zones` # Remove extra trash
|
||||
|
||||
for zone in $zones; do
|
||||
dsply=`find_display $zone $zonefile`
|
||||
dsply=`find_display $zone $TMP_DIR/zones`
|
||||
eval ${zone}_display=\$dsply
|
||||
done
|
||||
else
|
||||
zones="net local dmz gw"
|
||||
net_display=Net
|
||||
local_display=Local
|
||||
dmz_display=DMZ
|
||||
gw_display=Gateway
|
||||
fi
|
||||
|
||||
}
|
||||
|
||||
#
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
# /etc/rc.d/rc.local file is modified to start the firewall.
|
||||
#
|
||||
|
||||
VERSION=1.4.4b
|
||||
VERSION=1.4.5
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
@ -2,32 +2,19 @@ This is a minor release of Shorewall.
|
||||
|
||||
Problems Corrected:
|
||||
|
||||
1) The command "shorewall debug try <directory>" now correctly traces
|
||||
the attempt.
|
||||
|
||||
2) The INCLUDE directive now works properly in the zones file;
|
||||
previously, INCLUDE in that file was ignored.
|
||||
|
||||
3) /etc/shorewall/routestopped records with an empty second column are no
|
||||
longer ignored.
|
||||
|
||||
New Features:
|
||||
|
||||
1) A REDIRECT- rule target has been added. This target behaves for
|
||||
REDIRECT in the same was as DNAT- does for DNAT in that the
|
||||
Netfilter nat table REDIRECT rule is added but not the companion
|
||||
filter table ACCEPT rule.
|
||||
|
||||
2) The LOGMARKER variable has been renamed LOGFORMAT and has been
|
||||
changed to a 'printf' formatting template which accepts three
|
||||
arguments (the chain name, logging rule number (optional) and the
|
||||
disposition). The logging rule number is included if the LOGFORMAT
|
||||
value contains '%d'. For example, to use LOGFORMAT with fireparse,
|
||||
set it as:
|
||||
|
||||
LOGFORMAT="fp=%s:%d a=%s "
|
||||
|
||||
|
||||
CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT
|
||||
string (up to but not including the first '%') to find log messages
|
||||
in the 'show log', 'status' and 'hits' commands. This part should
|
||||
not be omitted (the LOGFORMAT should not begin with "%") and the
|
||||
leading part should be sufficiently unique for /sbin/shorewall to
|
||||
identify Shorewall messages.
|
||||
|
||||
3) When logging is specified on a DNAT[-] or REDIRECT[-] rule, the
|
||||
logging now takes place in the nat table rather than in the filter
|
||||
table. This way, only those connections that actually undergo DNAT
|
||||
or redirection will be logged.
|
||||
1) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
|
||||
contain a list of addresses. If the list begins with "!' then the
|
||||
rule will take effect only if the original destination address in
|
||||
the connection request does not match any of the addresses listed.
|
||||
|
||||
|
||||
21
STABLE/rules
21
STABLE/rules
@ -31,6 +31,11 @@
|
||||
# the companion ACCEPT rule.
|
||||
# REDIRECT -- Redirect the request to a local
|
||||
# port on the firewall.
|
||||
# REDIRECT-
|
||||
# -- Advanced users only.
|
||||
# Like REDIRET but only generates the
|
||||
# REDIRECT iptables rule and not
|
||||
# the companion ACCEPT rule.
|
||||
# CONTINUE -- (For experts only). Do not process
|
||||
# any of the following rules for this
|
||||
# (source zone,destination zone). If
|
||||
@ -157,14 +162,24 @@
|
||||
# Otherwise, a separate rule will be generated for each
|
||||
# port.
|
||||
#
|
||||
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT or
|
||||
# REDIRECT) If included and different from the IP
|
||||
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT[-] or
|
||||
# REDIRECT[-]) If included and different from the IP
|
||||
# address given in the SERVER column, this is an address
|
||||
# on some interface on the firewall and connections to
|
||||
# that address will be forwarded to the IP and port
|
||||
# specified in the DEST column.
|
||||
#
|
||||
# The address may optionally be followed by
|
||||
# A comma-separated list of addresses may also be used.
|
||||
# This is usually most useful with the REDIRECT target
|
||||
# where you want to redirect traffic destined for
|
||||
# particular set of hosts.
|
||||
#
|
||||
# Finally, if the list of addresses begins with "!" then
|
||||
# the rule will be followed only if the original
|
||||
# destination address in the connection request does not
|
||||
# match any of the addresses listed.
|
||||
#
|
||||
# The address (list) may optionally be followed by
|
||||
# a colon (":") and a second IP address. This causes
|
||||
# Shorewall to use the second IP address as the source
|
||||
# address in forwarded packets. See the Shorewall
|
||||
|
||||
@ -348,7 +348,16 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that
|
||||
timeout=$1
|
||||
fi
|
||||
|
||||
qt which awk && { haveawk=Yes; determine_zones; } || haveawk=
|
||||
|
||||
if qt which awk; then
|
||||
TMP_DIR=/tmp/shorewall-$$
|
||||
mkdir $TMP_DIR
|
||||
haveawk=Yes
|
||||
determine_zones
|
||||
rm -rf $TMP_DIR
|
||||
else
|
||||
haveawk=
|
||||
fi
|
||||
|
||||
while true; do
|
||||
display_chains
|
||||
@ -756,7 +765,7 @@ case "$1" in
|
||||
|
||||
echo " HITS PORT SERVICE(S)"
|
||||
echo " ---- ----- ----------"
|
||||
grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
|
||||
grep "$LOGFORMAT.*DPT" $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \
|
||||
while read count port ; do
|
||||
# List all services defined for the given port
|
||||
srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u`
|
||||
@ -776,7 +785,7 @@ case "$1" in
|
||||
try)
|
||||
[ -n "$SHOREWALL_DIR" ] && startup_error "Error: -c option may not be used with \"try\""
|
||||
[ $# -lt 2 -o $# -gt 3 ] && usage 1
|
||||
if ! $0 -c $2 restart; then
|
||||
if ! $0 $debugging -c $2 restart; then
|
||||
if ! iptables -L shorewall > /dev/null 2> /dev/null; then
|
||||
$0 start
|
||||
fi
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
%define name shorewall
|
||||
%define version 1.4.4b
|
||||
%define version 1.4.5
|
||||
%define release 1
|
||||
%define prefix /usr
|
||||
|
||||
@ -105,6 +105,8 @@ fi
|
||||
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
|
||||
|
||||
%changelog
|
||||
* Tue Jun 17 2003 Tom Eastep <tom@shorewall.net>
|
||||
- Changed version to 1.4.5-1
|
||||
* Thu May 29 2003 Tom Eastep <tom@shorewall.net>
|
||||
- Changed version to 1.4.4b-1
|
||||
* Tue May 27 2003 Tom Eastep <tom@shorewall.net>
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
# You may only use this script to uninstall the version
|
||||
# shown below. Simply run this script to remove Seattle Firewall
|
||||
|
||||
VERSION=1.4.4b
|
||||
VERSION=1.4.5
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
Loading…
Reference in New Issue
Block a user