学习札记

1.21 学下札记

   摘要： 数据安全   xinetd  openssh

        保护数据安全
 提示：早期的联网协议（TCP/IP协议）为我们提供了一个不可缺少的框架，但是其设计方案中

很少考虑到安全验证和隐私保护。导致了，当今的互联网安全性极差。还好，数学领域中的数字

理论所提供的加密算法、协议和技术为计算机界带来多种联网保安形式。其中就包括：安全验证

、数据完整性保证、以及隐私保护。
     不加密的数据易受攻击；同样因为不安全的传输协议（如telnet FTP 、POP3，不安全的密

码；sendmail、NFS、NIS不安全的信息；rcp 、 rsp，不安全的验证）会导致数据被窃取和篡改

。 
     加密的通讯协议通常有一组加密技术以构建块的形式构成。它通常可以从几个类似的算式

中选择一个来实现某种功能。例如，公钥加密大量使用对称加密。
     红帽企业版产品提供两种不同的密码服务实施方法：
        Gnu Privacy Guard  ，剪成gpg，可用来实现基于文件的加密；保证文件完整性、加密

电子邮件等。
        openssl提供了网络通讯的密码库。
     许多加密常规依赖于随机数字，但很难在电脑生成这些随机数字。一般来说，计算机使用

整数为种子的“伪随机“随机数字生成程序。为提高改进随机数字的生成，内核根据用户事件（

如鼠标动向，键盘输入和磁盘存取操作）来收集”熵池“。两种字符设备允许访问内核的随机数

字工具：
      /dev/random 仅从收集的熵池中生成随机数字。若熵池用完，进程就会被阻塞。（最佳源

）
      /dev/urandom 将会使用熵池知道它被用尽为止，然后退回使用一个伪随机算式。
   openssl 库也提供了一个随机数字生成程序。它可以通过 openssl rand 命令来使用。
单向散列
    单向散列使用被称为”指纹“或”消息摘要“的简单字符串来确保信息的完整性。可用某个

给定的内容来生成一个容易记录的较小指纹以便今后使用。以后，若要校验数据完整性，只需要

重新生成指纹，和前面的那个指纹比对。如果修改了数据，生成的指纹就会改变。此外，数据的

原始内容不能从指纹中推导出来，因此称其为”单向散列“。
    单向散列被经常用来确保文件的完整性。例如，rpm命令使用MD5散列来确保RPM软件包以及

系统上安装的文件的完整性。
对称加密
    对称加密常规提供了最基本的隐私保护。用单一密钥加密数据，从而使”明文文本“无法从

”加密文本“中推导出来。也可用同一密钥解密加密文本。
    对称加密算式还可用来生成单向散列，目的是保护密码安全。用带预订随机字符的用户密码

来为一个固定的文本块加密。其结果和预订随机字符一起贮存为用户密码的”加密形式“。当系

统打算校验用户密码的正确形时。他会加入相应的随机字符，然后在执行加密。如果结果匹配，

用户验证通过。当然用户的密码（对称密钥）从来不直接贮存在系统中。
    红帽企业版默认使用一种强大的基于MD5的算式来保护密码安全。该方法允许长达256个字符

的密码。处于兼容性考虑，也支持DES的方法。gpg和openssl还提供了对称加密协议，由于加密

速度较快，因此经常会在非对称协议内部使用对称加密。
非对称加密
   1 非对称加密，又称公钥加密，依赖于两个互补的钥匙：公钥和密钥。一个钥匙加密，另一

个解密。通常通过某正服务来公开公钥。密钥则需要严守秘密，因此许多协议的安全性要求密钥

仅被其拥有者所有。
    比如：艾丽丝和鲍勃要彼此互相通信。假定鲍勃已经生成一个公钥/密钥对，并且公开了他

的公钥。如果艾丽丝想给鲍勃发送一条私人消息，她就可以使用鲍勃的公钥来加密。艾丽丝可以

从相应的目录中查找鲍勃的公钥，或者让鲍勃发给她。当她将加密的消息发给鲍勃后，只有鲍勃

才有相应的密钥来给消息解密，看到其中的内容。
  2 非对称加密还允许使用数码签名。再看上文虚构的人物，艾丽丝和鲍勃。艾丽丝想给鲍勃发

送一份文档，她想让鲍勃确定该文档的确是她发的，而且在发送过程中，该文档未经任何人改动

。假定艾丽丝生成了一个正确的公钥/密钥对，她会使用密钥为文档加密。在鲍勃收到该文档时

