Doc updates

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1954 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-02-10 01:34:40 +00:00
parent 8d5387466c
commit 23d5d9de3c
7 changed files with 118 additions and 84 deletions

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-02-06</pubdate>
<pubdate>2005-02-08</pubdate>
<copyright>
<year>2004</year>
@ -330,8 +330,11 @@ spdadd 134.28.54.2/32 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2
<caution>
<para>If you are running kernel 2.6.10 or later, then you need
ipsec-tools (and racoon) 0.5 or later and you need to add <emphasis
role="bold">-P fwd</emphasis> rules -- see <ulink
ipsec-tools (and racoon) 0.5 or later OR you need to add <emphasis
role="bold">-P fwd</emphasis> rules (duplicate each <emphasis
role="bold">-P in</emphasis> rule and replace the <emphasis
role="bold">in</emphasis> with <emphasis role="bold">fwd</emphasis>) --
see <ulink
url="http://www.ipsec-howto.org/x277.html">http://www.ipsec-howto.org/x277.html</ulink>.</para>
</caution>

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-12-27</pubdate>
<pubdate>2005-02-05</pubdate>
<copyright>
<year>2001</year>
@ -26,6 +26,8 @@
<year>2004</year>
<year>2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -218,9 +220,11 @@ INIT="rc.firewall"</programlisting>
<para>To install my version of Shorewall on a fresh Bering disk, simply
replace the <quote>shorwall.lrp</quote> file on the image with the file
that you downloaded. See the <ulink url="two-interface.htm">two-interface
QuickStart Guide</ulink> for information about further steps
required.</para>
that you downloaded. For example, if you download
<filename>shorewall-lrp-2.2.0.tgz</filename> then you will rename the file
to <filename>shorwall.lrp</filename> and replace the file by that name on
the Bering disk with the new file. Then proceed to configure Shorewall as
described in the Bering (or Bering uClibc) documentation.</para>
</section>
<section>

View File

