Attachment 72396 Details for Bug 105256 – file.diff

[patch] file.diff

file.diff (text/plain), 8.42 KB, created by Niclas Zeising on 2006-11-07 21:20:17 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Niclas Zeising

Created: 2006-11-07 21:20:17 UTC

Size: 8.42 KB

patch

obsolete

>--- doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml.orig	2006-11-07 18:30:54.000000000 +0100
>+++ doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml	2006-11-07 21:02:16.000000000 +0100
>@@ -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 succeds.</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

Actions: View | Diff

Attachments on bug 105256: 72396