，他会使用艾丽丝的公钥来给文档解密。如果文档解密成功，鲍勃就可确定文档就是艾丽丝发送

的，而且没有被篡改。
   通常会使用非对称加密协议1和2.艾丽丝会首先使用她的密钥为文档签名（加密），然后使用

鲍勃的公钥来加密。鲍勃收到时，会首先使用他自己的密钥给文档解密，然后使用艾丽丝的公钥

解密。这样，双方通信就会同时具有加密传送和数码签名的优点。
   有一个和非对称协议相关的协议叫做”分离签名“。与其直接加密文档，艾丽丝使用一个众

所周知的单向散列(如MD5)生成文档散列，然后她使用自己的密钥为这个散列加密，再将文档原

文和加密的散列都发送给鲍勃。鲍可以直接使用文档，但是如果他想了解文档的真实性，他可以

生成该文档的文档散列，然后和艾丽丝发送给他的加密散列进行比较。
   公钥体系
  发行公钥是非对称加密方案的本质弱点。除了艾丽丝和鲍勃，现在添加一个居心叵测的人物：

马雷特。当艾丽丝想给鲍勃发送一条信息是，她会从公钥目录中查找鲍勃的公钥。然而，如果艾

丽丝不熟悉鲍勃，或者说，艾丽丝不熟悉公钥目录，她就无法保证所受到的公钥的确是鲍勃自己

生成的公钥。马雷特可以非常轻松的生成一个公钥/密钥，然后将公钥作为鲍勃的公钥来发行，

从而冒充鲍勃。
   两种防止劣质公钥的方法：
    指纹  能够确保鲍勃没有被冒充的一种方法是，鲍勃可以生成一个他的公钥指纹（单向散列

），然后将其包括在所有通讯中。当艾丽丝从公钥目录获取到鲍勃的公钥后，她可以从中计算出

指纹，然后和鲍勃的已知指纹进行比对。
   公钥体系
      构建双方彼此信任的第三方，证书授权机构。
    如，虚拟出第三方人物特兰特，充当信任第三方角色。假定特兰特生成自己的公钥/密钥对

，并且签发了他自己的公钥。这个自己的公钥就会被称为”证书签发者的证书“，或”证书授权

机构“，既CA。
    鲍勃，希望能和其他人以安全的方式交换敏感信息。他首先生成一个公钥/密钥，然后令特

兰特确信他的身份，并向他提供自己的公钥。特兰特会将他自己的身份、鲍勃的身份、以及鲍勃

的公钥和有效期合并。然后，他会创建一个单向散列，使用他自己的密钥为这个散列加密，从而

创建一个分离式数码签名。这个信息组合以及分离签名就构成一个数码证书。特兰特会将这个证

书交给鲍勃。特兰特被称为证书颁发者，鲍勃是证书的所有者。
   这是，艾丽丝如果想确认鲍勃的真实性，就会事先从特兰特那获得”证书授权机构证书“。

然后，鲍勃会向艾丽丝提供其证书，艾丽丝会从中抽取分离签名，和她已经获得的CA的证书比较

校验鲍勃的证书。
   生成数码证书
     1 生成公钥/密钥对
       openssl genrsa -out serverkey.pem  1024
     2 生成证书签名请求（CSR），必须建立身份。
       openssl req -new -key  server.key.pem -out server.csr.pem
     3 请求会被发送给CA。有CA来验证身份并签发
       当然也乐意自己签发一个”自签‘证书
        openssl req  -new -key  server.key.pem -out server.crt.pem  -x509
  openssh 总揽
     openssh项目为安全的shell协议。SSH协议族可以用来进行远程控件， 或在计算机之间传

送文件。而实现此功能的传统方式，如telnet(终端仿真协议), rcp(注2)都是极为不安全的，并

且会使用明文传送密码。OpenSSH提供了服务端后台程序和客户端工具，用来加密远程控件和文

件传输过程的中的数据，并由此来代替原来的类似服务。
    OpenSSH服务，sshd,是一个典型的独立守护进程(standalone daemon)，但也可以根据需要

通过网络守护进程(Internet Daemon)-inetd(注3)或Ineternet Daemon's more modern-xinted(

注4)加载。OpenSSH服务可以通过/etc/ssh/sshd_config文件进行配置。本章将介绍此配置文件

中的默认配置，并说明如何修改这些配置来提高sshd的安全性。
   OpenSSH服务的建议设定
      LogLevel INFO 
