os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

White space fix only. Translators can ignore.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-19 21:58:48 +00:00
parent dd0a14165c
commit ec7e896314
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43998
1 changed files with 278 additions and 260 deletions
Download patch file Download diff file Expand all files Collapse all files

538
en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
View file

@ -1508,26 +1508,28 @@ block drop out quick on $ext_if from any to $martians</programlisting>
</indexterm>
<para><application>IPFILTER</application>, also known as
<application>IPF</application>, is a cross-platform, open source firewall which
has been ported to several operating systems, including &os;, NetBSD, OpenBSD, and
&solaris;.</para>
<application>IPF</application>, is a cross-platform, open source
firewall which has been ported to several operating systems,
including &os;, NetBSD, OpenBSD, and &solaris;.</para>
<para><application>IPFILTER</application> is a kernel-side firewall and
<acronym>NAT</acronym> mechanism that can be controlled and
monitored by userland programs. Firewall rules
<para><application>IPFILTER</application> is a kernel-side
firewall and <acronym>NAT</acronym> mechanism that can be
controlled and monitored by userland programs. Firewall rules
can be set or deleted using <application>ipf</application>,
<acronym>NAT</acronym> rules can be set or deleted using
<application>ipnat</application>, run-time statistics for the kernel parts of
<application>IPFILTER</application> can be printed using
<application>ipfstat</application>, and
<application>ipmon</application> can be used to log <application>IPFILTER</application>
actions to the system log files.</para>
<application>ipnat</application>, run-time statistics for the
kernel parts of <application>IPFILTER</application> can be
printed using <application>ipfstat</application>, and
<application>ipmon</application> can be used to log
<application>IPFILTER</application> actions to the system log
files.</para>
<para><application>IPF</application> was originally written using a rule processing logic
of <quote>the last matching rule wins</quote> and only used
stateless rules. Since then, <application>IPF</application> has been enhanced to include
the <literal>quick</literal> and
<literal>keep state</literal> options.</para>
<para><application>IPF</application> was originally written using
a rule processing logic of <quote>the last matching rule
wins</quote> and only used stateless rules. Since then,
<application>IPF</application> has been enhanced to include the
<literal>quick</literal> and <literal>keep state</literal>
options.</para>
<para>For a detailed explanation of the legacy rules processing
method, refer to <uri
@ -1535,15 +1537,16 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<para>The <application>IPF</application> FAQ is at <uri
xlink:href="http://www.phildev.net/ipf/index.html">http://www.phildev.net/ipf/index.html</uri>.
A searchable archive of the IPFilter mailing list is
available at <uri
A searchable archive of the IPFilter mailing list is available
at <uri
xlink:href="http://marc.info/?l=ipfilter">http://marc.info/?l=ipfilter</uri>.</para>
<para>This section of the Handbook focuses on
<application>IPF</application> as it pertains to FreeBSD.
It provides examples which uses
rules that contain the <literal>quick</literal> and
<literal>keep state</literal> options.</para>
<application>IPF</application> as it pertains to FreeBSD. It
provides examples which uses rules that contain the
<literal>quick</literal> and <literal>keep state</literal>
options.</para>
<sect2>
<title>Enabling <application>IPF</application></title>
@ -1553,9 +1556,10 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<secondary>enabling</secondary>
</indexterm>
<para><application>IPF</application> is included in the basic &os; install as a kernel
loadable module, meaning that a custom kernel is not needed in
order to enable <application>IPF</application>.</para>
<para><application>IPF</application> is included in the basic
&os; install as a kernel loadable module, meaning that a
custom kernel is not needed in order to enable
<application>IPF</application>.</para>
<indexterm>
<primary>kernel options</primary>
@ -1581,35 +1585,37 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<secondary>kernel options</secondary>
</indexterm>
<para>For users who prefer to statically compile <application>IPF</application> support
into a custom kernel, refer to the instructions in <xref
linkend="kernelconfig"/>. The following kernel options are
available:</para>
<para>For users who prefer to statically compile
<application>IPF</application> support into a custom kernel,
refer to the instructions in <xref linkend="kernelconfig"/>.
The following kernel options are available:</para>
<programlisting>options IPFILTER
options IPFILTER_LOG
options IPFILTER_LOOKUP
options IPFILTER_DEFAULT_BLOCK</programlisting>
<para>where <literal>options IPFILTER</literal> enables support for
<application>IPFILTER</application>, <literal>options IPFILTER_LOG</literal> enables <application>IPF</application>
logging using the <filename>ipl</filename> packet logging
pseudo device for every rule that has the
<literal>log</literal> keyword,
<literal>IPFILTER_LOOKUP</literal> enables <acronym>IP</acronym> pools in
order to speed up <acronym>IP</acronym> lookups, and <literal>options IPFILTER_DEFAULT_BLOCK</literal> changes
the default behavior so that any packet not matching a
firewall <literal>pass</literal> rule gets blocked.</para>
<para>where <literal>options IPFILTER</literal> enables support
for <application>IPFILTER</application>,
<literal>options IPFILTER_LOG</literal> enables
<application>IPF</application> logging using the
<filename>ipl</filename> packet logging pseudo device for
every rule that has the <literal>log</literal> keyword,
<literal>IPFILTER_LOOKUP</literal> enables
<acronym>IP</acronym> pools in order to speed up
<acronym>IP</acronym> lookups, and <literal>options
IPFILTER_DEFAULT_BLOCK</literal> changes the default
behavior so that any packet not matching a firewall
<literal>pass</literal> rule gets blocked.</para>
<para>To configure the system to enable <application>IPF</application>
at boot time, add
the following entries to
<filename>/etc/rc.conf</filename>. These entries will also enable logging and
<literal>default pass all</literal>. To change the
default policy to <literal>block all</literal> without
compiling a custom kernel, remember to add a
<literal>block all</literal> rule at the end of the
ruleset.</para>
<para>To configure the system to enable
<application>IPF</application> at boot time, add the following
entries to <filename>/etc/rc.conf</filename>. These entries
will also enable logging and <literal>default pass
all</literal>. To change the default policy to
<literal>block all</literal> without compiling a custom
kernel, remember to add a <literal>block all</literal> rule at
the end of the ruleset.</para>
<programlisting>ipfilter_enable="YES" # Start ipf firewall
ipfilter_rules="/etc/ipf.rules" # loads rules definition text file
@ -1619,17 +1625,16 @@ ipmon_flags="-Ds" # D = start as daemon
# v = log tcp window, ack, seq
# n = map IP &amp; port to names</programlisting>
<para>If <acronym>NAT</acronym>
functionality is needed, also add these lines:</para>
<para>If <acronym>NAT</acronym> functionality is needed, also
add these lines:</para>
<programlisting>gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlisting>
<para>Then, to start <application>IPF</application> now:</para>
<programlisting>&prompt.root; <command>service ipfilter start</command></programlisting>
</sect2>
<sect2>
@ -1640,8 +1645,8 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
The bi-directional exchange of packets between hosts comprises
a session conversation. The firewall ruleset processes both
the packets arriving from the public Internet, as well as the
packets produced by the system as a response to them.
Each <acronym>TCP/IP</acronym> service is predefined by its
packets produced by the system as a response to them. Each
<acronym>TCP/IP</acronym> service is predefined by its
protocol and listening port. Packets destined for a specific
service originate from the source address using an
unprivileged port and target the specific service port on the
@ -1693,7 +1698,7 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<para>There is a way to build IPF rules that utilize the power
of script symbolic substitution. For more information, see
<xref linkend="firewalls-ipf-rules-script"/>.</para>
<xref linkend="firewalls-ipf-rules-script"/>.</para>
<indexterm>
<primary><application>IPFILTER</application></primary>
@ -1728,196 +1733,205 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<variablelist>
<varlistentry>
<term>ACTION</term>
<listitem>
<para>The action keyword indicates what to do with the packet
if it matches the rest of the filter rule. Each rule
<emphasis>must</emphasis> have an action. The following
actions are recognized:</para>
<term>ACTION</term>
<listitem>
<para>The action keyword indicates what to do with the
packet if it matches the rest of the filter rule. Each
rule <emphasis>must</emphasis> have an action. The
following actions are recognized:</para>
<para><literal>block</literal> indicates that the packet
should be dropped if the selection parameters match the
packet.</para>
<para><literal>block</literal> indicates that the packet
should be dropped if the selection parameters match the
packet.</para>
<para><literal>pass</literal> indicates that the packet should
exit the firewall if the selection parameters match the
packet.</para>
</listitem>
</varlistentry>
<para><literal>pass</literal> indicates that the packet
should exit the firewall if the selection parameters
match the packet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>IN-OUT</term>
<listitem>
<para>A mandatory requirement is that each filter rule
explicitly state which side of the I/O it is to be used
on. The next keyword must be either <literal>in</literal>
or <literal>out</literal> and one or the other has to be
included or the rule will not pass syntax checks.</para>
<varlistentry>
<term>IN-OUT</term>
<listitem>
<para>A mandatory requirement is that each filter rule
explicitly state which side of the I/O it is to be used
on. The next keyword must be either
<literal>in</literal> or <literal>out</literal> and one
or the other has to be included or the rule will not
pass syntax checks.</para>
<para><literal>in</literal> means this rule is being applied
against an inbound packet which has just been received on
the interface facing the public Internet.</para>
<para><literal>in</literal> means this rule is being
applied against an inbound packet which has just been
received on the interface facing the public
Internet.</para>
<para><literal>out</literal> means this rule is being applied
against an outbound packet destined for the interface facing
the public Internet.</para>
</listitem>
</varlistentry>
<para><literal>out</literal> means this rule is being
applied against an outbound packet destined for the
interface facing the public Internet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>OPTIONS</term>
<listitem>
<note>
<para>These options must be used in the order shown
here.</para>
</note>
<varlistentry>
<term>OPTIONS</term>
<listitem>
<note>
<para>These options must be used in the order shown
here.</para>
</note>
<para><literal>log</literal> indicates that the packet header
will be written to the &man.ipl.4; packet log pseudo-device
if the selection parameters match the packet.</para>
<para><literal>log</literal> indicates that the packet
header will be written to the &man.ipl.4; packet log
pseudo-device if the selection parameters match the
packet.</para>
<para><literal>quick</literal> indicates that if the selection
parameters match the packet, this rule will be the last
rule checked, and no further processing of any following
rules will occur for this packet.</para>
<para><literal>quick</literal> indicates that if the
selection parameters match the packet, this rule will be
the last rule checked, and no further processing of any
following rules will occur for this packet.</para>
<para><literal>on</literal> indicates the interface name to
be incorporated into the selection parameters. Interface
names are as displayed by &man.ifconfig.8;. Using this
option, the rule will only match if the packet is going
through that interface in the specified direction.</para>
<para><literal>on</literal> indicates the interface name
to be incorporated into the selection parameters.
Interface names are as displayed by &man.ifconfig.8;.
Using this option, the rule will only match if the
packet is going through that interface in the specified
direction.</para>
<para>When a packet is logged, the headers of the packet are
written to the &man.ipl.4; packet logging pseudo-device.
Immediately following the <literal>log</literal> keyword,
the following qualifiers may be used in this order:</para>
<para>When a packet is logged, the headers of the packet
are written to the &man.ipl.4; packet logging
pseudo-device. Immediately following the
<literal>log</literal> keyword, the following qualifiers
may be used in this order:</para>
<para><literal>body</literal> indicates that the first 128
bytes of the packet contents will be logged after the
headers.</para>
<para><literal>body</literal> indicates that the first 128
bytes of the packet contents will be logged after the
headers.</para>
<para><literal>first</literal>. If the <literal>log</literal>
keyword is being used in conjunction with a <literal>keep
state</literal> option, this option is recommended so that
only the triggering packet is logged and not every packet
which matches the stateful connection.</para>
</listitem>
</varlistentry>
<para><literal>first</literal>. If the
<literal>log</literal> keyword is being used in
conjunction with a <literal>keep state</literal> option,
this option is recommended so that only the triggering
packet is logged and not every packet which matches the
stateful connection.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SELECTION</term>
<listitem>
<para>The keywords described in this section are used to
describe attributes of the packet to be checked when
determining whether or not rules match. There is a
keyword subject, and it has sub-option keywords, one of
which has to be selected. The following general-purpose
attributes are provided for matching, and must be used in
this order:</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SELECTION</term>
<listitem>
<para>The keywords described in this section are used to
describe attributes of the packet to be checked when
determining whether or not rules match. There is a
keyword subject, and it has sub-option keywords, one of
which has to be selected. The following general-purpose
attributes are provided for matching, and must be used
in this order:</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PROTO</term>
<listitem>
<para><literal>proto</literal> is the subject keyword which
must include one of its corresponding keyword sub-option
values. The sub-option indicates a specific protocol to be
matched against.</para>
<varlistentry>
<term>PROTO</term>
<listitem>
<para><literal>proto</literal> is the subject keyword
which must include one of its corresponding keyword
sub-option values. The sub-option indicates a specific
protocol to be matched against.</para>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
protocol names found in <filename>/etc/protocols</filename>
are recognized and may be used. The special protocol
keyword <literal>tcp/udp</literal> may be used to match
either a <acronym>TCP</acronym> or a <acronym>UDP</acronym>
packet, and has been added as a convenience to save
duplication of otherwise identical rules.</para>
</listitem>
</varlistentry>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
protocol names found in
<filename>/etc/protocols</filename> are recognized and
may be used. The special protocol keyword
<literal>tcp/udp</literal> may be used to match either a
<acronym>TCP</acronym> or a <acronym>UDP</acronym>
packet, and has been added as a convenience to save
duplication of otherwise identical rules.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SRC_ADDR/DST_ADDR</term>
<listitem>
<para>The <literal>all</literal> keyword is equivalent to
<quote>from any to any</quote> with no other match
parameters.</para>
<varlistentry>
<term>SRC_ADDR/DST_ADDR</term>
<listitem>
<para>The <literal>all</literal> keyword is equivalent to
<quote>from any to any</quote> with no other match
parameters.</para>
<para><literal>from | to src to dst</literal>: the
<literal>from</literal> and <literal>to</literal>
keywords are used to match against IP addresses. Rules
must specify <emphasis>both</emphasis> the source and
destination parameters. <literal>any</literal> is a special
keyword that matches any IP address. Examples include:
<literal>from any to any</literal>, <literal>from 0.0.0.0/0
to any</literal>, <literal>from any to
0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
any</literal>, and <literal>from any to
0.0.0.0</literal>.</para>
<para><literal>from | to src to dst</literal>: the
<literal>from</literal> and <literal>to</literal>
keywords are used to match against IP addresses. Rules
must specify <emphasis>both</emphasis> the source and
destination parameters. <literal>any</literal> is a
special keyword that matches any IP address. Examples
include: <literal>from any to any</literal>,
<literal>from 0.0.0.0/0 to any</literal>, <literal>from
any to 0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
any</literal>, and <literal>from any to
0.0.0.0</literal>.</para>
<para>There is no way to match ranges of IP addresses which
do not express themselves easily using the dotted numeric
form / mask-length notation. The
<package>net-mgmt/ipcalc</package> port may be used to ease
the calculation. Additional information is available at the
utility's web page: <uri
xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
</listitem>
</varlistentry>
<para>There is no way to match ranges of IP addresses
which do not express themselves easily using the dotted
numeric form / mask-length notation. The
<package>net-mgmt/ipcalc</package> port may be used to
ease the calculation. Additional information is
available at the utility's web page: <uri
xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PORT</term>
<listitem>
<para>If a port match is included, for either or both of
source and destination, it is only applied to
<acronym>TCP</acronym> and <acronym>UDP</acronym> packets.
When composing port comparisons, either the service name
from <filename>/etc/services</filename> or an integer port
number may be used. When the port appears as part of the
<literal>from</literal> object, it matches the source port
number. When it appears as part of the
<literal>to</literal> object, it matches the destination
port number. An example usage is
<literal>from any to any port = 80</literal></para>
<varlistentry>
<term>PORT</term>
<listitem>
<para>If a port match is included, for either or both of
source and destination, it is only applied to
<acronym>TCP</acronym> and <acronym>UDP</acronym>
packets. When composing port comparisons, either the
service name from <filename>/etc/services</filename> or
an integer port number may be used. When the port
appears as part of the <literal>from</literal> object,
it matches the source port number. When it appears as
part of the <literal>to</literal> object, it matches the
destination port number. An example usage is
<literal>from any to any port = 80</literal></para>
<para>Single port comparisons may be done in a number of ways,
using a number of different comparison operators. Instead
of the <literal>=</literal> shown in the example above,
the following operators may be used: <literal>!=</literal>,
<literal>&lt;</literal>, <literal>&gt;</literal>,
<literal>&lt;=</literal>, <literal>&gt;=</literal>,
<literal>eq</literal>, <literal>ne</literal>,
<literal>lt</literal>, <literal>gt</literal>,
<literal>le</literal>, and <literal>ge</literal>.</para>
<para>Single port comparisons may be done in a number of
ways, using a number of different comparison operators.
Instead of the <literal>=</literal> shown in the example
above, the following operators may be used:
<literal>!=</literal>, <literal>&lt;</literal>,
<literal>&gt;</literal>, <literal>&lt;=</literal>,
<literal>&gt;=</literal>, <literal>eq</literal>,
<literal>ne</literal>, <literal>lt</literal>,
<literal>gt</literal>, <literal>le</literal>, and
<literal>ge</literal>.</para>
<para>To specify port ranges, place the two port numbers
between <literal>&lt;&gt;</literal> or
<literal>&gt;&lt;</literal></para>
</listitem>
</varlistentry>
<para>To specify port ranges, place the two port numbers
between <literal>&lt;&gt;</literal> or
<literal>&gt;&lt;</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>TCP</acronym>_FLAG</term>
<listitem>
<para>Flags are only effective for <acronym>TCP</acronym>
filtering. The letters represent one of the possible flags
that can be matched against the <acronym>TCP</acronym>
packet header.</para>
<varlistentry>
<term><acronym>TCP</acronym>_FLAG</term>
<listitem>
<para>Flags are only effective for <acronym>TCP</acronym>
filtering. The letters represent one of the possible
flags that can be matched against the
<acronym>TCP</acronym> packet header.</para>
<para>The modernized rules processing logic uses the
<literal>flags S</literal> parameter to identify the TCP
session start request.</para>
</listitem>
</varlistentry>
<para>The modernized rules processing logic uses the
<literal>flags S</literal> parameter to identify the TCP
session start request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>STATEFUL</term>
<listitem>
<para><literal>keep state</literal> indicates that on a pass
rule, any packets that match the rules selection parameters
should activate the stateful filtering facility.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term>STATEFUL</term>
<listitem>
<para><literal>keep state</literal> indicates that on a
pass rule, any packets that match the rules selection
parameters should activate the stateful filtering
facility.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
@ -2332,8 +2346,9 @@ EOF
</listitem>
<listitem>
<para>Disable <application>IPFILTER</application> in the system startup scripts by
adding <literal>ipfilter_enable="NO"</literal>to
<para>Disable <application>IPFILTER</application> in the
system startup scripts by adding
<literal>ipfilter_enable="NO"</literal>to
<filename>/etc/rc.conf</filename>.</para>
<para>Then, add a script like the following to
@ -2383,7 +2398,7 @@ sh /etc/ipf.rules.script</programlisting>
having to pay the ISP for multiple Internet accounts or IP
addresses.</para>
<para>In IPF, when a packet arrives at the firewall from the LAN
<para>In IPF, when a packet arrives at the firewall from the LAN
with a public destination, it passes through the outbound
filter rules. <acronym>NAT</acronym> gets its turn at the
packet and applies its rules top down, where the first
@ -2402,7 +2417,7 @@ sh /etc/ipf.rules.script</programlisting>
private IP address and then passed to the filter rules for
processing.</para>
<para><acronym>NAT</acronym> will automatically translate the
<para><acronym>NAT</acronym> will automatically translate the
private LAN IP address for each system on the LAN to the
single public IP address as packets exit the firewall bound
for the public Internet. It also performs the reverse
@ -2510,18 +2525,19 @@ sh /etc/ipf.rules.script</programlisting>
<literal>0/32</literal> which uses the IP address assigned to
<replaceable>IF</replaceable>.</para>
<sect3>
<title><acronym>NAT</acronym> for a Large LAN</title>
<sect3>
<title><acronym>NAT</acronym> for a Large LAN</title>
<para>For networks that have large numbers of systems on the LAN
or networks with more than a single LAN, the process of
funneling all those private IP addresses into a single public
IP address becomes a resource problem that may cause problems
with the same port numbers being used many times across many
connections, causing collisions. This section describes two ways to
relieve this resource problem.</para>
<para>For networks that have large numbers of systems on the
LAN or networks with more than a single LAN, the process of
funneling all those private IP addresses into a single
public IP address becomes a resource problem that may cause
problems with the same port numbers being used many times
across many connections, causing collisions. This section
describes two ways to relieve this resource problem.</para>
<para>The first method is to assign ports to use. A normal NAT rule would look like:</para>
<para>The first method is to assign ports to use. A normal
NAT rule would look like:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32</programlisting>
@ -2541,7 +2557,8 @@ sh /etc/ipf.rules.script</programlisting>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto</programlisting>
<para>The second method is to use a pool of public addresses. In very large LANs there comes a point where there are
<para>The second method is to use a pool of public addresses.
In very large LANs there comes a point where there are
just too many LAN addresses to fit into a single public
address. If a block of public IP addresses is available,
these addresses can be used as a <quote>pool</quote>, and
@ -2564,19 +2581,20 @@ sh /etc/ipf.rules.script</programlisting>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24</programlisting>
</sect3>
<sect3>
<title>Port Redirection</title>
<sect3>
<title>Port Redirection</title>
<para>A common practice is to have a web server, email server,
database server, and DNS server each segregated to a different
system on the LAN. In this case, the traffic from these
servers still has to undergo <acronym>NAT</acronym>, but there
has to be some way to direct the inbound traffic to the
correct server. For example, a web server operating on LAN
address <systemitem class="ipaddress">10.0.10.25</systemitem>
and using a single public IP address of
<systemitem class="ipaddress">20.20.20.5</systemitem>, would
use this rule:</para>
<para>A common practice is to have a web server, email server,
database server, and DNS server each segregated to a
different system on the LAN. In this case, the traffic from
these servers still has to undergo <acronym>NAT</acronym>,
but there has to be some way to direct the inbound traffic
to the correct server. For example, a web server operating
on LAN address <systemitem
class="ipaddress">10.0.10.25</systemitem> and using a
single public IP address of <systemitem
class="ipaddress">20.20.20.5</systemitem>, would use this
rule:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80</programlisting>
@ -2589,17 +2607,17 @@ sh /etc/ipf.rules.script</programlisting>
needs to receive public DNS requests:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 53 -&gt; 10.0.10.33 port 53 udp</programlisting>
</sect3>
</sect3>
<sect3>
<title>FTP and <acronym>NAT</acronym></title>
<sect3>
<title>FTP and <acronym>NAT</acronym></title>
<para>FTP has two modes: active mode and passive mode. The
difference is in how the data channel is acquired. Passive
mode is more secure as the data channel is acquired by the
ordinal ftp session requester. For a good explanation of FTP
and the different modes, see <uri
xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>FTP has two modes: active mode and passive mode. The
difference is in how the data channel is acquired. Passive
mode is more secure as the data channel is acquired by the
ordinal ftp session requester. For a good explanation of
FTP and the different modes, see <uri
xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>IP<acronym>NAT</acronym> has a built in FTP proxy option
which can be specified on the <acronym>NAT</acronym> map
@ -2797,9 +2815,9 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<!-- XXX: "can be considered short" == "with incomplete header" -->
<para>In order to setup <application>IPFILTER</application> to log all data to
<filename>/var/log/ipfilter.log</filename>, first
create the empty file:</para>
<para>In order to setup <application>IPFILTER</application> to
log all data to <filename>/var/log/ipfilter.log</filename>,
first create the empty file:</para>
<screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen>
@ -2896,7 +2914,7 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
the next being the ICMP message and sub-message type,
separated by a slash. For example: ICMP 3/3 for a port
unreachable message.</para>
</sect2>
</sect2>
</sect1>
<sect1 xml:id="firewalls-ipfw">