@ -15,10 +15,10 @@
</author>
</authorgroup>
<pubdate>2004-04-05</pubdate>
<pubdate>2005-02-08</pubdate>
<copyright>
<year>2001-2004</year>
<year>2001-2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -29,13 +29,15 @@
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>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.</para>
MAC address may be optionally associated with one or more IP
addresses.</para>
<important>
<para><emphasis role="bold">MAC addresses are only visible within an
@ -49,6 +51,11 @@
(CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o).</emphasis></para>
</important>
<important>
<para><emphasis role="bold">MAC verification is only applied to new
incoming connection requests. </emphasis></para>
</important>
<section>
<title>Components</title>
@ -57,16 +64,17 @@
<orderedlist>
<listitem>
<para>The <emphasis role="bold">maclist</emphasis> interface option in
<ulink url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.
When this option is specified, all traffic arriving on the interface
is subjet to MAC verification.</para>
<ulink
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.
When this option is specified, all new connection requests arriving on
the interface are subject to MAC verification.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">maclist</emphasis> option in <ulink
url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink>. When this
option is specified for a subnet, all traffic from that subnet is
subject to MAC verification.</para>
option is specified for a subnet, all new connection requests from
that subnet are subject to MAC verification.</para>
</listitem>
<listitem>
@ -83,8 +91,8 @@
and determines the disposition of connection requests that fail MAC
verification. The MACLIST_LOG_LEVEL variable gives the syslogd level
at which connection requests that fail verification are to be logged.
If set the the empty value (e.g., MACLIST_LOG_LEVEL=&#34;&#34;) then
failing connection requests are not logged.</para>
If set the the empty value (e.g., MACLIST_LOG_LEVEL="") then failing
connection requests are not logged.</para>
</listitem>
</orderedlist>
</section>
@ -99,7 +107,8 @@
<term>INTERFACE</term>
<listitem>
<para>The name of an ethernet interface on the Shorewall system.</para>
<para>The name of an ethernet interface on the Shorewall
system.</para>
</listitem>
</varlistentry>
@ -109,7 +118,8 @@
<listitem>
<para>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.</para>
this column although you may use that format if you so
choose.</para>
</listitem>
</varlistentry>
@ -155,11 +165,13 @@ eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIP
<para>As shown above, I use MAC Verification on my wireless zone.</para>
<para><note><para>While marketed as a wireless bridge, the WET11 behaves
like a wireless router with DHCP relay. When forwarding DHCP traffic, it
uses the MAC address of the host (TIPPER) but for other forwarded
traffic it uses it&#39;s own MAC address. Consequently, I list the IP
addresses of both devices in /etc/shorewall/maclist.</para></note></para>
<para><note>
<para>While marketed as a wireless bridge, the WET11 behaves like a
wireless router with DHCP relay. 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 list the IP
addresses of both devices in /etc/shorewall/maclist.</para>
</note></para>
</example>
<example>
@ -176,9 +188,9 @@ eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIP
<para>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&#39;s MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.</para>
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.</para>
</example>
</section>
</article>

View File

@ -15,10 +15,10 @@
</author>
</authorgroup>
<pubdate>2004-07-10</pubdate>
<pubdate>2002-02-07</pubdate>
<copyright>
<year>2001-2004</year>
<year>2001-2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -29,7 +29,8 @@
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
@ -67,23 +68,27 @@ eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55
<title>ip</title>
<programlisting>[root@gateway root]# <command>ip addr show dev eth0</command>
2: eth0: &#60;BROADCAST,MULTICAST,UP&#62; mtu 1500 qdisc htb qlen 100
2: eth0: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
[root@gateway root]# </programlisting>
<para><note><para>One <emphasis role="bold">cannot</emphasis> type
<quote><command>ip addr show dev eth0:0</command></quote> because
<quote><filename class="devicefile">eth0:0</filename></quote> is a label
for a particular address rather than a device name.</para><programlisting>[root@gateway root]# <command>ip addr show dev eth0:0</command>
Device &#34;eth0:0&#34; does not exist.
[root@gateway root]#</programlisting></note></para>
<para><note>
<para>One <emphasis role="bold">cannot</emphasis> type
<quote><command>ip addr show dev eth0:0</command></quote> because
<quote><filename class="devicefile">eth0:0</filename></quote> is a
label for a particular address rather than a device name.</para>
<programlisting>[root@gateway root]# <command>ip addr show dev eth0:0</command>
Device "eth0:0" does not exist.
[root@gateway root]#</programlisting>
</note></para>
</example>
<para>The iptables program doesn&#39;t support virtual interfaces in
either it&#39;s <quote>-i</quote> or <quote>-o</quote> command options; as
a consequence, Shorewall does not allow them to be used in the
<para>The iptables program doesn't support virtual interfaces in either
it's <quote>-i</quote> or <quote>-o</quote> command options; as a
consequence, Shorewall does not allow them to be used in the
/etc/shorewall/interfaces file or anywhere else except as described in the
discussion below.</para>
</section>
@ -92,8 +97,8 @@ Device &#34;eth0:0&#34; does not exist.
<title>Adding Addresses to Interfaces</title>
<para>Most distributions have a facility for adding additional addresses
to interfaces. If you have already used your distribution&#39;s capability
to add your required addresses, you can skip this section.</para>
to interfaces. If you have already used your distribution's capability to
add your required addresses, you can skip this section.</para>
<para>Shorewall provides facilities for automatically adding addresses to
interfaces as described in the following section. It is also easy to add
@ -124,7 +129,7 @@ esac</programlisting>
<title>So how do I handle more than one address on an interface?</title>
<para>The answer depends on what you are trying to do with the interfaces.
In the sub-sections that follow, we&#39;ll take a look at common
In the sub-sections that follow, we'll take a look at common
scenarios.</para>
<section>
@ -150,7 +155,7 @@ ACCEPT net $FW:206.124.146.178 tcp 22</programlisting></para>
zone at 192.168.1.3. That is accomplised by a single rule in the
<filename>/etc/shorewall/rules</filename> file:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
<programlisting>#ACTION SOURCE DEST PROTO DEST POR------------------T(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT net loc:192.168.1.3 tcp 80 - 206.124.146.178 </programlisting>
</section>
@ -159,17 +164,19 @@ DNAT net loc:192.168.1.3 tcp 80 - 20
<title>SNAT</title>
<para>If you wanted to use eth0:0 as the IP address for outbound
connections from your local zone (eth1), then in <filename>/etc/shorewall/masq</filename>:</para>
connections from your local zone (eth1), then in
<filename>/etc/shorewall/masq</filename>:</para>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0 eth1 206.124.146.178</programlisting>
<para>Shorewall can create the alias (additional address) for you if you
set ADD_SNAT_ALIASES=Yes in <filename>/etc/shorewall/shorewall.con</filename>f.
Beginning with Shorewall 1.3.14, Shorewall can actually create the
<quote>label</quote> (virtual interface) so that you can see the created
address using ifconfig. In addition to setting ADD_SNAT_ALIASES=Yes, you
specify the virtual interface name in the INTERFACE column as follows.</para>
set ADD_SNAT_ALIASES=Yes in
<filename>/etc/shorewall/shorewall.con</filename>f. Beginning with
Shorewall 1.3.14, Shorewall can actually create the <quote>label</quote>
(virtual interface) so that you can see the created address using
ifconfig. In addition to setting ADD_SNAT_ALIASES=Yes, you specify the
virtual interface name in the INTERFACE column as follows.</para>
<para><filename>/etc/shorewall/masq</filename><programlisting>#INTERFACE SUBNET ADDRESS
eth0:0 eth1 206.124.146.178</programlisting></para>
@ -195,7 +202,8 @@ eth0:2 = 206.124.146.180</programlisting>
<para>If you wanted to use one-to-one NAT to link <filename
class="devicefile">eth0:0</filename> with local address 192.168.1.3, you
would have the following in <filename>/etc/shorewall/nat</filename>:</para>
would have the following in
<filename>/etc/shorewall/nat</filename>:</para>
<programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0 192.168.1.3 no no</programlisting>
@ -210,9 +218,10 @@ eth0:2 = 206.124.146.180</programlisting>
<para><filename>/etc/shorewall/nat</filename><programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0:0 192.168.1.3 no no</programlisting></para>
<para>In either case, to create rules in <filename>/etc/shorewall/rules</filename>
that pertain only to this NAT pair, you simply qualify the local zone
with the internal IP address.</para>
<para>In either case, to create rules in
<filename>/etc/shorewall/rules</filename> that pertain only to this NAT
pair, you simply qualify the local zone with the internal IP
address.</para>
<example>
<title>You want to allow SSH from the net to 206.124.146.178 a.k.a.
@ -230,7 +239,7 @@ ACCEPT net loc:192.168.1.3 tcp 22</programlisting></para>
multiple subnetworks configured on a LAN segment. This technique does
not provide for any security between the subnetworks if the users of the
systems have administrative privileges because in that case, the users
can simply manipulate their system&#39;s routing table to bypass your
can simply manipulate their system's routing table to bypass your
firewall/router. Nevertheless, there are cases where you simply want to
consider the LAN segment itself as a zone and allow your firewall/router
to route between the two subnetworks.</para>

Binary file not shown.

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-02-06</pubdate>
<pubdate>2005-02-08</pubdate>
<copyright>
<year>2001-2005</year>
@ -250,7 +250,7 @@ loc $INT_IF detect dhcp
dmz $DMZ_IF -
- texas -
vpn tun+ -
Wifi $WIFI_IF - maclist
Wifi $WIFI_IF - maclist,dhcp
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
@ -496,6 +496,12 @@ DROP loc:!192.168.0.0/22 net
# SQUID
#
REDIRECT loc 3128 tcp 80
##########################################################################################################################################################################
#####
# Secure zone to Internet
#
# SQUID
#
REDIRECT sec 3128 tcp 80
##########################################################################################################################################################################
#####
@ -999,7 +1005,7 @@ ACCEPT net fw tcp 4000:4100
<blockquote>
<programlisting>dev tun
remote ursa.shorewall.net
remote gateway.shorewall.net
up /etc/openvpn/home.up
tls-client

View File

@ -13,10 +13,10 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-05-31</pubdate>
<pubdate>2005-02-07</pubdate>
<copyright>
<year>2001-2004</year>
<year>2001-2005</year>
<holder>Thomas M Eastep</holder>
</copyright>
@ -27,7 +27,8 @@
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
@ -36,25 +37,15 @@
<itemizedlist>
<listitem>
<para>A kernel that supports netfilter. I&#39;ve tested with 2.4.2 -
2.6.6. With current releases of Shorewall, Traffic Shaping/Control
<para>A kernel that supports netfilter. I've tested with 2.4.2 -
2.6.10. With current releases of Shorewall, Traffic Shaping/Control
requires at least 2.4.18. Check <ulink url="kernel.htm">here</ulink>
for kernel configuration information. If you are looking for a
firewall for use with 2.2 kernels, see <ulink
url="http://seawall.sourceforge.net">the Seattle Firewall site</ulink>.</para>
for kernel configuration information.</para>
</listitem>
<listitem>
<para>iptables 1.2 or later but beware version 1.2.3 -- see the <ulink
url="errata.htm">Errata</ulink>.</para>
<warning>
<para>The buggy iptables version 1.2.3 is included in RedHat 7.2 and
you should upgrade to iptables 1.2.4 prior to installing Shorewall.
Version 1.2.4 is available <ulink
url="http://www.redhat.com/support/errata/RHSA-2001-144.html">from
RedHat</ulink> and in the <ulink url="errata.htm">Shorewall Errata</ulink>.</para>
</warning>
<para>iptables 1.2 or later (but I recommend at least version
1.2.9)</para>
</listitem>
<listitem>
@ -66,17 +57,26 @@
<listitem>
<para>A Bourne shell or derivative such as bash or ash. This shell
must have correct support for variable expansion formats ${<emphasis>variable%pattern</emphasis>},
${<emphasis>variable%%pattern</emphasis>}, ${<emphasis>variable#pattern</emphasis>}
and ${<emphasis>variable##pattern</emphasis>}.</para>
must have correct support for variable expansion formats
${<emphasis>variable%pattern</emphasis>},
${<emphasis>variable%%pattern</emphasis>},
${<emphasis>variable#pattern</emphasis>} and
${<emphasis>variable##pattern</emphasis>}.</para>
</listitem>
<listitem>
<para>Your shell must produce a sensible result when a number n (128
&#60;= n &#60;= 255) is left shifted by 24 bits. You can check this at
a shell prompt by:<itemizedlist><listitem><para>echo $((128 &#60;&#60;
24))</para></listitem><listitem><para>The result must be either
2147483648 or -2147483648.</para></listitem></itemizedlist></para>
&lt;= n &lt;= 255) is left shifted by 24 bits. You can check this at a
shell prompt by:<itemizedlist>
<listitem>
<para>echo $((128 &lt;&lt; 24))</para>
</listitem>
<listitem>
<para>The result must be either 2147483648 or
-2147483648.</para>
</listitem>
</itemizedlist></para>
</listitem>
<listitem>