安全性是一个庞大和具有挑战性的主题，但每个负责服务器端工作的人都应当知道基本步骤。Cameron 概括了一些使您的用户账户清洁和安全的方法。

　　安全性是一大难题。它不会一成不变，而且很难知道它需要扩展到多大程度：如果您不小心的话，当您的老板真正想要的是不让看门人看到他的年度预算时，您才会最终相信他需要理解安全性的好处。

　　不管在计算安全性的所有方面跟上潮流是多么的具有挑战性，毕竟有几个领域已经足够成熟，值得进行系统地学习。对于任何使用 Linux 服务器的人，我建议他学习的第一个领域是账户管理。

　　注意您的用户

　　在第一批专门介绍 Linux 管理和编程的书籍中，许多都包括关于“用户管理”或“账户管理”的一章。它们的意思非常明确：如何为使用您主机的人设置和维护计算账户和组关系。

　　在那时，“使用”必然意味着“登录”。账户管理的全部工作就是：使用诸如 useradd、chsh 等命令来配置 Linux 账户，以便于由同部门开发人员占多数的用户群使用。/etc/passwd 及其 API 是 Linux 专家的关注重点。

　　那个时代早已成为过去，我对大多数服务器提出的第一个建议就是清除 /etc/passwd 的大部分内容。我的意思是：由于历史原因，大多数电子邮件服务器、Web 服务器、文件服务器等，都用 /etc/passwd 管理它们的用户访问。我认为这通常都是一个错误。在早些时候，当可能有十几个或二十几个工程师共享一台高端工作站时，这是一种明智方式。但是，当一台电子邮件服务器可能要处理几万名用户（他们中的大多数只是把计算当成和饮水器或电话系统一样的公用设施）的邮箱时，传统的 /etc/passwd 方式就是一个错误。

　　依靠 /etc/passwd 当然是可能的。它经历了足够的修补和调整，足以应付令人惊讶的工作量。但不是必须如此。如果您将用户账户移到专门的数据存储，如 LDAP（轻量级目录访问协议）甚至 RDBMS（关系数据库管理系统）数据存储，您可以在可伸缩性、安全性和维护方面受益。将 /etc/passwd 限制为只供少数真正需要登录的开发人员和管理员使用。

　　这一实践在安全性方面有很大好处，因为服务（电子邮件和 Web 等）用户的忙闲度与开发人员的完全不同。一旦您已设置好了一台新的服务器，它的 /etc/passwd 就不应经常更改。监控它是否被更新 — 特别是篡改 — 是一项简单的任务。但是，如果您正在运行一个较大的服务器，那么每天都会有几个新的和过期的电子邮件账户更改。需要将这些账户从 /etc/passwd 赋予的更大的访问权隔离开来。

　　构建一个替代性账户数据存储是一个认真而严肃的建议吗？的确如此，这确实令人惊讶。为了使由无需登录的用户占多数的非常庞大的 /etc/passwds 正常工作，过去几年已经投入了大量的工作。如果您确实决定编写自己的账户认证，并且依靠象 sendmail 这样的传统电子邮件程序，那么您很可能发现自己正在为 SMTP、POP3 和 IMAP4 服务器编写更改。

　　那些障碍常常使开发人员倾向于使用现成的软件。我的习惯是使用别人已编写好而我可以重用的解决方案。但是，与这些业界使用的服务器不同的一点在于：我还是常常需要定制它们 — 例如，设置特殊消息目录、日志记录信息或使用记账。对我来说最重要的一点是使安全性考虑事项模块化。我希望能够将开发人员和管理员账户与最终用户服务完全分开地加以管理。通过将后者从 /etc/passwd 清除，我可以很容易地锁定一方而不会影响另一方。

　　使策略自动化

　　和将开发人员账户与用户服务分开几乎同样重要的是使策略自动化。为创建和删除账户 — 既包括开发人员（/etc/passwd）的也包括最终用户（电子邮件、Web 和数据库等）的 — 建立明确而详细的过程。尽管将这些纳入可执行文件是很好的规定，但并不完全有必要。重要的是过程是可理解的和明确的。不小心的账户创建和删除总是会留下安全性漏洞。应当与人力资源、客户支持或其它相关部门一起检查您的过程。如果不亲身体验替代方案，那么您很难认识到这是多么关键。

　　当您没有为添加和除去用户账号编写过程时，则总会出现这样的结果：假定新员工周一报到，那么他或她可能到周五仍不能访问其公司文件。或者，某人辞职，在假日聚会做了道别，可在二月份开始时仍在检索特殊用途的公司资产。

　　账户自动化一个附带的好处是它鼓励更加彻底的验证。如果开发人员没有用不同特性配置账户的方便办法，他们很可能不会执行那些预计将使配置发生变化的应用程序。

　　我最近亲身经历了这样的情况。我因某个紧急事件而被召来，当时实现小组实际上在“正确地”允许经理查看雇员业绩评审 — 甚至包括那些不属于他们管理的雇员！尽管听起来可笑，但这是典型的安全性问题。它甚至在分析和设计评审期间被指出过几次。虽然每次都向决策者反映了这个问题，但由于它是巨大而混乱的问题集合的一部分，所以它每次都在没有明确决议的情况下被忽略。

　　只有当一位支持专家最终建立起一个一般实例的具体示例（在该示例中有几位经理，每位经理有多份雇员报告）时，错误才得到应有的注意。不要临阵磨枪；要定期对所有种类的用户账户的配置进行彻底的测试。

　　保持警觉

　　安全性最困难的部分，至少对我们中的许多人而言，是如何避免犯错。安全性是属于“最弱环节”事件之一，一个漏洞就可以使您目前的所有投资（不管多么庞大、计划多么周详）一钱不值。要做好安全性工作，您必须对原本不会考虑的事情保持警觉。

　　美国政府网站常常是证明那种挑战的严重程度的最好例子。常在有关“反恐”的安全问题新闻中出现的某联邦机构维护一个网站，在那里用户密码在用于更改用户首选项的页面上公开地显示。相当多的组织解决频繁发生的丢失密码问题的方法是：根据或多或少的公共信息指定密码（例如，“您的密码是您出生地的头四个字母，加上您出生年份的后两位数字”）。

　　如何能避免这样的灾难性错误？遗憾的是，几乎没有系统的方法能“聪明地”成功实现这样的抽象目标。但是，在需要采取的有用步骤中，对 RISKS 文摘的研究和严格的工程检查是有用的步骤之一。

　　RISKS 是 Peter G. Neumann 自 1985 年就一直在编辑的在线时事通讯（请参阅下面的参考资料）。在思考事情（特别是 Linux 服务器上的安全性）的出错原因方面，阅读它是个很好的习惯。Neumann 使该文摘易读而且有趣，当然偶尔会令人恐怖。

　　您还应该养成让其他人试验您的想法的习惯。您可能认为“软件检查”不过是找出开发人员的源代码中放错地方的标点符号的一种方法，但它实际上是非常有趣和高效的实践。特别是，检查是对需求文档、网站和所有其它产品的同行评审进行组织的极佳方法。请进行检查。通过别人的眼睛查看您的工作。您将有可能了解许多关于您服务器的安全或不安全性的信息。

　　结束语

　　参考资料指向更多读物，它们涉及关于加固服务器、Linux 安全性和检查方面的主题。尽管服务器安全性是一个庞大的主题，但您可以快速且少花代价地学习本专栏所描述的方方面面。如果您还没有研究这些方法，那么您应该一试；它们将极大地提高您操作的安全性。

　　(参考链接: http://linux.ccidnet.com/art/737/20070122/1006995_1.html)