你的网络的秘密生活,第 4 部分
在过去的几周里,有很多人要求我考虑在本系列中进行一次小的题外话。经典观点认为,您不应该开启任何您不需要的网络服务,并且在之前的文章中,我已经解释了如何通过您的 /etc/inetd.conf 文件开启和关闭服务。正如一位读者指出的那样,问题在于,在他将系统升级到 Red Hat 7.1 后,inetd 似乎消失了,取而代之的是一个名为 xinetd 的东西。更糟糕的是,事情并没有完全按照他期望的方式工作——在升级到 Red Hat 7.1 后,他注意到他再也无法从他的家庭客户端登录,并且 /etc/inetd.conf 文件也消失了。既然你们,读者,是我的 存在理由,我将从这次关于网络监控的讨论中抽出一些时间来介绍 xinetd。此外,事实证明,我们在这里也做一些监控。
在某种程度上,xinetd 的功能与 inetd 完全相同。我经常将 inetd 的角色比作电话接线员 Lily Tomlin 早些时候扮演的角色。本质上,您呼叫接线员 (inetd),询问您希望与之通话的对象(TCP 端口或服务),如果一切顺利(TCP wrappers 允许您进入),接线员会连接您。但是,如果仅仅是请求服务并建立连接的问题,那么您可能会问,为什么 inetd 会被 xinetd 取代?答案与我们想要密切关注网络上发生的事情的原因相同:安全。
xinetd 具有许多优于旧式 inetd 的增强功能,包括广泛的日志记录功能、对传入连接的限制(以防止拒绝服务攻击)、对本地和远程连接的灵活访问控制,以及更多功能(正如他们在电视上所说的那样)。配置 xinetd 以执行所有这些魔法始于 /etc/xinetd.conf 文件,其中各种服务的定义被分解为以下格式的段落
service_name { attribute assignment_operator value yet_another_attribute . . . etc }
如果您查看您的 /etc/xinetd.conf,您会注意到它可能看起来相当空旷。在我的系统中,有一个标记为“defaults”的部分和一个 include 参数。看看。
defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST only_from = 192.168.22.0 127.0.0.1 } includedir /etc/xinetd.d
defaults 段落(或部分)设置了一些基本内容,这些内容将应用于我系统上的所有服务。文件末尾的 includedir 语句告诉 xinetd 在哪里找到此系统上其他服务的配置详细信息。如果您在 /etc/xinetd.d 上执行 ls,您会注意到 echo、finger、rlogin 和 telnet 等内容——即您的标准网络服务。您不必以这种方式执行此操作。如果您希望在一个地方看到所有内容,则可以将所有服务包含在一个配置文件中。上面的示例恰好是它在我的 Red Hat 系统上设置的方式。
特别注意说明 only_from 的行。xinetd 提高安全性的一种方法是通过绑定机制,该机制使您可以仅对特定接口提供某些服务。换句话说,您可以将 FTP 访问权限开放给 eth0 上的内部网络,但不开放给 eth1 上的外部世界。当您首次安装(或升级)时,您可能会注意到仅允许访问 127.0.0.1。由于我的内部网络位于 192.168.22.0 上,因此我将该网络地址(我的 eth0)添加到 only_from 行。
与更改 /etc/inetd.conf 文件一样,必须重新启动守护程序,您所做的任何更改才能生效。为此,您可以将 SIGUSR1 或 SIGUSR2 发送到 xinetd 进程,您可以通过执行 ps ax | grep xinetd 找到该进程。因此,有两种可能性。您应该选择哪一个?答案是“视情况而定”。发送 SIGUSR1 会执行软重置,而 SIGUSR2 会执行硬重置。在大多数情况下,两者最终是相同的,但是如果您更改 xinetd.conf 并且该更改禁用了服务,则任何现有连接都将被终止;而 SIGUSR1 将重新读取配置文件并将更改应用于新连接。因此,如果我想对 xinetd 进行软重置,这将是我的方法
# ps as | grep xinetd 529 ? S 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid # kill -USR1 529
现在我们已经解决了这个问题,让我们看一下远程 shell (RSH) 的配置文件。在我的系统上,这是一个位于 /etc/xinetd.x 目录中的名为“rsh”的文本文件。
service shell { socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rshd disable = yes }
即使我们在 /etc/xinetd.d 目录中有一个服务定义,但这并不一定意味着该服务可用甚至处于活动状态。最后一行“disable = yes”向我们展示了这一点。要使服务可用,“disable”必须设置为 no。
日志记录呢?好吧,如果我们查看 defaults 段落,它说 log_type 参数为“SYSLOG authpriv”。如果我查看我的 /etc/syslog.conf 文件,我发现 authpriv 内容被记录到 /var/log/secure。
authpriv.* /var/log/secure
如果您希望将所有这些内容都记录到另一个文件中(而不是让 syslog 执行其操作),您可以使用 FILE 参数指定,如下所示
log_type = FILE /var/log/xinetd.log
我们重新启动 xinetd 进程,突然我们正在记录到一个全新的文件。
# tail /var/log/xinetd.log 01/7/18@16:38:03: START: pop3 pid=32665 from=127.0.0.1 01/7/18@16:40:05: START: telnet pid=32671 from=127.0.0.1 01/7/18@16:41:48: START: pop3 pid=32730 from=127.0.0.1 01/7/18@16:43:13: START: pop3 pid=32750 from=127.0.0.1
注意所有 START 标志。如果您还想在服务 EXIT 时记录日志,请更改您的 log_on_success 属性以包含 EXIT 参数。
log_on_success = HOST PID EXIT
就像这样,我们的日志开始变得非常丰富。这很棒,但是如果我们想分离其中一些服务并将它们记录到它们自己的特定位置,该怎么办呢?我喜欢说信息太多刚刚好,但是当您达到刚刚好时,它开始变得有点忙。在一个大型办公室中,我想到的一种相当繁忙的服务是 POP3。
service pop3 { socket_type = stream wait = no user = root server = /usr/sbin/ipop3d log_type = FILE /var/log/ipop3.log
如果,如上所述,我们替换不同的 log_user 参数,则 xinetd 所做的一切仍然会被记录,但 POP3 内容会转到文件 /var/log/ipop3.log 中。
让我们看看其他一些有用的参数。您会记得我说过 xinetd 可以限制给定服务的传入连接数。这是通过 instances 参数完成的。默认情况下,所有服务都提供无限数量的可能连接。如果我希望 pop3 连接不超过 50 个,我会在我的 ipop3 配置文件(或段落)中添加这一行"
instances = 50
您可以设置的另一个有用(且有趣)的事情是使用(您猜对了)banner 属性的连接标语。例如,每当有人使用 Telnet 连接时,我可能希望他们收到一条友好的小消息,祝贺他们并告诉他们他们有多聪明。为此,我创建一个文本文件,其中包含我希望他们在连接时看到的短语(或短语)。然后,我通过添加以下行来修改相应的服务段落或部分
banner = /usr/local/misc/telnet.txt
当我们的用户使用 Telnet 连接到系统时,我们会得到这样的结果
$ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Hey wow, you connected! Aren't you clever?
到目前为止一切顺利?还有更多,但我即将用完每周的电子配额,所以我将开始总结。您可以通过在命令提示符下键入 man xinetd.conf 来获得所有这些出色的配置选项,其中一些我已经提到过,还有一些我没有提到过。如果您还没有 xinetd 并且想尝试一下(作为 inetd 的替代品),您可以访问 http://www.xinetd.org 并获取您自己的副本。
既然我已经向您展示了如何手动配置所有这些,您可能会问,“有没有什么方法可以图形化地做到这一点?”。嗯,是有的。我最喜欢的管理界面之一仍然是 Webmin(我 之前在这个专栏中介绍过)。
这是 Webmin 正在运行的屏幕截图,正在编辑 rlogin 服务。
当我们下次在系统管理员专栏见面时,我们将回到这个网络可视化内容,因为我们试图理解在您的网络上飞来飞去的所有 噪声。在那之前,请记住问自己……如果您不监控您的网络,谁会监控?
正在查找本系列之前的文章? 点击此处查看列表。
电子邮件:ljeditors@ssc.com