svn commit: r44039 - head/en_US.ISO8859-1/books/handbook/firewalls

Dru Lavigne dru at FreeBSD.org
Mon Feb 24 04:16:59 UTC 2014


Author: dru
Date: Mon Feb 24 04:16:59 2014
New Revision: 44039
URL: http://svnweb.freebsd.org/changeset/doc/44039

Log:
  White space fix only. Translators can ignore.
  
  Sponsored by: iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Sun Feb 23 20:18:56 2014	(r44038)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Mon Feb 24 04:16:59 2014	(r44039)
@@ -179,11 +179,11 @@
 	xlink:href="http://www.sans.org/security-resources/idfaq/oddports.php">http://www.sans.org/security-resources/idfaq/oddports.php</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>
+      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>A firewall ruleset can be either
       <quote>exclusive</quote> or <quote>inclusive</quote>.  An
@@ -234,38 +234,37 @@
       flood of different attack methods employed by attackers.</para>
 
     <para><acronym>NAT</acronym> stands for <emphasis>Network
-	  Address Translation</emphasis>.
-	<acronym>NAT</acronym> function enables the private LAN behind
-	the firewall to share a single ISP-assigned IP address, even
-	if that address is dynamically assigned.  NAT allows each
-	computer in the LAN to have Internet access, without
-	having to pay the ISP for multiple Internet accounts or IP
-	addresses.</para>
-
-      <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
-	translation for returning packets.</para>
-
-      <para>According to RFC 1918, the following IP address ranges are
-	reserved for private networks which will never be routed
-	directly to the public Internet, and therefore are available
-	for use with NAT:</para>
-
-      <itemizedlist>
-	<listitem>
-	  <para><literal>10.0.0.0/8</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>172.16.0.0/12</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>192.168.0.0/16</literal>.</para>
-	</listitem>
-      </itemizedlist>
+	Address Translation</emphasis>.  <acronym>NAT</acronym>
+      function enables the private LAN behind the firewall to share a
+      single ISP-assigned IP address, even if that address is
+      dynamically assigned.  NAT allows each computer in the LAN to
+      have Internet access, without having to pay the ISP for multiple
+      Internet accounts or IP addresses.</para>
+
+    <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 translation
+      for returning packets.</para>
+
+    <para>According to RFC 1918, the following IP address ranges are
+      reserved for private networks which will never be routed
+      directly to the public Internet, and therefore are available
+      for use with NAT:</para>
+
+    <itemizedlist>
+      <listitem>
+	<para><literal>10.0.0.0/8</literal>.</para>
+      </listitem>
+
+      <listitem>
+	<para><literal>172.16.0.0/12</literal>.</para>
+      </listitem>
+
+      <listitem>
+	<para><literal>192.168.0.0/16</literal>.</para>
+      </listitem>
+    </itemizedlist>
 
     <warning>
       <para>When working with the firewall rules, be <emphasis>very
@@ -2228,145 +2227,146 @@ ipnat_rules="/etc/ipnat.rules"</programl
 
       <para><acronym>NAT</acronym> rules are flexible and can
 	accomplish many different things to fit the needs of both
-	commercial and home users.  The rule syntax presented here has been simplified to
-	demonstrate common usage.
-	For a complete rule syntax description, refer to
-	&man.ipnat.5;.</para>
+	commercial and home users.  The rule syntax presented here has
+	been simplified to demonstrate common usage.  For a complete
+	rule syntax description, refer to &man.ipnat.5;.</para>
 
       <para>The basic syntax for a <acronym>NAT</acronym> rule is as
-	follows, where <literal>map</literal> starts the rule and 
+	follows, where <literal>map</literal> starts the rule and
 	<replaceable>IF</replaceable> should be replaced with the
-	name of the external
-	interface:</para>
+	name of the external interface:</para>
 
       <programlisting>map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -> <replaceable>PUBLIC_ADDRESS</replaceable></programlisting>
 
       <para>The <replaceable>LAN_IP_RANGE</replaceable> is the range
