采取针对性措施保障 Unix 服务器的安全

　　通常情况下，我们特别关注特定主机的安全问题，却忘记了整体的网络安全设计。事实上，整个网络的安全设计问题还是与基于主机的安全有些区别的，在此我们不打算就这个问题展开讨论。

　　下面我们可以定义三种类型的服务器，当然根据你的实际需要，这些服务器可以进一步分类。

　　公共服务器，这是一种可以访问互联网的服务器。

　　登录服务器，这种服务器允许非超级用户登录。

　　其它服务器，如MySQL，内部LDAP或NFS服务器，这些服务器只能从内部网络到达。

　　根据我们定义的这些服务器，网络的总体布局和我们要运用的防火墙规则也就显而易见了。

　　问题是我们该如何管理这些服务器，保持其安全性。这是我们设计的难题之一，因为一个脆弱的设计可能就意味着灾难的降临。

　　从一个更的视点上来看，我们知道有些服务器要比其它服务器重要。一个或多个服务器需要被其它的服务器信任，这样才能保证自动化改变的发生。账号的创建，按照Tripwire 或Samhain方式对主机完整性的监视，甚至配置文件的备份都需要从某个服务器配置并维持，而这个服务器能够以根用户身份访问其它服务器。

　　这样一个服务器，我们或可称它为主服务器，只有超级用户账户可用于登录访问。超级用户的口令需要与其它服务器的口令不同，而且这个主服务器不应向外部世界提供服务。公共服务器的损害不应影响主服务器的安全。当一个表面上不重要的机器被损害时，黑客性质的登录会成为一个rootkit的一部分，这又会导致用户账户口令的暴露。这也就是sudo并非一个好主意的原因：它给你的用户口令根目录的访问权限。一个被损害的su可能会泄露根用户的口令，这也就是主服务器如此重要的原因。

　　主服务器应能够以SSH方式并以根用户的身份登录到所有其它的服务器，但只能通过SSH密钥进行。基于口令的根用户的登录不要允许通过SSH进行。如果主服务器被危及到其安全性，那么其它任何一个服务器都会落得同样的下场。因此，主服务器是一个堡垒，只运行SSH服务，并只与其它机器连接。配置文件的备份、主机完整性数据库等都可被存储在主服务器上。

　　可被公共访问的服务器是为脆弱的，原因就在于它们运行的应用程序，但登录服务器也会引起问题，而且它们在许多其它方面也是很脆弱的。其用户，不管是开发人员还是学生、客户，都不太在乎安全问题。他们会运行心目中的任何可得到的应用程序，其中包括SQL服务器，基于PHP的WEB应用程序(只采用安全性很差的安全记录)，以及看起来有用的其它任何东西。为了防止未知用户通过这些程序的漏洞进入系统，你还是为你的操作系统安装的补丁程序。

　　为操作系统打补丁并不是可选的，更不是一件可掉以轻心的事情。必须要反复强调：在一个安全更新可用时，必须为所有的服务器及时更新。对于那些只在周末为UNIX服务器打补丁的用户来说，他们要承担一种严重的责任，因为具有恶意用心的人可以很轻松地获得根目录的访问，因为对于系统漏洞的恶意利用代码出现的速度是极快的。此外还有一些很新的恶意利用;这些都是十分可怕的事情。SELlinux或者一台正确配置的Unix计算机能够在防止恶意利用漏洞方面大有帮助。因此我们认为总体上的安全架构是为关键的。

　　那些不安全的服务器可能允许用户登录。假定我们需要共享的home目录，要支持此处描述的环境可能会很困难。输出到不安全客户端的NFS共享需要仔细检查，特别是当开发人员或研究人员需要其机器上的根目录权。

　　既然NFS意味着无安全性，向一个未被控制的客户端授权访问NFS共享是相当可怕的。实质上，你必须假定在共享文件系统中的任何东西都可能被危及安全，因为在根用户可能会很轻易地SU到碰巧拥有文件的任何人那里。老的标准工作区是要将这些类型的共享移到其自有的分区中，而且将其共享给那些有害的客户端。AFS并不支持企业级特性，因此你不要采用它，而且它本身并不支持快照或兼容的ACL等。

　　我们可以对系统安全提出各种各样的方法和缺陷。从架构的视点来看，一般的观点是用两种方式将风险化：一是使其难于渗入，二是一旦进入系统，应难于扩散。通过采用恰如其分的监控，你应该能够快速地检测任何入侵并能阻止它。

　　不管你有300个还是3000个服务器，基本的原则都是相同的。这看起来简单，在配置一个新的或被破坏的服务器时却是基本的。请记住：

　　在暴露的服务器上尽量地减少服务;

　　尽量地减少暴露的服务器的数量;

　　在给NFS客户端任何权需要极端小心;