服务器评测
在Unix系统中，可以利用两个文件来统一管理客户端的连接。谁可以访问Unix服务器，都有这两个文件说了算。也就是说，这Hosts.allow与Hosts.deny两个文件就好像是Unix服务器的“看门狗”，它决定了哪些客户端可以访问Unix服务器，哪些则不行。
如果Unix系统工程师允许某些计算机可以访问这台服务器则可以在Hosts.allow文件中定义允许访问的计算机。反之，如果系统工程师不希望特定的计算机可以访问服务器，则应该在hosts.deny文件中定义拒绝访问服务器的计算机。当系统的进程在接受来自客户端的服务请求后，Unix系统会先检查Hosts.allow文件，看看是否允许此客户端的访问，如果允许访问的话则会将这个请求转送到特定的服务程序。如果在hosts.allow文件中没有这个客户端允许的纪录，则会检查hosts.deny文件的内容。如果这个客户端的IP地址等信息出现在这个文件中，则客户端的这个请求将会被拒绝。如果没有出现的话，则这个客户端的请求仍然会被转送到特定的服务器应用程序中。这个两个文件的具体工作流程图如下所示：
这两个文件看起来比较简单，其功用却不少。其就好像是Unix服务器的大门，直接跟Unix服务器的安全有关。为此系统工程师应该对这个文件引起重视。具体的说，系统工程师管理这个文件的时候，需要注意以下几点。
1、 两个文件的优先性问题。
在Unix系统眼中这两个文件的地位是不同的。这是系统工程师需要明确的第一个内容。Unix系统会先检查Hosts.allow文件的内容。如果在这里有符合的纪录，则会马上转发这个客户端的请求，而不会去考虑Hosts.deny中的内容。如果系统工程师以前有Cisco网络产品管理的经验，对于这一点就很好理解。因为其工作原理跟思科路由器的访问控制列表工作原理类似。只要在前面的纪录中找到符合要求的项目，则会忽略后续的内容。如现在有一个客户端，其IP地址为192.168.0.4。在以上两个文件中，都有这个客户端的信息。即在前面一个文件中允许这个客户端连接到Unix服务器中，而在后面一个文件中却又禁止其连接。那么这个互相矛盾的设置，哪一个设置更有效力呢?由于Unix服务器是先检查Hosts.allow文件，故最终Unix系统允许用户连接到服务器。
系统管理员不要认为这是Unix系统中的漏洞。其实Unix系统是故意这么设计的。这个特性在实际应用中非常的有效。如某个财务管理软件的服务器，就只允许财务部门的四个员工以及系统管理员可以连接上去。此时就可以把这五个用户的信息放入到hosts.allow文件中，然后在hosts.deny文件中填入ALL内容即可(表示全部计算机都不能够连接Unix服务器)。因为hosts.allow文件优先，故最终Unix系统只允许特定的五个用户可以连接到财务管理软件服务器中，从而提高财务管理软件的安全性。可见这个特性在实际工作中，具有很大的用途。
2、 多个主机的表示方法。
当企业网络中的客户端数量比较多时，如果一个个IP地址去配制的话，工作量会变得很大，而且也缺乏灵活性。为此需要能够提供一个简便的机制，如通过通配符来实现对一组IP地址的管理等等。在Unix服务器系统中，也提供了类似的机制。如在谈第一个问题的时候，笔者已经谈到，可以利用ALL选项来表示所有的计算机。除了利用这个参数外还有几个参数可供系统管理员采用。笔者这里就捡几个常用的重要参数举几个例子，让大家可以了解这些参数的用途。如参数LOCAL，表示不带小数点的主机名;如参数UNKNOWN，代表所有主机名或者IP地址为未置的客户端;如参数KNOWN，表示所有主机名以及IP地址为已知的主机;而参数PRARANOID则表示所有主机名与IP地址不一致的主机等等。这些都是服务器部署时常用的一些参数。注意以上这两个文件对于大小写是敏感的，为此系统管理员要使用这些参数的话，要注意最好能够使用大写字母。
除了使用这些特定的字符串(代表特定的含义)之外，还可以利用子网来表示。如192.168.1.0就表示所有以192.168.1 开头的主机。这里要注意一点，如果想通过IP地址来控制Unix服务器的访问，那么客户端最好就不能够使用DHCP服务器来获得IP地址，即要采用固定的IP地址方案。如笔者企业现在就使用的是IP地址与Mac地址绑定的方案。这虽然刚开始初始化的时候工作量会大一点，但是后续网络维护的工作量到底可以减少很多。而且采用固定IP的话，有很多针对IP地址的安全解救方案也比较容易实现。
故笔者在给企业部署Unix服务器的时候，如果企业有安全方面的要求，那么笔者都会见以企业采用固定IP地址分配方案。
3、 注意默认规则是全部允许访问。
笔者在描述这两个文件的工作流程时，各位读者不知道有没有注意一个问题。当客户端的信息在两个文件中都没有定义的时候，Unix服务器最终是否允许连接呢?答案是可以连接。也就是说，Unix服务器有一个默认的策略，当在以上两个文件中都找不到相关的纪录时，则服务器最终是允许客户端进行连接的。这就会造成一个安全的隐患。如上面财务管理软件这个案例。企业可能只允许四个财务人员与系统管理员可以连接到财务管理软件服务器。为此系统管理员就只在Hosts.allow文件中定义了这五个用户的信息。而在hosts.deny文件中没有定义其他信息。此时采购部的某个用户其能否访问这台Unix服务器呢?首先系统会查询hosts.allow文件，发现没有这个客户端的相关信息。此时Unix服务器就会去查询hosts.deny文件的信息。由于在这个文件中也没有明确定义用户不能够访问Unix服务器，故Unix操作系统又会放行。最后的结果就是采购用户可以访问财务管理软件的服务器系统。这个结果显然跟系统管理员的本意不符。
笔者上面谈到过，这两个文件的处理机制跟思科防火墙的访问控制列表类似。但是在这方面则是一个最大的不同。在思科路由器等网络设备中的防火控制列表，其默认情况下是全部拒绝的。也就是说，如果其前面没有匹配选项的话，则其最后采用拒绝全部用户连接电策略。而现在Unix服务器操作系统对这个两个文件的处理过程则刚好相反。默认情况下，其是允许用户进行连接的。即如果前面两个文件都没有客户端信息的话，则最终将允许这个客户端连接到Unix服务器中。这显然对于Unix服务器不怎么安全。为了避免这种情况，笔者建议在hosts.deny文件的尾部最好能够添加ALL:ALL一句。这个表示默认情况下拒绝所有客户端连接到Unix服务器中。如此的话，第一个文件定义允许的客户端;第二个文件定义拒绝的客户端(默认情况下为所有客户端都拒绝连接)。这就可以保证只有第一个文件中定义的客户端才可以连接到Unix服务器，就不会有漏网之鱼了。当然这是对于安全要求比较要的企业或者服务器来说。
而对于像文件服务器这种多个部门需要用到的管理软件，则不能够这么设置。因为其默认情况下是所有客户端都可以连接到文件服务器，故要把hosts.deny文件中的ALL:ALL参数去掉。如果需要限制某些客户端的连接(如某个员工要离职了，为了防止其对文件服务器中的文件进行故意损坏，就会中断这个员工跟服务器的连接)，则可以以显示的方式在hosts.deny这个文件中加入这个信息。拒绝这个客户端再次连接到Unix服务器中。
