1 files changed, 48 insertions, 57 deletions

diff --git a/zh_CN.GB2312/books/handbook/security/chapter.sgml b/zh_CN.GB2312/books/handbook/security/chapter.sgml
index cd29458074..5279cf8074 100644
--- a/zh_CN.GB2312/books/handbook/security/chapter.sgml
+++ b/zh_CN.GB2312/books/handbook/security/chapter.sgml
@@ -2,7 +2,7 @@
      The FreeBSD Documentation Project
      The FreeBSD Simplified Chinese Project
 
-     Original Revision: 1.303
+     Original Revision: 1.307
      $FreeBSD$
 -->
 
@@ -485,19 +485,19 @@
       <title>确保用户帐户的安全</title>
 
       <para>用户帐号的安全通常是最难保证的。虽然您可以为您的员工设置严苛的登录限制，
-	并用 <quote>星号</quote> 替换掉他们的口令，但您可能无法对普通的用户这么做。
-	如果有足够的决策权，那么在保证用户帐号安全的斗争中或许会处于优势，
-	但如果不是这样，您能做的只是警惕地监控这些帐号的异动。
-	让用户使用 ssh 或  Kerberos 可能会有更多的问题，
-	因为需要更多的管理和技术支持，尽管如此，与使用加密的口令文件相比，
+	并用 <quote>星号</quote> 替换掉他们的口令， 但您可能无法对普通的用户这么做。
+	如果有足够的决策权， 那么在保证用户帐号安全的斗争中或许会处于优势，
+	但如果不是这样， 您能做的只是警惕地监控这些帐号的异动。
+	让用户使用 ssh 或 Kerberos 可能会有更多的问题，
+	因为需要更多的管理和技术支持， 尽管如此， 与使用加密的口令文件相比，
 	这仍不失为一个好办法。</para>
     </sect2>
 
     <sect2>
       <title>确保口令文件的安全</title>
 
-      <para>尽可能使用 <literal>*</literal> 替换掉口令是保证口令文件安全唯一的解决方法，
-	如果能够用 ssh 或 Kerberos 的话。即使只有
+      <para>能够确保起作用的唯一一种方法， 是将口令文件中尽可能多的口令用星号代替，
+	并通过 ssh 或 Kerberos 来使用这些账号。 即使只有
 	<username>root</username> 用户能够读取加密过的口令文件 (<filename>/etc/spwd.db</filename>)，
 	入侵者仍然可能设法读到它的内容，
 	即使他暂时还无法写入这个文件。</para>
@@ -526,17 +526,18 @@
 	还有一个被称作模块加载器， &man.kldload.8; 的机制，也会包含潜在的危险。
 	尝试入侵企业网络的入侵者会尝试在正在运行的内核上安装他自己的
 	<devicename>bpf</devicename> 设备，或其他听包设备。为了防止这些问题，
-	需要抬高内核安全级，至少调整到1。可以通过对  <varname>kern.securelevel</varname>
-	执行 <command>sysctl</command> 来完成这个任务。一旦把安全级调整到1，
-	对于直接访问设备的写入操作将被拒绝，而特殊的 <command>chflags</command>
-	标记，如 <literal>schg</literal> ，将被强制执行。一定要在重要的启动执行文件、
+	需要抬高内核安全级， 至少调整到 1。 可以通过对  <varname>kern.securelevel</varname>
+	执行 <command>sysctl</command> 来完成这个任务。 一旦把安全级调整到1，
+	对于直接访问设备的写入操作将被拒绝， 而特殊的 <command>chflags</command>
+	标记， 如 <literal>schg</literal>， 也将强制执行。 一定要在重要的启动执行文件、
 	目录和脚本文件上设置 <literal>schg</literal> 标记 &mdash;
-	在安全级生效之前的所有文件。这可能做得有些过火，
-	并将导致在较高安全级上运行时升级系统变得困难。 此外，
-	运行于较高安全级上，而没有正确设置 <literal>schg</literal>
-	标记的系统仍然是存在弱点的。另一种方法是把
+	不要漏过在安全级生效之前将被运行的任何文件。 这可能做得有些过火，
+	并将导致在较高安全级上运行时升级系统变得困难。 您也可以略微做些妥协，
+	即以较高的安全级运行， 但并不将系统文件和目录配置为 <literal>schg</literal>。
+	另一种可行的方法是把
 	<filename>/</filename> 和 <filename>/usr</filename> 以只读方式挂接。
