Attachment 23428 Details for Bug 40313 – chapter.sgml.diff

[patch] chapter.sgml.diff

chapter.sgml.diff (text/plain), 14.47 KB, created by Chris Pepper on 2002-07-07 21:20:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Chris Pepper

Created: 2002-07-07 21:20:01 UTC

Size: 14.47 KB

patch

obsolete

>Index: chapter.sgml
>===================================================================
>RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v
>retrieving revision 1.111
>diff -u -u -r1.111 chapter.sgml
>--- chapter.sgml	2002/06/18 09:58:50	1.111
>+++ chapter.sgml	2002/07/07 19:47:27
>@@ -919,8 +919,8 @@
> 	respect except that it forwards encryption keys by default.  What
> 	this means is that if you have a secure workstation holding keys
> 	that give you access to the rest of the system, and you
>-	ssh to an insecure machine, your keys
>-	becomes exposed.  The actual keys themselves are not exposed, but
>+	ssh to an insecure machine, your keys are usable by the
>+	insecure system.  The actual keys themselves are not exposed, but
> 	ssh installs a forwarding port for the
> 	duration of your login, and if an attacker has broken
> 	<username>root</username> on the
>@@ -1921,7 +1921,7 @@
>       
>       <para>There are currently two distinct types of firewalls in common use
> 	on the Internet today.  The first type is more properly called a
>-	<emphasis>packet filtering router</emphasis>, where the kernel on a
>+	<emphasis>packet filtering router</emphasis>, where a
> 	multi-homed machine chooses whether to forward or block packets based
> 	on a set of rules.  The second type, known as a <emphasis>proxy
> 	  server</emphasis>, relies on daemons to provide authentication and to
>@@ -1946,29 +1946,29 @@
> 	<title>Packet Filtering Routers</title>
> 
> 	<para>A router is a machine which forwards packets between two or more
>-	  networks.  A packet filtering router has an extra piece of code in
>-	  its kernel which compares each packet to a list of rules before
>+	  networks.  A packet filtering router has extra code to
>+	  compare each packet to a list of rules before
> 	  deciding if it should be forwarded or not.  Most modern IP routing
> 	  software has packet filtering code within it that defaults to
> 	  forwarding all packets.  To enable the filters, you need to define a
>-	  set of rules for the filtering code so it can decide if the
>+	  set of rules for the filtering code so it can decide if any given
> 	  packet should be allowed to pass or not.</para>
> 	    
>-	<para>To decide whether a packet should be passed on, the code looks
>+	<para>To decide whether a packet should be passed on, the firewall looks
> 	  through its set of rules for a rule which matches the contents of
>-	  this packets headers.  Once a match is found, the rule action is
>+	  the packet's headers.  Once a match is found, the rule action is
> 	  obeyed.  The rule action could be to drop the packet, to forward the
> 	  packet, or even to send an ICMP message back to the originator.
>-	  Only the first match counts, as the rules are searched in order.
>+	  Only the first match counts, and the rules are searched in order.
> 	  Hence, the list of rules can be referred to as a <quote>rule
> 	  chain</quote>.</para>
> 	    
>-	<para>The packet matching criteria varies depending on the software
>+	<para>The packet-matching criteria varies depending on the software
> 	  used, but typically you can specify rules which depend on the source
> 	  IP address of the packet, the destination IP address, the source
> 	  port number, the destination port number (for protocols which
> 	  support ports), or even the packet type (UDP, TCP, ICMP,
>-	  etc).</para>
>+	  etc.).</para>
>       </sect3>
> 	  
>       <sect3 id="firewalls-proxy-servers">
>@@ -1976,29 +1976,29 @@
> 	    
> 	<para>Proxy servers are machines which have had the normal system
> 	  daemons (<application>telnetd</application>, 
>-	  <application>ftpd</application>, etc) replaced with special servers.
>+	  <application>ftpd</application>, etc.) replaced with special servers.
> 	  These
>-	  servers are called <emphasis>proxy servers</emphasis> as they
>+	  servers are called <emphasis>proxy servers</emphasis>, as they
> 	  normally only allow onward connections to be made.  This enables you
>-	  to run (for example) a proxy telnet server on your firewall host,
>-	  and people can telnet in to your firewall from the outside, go
>+	  to run (for example) a proxy <application>telnet</application> server on your firewall host,
>+	  so people can <application>telnet</application> in to your firewall from the outside, go
> 	  through some authentication mechanism, and then gain access to the
> 	  internal network (alternatively, proxy servers can be used for
> 	  signals coming from the internal network and heading out).</para>
> 	    
> 	<para>Proxy servers are normally more secure than normal servers, and
> 	  often have a wider variety of authentication mechanisms available,
>-	  including <quote>one-shot</quote> password systems so that even if
>-	  someone manages to discover what password you used, they will not be
>-	  able to use it to gain access to your systems as the password
>-	  instantly expires.  As they do not actually give users access to the
>+	  including <quote>one-shot</quote> password systems, so that even if
>+	  someone manages to record a password being used, they will not be
>+	  able to use it, as the password
>+	  instantly expires on first use.  As they do not actually give users direct access to the
> 	  host machine, it becomes a lot more difficult for someone to install
> 	  backdoors around your security system.</para>
> 	    
> 	<para>Proxy servers often have ways of restricting access further, so
> 	  that only certain hosts can gain access to the servers, and often
>-	  they can be set up so that you can limit which users can talk to
>-	  which destination machine.  Again, what facilities are available
>+	  they can be set up to limit which users can talk to
>+	  which destination machines.  Again, what facilities are available
> 	  depends largely on what proxy software you choose.</para>
>       </sect3>
>     </sect2>
>@@ -2011,12 +2011,12 @@
> 	FreeBSD, is a packet filtering and accounting system which resides in
> 	the kernel, and has a user-land control utility,
> 	    &man.ipfw.8;.  Together, they allow you to define and query the
>-	rules currently used by the kernel in its routing decisions.</para>
>+	rules used by the kernel for its routing decisions.</para>
> 	  
>       <para>There are two related parts to IPFW.
>-	The firewall section allows you to perform packet filtering.  There is
>-	also an IP accounting section which allows you to track usage of your
>-	router, based on similar rules to the firewall section.  This allows
>+	The firewall section performs packet filtering.  There is
>+	also an IP accounting section which tracks usage of your
>+	router, based on similar rules.  This allows
> 	you to see (for example) how much traffic your router is getting from
> 	a certain machine, or how much WWW (World Wide Web) traffic it is
> 	forwarding.</para>
>@@ -2078,13 +2078,13 @@
> 	      firewall activity, but do not want to be open to a denial of
> 	      service attack via syslog flooding.</para>
> 
>-	    <para>When a chain entry reaches the packet limit specified,
>+	    <para>When a chain entry (rule) reaches the packet limit specified,
> 	      logging is turned off for that particular entry.  To resume
> 	      logging, you will need to reset the associated counter using the
> 		&man.ipfw.8; utility:</para>
> 	    
> 	    <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen>
>-	    <para>Where 4500 is the chain entry you wish to continue
>+	    <para>Where 4500 is the chain entry you wish to resume
> 	      logging.</para>
> 	  </listitem>
> 	</varlistentry>
>@@ -2200,9 +2200,9 @@
> 	    <term>allow</term>
> 	    
> 	    <listitem>
>-	      <para>Pass the packet on as normal.  (aliases:
>-		<literal>pass</literal> and
>-		<literal>accept</literal>)</para>
>+	      <para>Pass the packet on as normal (aliases:
>+		<literal>pass</literal>, <literal>permit</literal>, and
>+		<literal>accept</literal>).</para>
> 	    </listitem>
> 	  </varlistentry>
> 	  
>@@ -2212,7 +2212,7 @@
> 	    <listitem>
> 	      <para>Drop the packet.  The source is not notified via an
> 		ICMP message (thus it appears that the packet never
>-		arrived at the destination).</para>
>+		arrived at the destination).  Alias: <literal>drop</literal>.</para>
> 	    </listitem>
> 	  </varlistentry>
> 	  
>@@ -2362,11 +2362,11 @@
> 	    <listitem>
> 	      <para>Matches if the IP header contains the comma separated list
> 		of options specified in <replaceable>spec</replaceable>.  The
>-		supported list of IP options are: <literal>ssrr</literal>
>+		supported list of IP options is: <literal>ssrr</literal>
> 		(strict source route), <literal>lsrr</literal> (loose source
> 		route), <literal>rr</literal> (record packet route), and
> 		<literal>ts</literal> (time stamp).  The absence of a
>-		particular option may be denoted with a leading
>+		particular option may be specified with a leading
> 		<literal>!</literal>.</para>
> 	    </listitem>
> 	  </varlistentry>
>@@ -2434,10 +2434,10 @@
> 	    <arg>-a</arg>
> 	    <arg>-t</arg>
> 	    <arg>-N</arg>
>-	    <arg choice="plain">l</arg>
>+	    <arg choice="plain">list</arg>
> 	  </cmdsynopsis></para>
> 
>-	<para>There are three valid flags when using this form of the
>+	<para>The list command may be abbreviated. There are three valid flags when using this form of the
> 	  command:</para>
> 	    
> 	<variablelist>
>@@ -2482,7 +2482,7 @@
> 
> 	<para>This causes all entries in the firewall chain to be removed
> 	  except the fixed default policy enforced by the kernel (index
>-	  65535).  Use caution when flushing rules, the default deny policy
>+	  65535).  Use caution when flushing rules; the default deny policy
> 	  will leave your system cut off from the network until allow entries
> 	  are added to the chain.</para>
>       </sect3>
>@@ -2499,7 +2499,7 @@
> 
> 	<para>When used without an <replaceable>index</replaceable> argument,
> 	  all packet counters are cleared.  If an
>-	  <replaceable>index</replaceable> is supplied, the clearing operation
>+	  <replaceable>index</replaceable> is supplied, the clear operation
> 	  only affects a specific chain entry.</para>
>       </sect3>
>     </sect2>
>@@ -2546,25 +2546,25 @@
>       
>       <note>
> 	<para>The following suggestions are just that: suggestions.  The
>-	  requirements of each firewall are different and we cannot tell you
>+	  requirements for each firewall are different and we cannot tell you
> 	  how to build a firewall to meet your particular requirements.</para>
>       </note>
> 	  
>       <para>When initially setting up your firewall, unless you have a test
> 	bench setup where you can configure your firewall host in a controlled
>-	environment, it is strongly recommend you use the logging version of the
>+	environment, it is strongly recommend you use the logging versions of the
> 	commands and enable logging in the kernel.  This will allow you to
> 	quickly identify problem areas and cure them without too much
> 	disruption.  Even after the initial setup phase is complete, I
>-	recommend using the logging for `deny' as it allows tracing of
>+	recommend using the logging for `deny' rule, as it allows tracing of
> 	possible attacks and also modification of the firewall rules if your
>-	requirements alter.</para>
>+	requirements change.</para>
> 	  
>       <note>
> 	<para>If you use the logging versions of the <command>accept</command>
> 	  command, it can generate <emphasis>large</emphasis> amounts of log
>-	  data as one log line will be generated for every packet that passes
>-	  through the firewall, so large FTP/http transfers, etc, will really
>+	  data, as one log line will be generated for every packet that passes
>+	  through the firewall; this means large FTP/http transfers, etc., will really
> 	  slow the system down.  It also increases the latencies on those
> 	  packets as it requires more work to be done by the kernel before the
> 	  packet can be passed on.  <application>syslogd</application> will 
>@@ -2576,7 +2576,7 @@
> 	  
>       <para>You should enable your firewall from
> 	<filename>/etc/rc.conf.local</filename> or
>-	<filename>/etc/rc.conf</filename>.  The associated manual page explains
>+	<filename>/etc/rc.conf</filename>.  The <filename>/etc/rc.conf</filename> manual page explains
> 	which knobs to fiddle and lists some preset firewall configurations.
> 	If you do not use a preset configuration, <command>ipfw list</command>
> 	will output the current ruleset into a file that you can
>@@ -2590,7 +2590,7 @@
> 	<emphasis>do</emphasis>! This is largely dependent on what access to
> 	your network you want to allow from the outside, and how much access
> 	to the outside world you want to allow from the inside. Some general
>-	rules are:</para>
>+	rules to start with are:</para>
>       
>       <itemizedlist>
> 	<listitem>
>@@ -2603,7 +2603,7 @@
> 	  <para>Block <emphasis>all</emphasis> incoming UDP traffic.  There
> 	    are very few useful services that travel over UDP, and what useful
> 	    traffic there is, is normally a security threat (e.g. Suns RPC and
>-	    NFS protocols).  This has its disadvantages also, since UDP is a
>+	    NFS protocols).  This has its disadvantages also; since UDP is a
> 	    connectionless protocol, denying incoming UDP traffic also blocks
> 	    the replies to outgoing UDP traffic.  This can cause a problem for
> 	    people (on the inside) using external archie (prospero) servers.
>@@ -2626,7 +2626,7 @@
> 	      
> 	<listitem>
> 	  <para>Check what ports any internal servers use (e.g. SQL servers,
>-	    etc).  It is probably a good idea to block those as well, as they
>+	    etc.).  It is probably a good idea to block those as well, as they
> 	    normally fall outside the 1-1024 range specified above.</para>
> 	</listitem>
>       </itemizedlist>
>@@ -2659,13 +2659,13 @@
> 	<literal>ip_fw_chk</literal> routine, displaying the results
> 	to the console every 1000 packets.</para>
> 
>-      <para>Two rule sets, each with 1000 rules were tested.  The
>+      <para>Two rule sets, each with 1000 rules, were tested.  The
> 	first set was designed to demonstrate a worst case scenario by
> 	repeating the rule:</para>
> 
>       <screen>&prompt.root; <userinput>ipfw add deny tcp from any to any 55555</userinput></screen>
> 
>-      <para>This demonstrates worst case by causing most of IPFW's
>+      <para>This demonstrates a worst case by causing most of IPFW's
> 	packet check routine to be executed before finally deciding
> 	that the packet does not match the rule (by virtue of the port
> 	number). Following the 999th iteration of this rule was an
>@@ -2686,7 +2686,7 @@
> 	rule. Thus the theoretical packet processing limit with these
> 	rules is around 370 packets per second. Assuming 10Mbps
> 	Ethernet and a ~1500 byte packet size, we would only be able
>-	to achieve a 55.5% bandwidth utilization.</para>
>+	to achieve 55.5% bandwidth utilization.</para>
> 
>       <para>For the latter case each packet was processed in
> 	approximately 1.172ms, or roughly 1.2 microseconds per rule.

Actions: View | Diff

Attachments on bug 40313: 23428