【前文说到：“我们可以监视这个日志文件来查看有多少调整是必需的；如果必要的话，增加这个命令的频率。”】
关冲剑─禁用基于xinetd的网络服务
本 文第一节展示的lsof和netstat的输出结果确认了auth、 telnet、vnc等服务是被xinetd互联网络服务进程所执行的。此进程是一个通用的网络进程，它等待那些在选定端口上进入的请求，并执行与那些端 口相关联的服务。Xinetd与许多早期Linux和Unix系统中的inetd相似，但xinetd功能有所增强，并且更加安全和灵活。
最 初引入到xinetd中的一个特性就是TCP封包。这是一个对终端用户的透明库，但却为系统管理员提供了主机能否访问特定网络及相关服务的详细控制。 TCP封包库通过检查/etc/hosts.allow（允许） 和 /etc/hosts.deny（禁止）两个文件是否限制那些在连接建立之前就能访问某个服务的主机。TCP封包被证明是相当有用的，所以现在多数现代 Linux系统发行版本，都将所有的网络进程用TCP封包库进行编译，这包括独立的进程（如sshd）和NFS进程（如portmap）。
所有被xinetd管理的进程配置文件位于/etc/xinetd.d目录。在Red Hat Enterprise Linux中，此目录包含如下的文件：
此目录中包含的文件是文本文件，这些文件包含了每个相关服务的启动指令。每一个文件都包含着一个登录项，用于确认相关的服务在目标计算机上是否被禁用。为了仔细检查哪一个服务被实际上启用了，可以启用如下的命令：
# cd /etc/xinetd.d
# grep disable * | grep no
auth: disable = no
krb5-telnet: disable = no
vnc: disable = no
你 的系统的输出结果可能会与此不同，但应该看起来相似。这显示出auth进程，即 telnet进程的Kerberos增强版本，以及vnc服务器都是由于响应进入相关端口的请求启动的。正如我们前面所指明的那样，我们需要禁用 telnet 和 vnc服务程序，并修改auth进程的行为。本节只解释前者，下一节讲述修改auth进程的行为。
为了禁用服务使其不能被xinetd启动，只需在一个文本编辑器中编辑每一个文件，将每一个禁用项的“no”改为“yes”即可。这个控制文件应是在重启后xinetd所管理的目录中唯一的文件。
下一节讲述如何修改xinetd控制文件，使命令仍可执行但需采用不同的方式。
少冲剑─修改基于xinetd网络服务的行为
正如前面所讨论的那样，我们仍想运行auth进程，但需要改变它，从而使其返回数字型的用户标识符而不是暴露出系统中用户的登录名。Auth进程的xinetd控制文件会是如下所示（已将注释除去）：
service auth
{
disable = no
socket_type = stream
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -t60 --xerror --os -E
}
在这个例子中，我们只想给authd命令加上-n选项，用户可以用自己喜欢的文本编辑器来这实现这一点，修改后的文件看起来会是如下这个样子：
service auth
{
disable = no
socket_type = stream
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -n -t60 --xerror --os -E
}
保存文件之后，下一次运行xinetd时，authd的请求不会再返回和显示用户名，却会返回并显示数字型的用户ID。虽然提供的功能是相同的，但是通过网络暴露的系统信息会更少。
少泽剑─验证网络服务的改变
对系统启动过程和可用服务进行改变之后，最好的检查就是重启系统，然后用我们前面使用的同样的命令检查它，来探索其效能。在重启系统之后，lsof命令会显示如下的信息：
要验证远程系统能怎样看这台样本计算机，只需在远程计算机上，使用nmap来确认只有更加有限的服务对其它计算机是可用的。
这就确认了样本系统对外暴露的程度很小。减少特定系统的可用服务也会带来额外的好处，也就是将服务需要的内存返回到系统自身可用的内存中。
总结
你可以采用的确保网络系统安全的最重大的步骤就是减少打开的端口和系统默认的网络可用服务。本文提供了一些例子，用以清除那些非必要的但却作为启动过程一部分的服务，也清除了那些被计算机上其它进程（如xinetd）所管理的服务。