-	of <acronym>IP</acronym> addresses used by
-	internal clients.  Usually, it is a private address range
-	such as <systemitem
-	  class="ipaddress">192.168.1.0/24</systemitem>.  The <replaceable>PUBLIC_ADDRESS</replaceable> can either
-	be the static external <acronym>IP</acronym> address or the keyword
-	<literal>0/32</literal> which represents the <acronym>IP</acronym> address assigned to
+	of <acronym>IP</acronym> addresses used by internal clients.
+	Usually, it is a private address range such as <systemitem
+	  class="ipaddress">192.168.1.0/24</systemitem>.  The
+	<replaceable>PUBLIC_ADDRESS</replaceable> can either be the
+	static external <acronym>IP</acronym> address or the keyword
+	<literal>0/32</literal> which represents the
+	<acronym>IP</acronym> address assigned to
 	<replaceable>IF</replaceable>.</para>
 
       <para>In <application>IPF</application>, when a packet arrives
-	at the firewall from the <acronym>LAN</acronym>
-	with a public destination, it first passes through the outbound
-	rules of the firewall ruleset.  Then, the packet is passed to the <acronym>NAT</acronym> ruleset
-	which is read from the top down, where the first
-	matching rule wins.  <application>IPF</application> tests each
-	<acronym>NAT</acronym> rule against the packet's interface name and source <acronym>IP</acronym>
-	address.  When a packet's interface name matches a
-	<acronym>NAT</acronym> rule, the packet's source <acronym>IP</acronym> address in
-	the private <acronym>LAN</acronym> is checked to see if it falls within the <acronym>IP</acronym>
-	address range specified in <replaceable>LAN_IP_RANGE</replaceable>.
-	On a match, the packet has its
-	source <acronym>IP</acronym> address rewritten with the public <acronym>IP</acronym> address
-	specified by <replaceable>PUBLIC_ADDRESS</replaceable>.
+	at the firewall from the <acronym>LAN</acronym> with a public
+	destination, it first passes through the outbound rules of the
+	firewall ruleset.  Then, the packet is passed to the
+	<acronym>NAT</acronym> ruleset which is read from the top
+	down, where the first matching rule wins.
+	<application>IPF</application> tests each
+	<acronym>NAT</acronym> rule against the packet's interface
+	name and source <acronym>IP</acronym> address.  When a
+	packet's interface name matches a <acronym>NAT</acronym> rule,
+	the packet's source <acronym>IP</acronym> address in the
+	private <acronym>LAN</acronym> is checked to see if it falls
+	within the <acronym>IP</acronym> address range specified in
+	<replaceable>LAN_IP_RANGE</replaceable>.  On a match, the
+	packet has its source <acronym>IP</acronym> address rewritten
+	with the public <acronym>IP</acronym> address specified by
+	<replaceable>PUBLIC_ADDRESS</replaceable>.
 	<application>IPF</application> posts an entry in its internal
