1.1 站点安全手册
地 位
这份备忘录为internet网络提供信息服务。它没有规定任何性质的internet标准，发行本备忘不受到任何限制。
摘 要
这本手册是对位于internet上的站点的处于发展中的计算机安全政策和措施的指南。本手册的目的是对想要努力保障信息和服务安全的管理员提供实用的指导。覆盖的主题包括政策的内容和构成，许多系统和网络安全技术主题，和安全事件响应。
目 录
1. 介绍
1.1 这项工作的目的
1.2 读者
1.3 定义
1.4 相关工作
1.5 基本方法
1.6 风险评估
2. 安全政策
2.1 安全政策是什么，我们为什么需要它?
2.2 怎样产生一个好的安全政策？
2.3 保持政策的灵活性
3. 体系结构
3.1 目标
3.2 网络和服务的配置
3.3 防火墙
4. 安全服务和程序
4.1 认证
4.2 保密性
4.3 完整性
4.4 授权
4.5 访问
4.6 审核
4.7 安全备份
5. 安全事件处理
5.1 事件处理的准备和计划
5.2 通知和联系人
5.3 识别一个事件
5.4 事件处理
5.5 事故的后果
5.6 责任
6. 正在进行的活动
7. 工具和存放地点
8. 邮件列表和其他资源
9. 参考资料
1.简介
本文档向系统和网络管理员提供怎样在internet社区从事安全发布的指导。它是在RFC1244的基础上由许多作者集体完成的。这些作者包括：
Jules P. Aronson(aronson@nlm.nih.gov)，
Nevil Brownlee(n.brownlee@auckland.ac.nz)，
Frank Byrum(byrum@norfolk.infi.net)，
Joao Nuno Ferreira(ferreira@rccn.net)，
Barbara Fraser(byf@cert.org)，
Steve Glass(glass@ftp.com)，
Erik Guttman(erik.guttman@eng.sun.com)，
Tom Killalea(tomk@nwnet.net)，
KlausPeter Kossakowski(kossakowski@cert.dfn.de)，
Lorna Leone(lorna@staff.singnet.com.sg)，
Edward.P.Lewis(Edward.P.Lewis.1@gsfc.nasa.gov)，
Gary Malkin(gmalkin@xylogics.com)，
Russ Mundy(mundy@tis.com)，
Philip J. Nesser(pjnesser@martigny.ai.mit.edu)，
Michael S. Ramsey(msr@interpath.net)。
在这些理论作者之外，许多的校对者还提供了十分有价值的见解。这些校对人员包括：Eric Luiijf(luiijf@fel.tno.nl)、Marijke Kaat(marijke.kaat@sec.nl)、Ray Plzak(plzak@nic.mil)和Han Pronk(h.m.pronk@vka.nl)。
还要特别感谢Joyce Reynolds、ISI、Paul Holbrook和CICnet在本手册第一版中表现出来的眼界、领导能力和努力精神。我们的工作小组真诚的希望本文可以像以前的版本那样对大家有所帮助。
1.1 这项工作的目的
这本手册是对位于internet上的站点进行安全设置的政策和措施的指南（当然，有些内容对那些没有联上internet的站点也会有帮助）。本指南列出了一个站点设置它的策略的时候必须考虑的问题和因素，并给出了大量的建议和提供了对相关领域的讨论。
这本手册仅仅是设置安全政策和措施的基本框架。为了让他们起作用，一个站点还必须作出许多决定并达成一致，然后通过交流贯彻这些政策。
1.2 读者
本文的读者应该是系统和网络的管理员，以及站点的决策者（比如“中级管理人员”），方便起见，在我们的整个文档中将用“管理员”来指代系统和网络管理员。
这篇文档并不针对于那些想创建安全可靠的程序和系统的程序员。本文的主题是政策和措施，用它们来支持站点中可能采用的特定安全技术。
属于internet社区成员的站点是本文的主要读者。另一方面，本文档会对任何允许和其他网站交流的站点有帮助。作为通用的安全政策指南，它也对独立系统上的站点有些作用。
1.3 定义
考虑到本文的目的，“站点”定义为任何拥有计算机或者网络相关资源的机构。这些资源可以包括多用户使用的计算机主机、路由器、终端服务器、个人电脑和其他可以访问internet的设备。站点可以是一个internet服务的终端用户或者是一个服务的提供者，比如中级网络。不过，大部分的焦点将集中在internet服务终端用户上。我们将假定通过站点资源拥有者的合作和支持，这些站点可以设置自己的政策和措施。我们还将假设，那些隶属于更大的机构的站点知道什么时候他们需要考虑、配合和听取大公司的建议。
“internet”是由成千上万的网络通过共同的一套协议组成的，这些协议使得网络上的任何用户都可以互相通讯，或者使用其他网络上的服务（参考RFC1594）。
“管理员”的概念包括了所有负责那些不间断工作的系统或网络资源的人，他们可能是一些个人用户，也可能是一个机构。
“安全管理员”的概念则包括所有负责信息和信息技术的安全的人。一些站点把他们合并到一般管理员（见上文）的工作中，其他的则给予他们独立的地位。
“决策者”指的是建立或批准一个站点的政策的人。这常常是（但不总是）资源的拥有者。
1.4 相关工作
站点安全手册工作小组正在编写一本《internet安全用户指南》。它将对终端用户提供经验丰富的指导，帮助他们保护他们的信息和使用的网络资源。
1.5 基本方法
这篇指南提供的是为你的站点开展安全计划的基本指导。一个通常被大家公认的方法是遵循[Fites 1989]等的建议，它包括以下的步骤：
(1) 确认你想保护什么
(2) 思考你想防止它被怎么样
(3) 思考这种威胁发生的可能性有多大
(4) 实施最经济有效的保护你个人财产的措施。
(5) 不断重复上面过程，每次都可以发现一个漏洞
本文主要涉及的将是上面的前4条，但是如果想在你的网站上建立一个有效的安全计划最后一步决不能忽略。在安全领域内有一个古老的真理，那就是防止威胁发生的花销一定要小于它已经发生了以后，再进行补救的花销。要记住这里的“花销”还包括失去的流通的及时性、名誉、信任和其他并不明显的方面。没有正确的了解你要保护什么和威胁发生的可能性有多大，执行本文中提到的法则是很困难的。
1.6 风险评估
1.6.1 概述（General Discussion）
建立计算机安全政策的一个最重要的原因是确保我们在保障安全上付出的努力得到应有的收益。尽管这看上去是显而易见的，但是哪里需要花力气却有可能搞错。举个例子来说，有许多事例是关于电脑系统入侵者的，但是大部分的电脑安全调查显示在多数机构中，“内部人员”所带来的实际损失要更大的多。
风险分析包括决定你想保护什么，需要防止它被怎么样和怎么保护它。这就是调查风险的过程，随后把它们按照安全的级别排序。这个过程包括做出经济有效的决定“到底你想保护什么”，就像上面提到的那样，你也许不应该付出多于它本身的价值来保护一样东西。
对风险分析的完整处理已经超出了本文的范畴，[Fites 1989]和[Pfleeger 1989]对这个问题提供了介绍，在下面的两节中我们仍会简要的说明风险分析的两个因素：
(1) 确定资产
(2) 确定威胁
对每份资产，安全最基本的目标就是有效性、机密性和完整性。每种威胁都要被仔细检验它可能怎样影响这些领域。
1.6.2 确定资产
在风险分析中的第一步是确定所有需要保护的东西。有些是很明显的，比如有价值的私人信息、知识产权和各种各样的硬件设备。而有些则常被忽略，比如真正使用系统的人。这里的要点就是列出所有可能被安全问题影响的东西。
[Pfleeger 1989]建议使用一个种类的列表，下面这个列表是由他的原始资料修改而成的：
(1) 硬件：CPU、主板、键盘、终端、工作站、个人电脑、打印机、磁盘、通讯线路、终端服务器、路由器。
(2) 软件：源代码、目标代码、应用程序、诊断程序、操作系统、通讯系统。
(3) 数据：使用中、在线存贮、离线存档、备份、督察日志、数据库、在通讯媒体中传输的。
(4) 人：用户、管理员、硬件维护人员。
(5) 文件：在程序、硬件、系统、本地管理手续中的。
(6) 物资：纸张、表格、色带、磁性媒体。
1.6.3 确定威胁
一旦需要保护的资产已经确定，现在需要确定的就是对于这些资产的威胁。检查这些威胁能确定存在着什么潜在危险，这样可以帮助你考虑想要防止你的资产被什么所威胁。下面是一些应该考虑的经典的威胁，依据你的站点不同，将会有更多特别的应该确认和对待的威胁。
(1) 对资源和（或）信息的未授权的使用
(2) 无意的和（或）未授权的信息泄漏
(3) 拒绝服务攻击
2. 安全政策
在这整篇文章中，有许多参考原则，这些参考中常包括对一些特别的政策的推荐。与其反复的指导怎样建立并传达这样一个政策，不如请读者们在实践本文后面提到的任何政策的时候都使用一下本章的建议。
2.1 安全政策是什么，我们为什么需要它?
你常常会做出或没能做出那些安全相关的决定，就像管理员主要要确定的是你的网络是多么的安全或者不安全，它的功能有多少，它用起来有多容易。然而，不先确定你的安全目标是什么，你就不能做出好的安全决定来。直到你确定你的安全目标是什么之前，你不可能有效的使用任何收集的安全工具，就因为你不知道检查什么和施加什么约束。
比如，你的目标或许和产品卖主的目标很不相同。卖主想的是使他们的产品配置和使用起来尽可能的简单，这就意味着默认的配置常常会尽可能的公开（也就是不安全）。在安装新的产品的确变得更容易了的同时，它留下的是使用这些系统和经过他们使用其他系统的权利向所有路过的用户敞开着。
你的目标可以主要通过以下几个重要的权衡而确定
(1) 提供服务和保证安全——
每个提供给用户的服务都会带来安全上的风险。对于有的风险高过受益的服务，管理员可能宁愿选择取消它而不去再试图保护。
(2) 易用性和安全性——
使用起来最简单的系统是允许任意用户不用密码就可以访问的系统，也就意味着没有任何安全性。要求密码使得系统有了一点点不方便，但是却更安全了。需要设备产生的一次性密码使得系统更难用了，但是又更加安全的多。
(3) 保障安全的开销和发生损失的风险——
保障安全的开销有许多种：金钱（购买像防火墙和一次性密码生产器这样的安全设备和软件的花销）、性能（加密和解密要花费时间）和易用性（就像上面提到的）。损失的风险也有许多级别：泄密（信息被未授权的个人所阅读）、数据丢失（信息错误或消除）和服务损失（填充数据存储空间，占用运算资源和拒绝网络服务）。每种开销都要和每种损失作权衡。
你的目标应该让所有的用户、操作人员和管理者通过一套安全规则进行交流，它称为“安全政策”。我们使用这个词而不是狭义的“计算机安全政策”，是因为它的范围包括所有种类的信息技术和使用这些技术存贮和处理的信息。
2.1.1 安全政策的定义
一个安全政策是一个正式的规则，那些有权访问这个组织的技术和信息资产的人并必须遵守它。
2.1.2 安全政策的作用
一个安全政策主要的作用是告诉用户、职员和经理们，保护技术和信息资产是他们必不可少的需求，这个政策应该成为保障这些需求的专门机制。它的另一个作用是提供一个基准，让我们在获得、配置、审核计算机系统和网络的时候有所依从。因此没有哪怕是一个暗含的安全政策的话，试图只使用一堆安全工具是毫无意义的。
一个“适当使用政策(AUP)”也可以是安全政策的一部分。它应该清楚的说明在不同组成的系统上用户应该和不应该做什么，另外还应包括网络上允许什么样的流量。AUP应该说得尽可能的清楚，从而避免表意模糊或引起误解。比如：一个AUP可以列举任何禁止的USENET新闻组。（注意：在有的地方适当使用政策被称作可接受使用政策）
2.1.3 建立政策会涉及到谁
为了让一个安全政策适当有效，机构中的各级雇员都应该接受并支持它。特别重要的是公司的管理者要完全支持这个安全政策，否则不会有任何作用。下面是应该参与创建和评论安全政策的文档的个人的列表。
(1) 站点安全管理员
(2) 信息技术的技术人员（比如计算机中心的职员）
(3) 机构中大的用户组的管理员（比如商业区域、大学中的计算机系等）
(4) 安全应急响应组
(5) 受安全政策影响的用户组代表
(6) 负责管理的人员
(7) 法律顾问（如果合适的话）
上面的列表代表了许多机构，但是他们并不一定都是必要的。之所以提供这些代表的想法是因为他们是系统密码的保管人，有预算和制定政策权利的管理者，了解什么可以和不可以实现的技术职员，知道不同政策下涉及的法律条文的法律顾问。
在一些机构里，可能再包括EDP审计人员要更合适。如果完成政策的条款需要达到尽可能广泛的接受的话，包括上这个小组将会是非常重要的。在这里还要提及的是，不同的国家内法律顾问的角色有可能是完全不同的。
2.2 怎样产生一个好的安全政策？
好的安全政策的因素是：
(1) 它必须是可实现的，可以通过系统管理员进程、发布使用手册或者其他适当的方法。
(2) 在被认可的合适的地方，或在技术手段无法阻止的地方，通过使用安全工具，它能被强制执行。
(3) 它必须清楚的定义好用户、管理员和经营者的职责。
好的安全政策包括以下组成部分：
(1) 计算机技术购买的指导方针（Computer Technology Purchasing Guidelines），它指出什么是必须的或首选的，指出安全的特征，这些对于已存在的购买的政策和指导方针将是补充。
(2) 隐秘政策，它规定了对隐秘的合理期望，比如怎么对待电子邮件的监视、按键记录和用户文件访问。
(3) 访问政策，它通过列举用户、操作人员、管理者允许使用的功能，规定了存取访问的权利和特权，从而保护资产不损失或泄密，它会在外部的连接、数据交流、网络连接装置和给系统添加新的软件等情况下，提供指导方针。它同时也要列出需要声明的信息（例如，连接信息应该提供关于授权使用和线上监视的警告，而不是仅仅简单的说个“欢迎”）。
(4) 责任政策，它规定了用户、操作人员、管理者的责任。它应该明确谁有审查的能力，并提供突发时间的处理方针（就是如果发现有可能被入侵了要做什么和联系谁）。
(5) 认证政策，它通过有效的密码政策建立信任，使用对远程身份认证设置指导方针的方法或使用认证设备（这里指一次性密码和产生它的设备）。
(6) 可用说明，它预计了用户的可以使用的资源。它应该考虑到冗余和恢复的情况，还有特殊的工作时间和停机维护的时期。它应该也包括系统和网络失败报告的连接信息。
(7) 信息技术系统和网络维护政策，它描述了人们被允许怎样运用技术手段进行内部的和外部的维护。这里要考虑的一个重要话题是是否允许远程维护，这种访问怎么控制。这里要考虑的另一个问题是外购和怎么管理它。
(8) 侵害报告政策，它指出哪种侵害（秘密还是安全，内部还是外部）必须报告，报告给谁。无危险的气氛和匿名报告的可能将会导致被发现的侵害都更可能报告上来。
(9) 支持信息，它向用户、职员和经理提供每种侵害的联系信息；怎么处理外部的关于安全事件的询问或什么可以被当作秘密私有的指导方针；安全程序和相关信息的交叉参照，例如公司政策和政府的法律规章。
对有的安全政策（如在线监控）可能需要一些调整，安全政策的创建者在产生政策的时候应该考虑寻求法律援助，至少这些政策必须让法律顾问过目一下。
一旦你的安全政策已经建立好了，应该清楚的与用户、职员和经理交流它。让所有的人都写下一句话表明他们已经阅读过了，理解了，并且同意遵守这个政策，这是整个过程中一个重要的部分。最后，你的政策应该被当作一个正式的基本政策进行重新检查，看看它是否成功的支持了你的安全需求。
2.3 保持政策的灵活性
为了让一个安全政策长期可行，它需要许多基于结构安全概念的灵活性。一个安全政策可能（很大程度上）与特殊的硬件和软件情况无关（有的特殊的系统通宵都在安装和卸除）。我们应该清楚的说明政策升级的机制，这个说明应该包括执行过程、相关的人员、和谁来最后标记升级结束。
重要的是要认识到所有的规则都是有例外的。只要有可能，我们的政策就该讲清楚会存在什么例外情况。例如，在什么特殊情况下系统管理员可以搜查用户的文件。还有，可能会有多个用户使用同一个帐号的情况。比如，在有“root”帐号的系统中，多个系统管理员可能都知道root的密码并且使用这个帐号。
另一个要考虑的方面被称为“垃圾车病症”。它指的是如果一个重要的人忽然无法完成他/她的工作职责时（例如，他忽然病了或者意外的离开了公司），一个网站将发生什么。由于最重要的安全信息存在于最小的分发范围中，信息没有共享给大家就导致了丢失重要信息的风险大大增加。在这里，确定一个合适的平衡点对你的网站是非常重要的。
3. 体系结构
3.1 目标
3.1.1 定义全面的安全计划
所有的站点都应该制订一个全面的安全计划。这个计划应该处于一个比第二章提到过的特殊政策还高的地位，它应该被精细的设计，从而成为广泛适用于各种具体政策基本框架。
有一个这样的框架存在是非常重要的，这样具体的政策就可以和整个网站安全体系结构相协调。举例来说，如果对于internet访问制定了很强的政策，而对使用拨号上网的使用限制很少，这样就和严格限制外部访问的整体安全体系相矛盾了。
一个安全计划应该详细说明以下内容：网络将会提供的服务列表；组织中那个区域来提供这些服务；谁有访问这些服务的权利；提供什么样的权利；谁管理这些服务；等等。
计划还应该写清怎么处理突发事件。第5章对这个问题给出了深入的讨论，明确一些经典的事件和相应的响应对每个站点都是很重要的。例如，带有防火墙的站点在激发响应以前，应该先设置一个极限值限制被挡在墙外的尝试的次数，攻击和防御都该逐步升级。没有防火墙的站点将不得不确认，是否一个简单的连接到主机的尝试会引起一次突发事故，进行一次系统的全面搜索会怎么样？
对于连接到internet上的站点，和internet相关的安全事故被媒体无限夸大了，这很可能掩盖（隐藏的）更严重的内部安全问题。同样的，从没有连接到internet的公司可能拥有有力的、完备的内部政策，但是却不能确定充分的外部连接的政策。
3.1.2 服务分离
一个站点可能希望向用户提供许多服务，其中一些服务还是对外的。各种各样的安全因素促使我们愿意把单独的服务放在专门的主机上，多数情况下这里还会有性能的因素，不过它不在本文讨论的范围之内。
在多数情况下，一个站点提供的服务可能会有不同级别的访问需要和信任模式。为了保证站点的安全性和平稳操作所必需，应该把提供的服务放在一个专门的严格控制访问权的机器上，这样要强于简单的在同一台机器上提供一个（或几个）常常不是很安全的服务，也强于要求用户对这些服务的配置很熟悉，而他们仅仅是碰巧需要关心一下安全而已。
同样重要的是要区别开不同信任模式下的主机（比如，所有的位于防火墙内的主机和任何一台在外部网络上的主机）。
还要分离一些潜在的服务，在3.2.3节会简略的提到它们。要记住系统的安全性是同整个链条中最脆弱的地方相同的。最近几年里，一些广为流传的入侵实例是利用电子邮件系统的弱点进行的。入侵者并不想偷取电子邮件，他们利用服务器在邮件上的漏洞来控制其他的系统。
如果可能的话，每个服务都应该运行在不同的机器上，每台机器的任务就是提供一种专门的服务。这样可以帮助我们分隔入侵者，并限制潜在地损失。
3.1.3 全部禁止/全部允许
这两个根本对立的方法都可以在确定安全计划的时候采用，他们都可以形成合理的模式，依据站点和安全需要的具体情况从中选择其一。
第一个方法指的是关掉所有的服务，然后再一项项的启动需要的服务。这个方法可以在主机或者网络层适当地完成。这个模式我们以后称其为“全部禁止”模式，它一般要比后面的章节描述的模式要更安全一些。成功的执行“全部禁止”模式需要更好的了解要启动的服务。只允许已知的服务使得我们能更好的分析服务和协议的细节，分析适合站点安全级别的安全机构的设计。
另一个模式我们以后称其为“全部允许”模式，相比之下它更易于实现，但是一般比“全部禁止”的安全性要低一些。简单的打开所有服务常常是主机的默认值，允许所有的协议通过网络交界也常常是路由器的默认值。由于这样使得安全漏洞非常明显，所以常常在主机或网络层进行限制或者打补丁。
这两个模式中的每一个都可以应用在网站的不同部分中，选择哪一个根据功能的需要，管理者的控制和站点的政策等等。例如，站点的政策可能是在设置工作站的一般用途时使用“全部允许”模式，但是在设置信息服务的时候就采用“全部禁止”的模式，就像email中心一样。同样的，可能在站点和内部LAN的通讯上采用“全部允许”的模式，但是在站点同internet之间就使用“全部禁止”模式。
像上面的例子这样混合两种方法时要小心，许多站点的设置采用了一个坚硬的外壳和脆弱的内核。他们愿意为他们同外部的通讯付出花销，并且对这里的安全有很强的要求，但是他们却不愿意或者不能对内部的交流提供相同的保护。这样的方法仅能在对外的防御永远不会被攻破、内部的用户可以被信任的前提下才能工作正常。一旦外壳（防火墙）被攻破了，搅乱整个内部网络是轻而易举的。
3.1.4 确定真正需要的服务
不论是对内部还是在internet上我们都有大量的服务可以提供。在许多情况下，管理安全就是管理站点内部的服务的访问权和管理内部用户怎样获得远程站点的信息。
服务就像internet上的海浪一样不断涌现。这几年里，许多站点建立起来了匿名ftp服务，gopher（菜单驱动系统）服务，wais（广域信息服务系统）服务，WWW服务，等等。虽然他们流行了起来，但是这并不是所有的站点都需要的。让我们评价一下所有的新服务，我们建立它们的时候采取的是怀疑的态度，到底他们是真正必需的还仅仅是跟随了internet上当前的时尚。
记住，安全的复杂度会随着提供服务的数量呈指数增长。路由器过滤器需要修改从而支持新的协议，一些协议天生的很难安全的过滤（比如RPC和UDP服务），这些给内部网络提供了更多的缺口。提供在同一台机器上的服务可以互相产生灾难性的影响。例如，一台机器同时开设匿名FTP服务和WWW服务可能让一个入侵者通过匿名FTP放置一个文件，然后让HTTP服务执行它。
3.2 网络和服务的配置
3.2.1 保护基础设施
许多网络管理员竭尽全力保护他们网络中的主机，只有少数管理员会努力保护网络本身。这是许多因素造成的，比如，保护一台主机要比保护一个网络容易的多，同时入侵者或许也更关心主机上的数据，毁坏网络无法达到他们的目的。然而，仍有一些理由让我们保护网络。比如，为了分析数据（也就是搜索密码），入侵者可能把网络的流量转向一个外部的主机，同时，基础设施除了包括网络和连接它们的路由器以外，还包括网络管理协议（比如SNMP）、服务（比如DNS、NFS、NTP、WWW）、和安全系统（比如用户认证和访问控制）。
保护基础设施还需要避免人为的错误。当一个管理员错误配置了一个主机，这个主机可能会提供一个“变质了”的服务。它唯一影响的是需要这台主机的用户，除非这个主机是重要服务器，但这样受影响的用户数量总还是有限的。然而，如果一个路由器被错误配置了，所有的需要网络的用户都会受到影响。这个数量显然要远远大于受任何一台主机影响的用户数量。
3.2.2 保护网络
脆弱的易受攻击的网络会带来许多问题。一个经典的问题就是“拒绝服务”攻击。这时，处于异常状态的网络无法携带用户的正常数据。通常有两种途径回产生这个结果：一种是对路由的攻击，另一种是使用无用信息对网络进行洪水攻击。请注意这里的术语“路由”指的是更广泛意义上的联通网络的器件，除了路由器还包括防火墙、代理服务器等等。
对路由的攻击的目的是使它停止转发信息包，或者出现转发错误。这种现象以前可能是配置错误、制造虚假路由更新信息、或“洪水攻击”（也就是路由器被无法路由的包挤满，导致它的性能下降）造成的。针对网络的洪水攻击和针对路由器的洪水攻击很类似，只不过它的大量的包常常都是广播包。一次完美的洪水攻击将仅仅发送一个包，它利用网络结点上的一些已知漏洞使它们反复转发这个包或者产生错误的包，这些包都被另一个站点收到并再次重复发送。一个精挑细选的攻击包甚至可以产生传输的指数爆炸。
另一个经典的问题是“路由欺骗”。在这种情况下，伪造的路由更新信息发送到一个或更多的路由器上，使得这些路由器错误的转发信息。这同拒绝服务攻击中仅仅是为了让自己隐藏在伪造的路由后是不同的。在拒绝服务中的目的是使路由器不能使用；这是一种网络用户很快就能检测到的状态。而在路由欺骗下，伪造的路由使信息包被转发到另一台主机，入侵者可能在这里监视信息包中的数据，然后这些信息包被重新发送到他们应该到达的目标。这时，入侵者可能已经改变了包中的内容。
解决多数这种问题的答案就是保证路由更新包是使用路由协议发出来的（如RIP-2,OSPF）。这里有3个级别的保护，明文密码、密码加校验、和全文加密。明文密码只提供最小的保护，它防止了没有直接访问物理网络权限的入侵者。它针对配置错误的路由器（如在隔离区外的路由器对转发包的尝试）也提供了一些防护。密码的优点是不论在带宽还是在CPU上都节约资源。校验的方法针对发送伪造信息包的行为进行保护，甚至在入侵者有物理网络的访问权的时候也适用。再组合上一个序列号或者其他的唯一标识，使用校验也可以防止被“重复”攻击，这是一种入侵者或错误配置的路由器将旧的（但当时却是有效的）路由升级信息重新提交的攻击方法。完全的密文和唯一的标识则提供了最多的安全保障，它从网络布局上彻底阻止了入侵者。不过它的缺点在于耗费了路由器处理升级信息的时间。
RIP-2(RFC1723)和OSPF(RFC1583)在它们的基本设计规范里都支持明文密码。此外这两种基本协议都可以扩展支持MD5加密方案。
不幸的是，我们没有适当的方法阻止洪水攻击和出问题的主机、路由器对网络的洪水信息。不过幸运的是这种攻击很明显，当它发生时，我们总能通过简单的关闭相关资源从而解决。
3.2.3 保护服务
我们有许多种的服务，每种都有自己的安全需求，这些需求将随着我们使用这些服务的目的而改变。比如，一个只在站点内部使用的服务（如NFS）和提供外部使用的服务相比，可能会需要不同的安全机制。我们知道通过对外部访问的控制将足以保护内部的服务，然而一个供世界各地用户浏览的主页的WWW服务器必须需要还有内置的保护。也就是说，服务、协议、服务器都必须提供充分的安全保障，防止未授权的访问和对网页数据库的随意改动。
像前面描述的那样，内部服务（就是说只在一个站点内部用户中使用的服务）和外部服务（就是说允许站点外部用户访问的服务）通常会有不同的保护需求。所以聪明的做法是，把内部的服务独立的放在一些服务器主机上，外部的放在另一些上。也就是内部的和外部的服务不该放在同一台机器上。事实上，许多站点只要有了一套子网（或甚至还是不同的网络）就开始运行了，而这些网络可以很容易的从外部网络或站点的另一套内部网络访问。当然，连接它们的地方常常会有防火墙，但是确保这样的防火墙总是正常工作必须非常的小心。
人们现在对于使用intranet（译注：企业内部网）连接企业的不同部分（如分公司之间）越来越感兴趣。虽然这篇文档通常只谈内部服务和外部服务的区别（公开的和私有的），但是使用intranet的站点应该知道它们需要考虑第三种情况，在他们设计和提供服务的时候就此采取合适的措施。在intranet上提供的服务既不是公开的服务，也不是完完全全的像一个单独的企业子网那样的私有服务。因此，这些服务需要它们自己的支持系统，从而把它们同内部、外部网络和服务分隔开。
匿名和guest的访问权是外部服务中一个值得特别考虑的问题，它可能发生在匿名ftp和使用guest登陆时。确保不该被外部用户访问的主机和文件系统与匿名FTP和guest登陆的用户被很小心的隔离开是一件非常重要的事。和匿名用户有关的另一个需要特别注意的是他们的写操作，一个站点对公众在此可能得到的信息内容承担有法律责任，所以我们建议您要仔细的监督匿名用户留在站点的各种信息。
现在让我们来考虑一下最流行的几个服务：域名服务、密码/密匙服务、认证/代理服务、电子邮件、www、文件传输、和NFS。因为它们是最常用的服务，所以它们也最容易被攻击。同时，由于对这些基础服务的信任，一次对它们的成功的攻击会造成严重的后果。
3.2.3.1 域名服务器（DNS和NIS(+)）
internet使用域名系统（DNS）来完成各主机和网络的域名到地址的解析。网络信息服务（NIS）和NIS＋虽然不是用于全球internet的服务，但却和DNS服务受同样因素的影响。域名到地址的解析对于任何一个网络的安全运转来说都是非常关键的，一个能成功控制或模仿DNS服务器的攻击者就可能使流通的信息错误路由，从而彻底破坏对安全的防护。例如，常规信息能被转移到某个危险的系统继而被监控；或者，用户被欺骗而提供他们的认证密码。公司应该创建一个众所周知的且被保护的站点作为第二域名服务器，同时使用路由器的过滤功能来保护他们的主DNS服务器不被拒绝服务所攻击。
传统意义上的DNS服务没有任何安全能力，特别是询问程序得到的返回信息无法检验它是否被修改过，或者分辨出它是否来自于有问题的域名服务器。改进的工作已经完成了——在协议中并入了数字签名，有了它们就可以用密码学的方法校验信息的完整性了（见RFC 2065）。
3.2.3.2 密码/密匙服务器（NIS(+)和KDC）
密码和密匙服务器通常使用加密运算保护它们的重要信息（即密码和密匙）。然而，即使一个单向加密的密码也能被字典攻击（穷举所有常用的单词进行加密，然后看它是否和要破译的密文一致）所破译，所以确保这些服务器不被不使用其服务的主机所访问是必要的，即使需要访问的主机也只允许它们访问这一种服务（指的是通常如Telnet和FTP这样的服务，都不应该允许管理员以外的任何人访问）。
3.2.3.3 认证/代理服务器（SOCKS，FWTK）
代理服务器增加了一定量的安全程度，它通过一个可被监视的，可隐藏内部结等的主机集中访问各种服务，但是这个好像漏斗的服务给潜在的入侵者创造了一个诱人的目标。代理服务器需要的保护措施非常的依赖于使用的代理协议和被代理的服务。通用的规则还是只有需要服务的主机才能来访问，同时它们不能访问其他服务，这将是提供保护的一个好的起点。
3.2.3.4 电子邮件服务器
电子邮件（email）系统很久以来一直是入侵者突破的源泉，这是因为email协议是最陈旧的协议之一，却又是使用最广的服务。同时，由于它的本性所决定，一个email服务器需要访问外部网络，多数的email服务器还允许任何来源的输入。一个email服务器通常由两部分组成：一个接受/发送进程和一个处理进程。因为email面对所有的用户，而且常常是私人性质的，所以处理进程需要系统（root）一级的特权来发送email。多数的email执行系统同时执行这个服务的两个部分，这意味着接收进程也拥有系统级特权，这就开放了一些本文没有谈及的漏洞。一些可用的email执行系统允许两个进程分隔开，这样的系统一般被认为更安全，但是我们仍然要小心的安装从而避免制造出安全问题。
3.2.3.5 万维网（WWW）服务器
由于万维网的易用性和浓缩信息服务的强大能力，它现在正以指数形式增长着。多数WWW服务器能接受一些类型的来自用户的用法和行为，最常见的例子是得到一个远程用户的请求，然后通过向一个运行在服务器上的程序提供相应的信息响应这个请求，一些在编写的时候没有考虑安全因素的程序这时就会制造安全漏洞。如果一个Web服务器在internet社区中使用，一件重要的事情就是机密的信息不能也放在这台服务器上。事实上，我们推荐服务器单独建在一台不被其他内部主机所“信任”的机器上。
许多站点可能想同时提供FTP服务在它们的WWW服务器上，但是只能使用提供信息用的匿名ftp（就是只能下载的ftp）。可以上载的ftp和WWW地结合将会带来危险（例如，这可能会导致你的站点发布在网上的信息被修改），而且不同的服务所要考虑的安全措施也是不同的。
3.2.3.6 文件传输（FTP，TFTP）服务器
FTP和TFTP都允许用户采用点对点的方式接受和发送文件。FTP需要认证而TFTP不需要。由于这个原因，TFTP应该尽量避免使用。
不正确的配置FTP服务器能允许入侵者在任何主机上随意的复制、替换和删除文件，所以正确配置这个服务是非常重要的。当服务配置的不正确的时候，对加密的密码和私人数据的访问权、木马程序的传入都属于少数的几个潜在安全漏洞。FTP服务器应该建在它自己单独的主机上，由于两种协议使用相同的安全策略，一些站点选择让FTP和Web服务器建在一起。然而我们并不建议这样做，特别当FTP服务允许上载文件的时候（见上面的WWW的一节）。就像在3.2.3一节的开始一段提到过的一样，向你的站点内部提供的服务不该和向外部提供的服务放在一起，它们每个都该有自己的主机。
TFTP和FTP提供的功能范围略有不同，并且没有任何安全设计。这个服务只能在内部使用，同时还要严格的配置使服务器只提供对一套事先确定的文件（取代系统所有可见文件）的访问权。也许TFTP的最常见的用途是下载路由配置文件到路由器上。TFTP应该有自己单独的机器，并且不能被安装在支持外部FTP或Web访问的主机上。
3.2.3.7 NFS服务器
网络文件服务允许主机共享普通的磁盘。NFS常用在依靠磁盘服务器提供所有存储需要的无盘主机上。不幸的是，NFS没有内置安全功能。所以只让使用这种服务的主机有权访问NFS服务器是十分必要的。这是通过列出对每个主机提供的文件系统和提供形式（如，只读、读写等等）实现的。文件系统不该提供给任何局域网之外的主机，因为这会要求NFS服务被外部访问。理想情况下，外部对NFS服务的访问应该被防火墙拦截住。
3.2.4 保护安全系统
令人吃惊的是站点常常忽略最明显的安全缺陷，它们竟然让安全服务器自己对开放在攻击面前。基于前面讨论过的考虑，下面的几点是很清楚的：安全服务器不该从外部访问；除了对内部的鉴定过的功能外，应该提供最小的访问控制权；不该同其他任何服务放在相同的主机上。进一步的，应该使用一种“纸介记录”记录所有对这个节点的访问，包括服务器自己在内。
3.3 防火墙
在internet上一个使用和宣传最广泛的安全措施是“防火墙”。防火墙被美誉为对于大多数，如果不是所有的，安全问题的万灵药。然而它们不是，防火墙仅是一种寻求系统安全的工具。它们提供一定级别的保护，并且通常是一种执行网络级安全政策的方案。防火墙提供的安全级别能随具体机器需要的安全级别而变换，在安全、易用、花费、复杂性等等还会有传统上的平衡。
任何用于控制和观察网络出入访问，其目的是为了保护网络的机制结构都是防火墙。一个防火墙就像一个大门，所有的信息流量从这里进入和出来，它保护着网络和/或系统的关口。防火墙帮助我们设置发生在被保护的网络和另一个网络（如internet或者站点的另一部分）之间交流的总量和类型的限制。
防火墙一般是在网络的一部分如公司的内部网络和网络的另一部分如整个internet之间建立一面墙的方法。这面墙的独一无二的特点是需要一些方法使得只有符合专门特征的流通信息才能通过那扇被小心的监视着的门（“网关”）。最困难的地方在于建立一个标准，什么样的包应该被允许或禁止从这个门通过。关于防火墙的书籍使用不同的术语来描述不同形式的防火墙，这将会把一个不熟悉防火墙的系统管理员搞晕，这里要注意的事情是描述防火墙没有固定的术语。
防火墙并不总是或甚至很少是一台单独的机器，其实防火墙经常是路由器、网络片断和计算机主机的结合体。因此由以上分析可以知道“防火墙”这个名词是由多于一个的物理设备组成的。典型的防火墙是由两个不同的组件组成，过滤路由器和代理服务器。
过滤路由器是防火墙中的概念最明确的组件，路由器使两个（或更多的）不同网络之间的数据继续传输或返回。一个“普通的”路由器从A网络获取一个包，然后把它“路由”到B网络中的目的地址。一个过滤路由器也会做相同的事情，但是它要判断的不仅是怎么路由这个包，还有它该不该路由这个包。这是通过安装一系列的过滤器而完成的，路由器可以使用它们决定怎么处理每个到达的数据包。
对于某种品牌路由器的功能和运行某种软件的版本的讨论已经超出了本文的范畴，然而当评测一个用于滤包的路由器时，下面的标准功能可能会在实施过滤政策的时候很重要：源IP地址和目的IP地址、源地址和目的地址的TCP端口号、TCP协议“ack”位的状态、UDP协议的原地址和目的地址的端口号、信息包的流向（即A->B还是B->A）。还有一些其他的建立安全过滤计划的必要信息，它们是路由器是否能重新安排过滤器的指令（指优化过滤器，但这样有时会改变它的含义并引起非故意的访问请求）、是否在每个接口处都可以过滤向内的和向外的包（如果只能过滤向外的包，那么路由器就在它自己的过滤器“之外”了，从而会很易于受到攻击）。除了路由器变得易受攻击之外，过滤向内或向外的包的区别还和多于2个接口的路由器密切相关。另一个重要的问题是基于IP头的选项和包的分段状态进行过滤的能力。建立一个好的过滤器将很难，并且需要对要过滤的服务（协议）类型有很好的理解。
为了更好的安全考虑，过滤器通常把两个连接的网络之间的访问限制到一台主机，即堡垒主机上，只有通过这台堡垒主机才能访问其他网络。由于只有这一台机器而不是上百台机器可能被攻击，所以维护一定的网络安全级别就容易多了，因为只有这台主机需要非常仔细的保护。为了使资源对合法通过防火墙的用户可用，服务信息被堡垒主机向前转发。一些服务器还把内置的服务也转发出去（像DNS服务器和SMTP服务器），对于其他的服务（如Telnet、FTP等）可以使用代理服务器采取一种安全的方法允许通过防火墙对资源进行的访问。
代理服务器是通过一台单独的机器集中请求服务的方法。它一般是一台单独的机器（堡垒主机），它同时为不同的协议（Telnet、SMTP、FTP、HTTP、等等）提供代理服务，不过也可以对每种服务都有单独的计算机主机。客户端不再直接连到外部服务器上，而是连接到代理服务器上，然后代理服务器再把连接转移到被请求的外部服务器上。根据使用代理服务器的类型，配置内部的客户端使之可以自动完成这个重定向的过程而不需要用户了解相关知识是可以实现的，而其他没有配置的就可能需要用户自己直接联到代理服务器，然后通过特殊的格式接通连接。
代理服务器可以带来显著的安全益处。它使得增加对协议的访问控制列表成为可能，还要求用户或者系统在获得访问权限之前必须提供某种级别的认证。更强大的代理服务器有时也被称为用户层网关（ALGs），可以用它写出特殊的协议和可以适当配置它从而只阻挡某种协议的一部分功能。例如，一个FTP的ALG能判断出“put”命令和“get”命令的区别，机构可能希望允许用户从internet上“get”文件，但是不希望能“put”内部文件到远程的服务器上去。与之对照的，一个过滤路由器只能把所有的FTP访问都阻挡，或者都不阻挡，却无法只阻挡一部分。
代理服务器也能配置为使用基于变化的参数的加密数据流。机构可能会使用这个特性允许都仅有一个在internet的访问点的两地之间建立加密的连接。
典型的防火墙被认为是一种把入侵者挡在外面的方法，但是它们也常常用于让合法的用户进入站点。有许多例子说明一个合法的用户需要经常的访问他的内部站点，比如在贸易展览的旅途中和会议中等等。这时访问internet常常是可以实现的，但是却可能通过的是一台不值得信任的机器或网络。一个正确配置的代理服务器可以允许正确的用户进入站点，同时继续禁止其他用户访问它。
当今在防火墙技术中最好的成就是使用一对屏蔽路由器和一个或几个处于两个路由器之间的网络中的代理服务器的组合。这样的设置允许外部路由器阻隔任何使用IP层以下手段破坏安全的企图（IP欺骗、源路由、分段信息包），然后使用代理服务器处理在较高层协议的安全漏洞。内部路由器的目的是阻隔除了通向代理服务器以外的所有信息流量。如果这样的设置被严格的实现了，就可以达到很高的安全级别。
为了使网络的安全管理员更方便，多数防火墙都提供了可供查看的日志记录。日志可以被集中管理，当发生异常情况时系统还可以发送警告消息。经常性的检查日志，寻找一切入侵的痕迹和闯入的企图是很重要的。因为一些入侵者会试图通过编辑日记文件来掩盖他们的痕迹，所以保护这些记录是值得注意的。以下的一些方法是可行的，它们包括：一次可写，多次可读（WORM）的驱动器；纸张日志；通过“syslog”程序集中管理日志记录。另一种技术是使用一个“假的”串行打印机，把串口连接到一台独立的机器来保存日志。
防火墙具有可以利用的范围很广的品质和实力。商业软件包的价格在10000美元到250000美元之间，“自制的”防火墙可以用于保护小规模的资产。不过要记住正确的设置防火墙（商业的和自制的）需要大量重要的技巧和对TCP/IP的知识。它们都需要经常的维护，安装软件补丁和升级、经常监视。当为防火墙进行预算的时候，这些附加的开销应该被加到防火墙的物理部件的开销中去。
说一句题外话，构建一个“自制”的防火墙需要大量的TCP/IP技术和知识。请不要轻易的尝试这样做，因为虚假的安全感比知道自己并不安全更糟。当受到威胁的时候，无论使用什么安全措施，确定要保护的资产的价值和实施安全措施所需的花费都是非常重要的。
有关防火墙最后要提醒一点，它们在为站点贯彻安全的时候带来了很多帮助，并且可以阻止许多不同的攻击，但是要记住它们只是解决方案的一部分，这是很重要的。它们不能保护你的站点不受到任何攻击。
4. 安全服务和程序
本章向读者介绍一些维护站点安全时遇到的问题，每一节谈及一种安全服务或维护站点安全所需要的能力，我们将在非常高的层次上向读者介绍这些问题的相关概念。
通观本章，你会发现我们经常提到密码学。关于密码学细节的深入研究已经超出了本文的范畴，不过感兴趣的读者可以从本文后面的参考文献里列出的文章和书目中获得更多的信息。
4.1 认证
许多年以来，人们一直用标准的、可重复使用的密码当作正规的用户认证方法。起先，这样的密码用于终端用户向中央计算机证明的自己身份。那时还没有网络（无论是内部的还是外部的），所以明文密码泄漏的风险非常小。然而今天我们的系统通过局域网连接在一起，然后这些局域网再进一步一起连成了Internet。用户可能从全世界登录进来，他们的重复使用的密码常常在同样的网络上被明文传输，网络中的任何人都有截获的可能。事实上，应急处理协调中心和其他的响应组都发现了大量的有关数据包嗅探器的事件，而它们就是在对明文密码进行着截获。
随着诸如一次性密码（如S/Key）、PGP、基于令牌的认证设备这样的新技术出现，人们开始使用类似密码的字符串作为秘密的令牌（token）和个人信息码（pin）。但如果这些秘密的令牌和个人信息码没有适当的选择并保护，认证将被轻而易举的破坏。
4.1.1 一次性密码
就像上面提到的那样，在现在的网络环境下，我们推荐那些关心系统和网络安全的站点不再使用标准的可重复密码。有许多入侵事件都涉及到网络木马程序（通过telnet或rlogin等）和网络数据包嗅探器程序，这些程序能截获主机名/用户名/密码这样的3元组，入侵者就可以使用这些截获的信息以后对这些主机和用户进行访问。这样的事情发生的原因是：1)密码被一次次的使用（对应概念“可重复的”），2)密码使用明文在网络中传输。
基于这个问题的一些新的认证技术被开发了出来，其中最有挑战性的是提供只能使用一次的密码（通常称作一次性密码）。有许多这样的产品可供站点考虑使用。在这些产品中进行审慎的选择是每个公司的指责，同时每个公司都应该根据自己的评估有自己的选择。
4.1.2 Kerberos系统
Kerberos是一个在无安全保证的网络上提供认证的分布式网络安全系统。如果应用程序需要的话，还可以提供加密和完整性验证功能。Kerberos最先是由麻省理工学院(MIT)在80年代中期开发出来的，现在主要流行的是它的4.0和5.0两个版本，由于一些应用上的的原因它们并不兼容。
Kerberos使用对称的密匙数据库，通过一个被称为Kerberos服务器的密匙分配中心（KDC）实现。在和KDC进行适当的交流以后，用户或者服务（的负责人）就可以得到一张电子“标签”，这些标签用来在负责人之间进行认证。所有的标签都含有一个时间戳，它限制了标签的有效时间。因此，Kerberos客户端和服务器都必须有一个安全的时间源，并且能够保证时间的精确。
Kerberos实用的方面表现在它与应用层的结合，典型的应用程序如FTP、telnet、POP、和NFS都被结合在Kerberos系统中，可以自由选择综合了不同级别的应用程序的执行方法。查询最新的Kerberos的FAQ信息请访问http://www.ov.com/misc/krbfaq.html。
4.1.3 选择并保护秘密令牌和个人信息码
选择秘密令牌的时候一定要非常小心，就像选择密码一样，它们应该能经受被强制猜测的尝试。也就是说，它们不能是任何语言的单词，任何普通的、工业的或文化的首字母缩写，等等。理想的令牌应该越长越好，应该由大小写字母、数字和其他字符组成。
一旦选好合适的秘密令牌，保护它们就是最重要的了。有时它们用于硬件设备的个人信息码（比如令牌卡），这时决不能将它们写在相关设备上，或放在一起。其他的情况，比如PGP的密匙，应该小心防止有人非法访问。
关于这个问题最后要说的是，当我们使用像PGP这样的密码产品的时候要注意检查密匙长度是否合适，还要让你的用户也同样这样做。随着技术的进步，最小的安全密码长度在持续的增长。确保你的站点跟上了最新的技术要求，可以让你确信你使用的密码系统向你提供的保护是有效的。
4.1.4 密码的确保
然而拒绝使用标准的可重复密码的要求也不能盲目夸大，应该承认一些组织可能仍在使用它们。在建议这些组织换用更好的技术的同时，我们还有以下的建议来帮助他们选择和维护传统密码。但是要记住，由于嗅探器程序的存在，这些办法都无法完全防止密码泄漏。
(1) 坚固的密码的重要性——在许多（如果不是多数的）系统入侵的情况下，入侵者需要得到某个系统中用户的访问权。一个有代表性的常见途径就是猜测合法帐号的密码，这常常是对系统密码文件运行带有庞大字典的自动密码破解程序而实现的。在这种情况下防止被破解的唯一方法只有谨慎的选择不易猜测的密码（这里指包括数字、字母和符号字符）。在系统支持和用户可以容忍的前提下，密码也应该越长越好。
(2) 改变默认密码——许多操作系统和应用程序安装有默认用户和密码，应该立刻把它们改成不易猜测或不易破解的。
(3) 限制对密码文件的访问权——具体的说，一些站点想要保护文件中存放密码的部分，从而使想要入侵的人无法破解它。一个有效的技术是使用遮蔽（shadow）密码的方法，它在文件通常存放密码的位置放入虚假的或错误的密码，而包含正确密码的文件被保护在系统的其他地方。
(4) 密码的老化——什么时候并且怎么样让密码过期仍然是安全领域中争论着的一个话题。大家公认的是一旦这个帐号不再使用了，他的密码应该失效。而正热烈争论的是应不应该强制一个正在使用中的用户经常更换成更好的密码。坚持改变密码的观点认为这样会避免泄漏的帐号的继续使用，而相反的观点认为频繁的更换会导致用户把他们的密码写在明显的地方（比如把它们贴到终端上），或使用户选择非常简单同样也是非常好猜的的密码，另一个依据是入侵者很可能会尽早使用他们截获或破译的密码，这种情况下密码过期带来的安全保护就很有限了。
虽然现在这场争论还没有一个确定的结果，但一个密码策略必须立刻发布并且能够向用户提供指导，应该多长时间更换一次密码。当然，对绝大部分用户来说，每年更换一次密码并不是什么难事，同时你该认识到需要这样做。我们建议至少在特权帐户的安全收到威胁的时候必须更换密码，比如职员（特别是管理员）的临时变动，或者一个普通帐户已经被入侵的时候。另外，如果一个特权帐户的密码被破译，则系统里所有的密码都应该改变。
(5) 密码/帐户停用——一些站点发现在一定次数的失败的认证尝试之后暂时停用这个帐户是一个有效的方法。如果你的站点决定采用这种机制，那最好不要暴露自己。帐户停用之后，即使是输入正确的密码，显示的信息应该仍然称这是失败的登陆尝试。执行这个机制最后还需要合法的用户向系统管理员申请恢复登录。
(6) 关于finger守护进程——作为默认值，finger守护进程会显示相当多的系统和用户信息。例如，它能显示当前使用系统的所有用户列表，或者某个特定用户的.plan文件的所有内容，这些信息常被入侵者用于识别用户名并猜测他们的密码。我们建议站点要对finger进程进行修改，从而限制它显示的信息。
4.2 保密性
你的站点需要防止信息资源泄漏给未授权的组织。通常操作系统内置有文件保护机制，在系统中它允许管理员控制谁能访问或“看到”特定文件的内容。然而提高保密性的更有效的方法是通过加密术。加密后得到的是不规则数据，这使得除了合法接收者和所有者之外，任何人想获得原来的纯文本文件都是非常困难和费时的事。合法接收者和所有者都应该持有相应的解密密匙，使他们可以轻松的将文件解密为可读的（明文）格式。我们建议站点使用加密术来提高保密性，保护重要的信息。
使用加密术有时会受到政府和站点规则的约束，所以我们鼓励管理员在采用它之前广泛了解相关法律和政策。这种情况下，讨论哪个算法和程序是可以采用的已经超出了本文的范畴，但是我们警告不要使用UNIX中的crypt程序，因为已经发现它很容易被破解。我们也鼓励每个使用者在使用任何特定的算法/产品之前花一些时间去了解它的加密强度。多数著名的产品都会有充分的文档说明，所以这将是一项非常容易的任务。
4.3 完整性
最为一个管理员，你会想确认信息（如，操作系统文件，公司数据，等等）没有被非法更改过。这意味着你将想要提供一些关于你的系统上信息完整性的断言。一种实现方法就是提供未改动文件的校验和，离线保存它们，定期（或需要时）检验以确认在线文件的校验和是否没有变过。
一些操作系统带有校验程序，比如UNIX的sum程序，然而它们并不能提供你真正想要的保护。可以以某种方法修改文件却保持UNIX的sum程序的结果！因此，我们建议你应该使用一个强度较大的加密程序，就像字符串变换程序MD5，来创建用于确保完整性的校验和。
还有一些其他需要确认完整性的应用，比如在两个用户间提交一封email的时候。有一些产品可以提供这样的功能。一旦你确定需要这样的功能，你可以立刻着手确定可以提供这个功能的技术手段。
4.4 授权
授权指的是授予进程和用户特权的进程。它和认证的区别在于后者是用于识别用户的进程，一旦识别出来了（可靠的），用户的特权、权利、所有权和被允许行为才被前者确定。
明确的列出每个用户（用户进程）对所有资源（对象）的已授权行为在合理的系统中是不可能的。真正的系统使用了一些技术来简单化授予和检查授权的过程。
在UNIX系统中被普及的一种途径是把每个对象分配给3个级别的用户：所有者、组员和全部用户。所有者是对象的创建者或者被超级用户指定为所有者的用户，所有者的权限（可读，可写，可执行）只有对所有者自己才适用。组是对某个对象有共享访问权的用户集合，组的权限（可读，可写，可执行）对所有属于这个组的用户（除了所有者）都适用。全部用户指的是可以访问这个系统的所有其他用户，全部用户的权限（可读，可写，可执行）对所有用户（除了所有者和组员）都适用。
另一种途径是把对象放到一张列表中，这个列表直接包括了所有许可访问的用户（或组）的身份。它称为访问控制列表(ACL)，ACL的优点是它们很易于维护（每个对象都有一个表）并且它很容易直接检查谁访问了什么。它的缺点是需要额外的资源存放这样的列表，庞大的系统就需要庞大数量的列表。
4.5 访问
4.5.1 物理访问
限制对主机的物理访问，同时只对允许其使用主机的用户提供访问权。主机在这里包括“被信任的”终端（即允许不可靠使用的系统控制台这样的终端，操作终端和专用于特别任务的终端），个人微机和工作站，特别是它们中连接到你的网络上的那些。要确保人们网状分布的所有工作区域都进行了访问限制，否则有人就可能籍此破坏你的物理安全（如人为的敞开大门）。
还要保护数据和程序的原始资料及其备份是安全可靠的。除了把它们放在良好的环境下以供长时间保存以外，还要小心防备被窃取。把备份和原始资料分开存放是非常重要的，不仅是为了损坏的因素，还要防止被窃。
移动电脑会带来特别的风险。如果你的一个职员的移动电脑被偷了，要确保这不会带来安全问题。对于将被允许存放到移动电脑的数据，要考虑出一种发展中的指导方针，当它们在移动电脑上的时候，究竟该怎么保护这些数据（比如使用加密）。
其他的需要限制的物理访问包括配线柜、重要的网络部件（比如文件服务器，域名服务器和路由器）。
4.5.2 随时的网络连接（walk-up network connection)
随时连接表示通过适宜的布置网络的连接点，使用户可以方便的将一台移动电脑联到你的网络上。
请思考你是否需要这样的服务，能不能承担任何人都能把一台未授权的主机连到你的网络上的风险。这会大大增加受到通过IP地址欺骗、包嗅探等手段的攻击的风险。用户和站点的管理者必须评估这些相关风险，如果决定提供随时的连接，一定要小心的配置服务和精确的定义提供服务的区域，这样你可以确认需要的物理访问保护。
在随时连接的用户被允许访问你网络中的资源之前，应该先对主机进行认证，这样才可能对物理访问进行控制。举个例子来说，如果这种服务面向的是学生使用，那么你可能只在学生实验室中提供随时连接插口。
如果你提供随时访问的目的是为了访问者可以方便的连回他们的本地网，可以考虑使用一个与内部网络无连通的分离子网。
请密切注视可能无监控的访问网络的地方，比如空闲的办公室之类。明智的做法是在配线柜处断开这样的区域，考虑使用安全的集线器且监视非法主机连接的企图。
4.5.3 其他网络技术
这里的技术包括X.25、ISDN、SMDS、DDS和帧中继。它们都使用电话交换线路提供物理连接，这给了它们被利用的潜在可能。破解者对于电话交换机有着同网络数据一样的兴趣！
只要需要，通过交换技术可以随时使用永久虚电路或封闭客户群。提供认证和加密（如IPv6）的技术正在迅速发展，在安全保障很重要的地方请考虑使用它们进行网络连接。
4.5.4 调制解调器
4.5.4.1 必须要控制调制解调器接入线路
尽管它们使用户更便捷的访问站点，但是同时也提供了绕开站点防火墙的有效途径。这是必须控制调制解调器接入的本质原因。
没有经过正确的认证，不允许用户安装调制解调器线路，包括临时的安装在内（例如在晚上把传真或电话线路插到调制解调器上）。
维护一个所有调制解调器接入线路的注册表，并保持你的注册表不断更新。经常的（最好是自动的）让站点检查有没有未授权的线路。
4.5.4.2 拨入的用户必须被认证
在用户访问你网络上的任何东西之前必须先检查它的用户名和密码。通常的密码安全性的注意事项（见4.1.1一节）在这里显得格外重要。
要记住电话线路是可以分接的，也就是截取信息将非常容易。现代的高速调制解调器使用了更多的成熟的调制技术，这使得监听变得更困难了一些，但是我们还是应该谨慎的假设黑客知道怎么偷听你的线路，因此你应该使用一次性密码。
只设置一个接入点（比如使用一个大调制解调器池）将会很有帮助，这样所有的用户都在同一个地方得到认证。
用户偶尔会输错密码，设置一个很短的延迟——比如2秒钟——在失败的登陆和下一次登录之间，并且在第三次失败以后断开连接，这样会放慢自动密码攻击的速度。不要告诉用户到底是用户名错了，密码错了还是都错了。
4.5.4.3 回拨功能
一些拨号服务器提供回拨功能（即，当用户拨入并获得认证以后，系统会断开通话，然后以特定的号码回拨给用户）。回拨的用处在于，如果有人猜出了用户名和密码，通话被系统断开之后系统会回拨给密码被破解的那个真正用户，服务器的电话会使他引起怀疑。这也意味着用户只能从一个地方登录（服务器回拨的地方），同时回拨还会带来相关的话费开销。
这个功能必谨慎使用，因为它可以被轻易的绕过。起码应该保证不使用接入的那部调制解调器来回拨。总的来说，尽管回拨可以提高调制解调器的安全性，但是不应该只依靠它。
4.5.4.4 所有的登录都应该被记载
所有的登录，不论成功的还是失败的都应该记载下来。但是不要在日志中留下正确的密码，只把它们记载为一次成功的登录就可以了。因为多数错误密码是合法用户的输入错误，它们和真正的密码只差一个字符，所以如果你不能保障这样一份日志的安全就根本不要记录它。
如果可以，充分利用接入线路识别的功能，记录下每个尝试登录的电话号码。这里要留意接入线路识别带来的隐私问题，还要知道它并不能完全信任（因为已经有入侵者攻破电话交换机，转发电话号码或做些其他改动的事例），这些数据只能用来了解情况，不能用来认证。
4.5.4.5 谨慎选择你的登录标题
许多站点使用系统的默认消息作为它们的登录标题。不幸的是，它常常会把主机的硬件类型或者使用的操作系统泄漏出去，这给入侵者提供了很有价值的信息。所以每个站点都应该建立它自己特别的登录标题，注意只要包含必须的信息就可以了。
要显示一个短标题，而且别提供什么“有吸引力”的名称（例如,XYZ大学的学生记录系统），给你的站点起一个名字，一个很短的通话可能被监视的警告，一个用户名/密码提示，最后检查一下在标题文字中可能涉及的法律条文。
对于更安全的应用，可以考虑使用“遮蔽”的密码（即，除非用户写下了密码，否则对输入没有任何响应），这样能有效的模拟一个失效的调制解调器。
4.5.4.6 拨出认证
拨出的用户也需要认证，特别当你的站点不得不为这些电话负费的时候。
永远不要允许从一个非法拨入的用户拨出，并且随时考虑你允许的是不是一个合法的用户。这么做的目的是防止有人把你的调制解调器池当作链式登录的一部分。这将很难检查，特别是当黑客建立了一条通过你站点中几个主机的通道的时候。
至少不要允许同一台调制解调器和同一根电话线既可以用于拨入，也可以拨出。如果你将拨入和拨出调制解调器池分开的话，这将很容易实现。
4.5.4.7 努力使你的调制解调器编程滴水不漏
要知道调制解调器不能在运行的时候重新编程。所以至少要保证你的调制解调器不会在两三个附加信号后就进入命令行状态！
编程使你的调制解调器在每次新调用之前重置到标准配置，如果这样不行，就让它们在每次调用之后重置。这样的可以防止你意外的重编调制解调器的程序。在每次调用的开始和结束时都重置会让我们有更有把握，这样新的调用不可能继承前面调用的对话。
请检查你的调制解调器终端调用是否“干净离索”。当一个用户从服务器注销时，检查服务器是不是完全挂断了电话线路。当用户意外的挂断时，服务器不论处于什么对话中，是不是都强制他注销了，这两点同样重要。
4.6 审核
本节介绍了用互联网收集数据的手续，它可以用于分析网络安全和响应安全事件。
4.6.1 收集什么
审核数据包括任何人、进程、网络中的其他公司的所有试图达到一个不同安全级别的尝试。它应该包含它们有什么样的登录和注销、超级用户权限（或非UNIX的其他环境）、标签的产生（比如使用Kerberos）、和其他对访问控制或状态的改变，特别要注意“anonymous”和“guest”帐户对公开服务器的访问。
从不同站点和同一站点的不同类型访问中收集来的真实数据将会非常不同。通常，你想要收集的信息包括：用户名和主机名，它们是关于登录和注销的；以前的和新的访问权利，它们是关于改变访问权的；还有时间戳。当然，还会有更多的信息被收集进来，这取决于它的系统能提供什么信息和我们有多少可用的空间以供存放。
一个非常重要的注意事项：不要收集密码。如果审核记录可能被不适当的访问，这样做将会制造一个巨大的安全隐患。同时也不要收集错误的密码，因为它们常常只是合法密码的简单变换或只差一个字符。
4.6.2 收集进程
收集进程应该由主机或者正在被访问的资源执行。根据数据的重要性和在服务被拒绝时要求数据留在本地的需要，数据可以选择保存在局部资源中直到需要它，或者在事件发生之后立刻转移到存储设备里。
有三种基本方法存放审核日志：主机上的一个可读/可写文件、一次可写/多次可读设备（如，CD-ROM或特殊配置的磁带机）、只可写设备（如行行式打印机），每个方法都有优点和缺点。
在三种方法种，文件日志使用最少的资源并且配置最容易。它可以立即访问记录内容从而进行分析，这对处理正在进行中的攻击是非常重要的。但是文件系统日志也是可靠性最低的，如果存放日志的主机被攻破了，那么文件系统通常是最先受到威胁的，一个入侵者可以很容易的覆盖入侵的痕迹。
收集审核数据到一个一次可写的设备上比使用简单文件稍稍复杂一些，但它的意义重大的进步是可以大大的增加安全性。因为入侵者不再能改变表明入侵的数据了。这种方法的缺点是需要维护一套这样的存储设备和存储介质的花销，同时，数据也不能立即可用。
行式打印机用于需要持续的又是立即的日志的系统。实时系统就是这样的一个例子，这种系统必须记录故障或攻击的确切时间。一台激光打印机或其他带有数据缓存的设备（如打印机服务器）在缓存突然填满时候可能会丢失数据。从字面上看，“纸介记录”的缺点还有需要保持打印机总联机，并且需要人工检索日志，此外还有哪里能存放可能的庞大数量的纸张的问题。
对上面提到的每个方法而言，都有一个是要保护被记录设备和记录设备（也就是文件服务器、磁带/CD-ROM驱动器、打印机）之间通路的问题。如果这条通路的安全受到了威胁，日志就可以被停止、更改或两者皆有。在理想情况下，记录设备应该附加一条单独的、简单的、点对点的连线。由于这常常是不切实际的，所以我们只要求这条通路通过最小数目的网络和路由器。即使日志可以被截获，我们仍可以使用密码校验（粗看来，或许加密日志并不是必要的，因为它们并不包括敏感信息）来防止虚假信息。
4.6.3 收集的负担
收集审核数据可以导致占用空间急速增长，所以用于这些信息的存储设备必须提前准备好。有一些方法可以降低存储需要的空间。首先有许多方法可以压缩数据。或者，完整数据仅保留很短的时间，只有这些数据的摘要长期保存也可以使需要的空间最小化。后一种方法一个主要的缺点涉及到事件响应，通常，一个突发事件在被站点注意并开始调查之前会持续一段时间。在这时，详细的审核日志将非常有用。如果只有摘要的话，就没有充足的细节帮助我们处理这个事件。
4.6.4 处理并保存审核数据
审核的数据应该是站点和备份中最需要安全保护的数据之一。如果入侵者得到了审核数据的访问权，那么整个系统再加上所有数据就都危险了。
审核数据也是调查、拘捕和检举事件的犯罪者的关键。因为这个原因，当决定怎么处理审核数据的时候去询问法律顾问的意见是非常明智的，这个过程应该进行在事件发生之前.
如果数据处理计划没有在事件发生之前制定好，这可能意味着你在事件后果中没有追索权，并且由于错误的处理这些数据还可能为你带来不利条件。
4.6.5 法律上的考虑
基于审核数据的内容，大量的需要询问法律顾问的法律问题涌现出来。如果你收集并保存审核数据，你就需要准备好根据它的存在和它的内容而分析得到的结果。有的地方会涉及到个人隐私，在一些例子里，审核数据会包括个人信息。一次数据搜索，甚至一次系统安全的例行检查都有可能意味着代表着对隐私的侵犯。
另一个需要我们关心的是来源与你站点内部的扰乱行为。如果一个组织保存了审核数据，那么它有责任经常检查它，搜索可能发生的意外事件吗？如果一个组织中的一台主机被用于向另一个组织进行攻击，第二个组织能要求使用第一个组织的审核数据来证明他的疏忽吗？
上面的例子不可能包罗万象，但是应该可以促使你的组织去考虑审核数据相关的法律问题。
4.7 安全备份
创建备份的过程是操作计算机系统的一个经典部分。在本文的内容中，备份属于站点全面安全计划的一部分。下面列出了关于备份的几个重要的方面：
(1) 确认你的站点创建备份
(2) 确认你的站点使用离线存储设备备份，站点的存储设备要谨慎选择，它应该即安全又有效。
(3) 考虑加密备份，一旦你丢失了它，这样会给你带来的信息保护。要知道你需要一套有效的关键字管理方案，使你能在将来任何时间恢复系统。还要确认你在将来需要解密的时候有权使用必要的解密程序。
(4) 不要总假设你的备份是完好的。在许多的计算机安全事件中，当站点发现的时候它已经发生很久了。这时，受到入侵的系统的备份也会受到感染。
(5) 周期性的校验备份的正确性和完整性。
5. 安全事件处理
本文中的这一章将提供一个以前用过的指导方针，它可以用于主机、网络、站点、或多个站点发生计算机安全事件之时和之后。在计算机安全入侵事件中的有效原则就是按照计划反击，不论这次破坏来源于外部入侵者攻击、无意的损害、一个学生测试了什么攻击软件缺陷的新程序、或是一切都起源于一个不满的雇员。这些可能发生的事件类型都应该提前在相应的意外计划中列出。
传统的计算机安全非常重视整个站点的安全计划，然而常常忽视一旦攻击发生后的处理方法。这样做就导致了当攻击进行的时候许多决定都是匆忙间作出的，从而破坏了应该做的事情，就像跟踪事件的起源，收集用于起诉的罪证，恢复系统的准备和对系统中珍贵数据的保护等。
最重要的却常常被忽视的是，有效的事件处理会带来经济上的益处。让技术和管理人员都来响应紧急事件相当于耗费很多资源。如果能准备好有效的事件处理对策，当它发生的时候就会只用很少的职员时间了。
由于万维网的存在，多数事件都不会局限在单独的站点中。一个系统中的弱点可能存在于成百万的其他系统中，而且许多弱点都利用的是网络本身。所以，尽快通知所有站点的相关人员非常重要。
另一个好处和公众关系有关，计算机安全事故的新闻往往会损害公司在客户和潜在客户的心中的形象。有效的事件处理会最小化这些潜在的负面影响。
有效的事件处理的最后一个好处和法律问题有关。受到攻击的组织很可能不久还要承担别的责任，因为有人通过它的一个节点进行了网络攻击。还有与此类似的一个情况，受到攻击后那些开发补丁程序或工作环境程序的人员却可能被控告，原因是可能由于补丁程序或工作环境的失效从而导致系统出现漏洞，或者干脆就是补丁和工作环境程序破坏了系统。所以，了解系统弱点和攻击模式，然后采取合适的方法防止这些潜在的威胁，是应对这些法律问题的紧急办法。
本章下面的部分提出了创建安全事件处理部分的站点政策的大纲和出发点，即：
(1) 准备和计划（事件处理的目标和对象是什么）
(2) 通知（处理事件时该联系谁）
——本地的经理和职员
——执法机构和研究机构
——计算机安全事件处理小组
——受到影响的相关站点
——内部通讯系统
——公众关系和新闻发布
(3) 识别事件（是不是真的发生了事故，它有多严重）
(4) 处理（当事件发生的时候该怎么办）
——通知（该通知谁发生了事故）
——保护证据和活动记录（什么记录应该在事件开始之前、之间、之后一直保留）
——遏制（怎样能尽量限制损失）
——根除（怎样消除发生事故的原因）
——恢复（怎么重新建立服务和系统）
——继续（事件之后应该干什么）
(5) 结果（过去的事件意味着什么）
(6) 对事件的行政响应
本章余下的部分将详细分析上面列出的每条重要标题，同时还会提出一些关于站点政策中应该包括什么事件处理的内容的建议。
5.1 事件处理的准备和计划
在事故第一次发生之前就进行准备是事件处理的一部分。它首先包括确定一个适当的保护级别，这在前面的章节中解释过。这样做可以在帮助你的站点防止安全事故发生的同时，还能对事故真的发生之后的损失进行限制。准备工作还包括把事件处理指导方针放到你的站点或公司的意外计划中，写好的计划会消除发生意外事件时会遇到的许多混乱，指导你作出更适当和全面的响应。在发生事件之前，通过“演习”测试你要使用的计划是十分重要的。有人至考虑在演习中雇佣一个破坏小组（这个破坏小组用于试图入侵安全系统）。
学会有效的响应意外事件是非常重要的，下面是一些原因：
(1) 保护可能被威胁的财产
(2) 保护可以更好的使用的资源，即使意外事件不需要它们提供服务
(3) 遵守（政府和其他部门的）规章
(4) 防止你的系统被用于攻击其他系统（这会为你招来法律责任）
(5) 最小化潜在的负面影响
任何预先制定的计划都必须注意事件处理的一系列目标，站点会给这些目标设定不同的优先级，为了处理好意外事件要能够确定出明确的目标：
(1) 判断它是怎么发生的
(2) 认识到怎样避免进一步暴露同样的弱点
(3) 避免扩大事件
(4) 评估事件带来的影响和损害
(5) 从事故中恢复
(6) 按照需要更新策略和程序
(7) 查明是谁干的（如果适当且可行）
由于突发事件的特性，问题来源的分析和系统与服务的恢复这两个过程可能会发生冲突。所有的目标（如保证关键系统的完整性）都可能成为无法分析这个事件的原因。当然，这里需要一个重要决策，但所有的相关人员都应该意识到如果不进行分析，那么同样的事件可能会再次发生。
在事件发生之前就确定好事件处理中行动的优先级也很重要。有时候意外事件太复杂了，以至于不可能立即作出所有该响应的事情，这时候就要依据优先级了。虽然不同的机构设定的优先级会不同，但下面列出的优先级的建议可以当作你的公司的出发点：
(1) 第一优先级——保护人类生命和人们的安全，人类的生命永远要比其他考虑更应该优先。
(2) 第二优先级——保护机密和（或）敏感的数据。防止机密和（或）敏感的系统、网络、站点的泄密。及时通知受到影响的机密和（或）敏感的系统、网络和站点已经发生的入侵。（要知道你的站点或政府部门的有关规则）
(3) 第三优先级——保护其他数据，包括私有的、科学的、管理的和其他数据，因为数据是非常贵重的一种资源。要防止它们被其他系统、网络和站点偷取，把发现的成功入侵通知给被影响的系统、网络和站点。
(4) 第四优先级——防止对系统的伤害（如，系统文件的丢失或改变，磁盘驱动器的损坏，等等），对系统的伤害可以导致付出停机时间和恢复所需的昂贵花费。
(5) 第五优先级——将对计算资源（包括处理器）的破坏减到最小。许多情况下最好的方法是关闭系统或断开网络，不要让你的数据和系统冒损坏的危险。你的站点可以在关机或断网和继续运行之间作出权衡。可能会有一些服务条款要求系统发生轻微甚至进一步的事故的时候保持服务运行，但是事故影响的范围很可能远远超乎想象，以至于服务条款不得不被完全结束。
定义优先级的一个重要含义是，当人类生命和国家安全没有问题时，挽救数据通常比保护系统软件和硬件更重要。尽管在事故中受到任何损害或损失都是令人不快的，但是系统还可以重新替换，而数据丢失或损坏（特别是机密的和私有的数据）在任何情况下一般都不是一个可以接受的结果。
另一个值得关心的问题是对他人（远离发生事故的系统和网络）的影响。由于政府规章的制约，尽快通知受影响的团体常常是非常重要的。由于这个问题涉及到法律，所以应该在计划中包括它，从而避免发生更多的拖延和管理员们的犹豫不决。
任何一个响应安全事件的计划都应该遵守地方政策和规章。政府和私人站点对于处理机密材料有特别的规则，我们必须遵守。
你的站点的对付突发事件的政策将决定你的响应。比如，如果你的站点没有计划对被发现的入侵者采取行动，那么创建监视并跟踪入侵者的机制就可能没有什么用。其它的机构采用的政策可能会影响你的计划，比如电话公司经常只向执法机关提供电话记录的信息。
事件处理会很单调，并且需要一些需要人工处理的例行任务。为了从这些工作中解放技术职员，安排一些进行诸如影印、传真之类工作的协助人员可能会很有帮助。
5.2 通知和联系人
在发生真正的事故之前建立和不同人员间的联系是很重要的。许多时候的事件并不是很紧急，甚至你经常能够在内部处理它们。然而还有许多时候你需要在事件处理时包括你的其他一些外部的相邻部门。这时附加的联系会包括本地管理者和系统管理员之间的，internet上同其他站点之间行政性的，和不同研究组织的。在事件发生之前得到这些联系方法会使你的事件处理更有效。
每种联系都要确定一个明确的“联系人”(POC)。这是技术上和管理上的需要，也是法律及研究部门和服务的提供者及用户的需要。当建立这些联系之后，重要的就是决定通过每一级联系要共享多少信息了。特别重要的是尽快确定什么信息可以分别被站点的用户、公众（包括媒体）、和其他站点所共享。
因为通知其他人是一种个人责任，所以解决这些问题对于事件处理中本地的个人责任尤其重要。一个每种联系的列表对这个处理事件的个人来说是重要的节约时间的方法，当许多紧急情况发生的时候找到要找的人也会非常困难。所以我们强烈建议所有的有关电话号码（也包括电子邮件地址和传真号码）应该记载在站点安全政策中，并且处理事件直接相关的个人的姓名和联系信息也应该放在这个列表的最上面。
5.2.1 本地的经理和职员
当意外事件发生时，一个主要的问题是决定谁来负责协调大量的工作者的劳动。常见的错误是让许多人互相独立的进行工作而不是在一起。这只会增加事件的混乱，还很可能导致浪费或无效劳动。
单纯的POC可以是也可以不是负责事件处理的人。POC和事件处理负责人是两个截然不同的角色。事件处理负责人对事件中使用的政策进行解释，并据此作出决定。相反的，POC必须协调所有和事件处理相关的职员的努力。
POC必须是一个具有专业技术的人，他要能成功的协调系统管理者和进行监视或回应攻击的用户的工作。确定这个人是谁需要格外留意，他不需要和对被攻击系统的管理者是同一个人，因为这样的管理者常常只会日复一日的使用计算机，而没有更高深的专业技术。
POC的另一个重要功能是与执法机关和其他外部机构保持联系，从而形成多公司的联合。联合的程度决定于管理者的决定和法律约束。
单纯的POC也应该是唯一负责收集证据的人，因为根据经验，接触一个潜在证据的人越多，它在法庭上不被认可的可能就越大。为了确保证据可以被法律团体接受，证据收集应该遵从预先制定的和地方法律及法规一致的程序。
POC的一个最重要的任务是协调所有的相关过程。它们可以分布在整个站点，包括各种独立的部门或小组中，让这些过程都成功需要很好的协调。如果设计到多个站点情况会变得更加复杂。当这样的事情发生的时候，只靠某个站点中的一个POC很难充分的协调整个事件的处理。这时相应的事件响应组就应该担任这个工作了。
事件处理过程应该提供一些升级机制。为了确定这样的机制，站点需要创建一个事件的内部分类计划。和每一级的事件相关联都应有相应的POC和过程。当事件逐步扩大时，POC也会改变，这个改变需要通知所有其他相关的事件处理人员。当POC的发生变化时，旧POC应该相信新POC的所有背景信息。
最后，用户必须知道怎样汇报可疑事件。站点应该建立汇报进程，这个进程应该在工作时间和非工作时间都运行，可以使用BP机和电话进行非工作时间的汇报。
5.2.2 执法机构和研究机构
在一个引起法律后果的事件中，尽快建立同法律机构（如FBI和美国情报局）的联系非常重要，同时也应该通知地方法律机构、地方安全办公室和校园警察部门。这一节描述了许多要面对的问题，但是被大家承认的现实是每个组织都有它自己的局部和政府的法律法规，这将影响到它们同执法机构及研究机构的相互作用。这里最重要一点的是每个站点都要解决这些问题。
在事件发生之前考虑好联系人的主要原因是一旦重大的攻击发生了，将会没有时间让这些机构确定需要联系谁。另一个原因是有礼貌的与这些机构合作是很重要的，这样会培养一个好的工作关系并严格按照这些机构的工作进程办事。提前知道办事的手续和得到你需要的联系人是这个方面工作的重大的一步。举个例子来说，收集可以被随后的法律行动中接受的证据是非常重要的，这就需要提前知道怎么收集这样的证据。最后一个尽快建立联系的原因是不可能知道哪个机构将负责管辖还未发生的事件，尽早的进行联系并找到合适的联系通道会让你响应事件时更加平稳。
如果你的组织或站点有律师，在你得知事故发生之后立刻通知他们。至少你的律师可以保护你的站点或组织的法律和财政的利益。这里有许多法律的和实际的问题，其中的一些是：
(1) 你的站点和组织是否愿意为了法律起诉而冒受到负面爆光的风险。
(2) 下游责任——如果你为了监视而保持系统被入侵的状态，有可能会有另一台计算机受到来源于你系统的攻击而被损害，你的站点或组织可能会为这些损害而负责。
(3) 信息发布——如果你的站点或组织发布这样的信息，可能涉及到其他站点或组织的一次攻击，或者可以影响一种产品的市场销售的一个产品缺陷。你的站点或组织就也有可能为所有的损失（包括名誉损害）负责。
(4) 监视带来的责任——你的站点或组织可能会被用户所控告，原因是他们在你的站点或其他地方发现你在监视用户的行动却没有让他们知道。
不幸的是，关于安全事件中涉及的职责和责任现在还没有一个清楚的惯例，也还没有人进行过相关的研究。调查人员常常鼓励公司帮助他们跟踪并监视入侵者。事实上，如果没有相关组织的广泛支持，多数调查人员无法追踪电脑入侵者。但是调查人员无法从责任上要求这些，而这种要求的被通过会是旷日持久，且非常困难。
另一方面，组织的法律顾问可能会对这样做提出极端的警告，他们会建议停止跟踪行为，并把入侵者关在系统之外。这样事实上没有提供任何责任上的保护，同时还阻止了调查人员把犯罪者抓出来。
提供入侵行为以供研究和限制自己的责任，实现这两者的平衡是一件错综复杂的事情。在具体的事件中决定该怎么做的时候，你需要考虑法律顾问的建议和入侵者带来的损失（如果有的话）。
当事件发生在你的站点时，你的律师应该参与在你同研究部门的联系中做出的任何决定。你的站点或组织同研究部门协商的决定必须是最适当的。让律师参与还会促进你的站点同涉及的专业研究部门之间的多级协同，最终得到有效的劳动分工。另一个结果是你很可能会从中获得知道，从而帮助你避免未来的法律错误。
最后，你的律师还应该评估你的站点订好的事件响应的手续。这实际上是在你真正实行这些手续前从法律角度提供一个“健康说明书”。
和研究机构打交道的时候一件重要的事是确认发出提问信息的人的确是对方公司的合法代表。不幸的是，如果打电话的人冒充政府机构代表的话，许多出于好心的人会不经意的泄漏事件的敏感细节，或让未经授权的人进入他们的系统，等等，（注意：这个警告适用于所有的外部联系。）
一个类似的考虑是使用安全的通讯手段。因为许多网络攻击者可以轻易的让电子邮件改道发送，所以避免使用电子邮件同其他机构（附近的其他处理事件的机构）通讯。无安全保障的电话线路（电话通常只用于商业用途）是网络入侵者更频繁瞄准的目标，所以一定要小心。
当地方政府卷入的时候，没有什么确定的惯例来响应事件。通常（在美国）除了使用法律命令以外，没有机构能强制你监听，从网络中断开，或禁止同攻击嫌疑犯电话联系，等等。在进行事件处理时，每个组织都有一套必须遵守的地方和国家法律法规。我们建议每个站点都应该熟悉这些法律法规，同时确认并联系上事件处理中可能负责管辖的部门。
5.2.3 计算机安全事件处理小组
现在有许多计算机安全事件响应组（CSIRTs），比如应急处理协调中心，德国DFN-CERT，和遍布全球的其他小组。这些小组存在于许多主要的政府机关和大公司中，如果周围存在这样的小组，在事件发生的早期就应该首先考虑通知它。这些小组的责任就是从整个站点和更大的机构的范围协调计算机安全事件。即使这个事件可以确定只发生在一个单独的站点中，通过一个响应组得到的有用的信息也可能有助于充分解决这个事件。
如果可以确定是由于系统的硬件和软件缺陷引起的入侵，应该尽快通知厂商（或供应商）和某个计算机安全事件处理小组。因为许多其他的系统也同样有这个漏洞，所以这样做是非常重要的。厂商和响应组会帮助你把消息传播到其他相关站点去。
设置事件处理的站点政策时，建立一个专门的小组是值得的。许多这样的小组已经存在了，他们负责为站点（或组织）处理计算机安全事件。这样的小组被建立以后，最重要的事情就是打开这个小组和其他小组的之间的通讯线路了。如果没有这条线路，一旦发生了突发事件再临时建立和其他小组的可信的对话将非常困难。
5.2.4 受到影响的和相关的站点
如果事件影响到了其他站点，立刻通知他们是一个好习惯。有的在一开始就可以发现事件的影响不仅仅限制在本地站点，其他的可能随着进一步的分析才逐渐显现出来。
每个站点都可以选择是直接联系其他站点，还是把消息交给一个合适的事件响应组。通常找到远程站点负责的POC是非常困难的，但是事件响应组能很容易的通过已经建立好的通道联系他们。
安全事件中的法律和责任问题因站点的不同而不同。重要的是在事件发生之前确定好关于其他站点的共享和日志信息的政策。
关于特殊人群的信息是特别敏感的，而且可能关系到隐私法律。为了避免在这里出问题，应该随时删除无关的信息并制定如何处理残存的信息的办法。这些信息用于干什么需要一个清楚的小结，这是问题的实质。发生安全事件的站点在通知别人时，都不愿意在公众媒体上读到这些。事件响应组在这个问题上就很重要了，在他们把消息传送给各站点负责的POC时，他们可以用匿名来保护举报源。但是要知道许多情况下，通过在其他站点上对日志和信息的分析可能会显示出你站点的地址。
所有上面讨论的问题都不能成为不通知受影响的其他站点的理由。事实上，现有的响应组的经验表明多数被通知发生安全问题的站点甚至都不知道他们的站点已经被攻击了。没有这些及时的消息，其他站点就无法针对入侵者采取行动。
5.2.5 内部通信
在重大事件发生时，说明为什么要采取一定的行动和希望职员（或者部门）做什么是至关重要的。特殊情况下还需要让职员明白允许（或不能）对外界（包括内部的其他部门）说什么。比如，一个公司肯定不愿看到职员对客户这样回答：“对于系统停工我很抱歉，我们被入侵了不过正在努力解决问题。”如果让他们用事先准备好的回答“对于系统无法使用我很抱歉，我们正在进行维护以提供更好的服务。”
同客户进行通信并订立合作协议的方式应该处理的切合实际而又不敏感，可以通过准备一个核对清单来应付主要的问题。当事件发生时，这个清单可以用作这种特殊环境下的附加意见。
公众关系部门在事件发生时会非常有用，他们应该在所有的计划中到涉及到，当需要同外界的部门和组织联系的时候，他们能提供结构清楚的回答以供我们使用。
5.2.6 公众关系——新闻发布
在美国，报道计算机安全事件的新闻媒体正在数量惊人的增多着。这样的新闻报道随着internet的发展和延伸迅速扩大到其他国家乃至全世界。在当地媒体还没有注意的地方，读者就可以得到远在美国的体验，这些都是需要小心并提前准备的。
一个需要考虑的最重要的问题是什么时候、谁和需要什么代价可以把消息通过新闻发布给普通大众。决定这个问题的时候，还有许多其他问题要考虑。首先，如果站点中有公众关系办公室，让它们来负责新闻是非常重要的。公众关系办公室在发布消息的措辞方面是训练有素的，它们将确保的说站点在事件中和事件后都已经被安全的保护起来了。公众关系办公室还有一个好处是你能坦白的同他们交流，并在持续的新闻关注和POC控制事态的要求之间提供一个缓冲。
如果没有公众关系办公室，新闻的信息发布必须被认真考虑。如果这些信息很敏感，那么只向新闻提供最少的和概况性的信息会有好处，任何提供给新闻的信息可能很快就会被事件的制造者看到。同时要注意错误的引导新闻媒体常常起到相反的作用，并且引起比发布敏感信息更多的伤害。
因为预先很难确定应该向媒体提供什么级别的细节，下面是一些要时刻注意的原则：
(1) 提供较少的技术细节。有关事件的细节可以为别人使用同样的方法攻击其他站点提供足够的信息，或损害事件结束后站点起诉罪犯的能力。
(2) 把个人看法排除在新闻声明之外。对引起了这个事件的人或动机的思考很可能会发生偏差，从而对这个事件产生错误观点。
(3) 协助执法人员保护证据。如果涉及起诉的话，确保收集证据的过程不泄露给媒体。
(4) 在你准备好之前，不要被媒体强行采访。著名的流行新闻是“2 am”采访，这样做的目的是抓住被访问者没有警惕的时候，从而获得其他方法无法得到的信息。
(5) 不要让媒体对贬低事件的处理方法感兴趣。要记住成功的结束这次事件是最重要的。
5.3 识别一个事件
5.3.1 它是真的是事件吗？
本节讨论是否真的存在什么问题。当然，病毒感染、系统入侵、恶意用户等等都会伴随着许多异常现象，比如硬件故障或者可疑的系统/用户行为。为了判断这是不是真的发生了事件，取得并使用有效的探测软件常常是很有帮助的。审核信息也是非常有用的，特别是检查这是否是网络攻击的时候。一怀疑什么东西出问题就做一张系统的快照是非常重要的。许多事件会导致发生动态的事件链。最初的系统快照将是最有价值的鉴别问题和攻击来源的工具。最后，做一个日志簿也会是非常重要的，它记录系统事件、电话交谈、时间戳等等。它可以促成更迅速和系统的对问题的鉴别，同时它是后来要进行的事件处理的基础。
有一些发生了事件的确定迹象或“症状”需要我们格外注意。
(1) 系统崩溃
(2) 新的用户帐号（比如意外的发现RUMPLESTILTSKIN的帐号被创建了）或者以前的低级帐号进行了高级的活动。
(3) 新文件（经常会伴随着异常或怪异的文件名，就像data.xx、k或.xx这样）。
(4) 自相矛盾的记录（在UNIX系统中你可能会注意到一个存放记录的压缩文件/usr/admin/lastlog，有时它能让你怀疑出现了入侵者）。
(5) 文件长度和日期的变化（如果在MS-DOS计算机中的一个.exe文件无缘无故的多了1800个字节，用户当然会产生怀疑）
(6) 试图修改系统（一个系统管理者注意到VMS系统中的一个特权用户试图改变文件RIGHTSLIST.DAT）
(7) 修改或删除数据（文件突然消失了）
(8) 拒绝服务（系统管理员和所有其他用户都被UNIX系统锁定，此时系统只能处于单人模式）
(9) 无法解释的系统性能降低
(10) 异常（“GOTCHA”显示在控制台上或频繁发出莫名其妙的“哔哔”声）
(11) 可疑的试探（大量的来自同一个节点的失败登录企图）
(12) 可疑的浏览（有的人成为UNIX系统中的root用户后会一个接一个的访问其它用户帐号的文件）
(13) 由于用户的帐号被更改了，他或她无法登录。
上面的列表并不全面；我们只是列出了一些常见的现象。最好结合上其他的技术以及计算机安全人员的看法，最终决定是不是真的发生了一次事件。
5.3.2 事件的类型和范围
在鉴别事件的同时还要评估它的范围和影响。正确的界定事件的范围是非常重要的，它可以帮助我们有效的处理它，并且按照优先次序响应。
为了确定范围和影响，需要定义一套与站点和可用连接类型适合的标准。它包括以下的一些问题：
(1) 这是一个多站点事件吗？
(2) 这个事件影响了你站点中的多台计算机吗？
(3) 涉及到敏感信息了吗？
(4) 事件中你的站点从哪里被突破（网络、电话线、本地终端等等）？
(5) 媒体介入了吗？
(6) 这次事件带来了什么相关损失？
(7) 估计用多少的时间解决这个事件？
(8) 事件处理中需要什么资源？
(9) 执法机关介入了吗？
5.3.3 评估损失和影响范围
对事件的损失和影响范围的分析会相当耗费时间，但是可以使我们看到一些事件的本质，并且帮助我们进行调查和起诉。在入侵发生的时候，整个系统和它的组成部分都应该被认为是可疑的。系统软件是最可能被怀疑的目标。充分的准备是能检测到所有可疑系统的变化的关键。它包括使用一种防止篡改的数学方法校验所有来自厂商的存储介质。（见4.3节）
如果假设厂商最初销售的存储介质都是可用的，我们就应该着手进行对所有系统文件的分析，同时注意任何异常并参照所有有关事件处理的团体的行为。许多时候确定哪一个存储备份保存正确的系统状态是非常困难的。考虑一下下面的例子，事件被发现之前可能已经持续了数月或数年，嫌疑犯可能成为了站点的一名雇员或采取其它方法得到了站点的秘密和系统的访问权。无论怎样，在事件之前的准备将决定可能进行什么样的恢复。
如果系统支持集中化的日志（大多数都支持），回到日志中去寻找异常。如果支持进程记录和连接时间记录的话，就去寻找系统使用的模式。至少磁盘的使用就可以把事件过程清楚地显示出来。记录可以提供许多对分析事件和最后起诉有用的信息。你对一个特殊事件的全部方面的控制能力依赖于成功的分析。
5.4 事件处理
有些步骤是事件处理中必须采取的。在所有的安全相关行为中，最重要的一条是所有站点都应该有适当的政策。没有确定政策和目标，采取的行动就会没有重点。应该由管理者和律师提前制定目标。
一个最基本的目标是恢复对被影响的系统的控制，并限制损伤造成的影响。在最坏情况下，关闭系统或把系统从网络中断开可能是唯一可行的解决方案。
由于有关行为非常复杂，所以要尽可能寻求更多的帮助。当试图独自解决问题的时候，由于耽搁或缺少信息可能会造成真正的损害。许多管理员把发现入侵者作为一个对个人的挑战。采取这种方法，在政策中更重要的其它目标就常常会被忽视，比如，试图抓住入侵者比起维护系统完整就显得不那么重要。监视一个黑客的行为是很有用的，但是冒让他继续活动的险不一定值得。
5.4.1 通知的类型和信息交换
当我们已经证实事件正在发生，就必须通知适当的人。怎样完成这个通知对于使事件从技术和情感的立场上都得到控制是十分重要的。为了使问题能被承认和了解，应该记述尽可能多的细节。决定在通知中给出什么样的技术细节需要非常小心。比如，把这种信息交给事件处理小组是很有帮助的，因为他们可以向你提供有用的线索从而根除你站点中的相关漏洞。另一方面，把这些敏感信息放到公共领域（如通过USENET新闻组或者邮件列表）可能潜在地把许多系统置于被入侵的危险之下。不能假设所有读到新闻组的管理员都有修改系统源代码的权限，或都能理解一个采用了足够步骤的建议。
首先，所有对本地或站点之外的职员的通知都应该是清楚明白的。这就需要提供事件信息的每个句子（可能是一个电子邮件的消息、电话、传真、BP机）都清晰、简明和足够确切。当你通知其它会帮助你处理事件的人时，“烟雾”可能只会分割你的成果并制造混乱。如果需要进行工作分工，向每人都提供其他人已完成的成果是很有帮助的。这样做不仅会减少重复劳动，还使人们知道从哪可以获得和他们那部分事件相关的信息。
在交流关于事件的信息时，另一个重要的考虑是事实性。试图通过提供错误和不完整的信息来隐藏事件的某一方面只会阻止对事件的正确分析，从而可能使形势更加恶化。
在向人们通知有关事件的消息时，选择使用的语言将会对信息的接受造成重大的影响。当你使用情绪化的或煽动性的词语时，你会增加事件潜在的损伤和负面影响。在文字和语言这两种交流中保持冷静是非常重要的。
另一个考虑是，并不是所有人都说同样的语言。由于这个原因会产生误解和迟延，特别是如果这是一个涉及到多国家事件时。其它国际性的考虑包括安全事件的不同法律含义和文化差异，然而文化差异不仅是存于国家之间，它们也存于国家内部不同的社交和用户团体间。比如，高校系统中的管理员对通过telnet试图连接系统并不在意，但是军用系统的管理员很可能把同样的行为当作一次可能的攻击。
另一个关于语言的问题是怎么写对非技术和站点外人员的通知。正确的描述事件而避免不适当的恐慌或混乱非常重要。因为对非技术人员形容一个事件更困难，所以它也常常更重要。非技术描述可能会需要高级管理人员，媒体，或执法人员。这些交流的重要性不能被低估，就是它造成了适当解决事件和使损失继续扩大之间的区别。
如果一个事件响应组介入了，可能会需要填写一个信息交换的模板，尽管这看上去像是多余的负担并产生了延迟，但是它帮助了小组按照这些最小化的信息进行行动。响应组可能能够对本地管理员没有发现的事件的方面作出反映。如果要把信息交给别的什么人，至少应该提供以下内容：
(1) 日志的时区，格林尼治时间或本地信息
(2) 远程系统的信息包括主机名，ip地址和（可选）用户ID
(3) 所有远程站点的相关日志
(4) 时间类型（发生了什么，应该注意什么）
如果本地信息（也就是本地用户ID）包括在日志里，提前把它们从日志中清除以避免隐私问题是必要的。通常所有的可能援助远程站点解决事件的信息都应该给出，除非本地政策禁止这样做。
5.4.2 保护证据和活动日志
在你响应事件的时候，会记录所有和事件相关的细节。在你剖析事件的过程时，这样做会给你和其它人提供有价值的信息。记录所有的细节最终会节约你的时间。例如，如果你不记录每一个相关电话，你很可能会忘记你得到的一部分重要信息，这将会使你不得不再次联系这些信息的来源。同时，记录细节还会提供起诉时所用的证据，促使情况向好的方面发展。记录事件还会帮你完成损失的最终评估（有时你的经理和执法部门会想知道），还会作为事件处理下一阶段的基础：根除，恢复，继续的“吸取教训”。
在事件的最初阶段，常常无法确定起诉是不是可行的，所以你应该像在收集法庭证据一样进行记录。起码你应该记录下：
(1) 所有的系统事件（审核记录）
(2) 你采取的所有行动（时间标记）
(3) 所有的对外会话（包括和谁会话，日期和时间，会话的内容）
最简单的维护文件记录的方法是保存一个日志簿。它可以让你在需要的时候得到一个集中管理的、时间排序的信息来源，而不需要你翻阅单张的记录。多数这样的信息都是潜在的法庭中的证据。因此，当可能发生法律程序的时候，一个人应该遵循事先准备好的程序，从而避免由于不适当地处理可能的证据而在法庭上受到损失。如果合适的话，应该采取下面的步骤：
(1) 有规律的（例如每天）制作复印的、标记的日志副本（和你用于记录系统事件的存储媒介）交给档案管理人
(2) 管理人应该把这些副本保存在安全的地方（例如保险箱）
(3) 当你递交存储信息的时候，你应该从档案管理人手里得到一个带签名和日期的收据
不遵守这些过程会导致你获得的证据在法庭上失效。
5.4.3 遏制
遏制的目的是限制攻击的范围。遏制的一个关键步骤就是作出决定（比如，决定是不是关闭系统，断开网络，监视系统或网络活动，设置陷阱，禁止像远程文件传输这样的功能，等等）。
有时这样的决定是微不足道的，例如，如果信息是机密的、敏感的或私人的，关闭系统的决定是理所当然的。要记住当事件发生时，取消所有的访问权会明显的通知所有用户（包括有嫌疑的用户），管理员已经意识到了问题，这对调查会产生不利的影响。在有的情况下，管理员会谨慎的及时取消所有的访问权和功能，然后恢复受一定限制的正常操作。而在其它情况，如果让系统继续运行能够使你识别出入侵者，就值得让系统冒受伤害的危险。
这个过程将涉及到对预定程序的执行。例如你的组织或站点应该确定在处理事件中可以接受的风险，并据此指导特殊的行为和策略。当需要迅速决定又不可能先联系相关团体进行讨论的时候，这样做会特别重要。没有事先定好的程序，负责处理事件的人常常很难作出决定（比如，他们一般都会选择关闭系统而失去有价值的监视结果）。在事件处理的这个步骤里，最后要做的是通知适当的权威人士。
5.4.4 根除
一旦事件被成功遏制，这就是根除它的起因的时候了。但是，在这之前需要认真的收集关于被入侵系统的所有必需信息和引起事件的原因，因为清除系统之后它们很可能就丢失了。
软件可以在根除的过程中起作用，像anti-virus软件。如果发现了伪造的文件，在删除它们之前先保存。在被病毒感染的情况下，清除并重新格式化包含感染文件的存储媒体是非常重要的。最后，确认所有的备份都是干净的。许多感染过病毒的系统会周期性的再次被感染，就是因为人们没有系统的根除备份中的病毒。根除之后，应该进行一次新的备份。
一旦发生事件，移除所有的漏洞是非常困难的，移除漏洞的关键是知识和对漏洞的了解。
我们可能需要回到存储媒体最初购买的状态，并重新定置系统。为了应付这种最坏的情况，我们应该维持一份最初系统设置和每次改变定制的记录。在基于网络攻击的情况下，为每个操作系统被发现的漏洞安装补丁是很重要的。
像5.4.2节讨论过的一样，安全日志在这个移除漏洞的阶段是非常有价值的。日志可以显示事件是怎么被发现和遏制的，它以后可以用于帮助判断特定事件损害的范围，安全日志中采取的步骤可以将来用于确保同样的问题不会再发生。理想情况下，它应该自动并有规律的执行同样的用于检测安全事件的测试。
如果发现了一个特殊漏洞正在被利用，接下来的步骤就是寻找一个能保护你系统的机制。安全邮件列表和公告将是一个搜索信息的好地方，你也可以从事件响应组那里得到建议。
5.4.5 恢复
一旦事件的起因被根除，恢复就是下一步要做的了。恢复的目标是使系统返回正常状态，通常按照需求的顺序提出服务可以减少用户的不方便，这是最好的习惯。要知道正确的系统恢复过程对于站点是非常重要的，也该是有效的。
5.4.6 继续
当你相信你的系统恢复到了一个“安全”状态时，仍然可能有漏洞或者陷阱潜伏在你的系统里。“继续”过程是事件响应中最重要的过程之一，也是最容易被忽视的。在继续过程里应该监视系统在清除过程中可能遗漏的地方，利用一些第7章提到的工具作为出发点会比较谨慎。要记住，这些工具并不能代替持续的系统监视和好的系统管理经验。
继续过程里最重要的步骤是进行事后分析。到底发生了什么，在什么时候？在事件中相关职员表现的如何？职员们需要快速获得哪种信息？他们怎样及时得到这些信息？下次他们应该有什么不同？
在事件之后，谨慎的做法是写一份记述事件准确次序的报告：发现的方法、改正的过程、监视的过程和得到的教训的摘要，它可以帮助我们清楚地认识问题。因为法律的原因，建立整齐的事件表（包括时间戳）也是很重要的。
由于许多原因，继续过程的报告是有价值的。它提供了可用于类似事件的参考，尽快获得事件引起的损害数量的货币评估也是非常重要的。评估应该包括和任何软件、文件相关的损失（特别是被公开的珍贵的私人数据），硬件损失，恢复被改变的文件所花的人力，重新配置受到影响的系统，等等。这个评估还可以成为后来起诉行为的基础，报告也可以协助证明一个组织的计算机安全管理行为是正当的。
5.5 事故的后果
当发生事故的时候，应该采取一些措施，这些措施可以概括为以下几点：
(1) 对系统资产列一个清单（如，仔细检查确定系统是如何被事故影响的）
(2) 从这个事故中学到的教训应该包含在修改过的安全规划中，以便防止再次发生此类事故。
(3) 根据事故开发新的风险分析机制。
(4) 如果值得的话，对引起事故的个人着手进行调查和惩罚。
如果事故是基于糟糕的策略，那么除非策略改变，过去的错误一定会被重复。一旦站点从事故中恢复，站点的策略合成需要重新审视，做出适当的改变来防止相同的事故。甚至没有事故发生，有规则的审查站点策略和程序也是谨慎的。根据现在的计算机环境变化情况，这种审视是势在必行的。
这种事后处理的所有目的就是要提高系统的安全措施，使得站点免于将来的攻击。作为事故的结果，一个站点和组织应该从此次经理中学到实际的知识。事后处理的一个更具体的目标是发展新的前慑性的方法。另一个方面可能是终端用户和系统管理员受到教育防止这种安全问题的再次发生。
5.6 责任
5.6.1 不要越线
保护自己的网络是一件事情，但是假设应该保护别人的网络就是另一回事了。在处理一个事件的时候，一个人自己的系统和他人系统的某种弱点就变得很明显了。追踪入侵这是很容易的甚至看起来很诱人。但是要记住的一点就是，你可能会“越线”，可能动机是很好的，你却变得不比一个入侵者好到哪里去。
在涉及到个人所有权的时候，最好的规则就是不要使用远程站点上不公开的工具。这显然要排除任何进入一个系统的可能入口。在一个安全入侵被探测到时，一个系统管理员可能会有想法来“跟踪它”，以便确定它能对远程的站点做什么伤害，这看起开很有诱惑，但是，不要去做！而是去到受影响站点的合适地方为止。
5.6.2 Internet的好公民
在一个安全事件中一个人有两种选择。首先，一个站点可以选择观察入侵这并希望抓住他；或者是站点在事件之后清理干净并且把入侵者关在系统之外。做出这个决定必须要经过深思熟虑。因为如果你选择让你的站点开放可能是一个法律责任，入侵者会用你的站点作为攻击其他站点的跳板。作为一个好的Internet公民，你应该警告其他站点他们可能会被入侵。这些站点在对你的日志文件做充分的分析后会做出准备。
5.6.3 对事故的管理性反应
当用户卷入了安全事故，站点的安全策略应该描述采取了什么行动。违反规则应该被严肃处理，但是确认用户所扮演的角色很重要。这个用户很天真吗？在给这个用户分配安全破坏规则中有错误吗？如果用户只是简单的犯了一个错误，却假设用户是有意引起了这个事故很采取管理性的行动。这时在你的策略中包括适合这种情形的处罚措施可能是比较合适的（如对用户进行教育和谴责），而不是对入侵和系统的误用的行动采取更严厉的措施。
6. 正在进行的活动
这一点从时间上来说，你的站点很有希望开发一个完全的安全策略，并且开发程序用来辅助配置和管理用于支持那些策略的技术。如果你能做好这个安全工作，你就可以舒舒服服的坐着休息了。很不幸，这是不可能的。你的系统和网络并不是一个静态的环境，所以你应该在一个规则的基础上仔细检测那些策略和程序。这里有一些你可以遵从的步骤用来帮助你跟踪你所做的改变，从而你可以做出相应的动作来找到那些改变。下面是一个启动集，你可以用于你的站点。
(1) 提交给那些由各种安全事故相应团队所公布的顾问，比如CERT协调中心的那些人，同时修改你的系统来访被对你的站点技术威胁。
(2) 时刻注意你的设备供应商所发布的安全补丁，得到并且安装所有这些补丁。
(3) 积极的监测你的系统配置以发现任何可能发生的变化，探究所有的异常现象。
(4) 每年（起码）都要审查所有的安全策略和程序。
(5) 阅读相关的邮件列表和USENET新闻组，对于各管理员所共享的最新信息保持敏感。
(6) 有规则的检查策略和程序的一致性。这种审查不能让定义或实现这些策略或程序的人来做，而应该由其他人来做。
7. 工具和存放地点
本章提供了一个可以在Internet上下载的公开的安全技术的简短列表。下面提到的这些很有可能会在本文档发表之前就被替代或者废弃。
有一些列出的工具是用户终端程序（客户端）和它们的支撑系统架构（服务器端）。其他工具是一个普通用户从来不会看到也不会用到的，但是可以被应用软件或者在管理员检测安全问题故障或者抵挡入侵者的时候用到。
一个令人难过的事实是现在没有多少有安全意识的应用软件可以使用。这主要是由对于一个安全架构的需求引起的，这个架构必须首先能使大多数应用软件安全运行。现在在建造这种架构上面下了很大的功夫，以便应用软件能够利用安全的通讯。
下面提到的大部分的工具和应用程序能够在这些站点找到:
(1) CERT协调中心
ftp://info.cert.org:/pub/tools
(2) DFN-CERT
ftp://ftp.cert.dfn.de/pub/tools/
(3) 计算机操作，审查和安全工具(COAST)
coast.cs.purdue.edu:/pub/tools
要注意的很重要的一点就是，包括CERT和COAST在内的很多站点在Internet上都有镜像。在使用一个“人所共知”的镜像站点来检索软件的时候要小心，使用认证工具(md5校验，等等)来验证这个软件。有些聪明的黑客可能公布一些安全软件，它能够对系统和数据进行访问。
工具
COPS
DES
Drawbridge
identd (not really a security tool)
ISS
Kerberos
logdaemon
lsof
MD5
PEM
PGP
rpcbind/portmapper replacement
SATAN
sfingerd
S/KEY
smrsh
ssh
swatch
TCP-Wrapper
tiger
Tripwire*
TROJAN.PL
8. 邮件列表和其他资源
把所有的有关站点安全的邮件列表和其他资源都列出来是不可能的。然而，这些资源是一些“起始点”。所有这些参考都是在INTERNET上的，更多的专门的资源也可以通过这些参考得到。
邮件列表
(1) CERT(TM) 顾问
邮件发送到: cert-advisory-request@cert.org
邮件正文: subscribe cert
它提供怎样获得补丁和著名的计算机安全问题的信息。CERT协调中心和供应商一起来开发一个问题的工作区和补丁，并且直到它们可用的时候才会公布有关弱点的信息。CERT顾问也可能警告顾客有关正在进行的攻击(如"CA-91:18.Active.Internet.tftp.Attacks")。
CERT顾问也有USENET新闻组：
comp.security.announce
CERT顾问的文档可以通过匿名FTP得到，在 info.cert.org 的 /pub/cert_advisories 目录。
(2) VIRUS-L 列表
邮件发送到: listserv%lehiibm1.bitnet@mitvma.mit.edu
邮件正文: subscribe virus-L FIRSTNAME LASTNAME
VIRUS-L 是一个比较适中的邮件列表主要集中在计算机病毒方面。
(3) Internet 防火墙
邮件发送到: majordomo@greatcircle.com
邮件正文: subscribe firewalls user@host
防火墙邮件列表是防火墙管理这和实现者的论坛。
USENET 新闻组
(1) comp.security.announce
The comp.security.announce 只是用来给CERT顾问发布信息的。
(2) comp.security.misc
它是一个讨论计算机安全的论坛，尤其是UNIX操作系统相关的。
(3) alt.security
它也是一个计算机安全的论坛，象车锁和警报系统等问题。
(4) comp.virus
它主要是是关于就计算机病毒的新闻组。
(5) comp.risks
它主要是有关计算机和相关系统公开的危险性的新闻组。
WWW 页面
(1) http://www.first.org/
Computer Security Resource Clearinghouse. 主要关注的是计算机相应信息；计算机安全相关的攻击和解决等信息。有时候，它也作为计算机安全信息的一个通用的索引，包括各种广泛的主题，如通用危险性，隐私，合法问题，病毒，担保，策略和训练。
(2) http://www.telstra.com.au/info/security.html
这个参考索引包含一个有关网络和计算机安全的信息的链接的列表。并不能确保所有的都能很好的工作，这些信息只是用作计算机安全技术的教育和合法使用。
(3) http://www.alw.nih.gov/Security/security.html
这个页面由计算机安全的通用信息。这些信息使用每个部分(section)组成的，部分是由主题(topic)组成的。
(4) http://csrc.ncsl.nist.gov
包括了大量和计算机安全有关的声明，程序和文档。
* CERT and Tripwire 在美国专利和商标局注册使用
9. 参考资料
下面的参考资料可能无法在所有的国家内使用
[Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and
McAuliffe, "The Law and The Internet", USENIX 1995 Technical
Conference on UNIX and Advanced Computing, New Orleans, LA, January
16-20, 1995.
[ABA, 1989] American Bar Association, Section of Science and
Technology, "Guide to the Prosecution of Telecommunication Fraud by
the Use of Computer Crime Statutes", American Bar Association, 1989.
[Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery",
Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.
[Barrett, 1996] D. Barrett, "Bandits on the Information
Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
[Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks,
Telecommunications and Data Communications", McGraw-Hill, 1992.
[Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48,
April 1989.
[Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the
Kerberos Authentication System", Computer Communications Review,
October 1990.
[Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings
of the Third Usenix Security Symposium, Baltimore, MD. September,
1992.
[Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M.
Bender, New York, NY, 1978-present.
[Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes",
Dow Jones- Irwin, Homewood, IL. 1990.
[Brand, 1990] R. Brand, "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery", R. Brand, 8
June 1990.
[Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and
the Vulnerability of National Telecommunications Networks to Computer
Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
[BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt,
"BS 7799 : 1995 Code of Practice for Information Security
Management", British Standards Institution, London, 54, Effective 15
February 1995.
[Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of
Information", Proceedings of the Fifth IFIP International Conference
on Computer Security, IFIP/Sec '88.
[Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition,
Butterworth Publishers, Stoneham, MA, 1987.
[Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and
The Law", MIT Press, Cambridge, MA, 1995.
[CCH, 1989] Commerce Clearing House, "Guide to Computer Law",
(Topical Law Reports), Chicago, IL., 1989.
[Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet
Filtering", USENIX: Proceedings of the Third UNIX Security Symposium,
Baltimore, MD, September 1992.
[Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building
Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
[Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet
Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA,
June 1990.
[Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker
is Lured, Endured, and Studied", AT&T Bell Laboratories.
[Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls
and Internet Security: Repelling the Wily Hacker", Addison-Wesley,
Reading, MA, 1994.
[Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation
and Prosecution", U.S. Dept. of Justice, Office of Justice Programs,
Under Contract Number OJP-86-C-002, National Institute of Justice,
Washington, DC, July 1989.
[Cooper, 1989] J. Cooper, "Computer and Communications Security:
Strategies for the 1990s", McGraw-Hill, 1989.
[CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR
Statement on the Computer Virus", CPSR, Communications of the ACM,
Vol. 32, No. 6, Pg. 699, June 1989.
[CSC-STD-002-85, 1985] Department of Defense, "Password Management
Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
[Curry, 1990] D. Curry, "Improving the Security of Your UNIX System",
SRI International Report ITSTD-721-FR-90-21, April 1990.
[Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and
Systems Administrators", Addision-Wesley, Reading, MA, 1992.
[DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem
Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3
November 1988.
[DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin
03", DDN Security Coordination Center, 17 October 1989.
[Denning, 1990] P. Denning, Editor, "Computers Under Attack:
Intruders, Worms, and Viruses", ACM Press, 1990.
[Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With
Microscope and Tweezers: An Analysis of the Internet Virus of
November 1988", Massachusetts Institute of Technology, February 1989.
[Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D.
Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell
University, 6 February 1989.
[Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and
C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford
University Press, NY, 1990. (376 pages, includes bibliographical
references).
[Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS
Security Checker System", Proceedings of the Summer 1990 USENIX
Conference, Anaheim, CA, Pgs. 165-170, June 1990.
[Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley,
Reading, MA, 1991.
[Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial
Tactics and Techniques", Litigation Course Handbook Series No. 280,
Prepared for distribution at the Computer Litigation, 1985: Trial
Tactics and Techniques Program, February-March 1985.
[Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and
Security of Computer Information Systems", Computer Science Press,
1989.
[Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The
Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.
[Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer
Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
Cambridge, MA, 1990.
[Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer
Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
Cambridge, MA, 1990. (192 pages including index.)
[GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer
Security - Virus Highlights Need for Improved Internet Management",
United States General Accounting Office, Washington, DC, 1989.
[Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford,
"Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2,
May 1991.
[Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly &
Associates, Sebastopol, CA, 1996.
[Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford,
"Practical UNIX and Internet Security", O'Reilly & Associates,
Sebastopol, CA, 1996.
[Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law",
Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True
Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell
Publishing, 1996.
[Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and
Social Implications of Computer Networking", Westview Press, Boulder,
CO, 1989.
[Greenia, 1989] M. Greenia, "Computer Security Information
Sourcebook", Lexikon Services, Sacramento, CA, 1989.
[Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk:
Outlaws and Hackers on the Computer Frontier", Touchstone, Simon &
Schuster, 1991.
[Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix
Network Protocol Security Study: Network Information Service", Texas
A&M University.
[Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and
Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages,
includes bibliographical references and index.)
[Howard, 1995] G. Howard, "Introduction to Internet Security: From
Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.
[Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors,
"Protection of Computer Systems and Software: New Approaches for
Combating Theft of Software and Unauthorized Intrusion", Papers
presented at a workshop sponsored by the National Science Foundation,
1986.
[Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security
Techniques", New Riders Publishing, Indianapolis, IN, 1995.
[IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the
Internet", RFC 1087, IAB, January 1989. Also appears in the
Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.
[Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W.
VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly &
Associates, Sebastopol, CA, 1995.
[IVPC, 1996] IVPC, "International Virus Prevention Conference '96
Proceedings", NCSA, 1996.
[Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A
Company Policy on Access to and Use and Disclosure of Electronic Mail
on Company Computer Systems".
[Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The
Ongoing War Against Information Sabotage", M&T Books, 1994.
[Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M.
Speciner, "Network Security: PRIVATE Communication in a PUBLIC
World", Prentice Hall, Englewood Cliffs, NJ, 1995.
[Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software
and Strict Registration Procedures will be Implemented this Year",
Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January
1990.
[Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution",
Delta, 1984.
[Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems
Audit Group, 1996.
[Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin
Mitnick", Little, Brown, Boston, MA., 1996.
[Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure
Communication in Internet Environments: A Hierarchical Key Management
Scheme for End-to-End Encryption", IEEE Transactions on
Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for
Multilevel Security in Computer Networks", IEEE Transactions on
Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
[Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics
in Engineering", McGraw Hill, 2nd Edition, 1989.
[Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal
of Cryptology, Vol. 3, No. 1.
[McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report
Contributors: D. Fester and H. Nugent, Prepared for the National
Institute of Justice, U.S. Department of Justice, by Institute for
Law and Justice, Inc., under contract number OJP-85-C-006,
Washington, DC, 1989.
[MIT, 1989] Massachusetts Institute of Technology, "Teaching Students
About Responsible Use of Computers", MIT, 1985-1986. Also reprinted
in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena
Project, MIT, June 1989.
[Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access
Controls for UNIX-based Gateways", Digital Western Research
Laboratory Research Report 89/4, March 1989.
[Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password
Checker for Unix"
[NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.
[NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention
Policy Model", NCSA, 1995.
[NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96
Proceedings", 1996.
[NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines
for Formal Verification Systems", Shipping list no.: 89-660-P, The
Center, Fort George G. Meade, MD, 1 April 1990.
[NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of
Computer Security Terms", Shipping list no.: 89-254-P, The Center,
Fort George G. Meade, MD, 21 October 1988.
[NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention,
Detection, and Treatment", National Computer Security Center C1
Technical Report C1-001-89, June 1989.
[NCSC Conference, 1989] National Computer Security Conference, "12th
National Computer Security Conference: Baltimore Convention Center,
Baltimore, MD, 10-13 October, 1989: Information Systems Security,
Solutions for Today - Concepts for Tomorrow", National Institute of
Standards and National Computer Security Center, 1989.
[NCSC-CSC-STD-003-85, 1985] National Computer Security Center,
"Guidance for Applying the Department of Defense Trusted Computer
System Evaluation Criteria in Specific Environments", CSC-STD-003-85,
NCSC, 25 June 1985.