Wording fixes and other minor nits to the 'Security' chapter.

Submitted by:	Niclas Zeising <lothrandil@n00b.apagnu.se>
PR:		docs/105256

en_US.ISO8859-1/books/handbook/security/chapter.sgml

@@ -559,7 +559,7 @@
       <title>Securing User Accounts</title>
 
       <para>User accounts are usually the most difficult to secure.  While
-	you can impose Draconian access restrictions on your staff and
+	you can impose draconian access restrictions on your staff and
 	<quote>star</quote> out their passwords, you may not be able to
 	do so with any general user accounts you might have.  If you do
 	have sufficient control, then you may win out and be able to secure
@@ -568,13 +568,13 @@
 	ssh and Kerberos for user accounts is
 	more problematic, due to the extra administration and technical
 	support required, but still a very good solution compared to a
-	crypted password file.</para>
+	encrypted password file.</para>
     </sect2>
 
     <sect2>
       <title>Securing the Password File</title>
 
-      <para>The only sure fire way is to <literal>*</literal> out as many
+      <para>The only sure fire way is to star out as many
 	passwords as you can and use ssh or
 	Kerberos for access to those accounts.  Even though the encrypted
 	password file (<filename>/etc/spwd.db</filename>) can only be read
@@ -631,7 +631,7 @@
 	<literal>schg</literal> flag for every system file and directory
 	under the sun.  Another possibility is to simply mount
 	<filename>/</filename> and <filename>/usr</filename> read-only.
-	It should be noted that being too Draconian in what you attempt to
+	It should be noted that being too draconian in what you attempt to
 	protect may prevent the all-important detection of an
 	intrusion.</para>
     </sect2>
@@ -650,12 +650,11 @@
 	The last layer of your security onion is perhaps the most
 	important &mdash; detection.  The rest of your security is pretty
 	much useless (or, worse, presents you with a false sense of
-	safety) if you cannot detect potential incursions.  Half the job
+	security) if you cannot detect potential intrusions.  Half the job
 	of the onion is to slow down the attacker, rather than stop him, in
-	order to give the detection side of the equation a chance to catch
-	him in the act.</para>
+	order to be able to catch him in the act.</para>
 
-      <para>The best way to detect an incursion is to look for modified,
+      <para>The best way to detect an intrusion is to look for modified,
 	missing, or unexpected files.  The best way to look for modified
 	files is from another (often centralized) limited-access system.
 	Writing your security scripts on the extra-secure limited-access
@@ -678,7 +677,7 @@
 	the audit-trail tracks that ssh
 	lays.</para>
 
-      <para>Once you give a limited-access box, at least read access to the
+      <para>Once you have given a limited-access box at least read access to the
 	client systems it is supposed to monitor, you must write scripts
 	to do the actual monitoring.  Given an NFS mount, you can write
 	scripts out of simple system utilities such as &man.find.1; and
@@ -707,7 +706,7 @@
       <para>A good security script will also check for changes to user and
 	staff members access configuration files:
 	<filename>.rhosts</filename>, <filename>.shosts</filename>,
-	<filename>.ssh/authorized_keys</filename> and so forth&hellip;
+	<filename>.ssh/authorized_keys</filename> and so forth,
 	files that might fall outside the purview of the
 	<literal>MD5</literal> check.</para>
 
@@ -718,24 +717,23 @@
 	<literal>nosuid</literal> options (see &man.mount.8;) are what you
 	want to look into.  You should probably scan them anyway, at least
 	once a week, since the object of this layer is to detect a break-in
-	whether or not the break-in is effective.</para>
+	attempt, whether or not the attempt succeeds.</para>
 
       <para>Process accounting (see &man.accton.8;) is a relatively
 	low-overhead feature of the operating system which might help
 	as a post-break-in evaluation mechanism.  It is especially
 	useful in tracking down how an intruder has actually broken into