-	<acronym>NAT</acronym> table so that when the packet returns from
-	the Internet, it can be mapped back to its original
-	private <acronym>IP</acronym> address before being passed to the firewall rules for
-	further processing.</para>
-
-	<para>For networks that have large numbers of internal systems
-	  or multiple subnets, the process of
-	  funneling every private <acronym>IP</acronym> address into a single
-	  public <acronym>IP</acronym> address becomes a resource problem.  Two methods
-	  are available to relieve this issue.</para>
-
-	<para>The first method is to assign a range of ports to use
-	  as source ports.  By
-	  adding the <literal>portmap</literal> keyword,
-	  <acronym>NAT</acronym> can be directed to only use
-	  source ports in the specified range:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000</programlisting>
-
-	<para>Alternately, use the <literal>auto</literal> keyword which tells
-	  <acronym>NAT</acronym> to determine the ports that are
-	  available for use:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto</programlisting>
-
-	<para>The second method is to use a pool of public addresses.
-	  This is useful when there are
-	  too many <acronym>LAN</acronym> addresses to fit into a single public
-	  address and a block of public <acronym>IP</acronym> addresses is available.
-	  These public addresses can be used as a pool from which
-	  <acronym>NAT</acronym> selects an <acronym>IP</acronym> address
-	  as a packet's address is mapped on its way
-	  out.</para>
-
-	<para>The range of public <acronym>IP</acronym> addresses can
-	  be specified
-	  using a netmask or <acronym>CIDR</acronym> notation.  These
-	  two rules are equivalent:</para>
+	<acronym>NAT</acronym> table so that when the packet returns
+	from the Internet, it can be mapped back to its original
+	private <acronym>IP</acronym> address before being passed to
+	the firewall rules for further processing.</para>
+
+      <para>For networks that have large numbers of internal systems
+	or multiple subnets, the process of funneling every private
+	<acronym>IP</acronym> address into a single public
+	<acronym>IP</acronym> address becomes a resource problem.
+	Two methods are available to relieve this issue.</para>
+
+      <para>The first method is to assign a range of ports to use as
+	source ports.  By adding the <literal>portmap</literal>
+	keyword, <acronym>NAT</acronym> can be directed to only use
+	source ports in the specified range:</para>
+
+      <programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000</programlisting>
+
+      <para>Alternately, use the <literal>auto</literal> keyword
+	which tells <acronym>NAT</acronym> to determine the ports
+	that are available for use:</para>
+
+      <programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto</programlisting>
+
+      <para>The second method is to use a pool of public addresses.
+	This is useful when there are too many
+	<acronym>LAN</acronym> addresses to fit into a single public
+	address and a block of public <acronym>IP</acronym> addresses
+	is available.  These public addresses can be used as a pool
+	from which <acronym>NAT</acronym> selects an
+	<acronym>IP</acronym> address as a packet's address is
+	mapped on its way out.</para>
+
+      <para>The range of public <acronym>IP</acronym> addresses can
+	be specified using a netmask or <acronym>CIDR</acronym>
+	notation.  These two rules are equivalent:</para>
 
-	<programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0
+      <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0
 map dc0 192.168.1.0/24 -> 204.134.75.0/24</programlisting>
 
-	<para>A common practice is to have a publically accessible web server or mail server
-	  segregated to an internal
-	  network segment.  The traffic from
-	  these servers still has to undergo <acronym>NAT</acronym>,
-	  but port redirection is needed to direct inbound traffic
-	  to the correct server.  For example, to map a web server using
-	  the internal address <systemitem
-	    class="ipaddress">10.0.10.25</systemitem> to its
-	  public <acronym>IP</acronym> address of <systemitem
-	    class="ipaddress">20.20.20.5</systemitem>, use this
-	  rule:</para>
+      <para>A common practice is to have a publically accessible web
+	server or mail server segregated to an internal network
+	segment.  The traffic from these servers still has to undergo
+	<acronym>NAT</acronym>, but port redirection is needed to
+	direct inbound traffic to the correct server.  For example, to
+	map a web server using the internal address <systemitem
+	  class="ipaddress">10.0.10.25</systemitem> to its public
+	<acronym>IP</acronym> address of <systemitem
+	  class="ipaddress">20.20.20.5</systemitem>, use this
+	rule:</para>
+
+      <programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting>
+
+      <para>If it is the only web server, this rule would also work as
+	it redirects all external <acronym>HTTP</acronym> requests to
+	<literal>10.0.10.25</literal>:</para>
+
+      <programlisting>rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80</programlisting>
+
+      <para><application>IPF</application> has a built in
+	<acronym>FTP</acronym> proxy which can be used with
+	<acronym>NAT</acronym>.  It monitors all outbound traffic for
+	active or passive <acronym>FTP</acronym> connection requests
+	and dynamically creates temporary filter rules containing the
+	port number used by the <acronym>FTP</acronym> data channel.
+	This eliminates the need to open large ranges of high order
+	ports for <acronym>FTP</acronym> connections.</para>
+
+      <para>This rule will handle all the traffic for the internal
+	LAN:</para>
+
+      <programlisting>map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp</programlisting>
+
+      <para>This rule handles the <acronym>FTP</acronym> traffic from
+	the gateway:</para>
+
+      <programlisting>map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp</programlisting>
+
+      <para>This rule handles all non-<acronym>FTP</acronym> traffic
+	from the internal LAN:</para>
+
+      <programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting>
+
+      <para>The <acronym>FTP</acronym> <literal>map</literal> rules go
+	before the <acronym>NAT</acronym> rule so that when a packet
+	matches an <acronym>FTP</acronym> rule, the
+	<acronym>FTP</acronym> proxy creates temporary filter rules to
+	let the <acronym>FTP</acronym> session packets pass and
+	undergo <acronym>NAT</acronym>.  All LAN packets that are not
+	<acronym>FTP</acronym> will not match the
+	<acronym>FTP</acronym> rules but will undergo
+	<acronym>NAT</acronym> if they match the third rule.</para>
+
+      <para>Only one filter rule is needed for <acronym>FTP</acronym>
+	if the <acronym>NAT</acronym> <acronym>FTP</acronym> proxy is
+	used.</para>
 
