White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
8f97d77882
commit
0f6e87bfc4
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44083
1 changed files with 349 additions and 348 deletions
|
|
@ -1708,40 +1708,39 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
</itemizedlist>
|
||||
|
||||
<para>If <literal>firewall_type</literal> is set to either
|
||||
<literal>client</literal> or <literal>simple</literal>,
|
||||
modify the default rules found in
|
||||
<filename>/etc/rc.firewall</filename> to fit the
|
||||
configuration of the system.</para>
|
||||
<literal>client</literal> or <literal>simple</literal>,
|
||||
modify the default rules found in
|
||||
<filename>/etc/rc.firewall</filename> to fit the
|
||||
configuration of the system.</para>
|
||||
|
||||
<para>Note that the
|
||||
<literal>filename</literal> type is used to load a custom ruleset.</para>
|
||||
<para>Note that the <literal>filename</literal> type is used to
|
||||
load a custom ruleset.</para>
|
||||
|
||||
<para>An alternate way to load a custom ruleset is to set the
|
||||
<literal>firewall_script</literal> variable to the absolute
|
||||
path of an <emphasis>executable script</emphasis> that includes
|
||||
<application>IPFW</application> commands. The examples used in this
|
||||
section assume that the <literal>firewall_script</literal>
|
||||
is set to <filename>/etc/ipfw.rules</filename>:</para>
|
||||
path of an <emphasis>executable script</emphasis> that
|
||||
includes <application>IPFW</application> commands. The
|
||||
examples used in this section assume that the
|
||||
<literal>firewall_script</literal> is set to
|
||||
<filename>/etc/ipfw.rules</filename>:</para>
|
||||
|
||||
<programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
|
||||
<programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
|
||||
|
||||
<para>To enable logging, include this line:</para>
|
||||
|
||||
<programlisting>firewall_logging="YES"</programlisting>
|
||||
|
||||
<para>There is no
|
||||
<filename>/etc/rc.conf</filename> variable to set logging
|
||||
limits. To limit the number of times a rule is logged
|
||||
per connection attempt, specify the number using this line
|
||||
in
|
||||
<filename>/etc/sysctl.conf</filename>:</para>
|
||||
<para>There is no <filename>/etc/rc.conf</filename> variable to
|
||||
set logging limits. To limit the number of times a rule is
|
||||
logged per connection attempt, specify the number using this
|
||||
line in <filename>/etc/sysctl.conf</filename>:</para>
|
||||
|
||||
<programlisting>net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></programlisting>
|
||||
|
||||
|
||||
<para>After saving the needed edits, start the firewall. To
|
||||
enable logging limits now, also set the
|
||||
<command>sysctl</command> value specified above:</para>
|
||||
|
||||
|
||||
<screen>&prompt.root; <userinput>service ipfw start</userinput>
|
||||
&prompt.root; <userinput>sysctl net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></userinput></screen>
|
||||
</sect2>
|
||||
|
|
@ -1755,13 +1754,12 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<secondary>rule processing order</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>When a packet enters the <application>IPFW</application> firewall,
|
||||
it is compared against the first rule in the ruleset and
|
||||
progresses one rule at a time, moving from top to bottom in
|
||||
sequence. When the
|
||||
packet matches the selection parameters of a rule, the rule's
|
||||
action is executed and the search of the ruleset
|
||||
terminates for that packet. This is referred to as
|
||||
<para>When a packet enters the <application>IPFW</application>
|
||||
firewall, it is compared against the first rule in the ruleset
|
||||
and progresses one rule at a time, moving from top to bottom
|
||||
in sequence. When the packet matches the selection parameters
|
||||
of a rule, the rule's action is executed and the search of the
|
||||
ruleset terminates for that packet. This is referred to as
|
||||
<quote>first match wins</quote>. If the packet does not match
|
||||
any of the rules, it gets caught by the mandatory
|
||||
<application>IPFW</application> default rule number 65535,
|
||||
|
|
@ -1781,19 +1779,20 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<para>When creating an
|
||||
<application>IPFW</application> rule, keywords must be
|
||||
written in the following order. Some keywords are mandatory
|
||||
while other keywords are optional. The words shown in uppercase
|
||||
represent a variable and the words shown in lowercase must
|
||||
precede the variable that follows it. The <literal>#</literal> symbol is used
|
||||
to mark the start of a comment and may appear at the end of a
|
||||
rule or on its own line. Blank lines are ignored.</para>
|
||||
while other keywords are optional. The words shown in
|
||||
uppercase represent a variable and the words shown in
|
||||
lowercase must precede the variable that follows it. The
|
||||
<literal>#</literal> symbol is used to mark the start of a
|
||||
comment and may appear at the end of a rule or on its own
|
||||
line. Blank lines are ignored.</para>
|
||||
|
||||
<para><replaceable>CMD RULE_NUMBER set SET_NUMBER ACTION log
|
||||
LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
|
||||
LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
|
||||
OPTIONS</replaceable></para>
|
||||
|
||||
<para>This section provides an overview of these keywords and
|
||||
their options. It is not an exhaustive list of every possible
|
||||
option. Refer to &man.ipfw.8; for a complete description of
|
||||
their options. It is not an exhaustive list of every possible
|
||||
option. Refer to &man.ipfw.8; for a complete description of
|
||||
the rule syntax that can be used when creating
|
||||
<application>IPFW</application> rules.</para>
|
||||
|
||||
|
|
@ -1812,9 +1811,10 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<para>Each rule is associated with a number in the
|
||||
range of <literal>1</literal> to
|
||||
<literal>65534</literal>. The number is used to
|
||||
indicate the order of rule processing. Multiple rules can have the same
|
||||
number, in which case they are checked according to
|
||||
the order in which they have been added.</para>
|
||||
indicate the order of rule processing. Multiple rules
|
||||
can have the same number, in which case they are checked
|
||||
according to the order in which they have been
|
||||
added.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -1822,13 +1822,12 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<term>SET_NUMBER</term>
|
||||
<listitem>
|
||||
<para>Each rule is associated with a set number in the
|
||||
range of <literal>0</literal> to
|
||||
<literal>31</literal>. Sets can be individually
|
||||
disabled or enabled, making it possible to quickly add
|
||||
or delete a set of rules. If a SET_NUMBER is not
|
||||
specified, the rule will be added to set <literal>0</literal>.</para>
|
||||
|
||||
</listitem>
|
||||
range of <literal>0</literal> to <literal>31</literal>.
|
||||
Sets can be individually disabled or enabled, making it
|
||||
possible to quickly add or delete a set of rules. If a
|
||||
SET_NUMBER is not specified, the rule will be added to
|
||||
set <literal>0</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
@ -1840,14 +1839,15 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
rule.</para>
|
||||
|
||||
<para><parameter>allow | accept | pass |
|
||||
permit</parameter>: these keywords are equivalent and allow packets
|
||||
that match the rule.</para>
|
||||
permit</parameter>: these keywords are equivalent and
|
||||
allow packets that match the rule.</para>
|
||||
|
||||
<para><parameter>check-state</parameter>: checks the packet against the dynamic state table.
|
||||
If a match is found, execute the action associated with
|
||||
the rule which generated this dynamic rule, otherwise
|
||||
move to the next rule. A <literal>check-state</literal>
|
||||
rule does not have selection criterion. If no
|
||||
<para><parameter>check-state</parameter>: checks the
|
||||
packet against the dynamic state table. If a match is
|
||||
found, execute the action associated with the rule which
|
||||
generated this dynamic rule, otherwise move to the next
|
||||
rule. A <literal>check-state</literal> rule does not
|
||||
have selection criterion. If no
|
||||
<literal>check-state</literal> rule is present in the
|
||||
ruleset, the dynamic rules table is checked at the first
|
||||
<literal>keep-state</literal> or
|
||||
|
|
@ -1857,9 +1857,9 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
all packets that match rule. The search continues with
|
||||
the next rule.</para>
|
||||
|
||||
<para><parameter>deny | drop</parameter>: either word discards
|
||||
packets that match this rule.</para>
|
||||
|
||||
<para><parameter>deny | drop</parameter>: either word
|
||||
discards packets that match this rule.</para>
|
||||
|
||||
<para>Additional actions are available. Refer to
|
||||
&man.ipfw.8; for details.</para>
|
||||
</listitem>
|
||||
|
|
@ -1873,15 +1873,14 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
to &man.syslogd.8; with a facility name of
|
||||
<literal>SECURITY</literal>. Logging only occurs if the
|
||||
number of packets logged for that particular rule does
|
||||
not exceed the optional specified LOG_AMOUNT.
|
||||
If no LOG_AMOUNT is specified, the
|
||||
limit is taken from the value
|
||||
of <varname>net.inet.ip.fw.verbose_limit</varname>. A
|
||||
value of zero removes the logging limit.
|
||||
Once the limit is reached, logging can be re-enabled by
|
||||
clearing the logging counter or the packet counter for
|
||||
that rule, using <command>ipfw reset
|
||||
log</command>.</para>
|
||||
not exceed the optional specified LOG_AMOUNT. If no
|
||||
LOG_AMOUNT is specified, the limit is taken from the
|
||||
value of
|
||||
<varname>net.inet.ip.fw.verbose_limit</varname>. A
|
||||
value of zero removes the logging limit. Once the limit
|
||||
is reached, logging can be re-enabled by clearing the
|
||||
logging counter or the packet counter for that rule,
|
||||
using <command>ipfw reset log</command>.</para>
|
||||
|
||||
<note>
|
||||
<para>Logging is done after all other packet matching
|
||||
|
|
@ -1898,25 +1897,25 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<para>This optional value can be used to specify any
|
||||
protocol name or number found in
|
||||
<filename>/etc/protocols</filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>SRC</term>
|
||||
<listitem>
|
||||
<para>The <literal>from</literal>
|
||||
keyword must be followed by the source address or a
|
||||
keyword that represents the source address. An address
|
||||
can be represented by the <literal>any</literal>,
|
||||
<literal>me</literal> (any address configured on an
|
||||
interface on this system),
|
||||
<para>The <literal>from</literal> keyword must be followed
|
||||
by the source address or a keyword that represents the
|
||||
source address. An address can be represented by the
|
||||
<literal>any</literal>, <literal>me</literal> (any
|
||||
address configured on an interface on this system),
|
||||
<literal>me6</literal>, (any <acronym>IPv6</acronym>
|
||||
address configured on an interface on this system), or
|
||||
<literal>table</literal> followed by the number of a
|
||||
lookup table which contains a list of addresses. When
|
||||
specifying an <acronym>IP</acronym> address, it can be
|
||||
optionally followed by its <acronym>CIDR</acronym> mask
|
||||
or subnet mask. For example, <literal>1.2.3.4/25</literal> or
|
||||
or subnet mask. For example,
|
||||
<literal>1.2.3.4/25</literal> or
|
||||
<literal>1.2.3.4:255.255.255.128</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -1934,10 +1933,10 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<term>DST</term>
|
||||
<listitem>
|
||||
<para>The <literal>to</literal> keyword must be followed
|
||||
by the destination address or a
|
||||
keyword that represents the destination address. The
|
||||
same keywords and addresses described in the SRC section
|
||||
can be used to describe the destination.</para>
|
||||
by the destination address or a keyword that represents
|
||||
the destination address. The same keywords and
|
||||
addresses described in the SRC section can be used to
|
||||
describe the destination.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -1956,28 +1955,29 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
<para>Several keywords can follow the source and
|
||||
destination. As the name suggests, OPTIONS are
|
||||
optional. Commonly used options include
|
||||
<literal>in</literal> or
|
||||
<literal>out</literal>, which specify the direction of
|
||||
packet flow, <literal>icmptypes</literal> followed by
|
||||
the type of <acronym>ICMP</acronym> message, and
|
||||
<literal>in</literal> or <literal>out</literal>, which
|
||||
specify the direction of packet flow,
|
||||
<literal>icmptypes</literal> followed by the type of
|
||||
<acronym>ICMP</acronym> message, and
|
||||
<literal>keep-state</literal>.</para>
|
||||
|
||||
<para>When a <parameter>keep-state</parameter> rule is matched, the
|
||||
firewall will create a dynamic rule which
|
||||
matches bidirectional traffic between the
|
||||
source and destination addresses and ports using the same
|
||||
<para>When a <parameter>keep-state</parameter> rule is
|
||||
matched, the firewall will create a dynamic rule which
|
||||
matches bidirectional traffic between the source and
|
||||
destination addresses and ports using the same
|
||||
protocol.</para>
|
||||
|
||||
<para>The dynamic rules facility is vulnerable to resource
|
||||
depletion from a SYN-flood attack which would open a
|
||||
huge number of dynamic rules. To counter this type of
|
||||
attack with <application>IPFW</application>, use
|
||||
<literal>limit</literal>. This option limits the
|
||||
number of simultaneous sessions by checking the open dynamic rules, counting
|
||||
the number of times this rule and <acronym>IP</acronym> address
|
||||
combination occurred. If this count is greater than the
|
||||
value specified by <literal>limit</literal>, the packet
|
||||
is discarded.</para>
|
||||
<literal>limit</literal>. This option limits the number
|
||||
of simultaneous sessions by checking the open dynamic
|
||||
rules, counting the number of times this rule and
|
||||
<acronym>IP</acronym> address combination occurred. If
|
||||
this count is greater than the value specified by
|
||||
<literal>limit</literal>, the packet is
|
||||
discarded.</para>
|
||||
|
||||
<para>Dozens of OPTIONS are available. Refer to
|
||||
&man.ipfw.8; for a description of each available
|
||||
|
|
@ -1988,38 +1988,38 @@ options IPDIVERT # enables NAT</programlisting>
|
|||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Example Ruleset</title>
|
||||
<title>Example Ruleset</title>
|
||||
|
||||
<para>This section demonstrates how to create an example
|
||||
stateful firewall ruleset script named
|
||||
<filename>/etc/ipfw.rules</filename>. In this example, all
|
||||
connection rules use <literal>in</literal> or
|
||||
<literal>out</literal> to clarify the direction. They also
|
||||
use <literal>via</literal>
|
||||
<replaceable>interface-name</replaceable> to specify
|
||||
the interface the packet is traveling over.</para>
|
||||
<para>This section demonstrates how to create an example
|
||||
stateful firewall ruleset script named
|
||||
<filename>/etc/ipfw.rules</filename>. In this example, all
|
||||
connection rules use <literal>in</literal> or
|
||||
<literal>out</literal> to clarify the direction. They also
|
||||
use <literal>via</literal>
|
||||
<replaceable>interface-name</replaceable> to specify
|
||||
the interface the packet is traveling over.</para>
|
||||
|
||||
<note>
|
||||
<para>When first creating or testing a firewall ruleset,
|
||||
consider temporarily setting this tunable:</para>
|
||||
<note>
|
||||
<para>When first creating or testing a firewall ruleset,
|
||||
consider temporarily setting this tunable:</para>
|
||||
|
||||
<programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
|
||||
<programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
|
||||
|
||||
<para>This sets the default policy of &man.ipfw.8; to
|
||||
be more permissive than the default <literal>deny ip from
|
||||
any to any</literal>, making it slightly more difficult
|
||||
to get locked out of the system right after a reboot.</para>
|
||||
<para>This sets the default policy of &man.ipfw.8; to be more
|
||||
permissive than the default <literal>deny ip from any to
|
||||
any</literal>, making it slightly more difficult to get
|
||||
locked out of the system right after a reboot.</para>
|
||||
</note>
|
||||
|
||||
<para>The firewall script begins by indicating that it is a
|
||||
Bourne shell script and flushes any existing rules. It then
|
||||
creates the <literal>cmd</literal> variable so that
|
||||
<literal>ipfw add</literal> does not have to be typed at the
|
||||
beginning of every rule. It also defines the
|
||||
<literal>pif</literal> variable which represents the name of
|
||||
the interface that is attached to the Internet.</para>
|
||||
<para>The firewall script begins by indicating that it is a
|
||||
Bourne shell script and flushes any existing rules. It then
|
||||
creates the <literal>cmd</literal> variable so that
|
||||
<literal>ipfw add</literal> does not have to be typed at the
|
||||
beginning of every rule. It also defines the
|
||||
<literal>pif</literal> variable which represents the name of
|
||||
the interface that is attached to the Internet.</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
<programlisting>#!/bin/sh
|
||||
# Flush out the list before we begin.
|
||||
ipfw -q -f flush
|
||||
|
||||
|
|
@ -2027,24 +2027,24 @@ ipfw -q -f flush
|
|||
cmd="ipfw -q add"
|
||||
pif="dc0" # interface name of NIC attached to Internet</programlisting>
|
||||
|
||||
<para>The first two rules allow all traffic on the trusted
|
||||
internal interface and on the loopback interface:</para>
|
||||
<para>The first two rules allow all traffic on the trusted
|
||||
internal interface and on the loopback interface:</para>
|
||||
|
||||
<programlisting># Change xl0 to LAN NIC interface name
|
||||
<programlisting># Change xl0 to LAN NIC interface name
|
||||
$cmd 00005 allow all from any to any via xl0
|
||||
|
||||
# No restrictions on Loopback Interface
|
||||
$cmd 00010 allow all from any to any via lo0</programlisting>
|
||||
|
||||
<para>The next rule allows the packet through if it matches
|
||||
an existing entry in the dynamic rules table:</para>
|
||||
<para>The next rule allows the packet through if it matches an
|
||||
existing entry in the dynamic rules table:</para>
|
||||
|
||||
<programlisting>$cmd 00015 check-state</programlisting>
|
||||
<programlisting>$cmd 00015 check-state</programlisting>
|
||||
|
||||
<para>The next set of rules defines which stateful connections
|
||||
internal systems can create to hosts on the Internet:</para>
|
||||
<para>The next set of rules defines which stateful connections
|
||||
internal systems can create to hosts on the Internet:</para>
|
||||
|
||||
<programlisting># Allow access to public DNS
|
||||
<programlisting># Allow access to public DNS
|
||||
# Replace x.x.x.x with the IP address of a public DNS server
|
||||
# and repeat for each DNS server in /etc/resolv.conf
|
||||
$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state
|
||||
|
|
@ -2076,14 +2076,14 @@ pif="dc0" # interface name of NIC attached to Internet</programlisting>
|
|||
# deny and log all other outbound connections
|
||||
$cmd 00299 deny log all from any to any out via $pif</programlisting>
|
||||
|
||||
<para>The next set of rules controls connections from
|
||||
Internet hosts to the internal network. It starts by
|
||||
denying packets typically associated with attacks and then
|
||||
explicitly allows specific types of connections. All the
|
||||
authorized services that originate from the Internet use
|
||||
<literal>limit</literal> to prevent flooding.</para>
|
||||
<para>The next set of rules controls connections from Internet
|
||||
hosts to the internal network. It starts by denying packets
|
||||
typically associated with attacks and then explicitly allows
|
||||
specific types of connections. All the authorized services
|
||||
that originate from the Internet use <literal>limit</literal>
|
||||
to prevent flooding.</para>
|
||||
|
||||
<programlisting># Deny all inbound traffic from non-routable reserved address spaces
|
||||
<programlisting># Deny all inbound traffic from non-routable reserved address spaces
|
||||
$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP
|
||||
$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP
|
||||
$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP
|
||||
|
|
@ -2125,50 +2125,49 @@ pif="dc0" # interface name of NIC attached to Internet</programlisting>
|
|||
# Reject and log all other incoming connections
|
||||
$cmd 00499 deny log all from any to any in via $pif</programlisting>
|
||||
|
||||
<para>The last rule logs all packets that do not match any of
|
||||
the rules in the
|
||||
ruleset:</para>
|
||||
<para>The last rule logs all packets that do not match any of
|
||||
the rules in the ruleset:</para>
|
||||
|
||||
<programlisting># Everything else is denied and logged
|
||||
<programlisting># Everything else is denied and logged
|
||||
$cmd 00999 deny log all from any to any</programlisting>
|
||||
</sect2>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="network-natd">
|
||||
<info>
|
||||
<sect2 xml:id="network-natd">
|
||||
<info>
|
||||
<title>Configuring <acronym>NAT</acronym></title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Chern</firstname>
|
||||
<surname>Lee</surname>
|
||||
</personname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</info>
|
||||
<indexterm>
|
||||
<primary>NAT</primary>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Chern</firstname>
|
||||
<surname>Lee</surname>
|
||||
</personname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</info>
|
||||
<indexterm>
|
||||
<primary>NAT</primary>
|
||||
|
||||
<secondary>and <application>IPFW</application></secondary>
|
||||
</indexterm>
|
||||
<secondary>and <application>IPFW</application></secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>&os;'s built-in
|
||||
<acronym>NAT</acronym> daemon, &man.natd.8;, works in
|
||||
conjunction with <application>IPFW</application> to provide
|
||||
network address translation. This can be used to provide an
|
||||
Internet Connection Sharing solution so that
|
||||
several internal computers can connect to the Internet using
|
||||
<acronym>IP</acronym> address.</para>
|
||||
<para>&os;'s built-in <acronym>NAT</acronym> daemon,
|
||||
&man.natd.8;, works in conjunction with
|
||||
<application>IPFW</application> to provide network address
|
||||
translation. This can be used to provide an Internet
|
||||
Connection Sharing solution so that several internal computers
|
||||
can connect to the Internet using <acronym>IP</acronym>
|
||||
address.</para>
|
||||
|
||||
<para>To do this, the &os; machine connected to the Internet
|
||||
<para>To do this, the &os; machine connected to the Internet
|
||||
must act as a gateway. This gateway machine must have two
|
||||
<acronym>NIC</acronym>s: one connects to the Internet router
|
||||
and the other connects to a <acronym>LAN</acronym>. All the
|
||||
machines on the <acronym>LAN</acronym> are connected through
|
||||
a hub or switch.</para>
|
||||
|
||||
<para>Each machine and interface behind the
|
||||
<para>Each machine and interface behind the
|
||||
<acronym>LAN</acronym> should be assigned
|
||||
<acronym>IP</acronym> addresses in the private network space,
|
||||
as defined by <link
|
||||
|
|
@ -2177,18 +2176,18 @@ pif="dc0" # interface name of NIC attached to Internet</programlisting>
|
|||
&man.natd.8; machine's internal <acronym>IP</acronym>
|
||||
address.</para>
|
||||
|
||||
<para>Some additional configuration is
|
||||
needed in order to activate the <acronym>NAT</acronym>
|
||||
function of <application>IPFW</application>. If the system
|
||||
has a custom kernel, the kernel configuration file needs to
|
||||
include <literal>option IPDIVERT</literal> with the other
|
||||
<literal>IPFIREWALL</literal> options.</para>
|
||||
<para>Some additional configuration is needed in order to
|
||||
activate the <acronym>NAT</acronym> function of
|
||||
<application>IPFW</application>. If the system has a custom
|
||||
kernel, the kernel configuration file needs to include
|
||||
<literal>option IPDIVERT</literal> with the other
|
||||
<literal>IPFIREWALL</literal> options.</para>
|
||||
|
||||
<para>To enable firewall and <acronym>NAT</acronym> support at
|
||||
boot time, the following must be in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
<para>To enable firewall and <acronym>NAT</acronym> support at
|
||||
boot time, the following must be in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>gateway_enable="YES" # enables the gateway function
|
||||
<programlisting>gateway_enable="YES" # enables the gateway function
|
||||
natd_enable="YES" # enables the <acronym>NAT</acronym> function
|
||||
natd_interface="rl0" # specify interface name of NIC attached to Internet
|
||||
natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting>
|
||||
|
|
@ -2213,87 +2212,87 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
|
|||
consult &man.natd.8;.</para>
|
||||
</note>
|
||||
|
||||
<para>Utilizing stateful rules with a <literal>divert
|
||||
natd</literal> rule complicates the ruleset logic. The
|
||||
positioning of the <literal>check-state</literal>, and
|
||||
<literal>divert natd</literal> rules in the ruleset is
|
||||
critical and a new action type is used, called
|
||||
<literal>skipto</literal>. When using
|
||||
<literal>skipto</literal>, it is mandatory that each rule is
|
||||
numbered, so that the <literal>skipto</literal> rule knows
|
||||
which rule to jump to.</para>
|
||||
<para>Utilizing stateful rules with a <literal>divert
|
||||
natd</literal> rule complicates the ruleset logic. The
|
||||
positioning of the <literal>check-state</literal>, and
|
||||
<literal>divert natd</literal> rules in the ruleset is
|
||||
critical and a new action type is used, called
|
||||
<literal>skipto</literal>. When using
|
||||
<literal>skipto</literal>, it is mandatory that each rule is
|
||||
numbered, so that the <literal>skipto</literal> rule knows
|
||||
which rule to jump to.</para>
|
||||
|
||||
<para>The following is an uncommented example of a ruleset
|
||||
which explains the sequence of the packet flow.</para>
|
||||
<para>The following is an uncommented example of a ruleset
|
||||
which explains the sequence of the packet flow.</para>
|
||||
|
||||
<para>The processing flow starts with the first rule from the
|
||||
top of the ruleset and progresses one rule at a time until
|
||||
the end is reached or the packet matches and the packet is
|
||||
released out of the firewall. Take note of the location of
|
||||
rule numbers 100 101, 450, 500, and 510. These rules
|
||||
control the translation of the outbound and inbound packets
|
||||
so that their entries in the dynamic keep-state table always
|
||||
register the private LAN IP address. All the allow and deny
|
||||
rules specify the direction of the packet and the interface.
|
||||
All start outbound session requests will
|
||||
<literal>skipto rule 500</literal> to undergo NAT.</para>
|
||||
<para>The processing flow starts with the first rule from the
|
||||
top of the ruleset and progresses one rule at a time until
|
||||
the end is reached or the packet matches and the packet is
|
||||
released out of the firewall. Take note of the location of
|
||||
rule numbers 100 101, 450, 500, and 510. These rules
|
||||
control the translation of the outbound and inbound packets
|
||||
so that their entries in the dynamic keep-state table always
|
||||
register the private LAN IP address. All the allow and deny
|
||||
rules specify the direction of the packet and the interface.
|
||||
All start outbound session requests will
|
||||
<literal>skipto rule 500</literal> to undergo NAT.</para>
|
||||
|
||||
<para>Consider a web browser which initializes a new HTTP
|
||||
session over port 80. When the first outbound packet enters
|
||||
the firewall, it does not match rule 100 because it is
|
||||
headed out rather than in. It passes rule 101 because this
|
||||
is the first packet, and it has not been posted to the
|
||||
dynamic keep-state table yet. The packet finally matches
|
||||
rule 125 as it is outbound through the NIC facing the
|
||||
Internet and has a source IP address as a private LAN IP
|
||||
address. On matching this rule, two actions take place.
|
||||
<literal>keep-state</literal> adds this rule to the dynamic
|
||||
keep-state rules table and the specified action is executed
|
||||
and posted as part of the info in the dynamic table. In
|
||||
this case, the action is <literal>skipto rule 500</literal>.
|
||||
Rule 500 <acronym>NAT</acronym>s the packet IP address and
|
||||
sends it out to the Internet. This packet makes its way to
|
||||
the destination web server, where a response packet is
|
||||
generated and sent back. This new packet enters the top of
|
||||
the ruleset. It matches rule 100 and has it destination IP
|
||||
address mapped back to the corresponding LAN IP address. It
|
||||
then is processed by the <literal>check-state</literal>
|
||||
rule, is found in the table as an existing session, and is
|
||||
released to the LAN. It goes to the LAN system that sent it
|
||||
and a new packet is sent requesting another segment of the
|
||||
data from the remote server. This time it matches the
|
||||
<literal>check-state</literal> rule, its outbound entry is
|
||||
found, and the associated action,
|
||||
<literal>skipto 500</literal>, is executed. The packet
|
||||
jumps to rule 500, gets <acronym>NAT</acronym>ed, and is
|
||||
released to the Internet.</para>
|
||||
<para>Consider a web browser which initializes a new HTTP
|
||||
session over port 80. When the first outbound packet enters
|
||||
the firewall, it does not match rule 100 because it is
|
||||
headed out rather than in. It passes rule 101 because this
|
||||
is the first packet, and it has not been posted to the
|
||||
dynamic keep-state table yet. The packet finally matches
|
||||
rule 125 as it is outbound through the NIC facing the
|
||||
Internet and has a source IP address as a private LAN IP
|
||||
address. On matching this rule, two actions take place.
|
||||
<literal>keep-state</literal> adds this rule to the dynamic
|
||||
keep-state rules table and the specified action is executed
|
||||
and posted as part of the info in the dynamic table. In
|
||||
this case, the action is <literal>skipto rule 500</literal>.
|
||||
Rule 500 <acronym>NAT</acronym>s the packet IP address and
|
||||
sends it out to the Internet. This packet makes its way to
|
||||
the destination web server, where a response packet is
|
||||
generated and sent back. This new packet enters the top of
|
||||
the ruleset. It matches rule 100 and has it destination IP
|
||||
address mapped back to the corresponding LAN IP address. It
|
||||
then is processed by the <literal>check-state</literal>
|
||||
rule, is found in the table as an existing session, and is
|
||||
released to the LAN. It goes to the LAN system that sent it
|
||||
and a new packet is sent requesting another segment of the
|
||||
data from the remote server. This time it matches the
|
||||
<literal>check-state</literal> rule, its outbound entry is
|
||||
found, and the associated action,
|
||||
<literal>skipto 500</literal>, is executed. The packet
|
||||
jumps to rule 500, gets <acronym>NAT</acronym>ed, and is
|
||||
released to the Internet.</para>
|
||||
|
||||
<para>On the inbound side, everything coming in that is part
|
||||
of an existing session is automatically handled by the
|
||||
<literal>check-state</literal> rule and the properly placed
|
||||
<literal>divert natd</literal> rules. The ruleset only has
|
||||
to deny bad packets and allow only authorized services.
|
||||
Consider a web server running on the firewall where web
|
||||
requests from the Internet should have access to the local
|
||||
web site. An inbound start request packet will match rule
|
||||
100 and its IP address will be mapped to the LAN IP address
|
||||
of the firewall. The packet is then matched against all the
|
||||
nasty things that need to be checked and finally matches
|
||||
rule 425 where two actions occur. The packet rule is posted
|
||||
to the dynamic keep-state table but this time, any new
|
||||
session requests originating from that source IP address are
|
||||
limited to 2. This defends against DoS attacks against the
|
||||
service running on the specified port number. The action is
|
||||
<literal>allow</literal>, so the packet is released to the
|
||||
LAN. The packet generated as a response is recognized by the
|
||||
<literal>check-state</literal> as belonging to an existing
|
||||
session. It is then sent to rule 500 for
|
||||
<acronym>NAT</acronym>ing and released to the outbound
|
||||
interface.</para>
|
||||
<para>On the inbound side, everything coming in that is part of
|
||||
an existing session is automatically handled by the
|
||||
<literal>check-state</literal> rule and the properly placed
|
||||
<literal>divert natd</literal> rules. The ruleset only has
|
||||
to deny bad packets and allow only authorized services.
|
||||
Consider a web server running on the firewall where web
|
||||
requests from the Internet should have access to the local
|
||||
web site. An inbound start request packet will match rule
|
||||
100 and its IP address will be mapped to the LAN IP address
|
||||
of the firewall. The packet is then matched against all the
|
||||
nasty things that need to be checked and finally matches
|
||||
rule 425 where two actions occur. The packet rule is posted
|
||||
to the dynamic keep-state table but this time, any new
|
||||
session requests originating from that source IP address are
|
||||
limited to 2. This defends against DoS attacks against the
|
||||
service running on the specified port number. The action is
|
||||
<literal>allow</literal>, so the packet is released to the
|
||||
LAN. The packet generated as a response is recognized by the
|
||||
<literal>check-state</literal> as belonging to an existing
|
||||
session. It is then sent to rule 500 for
|
||||
<acronym>NAT</acronym>ing and released to the outbound
|
||||
interface.</para>
|
||||
|
||||
<para>Example Ruleset #1:</para>
|
||||
<para>Example Ruleset #1:</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
<programlisting>#!/bin/sh
|
||||
cmd="ipfw -q add"
|
||||
skip="skipto 500"
|
||||
pif=rl0
|
||||
|
|
@ -2340,13 +2339,13 @@ ipfw -q -f flush
|
|||
|
||||
######################## end of rules ##################</programlisting>
|
||||
|
||||
<para>The next example is functionally equivalent, but uses
|
||||
descriptive comments to help the inexperienced IPFW rule
|
||||
writer to better understand what the rules are doing.</para>
|
||||
<para>The next example is functionally equivalent, but uses
|
||||
descriptive comments to help the inexperienced IPFW rule
|
||||
writer to better understand what the rules are doing.</para>
|
||||
|
||||
<para>Example Ruleset #2:</para>
|
||||
<para>Example Ruleset #2:</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
<programlisting>#!/bin/sh
|
||||
################ Start of IPFW rules file ###############################
|
||||
# Flush out the list before we begin.
|
||||
ipfw -q -f flush
|
||||
|
|
@ -2499,130 +2498,132 @@ pif="rl0" # public interface name of NIC
|
|||
$cmd 999 deny log all from any to any
|
||||
################ End of IPFW rules file ###############################</programlisting>
|
||||
|
||||
<sect3>
|
||||
<title>Port Redirection</title>
|
||||
<sect3>
|
||||
<title>Port Redirection</title>
|
||||
|
||||
<para>The drawback with &man.natd.8; is that the
|
||||
<acronym>LAN</acronym> clients are not accessible from the
|
||||
Internet. Clients on the <acronym>LAN</acronym> can make
|
||||
outgoing connections to the world but cannot receive incoming
|
||||
ones. This presents a problem if trying to run Internet
|
||||
services on one of the <acronym>LAN</acronym> client machines.
|
||||
A simple way around this is to redirect selected Internet
|
||||
ports on the &man.natd.8; machine to a <acronym>LAN</acronym>
|
||||
client.</para>
|
||||
<para>The drawback with &man.natd.8; is that the
|
||||
<acronym>LAN</acronym> clients are not accessible from the
|
||||
Internet. Clients on the <acronym>LAN</acronym> can make
|
||||
outgoing connections to the world but cannot receive
|
||||
incoming ones. This presents a problem if trying to run
|
||||
Internet services on one of the <acronym>LAN</acronym>
|
||||
client machines. A simple way around this is to redirect
|
||||
selected Internet ports on the &man.natd.8; machine to a
|
||||
<acronym>LAN</acronym> client.</para>
|
||||
|
||||
<para>For example, an <acronym>IRC</acronym> server runs on
|
||||
client <systemitem>A</systemitem> and a web server runs on
|
||||
client <systemitem>B</systemitem>. For this to work properly,
|
||||
connections received on ports 6667 (<acronym>IRC</acronym>)
|
||||
and 80 (<acronym>HTTP</acronym>) must be redirected to the
|
||||
respective machines.</para>
|
||||
<para>For example, an <acronym>IRC</acronym> server runs on
|
||||
client <systemitem>A</systemitem> and a web server runs on
|
||||
client <systemitem>B</systemitem>. For this to work
|
||||
properly, connections received on ports 6667
|
||||
(<acronym>IRC</acronym>) and 80 (<acronym>HTTP</acronym>)
|
||||
must be redirected to the respective machines.</para>
|
||||
|
||||
<para>The syntax for <option>-redirect_port</option> is as
|
||||
follows:</para>
|
||||
<para>The syntax for <option>-redirect_port</option> is as
|
||||
follows:</para>
|
||||
|
||||
<programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT]
|
||||
<programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT]
|
||||
[aliasIP:]aliasPORT[-aliasPORT]
|
||||
[remoteIP[:remotePORT[-remotePORT]]]</programlisting>
|
||||
|
||||
<para>In the above example, the argument should be:</para>
|
||||
<para>In the above example, the argument should be:</para>
|
||||
|
||||
<programlisting> -redirect_port tcp 192.168.0.2:6667 6667
|
||||
<programlisting> -redirect_port tcp 192.168.0.2:6667 6667
|
||||
-redirect_port tcp 192.168.0.3:80 80</programlisting>
|
||||
|
||||
<para>This redirects the proper <acronym>TCP</acronym> ports
|
||||
to the <acronym>LAN</acronym> client machines.</para>
|
||||
<para>This redirects the proper <acronym>TCP</acronym> ports
|
||||
to the <acronym>LAN</acronym> client machines.</para>
|
||||
|
||||
<para>Port ranges over individual ports can be indicated with
|
||||
<option>-redirect_port</option>. For example,
|
||||
<replaceable>tcp 192.168.0.2:2000-3000 2000-3000</replaceable>
|
||||
would redirect all connections received on ports 2000 to 3000
|
||||
to ports 2000 to 3000 on client
|
||||
<systemitem>A</systemitem>.</para>
|
||||
<para>Port ranges over individual ports can be indicated with
|
||||
<option>-redirect_port</option>. For example,
|
||||
<replaceable>tcp 192.168.0.2:2000-3000
|
||||
2000-3000</replaceable> would redirect all connections
|
||||
received on ports 2000 to 3000 to ports 2000 to 3000 on
|
||||
client <systemitem>A</systemitem>.</para>
|
||||
|
||||
<para>These options can be used when directly running
|
||||
&man.natd.8;, placed within the
|
||||
<literal>natd_flags=""</literal> option in
|
||||
<filename>/etc/rc.conf</filename>, or passed via a
|
||||
configuration file.</para>
|
||||
<para>These options can be used when directly running
|
||||
&man.natd.8;, placed within the
|
||||
<literal>natd_flags=""</literal> option in
|
||||
<filename>/etc/rc.conf</filename>, or passed via a
|
||||
configuration file.</para>
|
||||
|
||||
<para>For further configuration options, consult
|
||||
&man.natd.8;</para>
|
||||
</sect3>
|
||||
<para>For further configuration options, consult
|
||||
&man.natd.8;</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Address Redirection</title>
|
||||
<sect3>
|
||||
<title>Address Redirection</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>address redirection</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>address redirection</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Address redirection is useful if more than one
|
||||
<acronym>IP</acronym> address is available. Each
|
||||
<acronym>LAN</acronym> client can be assigned its own
|
||||
external <acronym>IP</acronym> address by &man.natd.8;,
|
||||
which will then rewrite outgoing packets from the
|
||||
<acronym>LAN</acronym> clients with the proper external
|
||||
<acronym>IP</acronym> address and redirects all traffic
|
||||
incoming on that particular <acronym>IP</acronym> address
|
||||
back to the specific <acronym>LAN</acronym> client. This is
|
||||
also known as static <acronym>NAT</acronym>. For example,
|
||||
if <acronym>IP</acronym> addresses <systemitem
|
||||
class="ipaddress">128.1.1.1</systemitem>, <systemitem
|
||||
class="ipaddress">128.1.1.2</systemitem>, and <systemitem
|
||||
class="ipaddress">128.1.1.3</systemitem> are available,
|
||||
<systemitem class="ipaddress">128.1.1.1</systemitem> can be
|
||||
used as the &man.natd.8; machine's external
|
||||
<acronym>IP</acronym> address, while <systemitem
|
||||
class="ipaddress">128.1.1.2</systemitem> and <systemitem
|
||||
class="ipaddress">128.1.1.3</systemitem> are forwarded back
|
||||
to <acronym>LAN</acronym> clients <systemitem>A</systemitem>
|
||||
and <systemitem>B</systemitem>.</para>
|
||||
<para>Address redirection is useful if more than one
|
||||
<acronym>IP</acronym> address is available. Each
|
||||
<acronym>LAN</acronym> client can be assigned its own
|
||||
external <acronym>IP</acronym> address by &man.natd.8;,
|
||||
which will then rewrite outgoing packets from the
|
||||
<acronym>LAN</acronym> clients with the proper external
|
||||
<acronym>IP</acronym> address and redirects all traffic
|
||||
incoming on that particular <acronym>IP</acronym> address
|
||||
back to the specific <acronym>LAN</acronym> client. This is
|
||||
also known as static <acronym>NAT</acronym>. For example,
|
||||
if <acronym>IP</acronym> addresses <systemitem
|
||||
class="ipaddress">128.1.1.1</systemitem>, <systemitem
|
||||
class="ipaddress">128.1.1.2</systemitem>, and <systemitem
|
||||
class="ipaddress">128.1.1.3</systemitem> are available,
|
||||
<systemitem class="ipaddress">128.1.1.1</systemitem> can be
|
||||
used as the &man.natd.8; machine's external
|
||||
<acronym>IP</acronym> address, while <systemitem
|
||||
class="ipaddress">128.1.1.2</systemitem> and <systemitem
|
||||
class="ipaddress">128.1.1.3</systemitem> are forwarded
|
||||
back to <acronym>LAN</acronym> clients
|
||||
<systemitem>A</systemitem> and
|
||||
<systemitem>B</systemitem>.</para>
|
||||
|
||||
<para>The <option>-redirect_address</option> syntax is as
|
||||
follows:</para>
|
||||
<para>The <option>-redirect_address</option> syntax is as
|
||||
follows:</para>
|
||||
|
||||
<programlisting>-redirect_address localIP publicIP</programlisting>
|
||||
<programlisting>-redirect_address localIP publicIP</programlisting>
|
||||
|
||||
|
||||
<informaltable frame="none" pgwide="1">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>localIP</entry>
|
||||
<entry>The internal <acronym>IP</acronym> address of
|
||||
the <acronym>LAN</acronym> client.</entry>
|
||||
</row>
|
||||
<informaltable frame="none" pgwide="1">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>localIP</entry>
|
||||
<entry>The internal <acronym>IP</acronym> address of
|
||||
the <acronym>LAN</acronym> client.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>publicIP</entry>
|
||||
<entry>The external <acronym>IP</acronym> address
|
||||
corresponding to the <acronym>LAN</acronym>
|
||||
client.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
<row>
|
||||
<entry>publicIP</entry>
|
||||
<entry>The external <acronym>IP</acronym> address
|
||||
corresponding to the <acronym>LAN</acronym>
|
||||
client.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>In the example, this argument would read:</para>
|
||||
<para>In the example, this argument would read:</para>
|
||||
|
||||
<programlisting>-redirect_address 192.168.0.2 128.1.1.2
|
||||
<programlisting>-redirect_address 192.168.0.2 128.1.1.2
|
||||
-redirect_address 192.168.0.3 128.1.1.3</programlisting>
|
||||
|
||||
<para>Like <option>-redirect_port</option>, these arguments are
|
||||
placed within the <literal>natd_flags=""</literal> option
|
||||
of <filename>/etc/rc.conf</filename>, or passed via a
|
||||
configuration file. With address redirection, there is no
|
||||
need for port redirection since all data received on a
|
||||
particular <acronym>IP</acronym> address is redirected.</para>
|
||||
<para>Like <option>-redirect_port</option>, these arguments
|
||||
are placed within the <literal>natd_flags=""</literal>
|
||||
option of <filename>/etc/rc.conf</filename>, or passed via a
|
||||
configuration file. With address redirection, there is no
|
||||
need for port redirection since all data received on a
|
||||
particular <acronym>IP</acronym> address is
|
||||
redirected.</para>
|
||||
|
||||
<para>The external <acronym>IP</acronym> addresses on the
|
||||
&man.natd.8; machine must be active and aliased to the
|
||||
external interface. Refer to &man.rc.conf.5; for
|
||||
details.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<para>The external <acronym>IP</acronym> addresses on the
|
||||
&man.natd.8; machine must be active and aliased to the
|
||||
external interface. Refer to &man.rc.conf.5; for
|
||||
details.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="firewalls-ipfw-cmd">
|
||||
<title>The <application>IPFW</application> Command</title>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue