forked from extern/shorewall_code
More documentation changes for 4.4
This commit is contained in:
Tom Eastep
parent
228f603d32
commit
a953c1af46
@ -30,7 +30,7 @@
|
||||
|
||||
<year>2006</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
<holder>2009 Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
<copyright>
|
||||
@ -62,22 +62,19 @@
|
||||
have IPSEC end-points on the same system where Shorewall is used.</para>
|
||||
</important>
|
||||
|
||||
<warning>
|
||||
<para>To use the features described in this article, your kernel must be
|
||||
2.6.16 or later <emphasis role="bold">or</emphasis> your kernel and
|
||||
iptables must include the Netfilter+ipsec patches and policy match
|
||||
support. The Netfilter patches are available from Netfilter
|
||||
Patch-O-Matic-NG and are also included in some commercial distributions
|
||||
(most notably <trademark>SUSE</trademark> 9.1 through 10.0).</para>
|
||||
</warning>
|
||||
<important>
|
||||
<para>While this article shows configuration of IPSEC using ipsec-tools,
|
||||
Shorewall configuration is exactly the same when using OpenSwan or
|
||||
FreeSwan.</para>
|
||||
</important>
|
||||
|
||||
<warning>
|
||||
<para>As of this writing, the Netfilter+ipsec and policy match support are
|
||||
broken when used with a bridge device. The problem has been reported to
|
||||
the responsible Netfilter developer who has confirmed the problem. The
|
||||
problem was presumably corrected in Kernel 2.6.20 as a result of the
|
||||
removal of deferred FORWARD/OUTPUT processing of traffic destined for a
|
||||
bridge. See the <ulink
|
||||
<para>When running a Linux kernel prior to 2.6.20, the Netfilter+ipsec and
|
||||
policy match support are broken when used with a bridge device. The
|
||||
problem has been reported to the responsible Netfilter developer who has
|
||||
confirmed the problem. The problem was corrected in Kernel 2.6.20 as a
|
||||
result of the removal of deferred FORWARD/OUTPUT processing of traffic
|
||||
destined for a bridge. See the <ulink
|
||||
url="bridge-Shorewall-perl.html">"<emphasis>Shorewall-perl and Bridged
|
||||
Firewalls</emphasis>"</ulink> article.</para>
|
||||
</warning>
|
||||
@ -247,7 +244,7 @@
|
||||
<orderedlist numeration="loweralpha">
|
||||
<listitem>
|
||||
<para>Open the firewall so that the IPSEC tunnel can be established
|
||||
(allow the ESP and AH protocols and UDP Port 500).</para>
|
||||
(allow the ESP protocol and UDP Port 500).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -895,7 +892,7 @@ net eth0 detect routefilter,dhcp,tcpflags
|
||||
|
||||
<programlisting>#TYPE ZONE GATEWAY GATEWAY
|
||||
# ZONE
|
||||
ipsec:noah net 192.168.20.0/24 loc</programlisting>
|
||||
ipsec net 192.168.20.0/24 loc</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/zones</filename>:</para>
|
||||
|
||||
|
||||
@ -40,11 +40,10 @@
|
||||
<title>What are Ipsets?</title>
|
||||
|
||||
<para>Ipsets are an extension to Netfilter/iptables that are currently
|
||||
available in Patch-O-Matic-ng (<ulink
|
||||
url="http://www.netfilter.org">http://www.netfilter.org</ulink>). Using
|
||||
ipsets requires that you patch your kernel and iptables and that you build
|
||||
and install the ipset utility from <ulink
|
||||
url="http://ipset.netfilter.org/">http://ipset.netfilter.org/</ulink>.</para>
|
||||
available in <ulink
|
||||
url="http://xtables-addons.sourceforge.net/">xtables-addons</ulink>.
|
||||
Instructions for installing xtables-addons may be found in the <ulink
|
||||
url="Dynamic.html">Dynamic Zones article</ulink>.</para>
|
||||
|
||||
<para>Ipset allows you to create one or more named sets of addresses then
|
||||
use those sets to define Netfilter/iptables rules. Possible uses of ipsets
|
||||
@ -59,9 +58,9 @@
|
||||
|
||||
<listitem>
|
||||
<para>Zone definition. Using the /etc/shorewall/hosts file, you can
|
||||
define a zone based on the (dynamic) contents of an ipset. Again, you
|
||||
can then add or delete addresses to the ipset without restarting
|
||||
Shorewall.</para>
|
||||
<ulink url="Dynamic.html">define a zone based on the (dynamic)
|
||||
contents of an ipset</ulink>. Again, you can then add or delete
|
||||
addresses to the ipset without restarting Shorewall.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
@ -103,7 +102,7 @@
|
||||
<para>Example 2: Allow SSH from all hosts in an ipset named "sshok:</para>
|
||||
|
||||
<para><filename>/etc/shorewall/rules</filename><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT +sshok $FW tcp 22</programlisting></para>
|
||||
ACCEPT net:+sshok $FW tcp 22</programlisting></para>
|
||||
|
||||
<para>Shorewall is not in the ipset load/reload business because the
|
||||
Netfilter rule set is never cleared. That means that there is no
|
||||
@ -150,34 +149,4 @@ fi</programlisting>
|
||||
ignore <filename>/etc/shorewall/ipsets</filename> and will issue a warning
|
||||
if you set SAVE_IPSETS=Yes in <filename>shorewall.conf</filename></para>
|
||||
</section>
|
||||
|
||||
<section id="Dynamic">
|
||||
<title>Defining Dynamic Zones using Ipsets</title>
|
||||
|
||||
<para>The use of ipsets provides a much better way to define dynamic zones
|
||||
than is provided by the native Shorewall implementation. To define a
|
||||
dynamic zone of hosts <emphasis role="bold">dyn</emphasis> that is a
|
||||
sub-zone of zone <emphasis role="bold">loc</emphasis> and that interfaces
|
||||
through interface eth3, use:</para>
|
||||
|
||||
<para>/etc/shorewall/zones:</para>
|
||||
|
||||
<programlisting>#ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
|
||||
loc ipv4
|
||||
dyn:loc ipv4</programlisting>
|
||||
|
||||
<para>/etc/shorewall/interfaces:</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE OPTIONS
|
||||
loc eth3 …</programlisting>
|
||||
|
||||
<para>/etc/shorewall/hosts:</para>
|
||||
|
||||
<programlisting>#ZONE HOSTS OPTIONS
|
||||
dyn eth3:+Dyn</programlisting>
|
||||
|
||||
<para>Now create an ipmap named <emphasis role="bold">Dyn</emphasis> and
|
||||
you're all set. You can add and delete addresses from Dyn without having
|
||||
to touch Shorewall.</para>
|
||||
</section>
|
||||
</article>
|
||||
|
||||
@ -254,7 +254,7 @@ SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443</programlisting>
|
||||
If a host in 192.168.1.0/24 attempts a connection on TCP port 80
|
||||
or 443 and it has sent a packet on either of those ports in the
|
||||
last five minutes then the new connection will use the same
|
||||
provider as the connection over which that ‒‒last packet was
|
||||
provider as the connection over which that last packet was
|
||||
sent.</para>
|
||||
|
||||
<para>When used in the OUTPUT chain, it causes all matching
|
||||
@ -336,7 +336,7 @@ SAME $FW 0.0.0.0/0 tcp 80,443</programlisting>
|
||||
<member><replaceable>shift</replaceable> = 0</member>
|
||||
</simplelist>
|
||||
|
||||
<para> <option>src</option> and <option>dst</option> specify
|
||||
<para><option>src</option> and <option>dst</option> specify
|
||||
whether the mark is to be based on the source or destination
|
||||
address respectively. The selected address is first shifted
|
||||
right by <replaceable>shift</replaceable>, then LANDed with
|
||||
@ -348,7 +348,7 @@ SAME $FW 0.0.0.0/0 tcp 80,443</programlisting>
|
||||
<para>Example:</para>
|
||||
|
||||
<blockquote>
|
||||
<para> IPMARK(src,0xff,0x10100)</para>
|
||||
<para>IPMARK(src,0xff,0x10100)</para>
|
||||
|
||||
<simplelist>
|
||||
<member>Suppose that the source IP address is 192.168.4.3 =
|
||||
|
||||
@ -231,6 +231,37 @@
|
||||
ip6tables/Netfilter provides the necessary support.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">SAME</emphasis> (Added in Shorewall
|
||||
4.3.5) -- Some websites run applications that require multiple
|
||||
connections from a client browser. Where multiple 'balanced'
|
||||
providers are configured, this can lead to problems when some of
|
||||
the connections are routed through one provider and some through
|
||||
another. The SAME target allows you to work around that problem.
|
||||
SAME may be used in the PREROUTING and OUTPUT chains. When used
|
||||
in PREROUTING, it causes matching connections from an individual
|
||||
local system to all use the same provider. For example:
|
||||
<programlisting>#MARK/ SOURCE DEST PROTO DEST
|
||||
#CLASSIFY PORT(S)
|
||||
SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443</programlisting>
|
||||
If a host in 192.168.1.0/24 attempts a connection on TCP port 80
|
||||
or 443 and it has sent a packet on either of those ports in the
|
||||
last five minutes then the new connection will use the same
|
||||
provider as the connection over which that last packet was
|
||||
sent.</para>
|
||||
|
||||
<para>When used in the OUTPUT chain, it causes all matching
|
||||
connections to an individual remote system to all use the same
|
||||
provider. For example:<programlisting>#MARK/ SOURCE DEST PROTO DEST
|
||||
#CLASSIFY PORT(S)
|
||||
SAME $FW 0.0.0.0/0 tcp 80,443</programlisting>
|
||||
If the firewall attempts a connection on TCP port 80 or 443 and
|
||||
it has sent a packet on either of those ports in the last five
|
||||
minutes to the same remote system then the new connection will
|
||||
use the same provider as the connection over which that last
|
||||
packet was sent.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">COMMENT</emphasis> -- the rest of
|
||||
the line will be attached as a comment to the Netfilter rule(s)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user