在默认的设置下，sshd的登录日志以INFO级别写入AUTH系统日志设备(SyslogFacility)。如果

ssh作为你远程控制Ubuntu主机的主要方式，您应该考虑将日志级别由INFO提升为VERBOSE。这样

，在日志中将会记录更多有关登录成功和登录失败的信息。

LogLevel VERBOSE 

这样，所有ssh登录成功信息，和未成功登录的信息都以VERBOSE的日志级别记录在你的AUTH文件

中(/var/log/auth.log)。
 验证
LoginGraceTime 120 

默认设置下，通过sshd登录Ubuntu后，必须在出现操作提示符的120秒(2分钟)内登录系统，不然

sshd将会自动切断与主机的连接。这个时间值可以通过LoginGraceTime进行设置

LoginGraceTime 20 

将LoginGraceTime设置为20秒。可以有效的防御自动化阻遏(thwarting automated)，暴力攻击

ssh，和拒绝服务式攻击(DDOS)。

X11Forwarding yes 

如果你不希望有人能够通过ssh使用图形用户界面的程序(这些程序通过SSH通道-SSH tunnel显示

)，你可以通过X11Forwarding指令将其关闭，由此来减少很多攻击的可能。

X11Forwarding no 

现在，sshd的X11 forwarding功能被关闭了。

 警告: 我们并不推荐关闭X11 forwarding，如果某个服务是基于使用X11或LTSP的，将X11

Forwarding关闭将导致此服务不可用。

#Banner /etc/issue.net 

显示一个不欢迎的警示条，或更好的方法对于安全是件好事。它将告知好奇的人,或者未经许可

的恶意登录到你的OpenSSH服务器的人，远程访问你的计算机是必须经过许可，并且需要用户授

权。
有一个的不欢迎警示条目可以帮你成功起诉攻击者,或别的组织未经许可的尝试经由ssh访问你的

服务器。
Banner /etc/issue.net 
LietenAddress  192.168.0.250:22

 

xinetd 简介
那么 xinetd 是什么？一句话，它就是个程序。处理入站网络连接没什么神奇。可以使用 Perl

、Python 或 Java 来处理。Xinetd 是用 C 编写的，而且它和它的前辈 inetd 一样快，如果不

是更快的话（例如，TCP 封装器不必为每个入站连接而执行；它们在启动时装入内存）。
xinetd 正在开发中。（您的版本可能过时了，所以请务必到主页上查找最新的版本；请参阅 参

考资料。）因为它正在开发中，所以 xinetd 的安全漏洞得以迅速弥补，而不象 inetd 那样薄

弱，通常要很长时间才能弥补。当然，xinetd 是随源代码一起交付的，所以您可以复查源代码

并自己找到可能存在弱点的地方。
如何使用 xinetd 定义服务呢？编写一个服务文件，它除了指定 /etc/xinetd.conf 中所指定的

一般参数之外，还指定特定配置。所以，如果 /etc/xinetd.conf 是这样的：

清单 2，样本 xinetd.conf（标准的 Red Hat 7.1）
defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}
service telnet
{
        flags           = REUSE
        socket_type     = stream       
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}
includedir /etc/xinetd.d

您放到 /etc/xinetd.d 中的每个服务文件都会继承这些缺省值，并指定它自己的参数。这里，

telnet 服务在顶级定义，而不是在子目录中定义。这太棒了，这种模块性允许复杂的配置。
要使 xinetd 重新读取配置文件，不必重新启动它。只要向它发送 USR2 信号即可。
那些参数表示什么意思？让我们通读整个清单。您也可以在命令行下使用 man xinetd.conf 来

查看列表（如果那个帮助页面正确安装的话），但这个概述试图用更简单的术语来解释参数，并

不假定您已经知道关于套接字和服务的所有信息。一些参数（rpc_version、rpc_number）被跳

过。
常规参数
id
该服务的唯一名称。服务名称在花括号之前指定，但是 ID 使逻辑上相同的服务可能拥有多个协

议。这是对于临时用户的受限使用。例如，NFS 服务可以在 UDP 或 TCP 传输协议上运行。在

Red Hat Linux 7.1 上，TCP 版本（在 /etc/xinetd.d/time 中）和 UDP 版本（在

/etc/xinetd.d/time-udp中）中提供了对于 xinetd 来说内部的时间服务。
type
这实际上应该称为“特殊类型”，因为它只适用于特殊服务。它可以是以下几种类型的组合：“