-	此外，请注意过于严苛的安全设置将使得入侵检测同样无法进行。</para>
+	请注意， 如果保护措施做的过分的严苛， 则可能导致入侵检测无法进行，
+	而这种检测是安全中十分重要的一环。</para>
     </sect2>
 
     <sect2 id="security-integrity">
@@ -546,14 +547,15 @@
 	<command>chflags</command> 来把 <literal>schg</literal> 标记
 	应用到 <filename>/</filename> 和
 	<filename>/usr</filename> 中的绝大多数文件上可能会起到反作用，
-	因为尽管它能够保护那些文件，但同样关掉了一个很好的监测机制。
-	层次化安全的最后一层可能是最重要的 &mdash; 检测。
-	安全的其他部分可能相对来讲意义并不那么大 (或者，更糟糕的事情是，
-	那些措施会给您安全的假象)， 假如您无法检测潜在的入侵事件。
-	层次化安全最重要的功能是减缓入侵者，
-	而不是彻底不让他们入侵，这能够让检测起到作用，并更好地捕捉入侵行为。</para>
-
-      <para>检测入侵的一种好办法是查找那些被修改、删除或添加的文件。
+	因为尽管它能够保护那些文件， 但同时也使入侵检测无法进行。
+	层次化安全的最后一层可能也是最重要的 &mdash; 检测。
+	如果无法检测出潜在的入侵行为，
+	那么安全的其他部分可能相对来讲意义可能就不那么大了 (或者，更糟糕的事情是，
+	那些措施会给您安全的假象)。
+	层次化安全最重要的功能是减缓入侵者， 而不是彻底不让他们入侵，
+	这样才可能当场抓住入侵者。</para>
+
+      <para>检测入侵的一种好办法是查找那些被修改、 删除或添加的文件。
 	检测文件修改的最佳方法是与某个 (通常是中央的) 受限访问的系统上的文件进行比对。
 	在一台严格限制访问的系统上撰写您的安全脚本通常不能够被入侵者察觉，
 	因此，这非常重要。为了最大限度地发挥这一策略的优势，通常会使用只读的 NFS，
@@ -583,7 +585,7 @@
 
       <para>安全脚本还应该检查用户以及职员成员的权限设置文件：
 	<filename>.rhosts</filename>、 <filename>.shosts</filename>、
-	<filename>.ssh/authorized_keys</filename> 等等。 &hellip;
+	<filename>.ssh/authorized_keys</filename> 等等。
 	这些文件可能并非通过
 	<literal>MD5</literal> 来进行检查。</para>
 
@@ -603,7 +605,7 @@
 	&mdash; 远程 syslog 可能非常有用。 入侵者会试图掩盖他们的踪迹，
 	而日志文件对于希望了解入侵发生时间的系统管理员来说则显得尤为重要。
 	保持日志文件的永久性记录的一种方法是在串口上运行系统控制台，
-	并持续不断地在一台安全的机器上收集这些信息。</para>
+	并在一台安全的机器上收集这些信息。</para>
     </sect2>
 
     <sect2>
@@ -624,11 +626,11 @@
 
       <para>这一节将介绍拒绝服务攻击。 DoS 攻击通常是基于数据包的攻击，
 	尽管几乎没有任何办法来阻止大量的伪造数据包耗尽网络资源，
-	但通常可以通过一些手段来限制这类攻击的损害，使它们无法击垮服务器。</para>
+	但通常可以通过一些手段来限制这类攻击的损害，使它们无法击垮服务器：</para>
 
       <orderedlist>
 	<listitem>
-	  <para>限制服务进程 fork.</para>
+	  <para>限制服务进程 fork。</para>
 	</listitem>
 
 	<listitem>
@@ -637,13 +639,13 @@
 	</listitem>
 
 	<listitem>
-	  <para>内核路由缓存</para>
+	  <para>使内核路由缓存过载。</para>
 	</listitem>
       </orderedlist>
 