-	<programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting>
-
-	<para>If it is the only web server, this rule would also work
-	  as it redirects all external <acronym>HTTP</acronym>
-	  requests to <literal>10.0.10.25</literal>:</para>
-
-	<programlisting>rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80</programlisting>
-
-	<para><application>IPF</application> has a built in
-	  <acronym>FTP</acronym> proxy
-	  which can be used with <acronym>NAT</acronym>.
-	  It monitors all outbound traffic for active or passive <acronym>FTP</acronym>
-	  connection requests and dynamically
-	  creates temporary filter rules containing the port number
-	  used by the <acronym>FTP</acronym> data channel.  This eliminates the
-	  need to open large ranges of high order ports for
-	  <acronym>FTP</acronym> connections.</para>
-
-	<para>This rule will handle all the traffic for the internal
-	  LAN:</para>
-
-	<programlisting>map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp</programlisting>
-
-	<para>This rule handles the <acronym>FTP</acronym> traffic from the
-	  gateway:</para>
-
-	<programlisting>map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp</programlisting>
-
-	<para>This rule handles all non-<acronym>FTP</acronym> traffic from the internal
-	  LAN:</para>
-
-	<programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting>
-
-	<para>The <acronym>FTP</acronym> <literal>map</literal> rules go before the
-	  <acronym>NAT</acronym> rule so that when a packet matches an
-	  <acronym>FTP</acronym> rule, the <acronym>FTP</acronym> proxy creates temporary filter rules to
-	  let the <acronym>FTP</acronym> session packets pass and undergo
-	  <acronym>NAT</acronym>.  All LAN packets that are not <acronym>FTP</acronym>
-	  will not match the <acronym>FTP</acronym> rules but will undergo
-	  <acronym>NAT</acronym> if they match the third rule.</para>
-
-	<para>Only one filter rule is needed for <acronym>FTP</acronym> if the
-	  <acronym>NAT</acronym> <acronym>FTP</acronym> proxy is used.</para>
-
-	<para>Without the <acronym>FTP</acronym> proxy, the following three rules will be
-	  needed:</para>
+      <para>Without the <acronym>FTP</acronym> proxy, the following
+	three rules will be needed:</para>
 
-	<programlisting># Allow out LAN PC client FTP to public Internet
+      <programlisting># Allow out LAN PC client FTP to public Internet
 # Active and passive modes
 pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
 


More information about the svn-doc-all mailing list