-	a system, assuming the file is still intact after the break-in
-	occurs.</para>
+	a system, assuming the file is still intact after the break-in has
+	occured.</para>
 
       <para>Finally, security scripts should process the log files, and the
 	logs themselves should be generated in as secure a manner as
 	possible &mdash; remote syslog can be very useful.  An intruder
-	tries to cover his tracks, and log files are critical to the
+	will try to cover his tracks, and log files are critical to the
 	sysadmin trying to track down the time and method of the initial
 	break-in.  One way to keep a permanent record of the log files is
 	to run the system console to a serial port and collect the
-	information on a continuing basis through a secure machine
-	monitoring the consoles.</para>
+	information to a secure machine monitoring the consoles.</para>
     </sect2>
 
     <sect2>
@@ -759,7 +757,7 @@
 	is typically a packet attack.  While there is not much you can do
 	about modern spoofed packet attacks that saturate your network,
 	you can generally limit the damage by ensuring that the attacks
-	cannot take down your servers.</para>
+	cannot take down your servers by:</para>
 
       <orderedlist>
 	<listitem>
@@ -772,13 +770,14 @@
 	</listitem>
 
 	<listitem>
-	  <para>Kernel Route Cache.</para>
+	  <para>Overloading the Kernel Route Cache.</para>
 	</listitem>
       </orderedlist>
 
-      <para>A common DoS attack is against a forking server that attempts
-	to cause the server to eat processes, file descriptors, and memory,
-	until the machine dies.  <application>inetd</application>
+      <para>A common DoS attack scenario is attacking a forking server and
+	making it spawning so many child processes that the host system
+	eventually runs out of memory, file descriptors, etc. and then
+	grinds to a halt.  <application>inetd</application> 
 	(see &man.inetd.8;) has several
 	options to limit this sort of attack.  It should be noted that
 	while it is possible to prevent a machine from going down, it is
@@ -857,7 +856,7 @@
 	The attacker spoofs ping packets sent to your LAN's broadcast
 	address with the source IP address set to the actual machine they
 	wish to attack.  If your border routers are not configured to
-	stomp on ping's to broadcast addresses, your LAN winds up
+	stomp on ping packets to broadcast addresses, your LAN winds up
 	generating sufficient responses to the spoofed source address to
 	saturate the victim, especially when the attacker uses the same
 	trick on several dozen broadcast addresses over several dozen
@@ -868,7 +867,7 @@
 	attacker can saturate a server's incoming network and cause the
 	server to saturate its outgoing network with ICMP responses.  This
 	type of attack can also crash the server by running it out of
-	mbuf's, especially if the server cannot drain the ICMP responses
+	memory, especially if the server cannot drain the ICMP responses
 	it generates fast enough.
 	Use the <application>sysctl</application>
 	variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks.
@@ -927,7 +926,7 @@
 
       <para>There are a few issues with both Kerberos and
 	ssh that need to be addressed if
-	you intend to use them.  Kerberos V is an excellent
+	you intend to use them.  Kerberos 5 is an excellent
 	authentication protocol, but there are bugs in the kerberized
 	<application>telnet</application> and
 	<application>rlogin</application> applications that make them
@@ -936,7 +935,7 @@
 	<option>-x</option> option.  <application>ssh</application>
 	encrypts everything by default.</para>
 
-      <para>ssh works quite well in every
+      <para>Ssh works quite well in every
 	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
@@ -950,10 +949,10 @@
 
       <para>We recommend that you use ssh in
 	combination with Kerberos whenever possible for staff logins.
-	<application>ssh</application> can be compiled with Kerberos
+	<application>Ssh</application> can be compiled with Kerberos
 	support.  This reduces your reliance on potentially exposed
 	ssh keys while at the same time
-	protecting passwords via Kerberos.  ssh
+	protecting passwords via Kerberos.  Ssh
 	keys should only be used for automated tasks from secure machines
 	(something that Kerberos is unsuited to do).  We also recommend that
 	you either turn off key-forwarding in the