-      <para>对于通过复制进程 (fork) 来进行服务的服务器的一种很常见的攻击是想办法耗尽其进程、
-	文件描述符或者内存， 直到机器彻底死掉。
-	<application>inetd</application>
+      <para>一种比较常见的 DoS 攻击情形， 是通过攻击复制进程 (fork)
+	的服务， 使其产生大量子进程， 从而是其运行的机器耗尽内存、 文件描述符等资源，
+	直到服务器彻底死掉。 <application>inetd</application> 
 	(参见 &man.inetd.8;) 提供了许多选项来限制这类攻击。
 	需要注意的是， 尽管能够阻止一台机器彻底垮掉，
 	但通常无法防止服务本身被击垮。
@@ -708,12 +710,12 @@
 	最常见的攻击就是 <emphasis>ICMP ping 广播攻击</emphasis>。
 	攻击者通过伪造 ping 包， 将其源 IP 设置为希望攻击的机器的 IP。
 	如果您的边界路由器没有进行禁止 ping 广播地址的设置， 则您的网络将最终陷于响应伪造的
-	ping 之中， 特别是当攻击者同时使用了多个不同的网络时。
+	ping 包之中， 特别是当攻击者同时使用了多个不同的网络时。
 	广播攻击能够产生超过 120 兆位的瞬时流量。
 	另一种常见的针对 ICMP 错误报告系统的 springboard 攻击，
 	通过建立可以生成 ICMP 出错响应的包， 攻击者能够攻击服务器的网络下行资源，
-	并导致其上行资源耗尽。 这种类型的攻击也可以通过耗尽 mbuf
-	来使得使得被攻击的服务器崩溃，特别是当这些服务器无法足够快地完成
+	并导致其上行资源耗尽。 这种类型的攻击也可以通过耗尽内存来使得使得被攻击的服务器崩溃，
+	特别是当这些服务器无法足够快地完成
 	ICMP 响应的时候。 较新的内核可以通过调整 <application>sysctl</application>
 	变量 <literal>net.inet.icmp.icmplim</literal> 来限制这种攻击。
 	最后一类主要的 springboard 是针对某些
@@ -760,7 +762,7 @@
       <indexterm><primary>KerberosIV</primary></indexterm>
 
       <para>如果您打算使用， 那么 Kerberos 和 ssh 都有一些需要解决的问题。
-	Kerberos V 是一个很棒的验证协议， 但使用了它的
+	Kerberos 5 是一个很棒的验证协议， 但使用了它的
 	<application>telnet</application> 和
 	<application>rlogin</application> 应用程序有一些 bug，
 	使得它们不适合处理二进制流。
@@ -769,7 +771,7 @@
 	 <application>ssh</application>
 	在默认时加密所有的会话内容。</para>
 
-      <para>除了默认转发加密密钥， ssh 在所有的其他方面都做得很好。
+      <para>除了默认转发加密密钥之外， ssh 在所有的其他方面都做得很好。
 	这意味着如果您持有供您访问系统其他部分密钥的工作站作了很好的安全防护，
 	而您连到了一台不安全的机器上， 则您的密钥可能被别人获得。
 	尽管实际的密钥并没有被泄漏， 但由于 ssh 会在您登录的过程中启用一个转发端口，
@@ -779,9 +781,9 @@
 
       <para>我们建议您在使用 ssh 时配合
 	Kerberos 来完成工作人员的登录过程。
-	<application>ssh</application> 在编译时可以加入 Kerberos 支持。
+	<application>Ssh</application> 在编译时可以加入 Kerberos 支持。
 	在减少了潜在地暴露 ssh 密钥的机会的同时， 它还能够通过 Kerberos 来保护口令。
-	ssh 密钥只有在做过安全防护的机器上执行自动操作时才应使用
+	Ssh 密钥只有在做过安全防护的机器上执行自动操作时才应使用
 	(这是 Kerberos 不适合的情形)。 此外，我们还建议您要么在
 	ssh 配置中关闭密钥转发， 要么在 <filename>authorized_keys</filename> 中增加
 	<literal>from=IP/DOMAIN</literal> 选项， 来限制这些密钥能够登录的来源机器。</para>
