Unix操作系统管理客户端

 在Unix操作系统中，可以利用两个文件来统一管理客户端的连接。谁可以访问Unix服务器，都有这两个文件说了算。也就是说，这Hosts.allow与Hosts.deny两个文件就好像是Unix服务器的“看门狗”，它决定了哪些客户端可以访问Unix服务器，哪些则不行。

笔者在描述这两个文件的工作流程时，各位读者不知道有没有注意一个问题。当客户端的信息在两个文件中都没有定义的时候，Unix操作系统服务器最终是否允许连接呢?答案是可以连接。也就是说，Unix操作系统服务器有一个默认的策略，当在以上两个文件中都找不到相关的纪录时，则服务器最终是允许客户端进行连接的。

这就会造成一个安全的隐患。如上面财务管理软件这个案例。企业可能只允许四个财务人员与系统管理员可以连接到财务管理软件服务器。为此Unix操作系统管理员就只在Hosts.allow文件中定义了这五个用户的信息。而在hosts.deny文件中没有定义其他信息。此时采购部的某个用户其能否访问这台Unix服务器呢?首先Unix操作系统会查询hosts.allow文件，发现没有这个客户端的相关信息。此时Unix服务器就会去查询hosts.deny文件的信息。

由于在这个文件中也没有明确定义用户不能够访问Unix服务器，故Unix操作系统又会放行。最后的结果就是采购用户可以访问财务管理软件的服务器系统。这个结果显然跟系统管理员的本意不符。

笔者上面谈到过，这两个文件的处理机制跟思科防火墙的访问控制列表类似。但是在这方面则是一个最大的不同。在思科路由器等网络设备中的防火控制列表，其默认情况下是全部拒绝的。也就是说，如果其前面没有匹配选项的话，则其最后采用拒绝全部用户连接电策略。而现在Unix操作系统对这个两个文件的处理过程则刚好相反。默认情况下，其是允许用户进行连接的。

即如果前面两个文件都没有客户端信息的话，则最终将允许这个客户端连接到Unix服务器中。这显然对于Unix操作系统服务器不怎么安全。为了避免这种情况，笔者建议在hosts.deny文件的尾部最好能够添加ALL:ALL一句。

这个表示默认情况下拒绝所有客户端连接到Unix操作系统服务器中。如此的话，第一个文件定义允许的客户端;第二个文件定义拒绝的客户端(默认情况下为所有客户端都拒绝连接)。这就可以保证只有第一个文件中定义的客户端才可以连接到Unix服务器，就不会有漏网之鱼了。当然这是对于安全要求比较要的企业或者服务器来说。

而对于像文件服务器这种多个部门需要用到的管理软件，则不能够这么设置。因为其默认情况下是所有客户端都可以连接到文件服务器，故要把hosts.deny文件中的ALL:ALL参数去掉。

如果Unix操作系统需要限制某些客户端的连接(如某个员工要离职了，为了防止其对文件服务器中的文件进行故意损坏，就会中断这个员工跟服务器的连接)，则可以以显示的方式在hosts.deny这个文件中加入这个信息。拒绝这个客户端再次连接到Unix服务器中。