RPC”，用于 RPC 服务（由 SUN 引入的远程过程调用，导致了很多安全性问题，最好避免使用

）；“INTERNAL”，用于构建到 xinetd 内部的服务，譬如时间服务；“UNLISTED”，用于在系

统列表（/etc/services 或用于 RPC 服务的 /etc/rpc）中找不到的非标准服务。
flags
这里放置着所有额外标志。列表很长并且技术性很强；我们感兴趣的标志包括 REUSE（用于套接

字重用，譬如 telnet）、NAMEINARGS/NOLIBWRAP（如果您希望手工调用 TCP 封装器或者完全地

避免使用封装器）、NODELAY/KEEPALIVE（用于调整 TCP 套接字）、DISABLE（覆盖顶

级“disable”参数）以及 SENSOR（用于检测和防止某些类型的“拒绝服务（denial-of-

service）”网络攻击）。
disable
除非您希望禁用某项服务，否则总是把它设成“no”。Red Hat Linux 的 chkconfig 程序将为

您打开或关闭“disable”参数；在 Red Hat 上，用 chkconfig 启用和禁用特定服务可能比手

工方式简单些。请注意，chkconfig 预期在 /etc/xinetd.d/SERVICE 中找到服务文件。所以对

于上面 清单 2 中的示例，chkconfig 将不会在请求时打开或关闭 telnet。可以将它认为是一

个错误或特性，取决于您的观点。
socket_type
通常您希望这个参数设置成“stream”，除非使用 UDP 服务，此时设置成“dgram”。该参数也

可以设置成“raw”和“seqpacket”，但极少见。
protocol
这是连接所用的协议，通常是“tcp”或“udp”，但是在理论上您可以使用来自

/etc/protocols 的任何值。
wait
如果设置成“no”，xinetd 将为每个连接上的服务启动一个新的处理程序。如果是“yes”，

xinetd 预期该处理程序处理所有后续连接直到它死亡。在大多数情况下，这个参数是“no”。
server, server_args
处理程序的程序名，以及它应当获得的参数。处理程序名不应该象在 inetd 环境下那样，出现

在参数中。
port
服务的端口。通常不需要，因为端口通过 /etc/services 文件来映射到服务。
redirect
允许 xinetd 将所有服务的流量发送给另一台主机。因此，受防火墙保护的主机可以通过中央

xinetd 转发器接受安全流量，而不必建立与外部网络的连接。在某些工作中，可以采用这个特

征来在两台主机间执行故障转移服务。
banner, banner_success, banner_fail
一个将要在“任意/一个成功/一个不成功”连接上打印的来自文件的定制文本块。
enabled
在全局级别上补充“disabled”参数和 DISABLE 标志。
include, includedir
告诉 xinetd 要包含文件或目录。
环境参数
user, group, umask, groups
当启动服务处理程序时，xinetd 应该扮演的 UNIX 属性。这主要用于非安全服务。
nice
确定该服务对于系统有多重要的 UNIX 优先级级别。可以针对您的系统调整它，请查看“nice”

的 man 页面。
env
用于服务处理程序的环境变量。
passenv
应该向下传递到服务处理程序的 xinetd 中的环境变量。
资源管理参数
instances
可以同时启动的处理程序数。可以调整这个参数以防止拒绝服务攻击。如果您希望缺省（无限制

）行为，将它设置成“UNLIMITED”。
max_load
I: ) 如果系统过载，停止接受连接。负载数取决于系统，仅当您确实知道自己在做什么时才能

调整它。
rlimit_as, rlmist_cpu, rlimit_data, rlimit_rss, rlimit_stack
rlimit 参数指定用于服务处理程序的资源限制（内存、CPU 以及特定内存区域）。
特定于安全性的参数
only_from, no_access
对 TCP 封装器的补充，这是阻挡主机建立与我们的连接的方法之一。请注意，缺省值是允许对

任何人的访问，除非 TCP 封装器（其规则通常在 /etc/hosts.allow 中）另有规定。
access_times
一天中服务可用的时间。例如，“6:00-23:00”意味着服务从上午 6 点到晚上 11:01 可用。
log_type, log_on_success, log_on_failure
各种日志记录选项。USERID 标志可能特别麻烦，因为它向连接的主机询问关于与我们连接的用

户，这使得处理变慢。尽可能避免使用 USERID。
bind
允许服务特定于接口，通常是出于安全性考虑。例如，在网络内部的 FTP 服务只是 FTP，而外