@@ -1500,7 +1502,7 @@ Edit O.K.
 	<command>ext_srvtab</command> 命令。 这将创建一个文件，
 	它需要被 <emphasis>通过安全的途径</emphasis> 复制或移动到每一个
 	Kerberos 客户端的
-	<filename>/etc/kerberosIV</filename> 目录中。
+	<filename>/etc</filename> 目录中。
 	在每一台服务器上都必须存在这个文件，
 	它对 Kerberos 的运行至关重要。</para>
 
@@ -1518,8 +1520,7 @@ Generating 'grunt-new-srvtab'....</screen>
 
       <screen>&prompt.root; <userinput>mv grunt-new-srvtab srvtab</userinput></screen>
 
-      <para>如果文件是针对客户系统的， 而且网络可能会不安全，
-	则应把
+      <para>如果文件是针对客户系统的， 而且网络可能会不安全， 则应把
 	<filename><replaceable>client</replaceable>-new-srvtab</filename> 复制到可移动的介质上，
 	并通过物理上安全的方式拿走。
 	将其改名为 <filename>srvtab</filename> 并放到客户机的
@@ -1982,10 +1983,10 @@ Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
 	<acronym>KDC</acronym> 确实在正常工作， 使用
 	<acronym>KDC</acronym> 本身的功能：</para>
 
-      <screen>&prompt.user; <userinput>k5init <replaceable>tillman</replaceable></userinput>
+      <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
 tillman@EXAMPLE.ORG's Password:
 
-&prompt.user; <userinput>k5list</userinput>
+&prompt.user; <userinput>klist</userinput>
 Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
 	Principal: tillman@EXAMPLE.ORG
 
@@ -2122,16 +2123,6 @@ kadmin><userinput> exit</userinput></screen>
 	  参数， 它将加密整个数据流 (类似
 	  <command>ssh</command>)。</para>
 
-	<para>核心的 <application>Kerberos</application> 客户端应用
-	  (按照传统命名， 包括了 <command>kinit</command>、
-	  <command>klist</command>、 <command>kdestroy</command>， 以及
-	  <command>kpasswd</command>) 已经随
-	  基本的 &os; 安装到了系统上。 请注意 5.0 之前的 &os; 版本将它们改名为
-	  <command>k5init</command>、
-	  <command>k5list</command>、 <command>k5destroy</command>、
-	  <command>k5passwd</command>， 以及 <command>k5stash</command>
-	  (尽管这些命令通常只会用到一次)。</para>
-
 	<para>许多非核心的 <application>Kerberos</application> 客户应用程序也是默认安装的。
 	  在 Hemidal 的 <quote>最小</quote> 安装理念下，
 	  <command>telnet</command> 是唯一一个采用了
@@ -3027,14 +3018,14 @@ options   IPSEC_DEBUG  #debug for IP security
       <para>在网络 #1 的网关机上可以通过下面的这些命令来配置隧道。</para>
  
       <screen>&prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> create</userinput>
-&prompt.root; <userinput>ifconfig tunnel <replaceable>gif0</replaceable> <replaceable>A.B.C.D</replaceable> <replaceable>W.X.Y.Z</replaceable></userinput>
+&prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> tunnel <replaceable>A.B.C.D</replaceable> <replaceable>W.X.Y.Z</replaceable></userinput>
 &prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> inet <replaceable>192.168.1.1</replaceable> <replaceable>192.168.2.1</replaceable> netmask <replaceable>0xffffffff</replaceable></userinput>
       </screen>
 
       <para>在另一台网关上也需要执行同样的命令， 但 IP 地址的顺序相反。</para>
 
       <screen>&prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> create</userinput>
-&prompt.root; <userinput>ifconfig tunnel <replaceable>gif0</replaceable> <replaceable>W.X.Y.Z</replaceable> <replaceable>A.B.C.D</replaceable></userinput>
+&prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> tunnel <replaceable>W.X.Y.Z</replaceable> <replaceable>A.B.C.D</replaceable></userinput>
 &prompt.root; <userinput>ifconfig <replaceable>gif0</replaceable> inet <replaceable>192.168.2.1</replaceable> <replaceable>192.168.1.1</replaceable> netmask <replaceable>0xffffffff</replaceable></userinput>
       </screen>