部 FTP 连接将生成入侵者警报。“id”参数在这里很有用。
per_source
指定来自源 IP 的服务的最大实例数。对于处理“单源拒绝服务（single-source denial-of-

service）”攻击或出错程序建立的过多连接非常有用。
cps
每秒允许的最大连接数，以及服务再度启用之前的秒数。“30 45”表示“每秒 30 个入站连接

，如果超过限制，则等待 45 秒”。主要用于对付拒绝服务攻击。
deny_time
对引发 SENSOR 标志的人拒绝服务的时间。
服务配置
让我们看一些基本的应用。我们先看第一个基本的服务echo，它是inetd 和xinetd固有的服务。

service echo
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        type            = INTERNAL
        id              = echo-stream
}
echo 以root权限运行, 是一个tcp 流并在内部处理。echo-stream指示符将出现在日志中。如果

没有only_from或是 no_access在指示符中,对这个服务的访问的配置将是不受限制的。

现在，让我们看一个正规的服务，daytime：

service daytime
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = /usr/sbin/in.date
        instances       = 1
        nice            = 10
        only_from       = 0.0.0.0
}
再说一次，任何人都可以连接, 不过我们指明它以nobody的身份运行来返回信息。和前一个例子

相比，这个并没有额外的什么。现在我们看另一个服务 secure shell version 1。下面的设置

可以防止sshd所带来的资源耗尽问题。

service ssh1
{
        socket_type     = stream
        protocol        = tcp
        instances       = 10
        nice            = 10
        wait            = no
        user            = root
        server          = /usr/local/sbin/sshd1
        server_args     = -i
        log_on_failure  += USERID
        only_from       = 192.168.0.0
        no_access       = 192.168.54.0
        no_access       += 192.168.33.0
}
在这里，我们建立了前面我们所作的。当作为超级用户inetd或者 xinetd重新调用sshd 需要用

-i 参数， 所以我们把它放在了 server_args 指示符后。注意：把这个标记添加到server标识

符出会导致失败。在任何时候只有十个人可以同时使用，在这个服务器上这不是问题，这个例子

我们从日志得到。另外作为默认信息，如果不能连接的话，连接方的用户 ID在RFC 1413中描述

。最后，我们列出了两个网络不能访问这个服务。

日志和 xinetd
日志中有几个值可以用于得到你的服务器的信息

表2 不同的日志指示值
值  成功/失败  描述
PID  success  当一个连接成功时登记产生的进程的pid
HOST  both  登记远程主机地址
USERID  both  登记远程用户的RFC 1413 ID 
EXIT  success  登记产生的进程的完成
DURATION success  登记任务持续的时间
ATTEMPT  failure  登记连接失败的原因
RECORD  failure  关于连接失败的额外的信息

这样，可以添加一些标准的行指明日志，就像下面的样子。对一个成功连接的服务，我们通常想

登记服务产生的进程id，连接的主机和退出的时间：

log_on_success = PID HOST EXIT
这样可以给出我们用来排错的有用的信息和正常的服务器操做信息。针对失败，我们可以记录我

们想要的：

log_on_failure = HOST RECORD ATTEMPT
我们记录了连接的主机、拒绝连接的原因和关于连接中的主机的额外的信息(有的时候是那些试

图连接的用户ID)。推荐你这样做，可以对你的服务器有一个好的把握。

还看上面，在我们的默认段中，我们的日志写在/var/adm/servicelog中。我们指定所有信息，

成功和失败的都要被xinetd记录。我们的大多数信息看起来像这样：

00/9/13@16:05:07: START: pop3 pid=25679 from=192.168.152.133
00/9/13@16:05:09: EXIT: pop3 status=0 pid=25679
00/10/3@19:28:18: USERID: telnet OTHER :www
使用这个信息，可以轻易对 xinetd 排错和进行和正常操作。也可以容易发现安全问题（如你试

图阻止的连接企图），在日志中简单的用 grep 作 ''FAIL'' 过滤，这些项显示如下：

00/10/4@17:04:58: FAIL: telnet address from=216.237.57.154
00/10/8@22:25:09: FAIL: pop2 address from=202.112.14.184
真正的安全问题需要另外的文章，但是，这足以说明，既然地址可以伪造，不要把地址报告看作

固定的信息。xinetd.log文件（包含了从 xinetd得到的信息）在连接出错的时候作为排错信息

很有用。

00/10/25@21:10:48 xinetd[50]: ERROR: service echo-stream,
accept:
Connection reset by peer