[ 上一页 ] [ 目录 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ 下一页 ]

Securing Debian Manual
第 11 章 - 常见问题解答 (FAQ)


本章介绍源自 Debian 安全邮件列表中的一些常见问题, 当您准备发送邮件, 甚至别人告诉您去 RTFM 时, 您可以阅读它们.


11.1 Debian 操作系统的安全


11.1.1 Debian 比 X 更安全吗?

一个系统只会和其管理员设置的一样安全. Debian 中服务的默认安装是安全的, 但是可能不象有些偏执的操作系统那样其安装的服务默认是被禁用的. 无论如何, 系统管理员都需要根据本地安全策略来配置系统的安全.

http://securityfocus.com/vulns/stats.shtml 处搜集了很多操作系统安全漏洞的相关数据. 这些数据有用吗? 当解释数据时, 站点列举了一些应当考虑的事实和警告, 不同操作系统间的漏洞数据无法相互比较. [48] 并且记住一些关于 Debian 的 Bugtraq 漏洞只适用于 unstable 分支.


11.1.1.1 Debian 比其它发行版安全吗(譬如 RedHat, SuSE...)?

各个 Linux 发行版之间除了基本安装和包管理系统外并没有多少实质性的差别. 多数发行版共享许多相同的程序, 主要的不同是在其稳定版中的引入软件版本的不同. 例如, 内核, Bind, Apache, OpenSSH, XFree, gcc, zlib, 等等, 在所有的 Linux 发行版中都有.

例如,RedHat 不幸的在 foo 当前版本是 1.2.3 时将其引入, 这个版本最近发现了一个安全漏洞. 另一方面, Debian 幸运的引入的是修复了这个错误的 foo 1.2.4. 几年前的 rpc.statd 问题就是这种情况.

在主 Linux 发行版的应急安全小组之间有着很多合作. 著名的安全更新是很少的, 如果有的话, 一般是由开发者来完成. 安全漏洞的信息从未向其它发行版的供应商保留, 修补通常是同上游协同完成, 或者是同 CERT. 结果, 必要的安全更新通常在同一时间发布, 并且不同发行版之间的安全更新基本相同.

Debian 在安全方面主要的优势在于系统通过 apt 完成升级非常简单. Debian 在安全方面还有以下方面值得考虑:


11.1.2 在 Bugtraq 中有很多 Debian bug. 这是否意味着它很脆弱吗?

Debian 发行版号称拥有最多的软件包, 可能比任何一个操纵系统都多. 安装的软件包越多, 潜在的安全问题就越大.

越来越多的人测试原代码的缺陷. 在 Debian 中许多公告与主要软件组件的源码审计有关. 每当诸如此类的源码审计出现漏洞, 它们将会被修复, 并向如 Bugtraq 的列表发送一个公告.

通常在 Debian 中发现的 bug 同样会影响到其它发行版和开发商. 检查每个公告 (DSA) 顶端的 "Debian specific: yes/no" 部分.


11.1.3 Debian 有与安全相关的证书吗?

简短的回答: 没有.

详细的回答: 证书需要花钱(特别是重要的安全认证), 但没有人出资来验证 Debian GNU/Linux 对应于某个等级, 例如 Common Criteria. 如果您对拥有一个获取证书的 GNU/Linux 发行版感兴趣, 请提供完成认证的必需的资金.

当前至少有两个对应不同的EAL级别的发行版认证. 注意一些 CC 测试已经被整合到 Linux Testing Project, 其可以从 Debian 的 ltp 软件包中找到.


11.1.4 有针对 Debian 的安全化程序吗?

是的. Bastille Linux, 最初是针对其它发行版(RedHat 和 Mandrake)的, 现在用于 Debian. 将对上游版本的修改集成到了 Debian 软件包中, 命名为 bastille.

但是, 有些人认为一个安全设置工具并不能满足一个好的管理员的需求.


11.1.5 我想要运行 XYZ 服务, 应当选择哪个?

Debian 的一个强大之处在于对于相同功能( DNS 服务器, 邮件服务器, ftp服务器, web 服务器, 等等) 有很多软件包可供选择. 对于新管理员确定哪个软件包更适合来说很容易被搞糊涂. 对于给定条件的最好的选择是基于您的特点与安全需求之间的平衡. 当您在相似的软件包之间作选择时, 应当问自己这么几个问题:


11.1.6 在 Debian 中如何使 XYZ 服务更安全?

在本文档中您会找到一些在 Debian GNU/Linux 中使一些服务(FTP,Bind)更安全的方法. 这里所没有提供的, 您可以查看程序的文档, 或常用的 Linux 信息. 大多数的用于 Unix 系统的安全指南同样适用于 Debian. 很多情况下, Debian 中服务 X 的安全设置于在其它 Linu x发行版相同行(或 Un*x ,就此而言).


11.1.7 如何删除服务的所有标语?

例如, 如果您不希望用户连接到您的 POP3 进程, 并检索您系统的信息, 您或许想删除(或修改)服务所显示给用户的标语.[50]所用方法与您运行的指定服务的软件有关. 例如 postfix, 你可以在 /etc/postfix/main.cf 中设置 SMTP 标语:

      
       smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

其它软件并不象这样容易修改. 如果要修改 OpenSSH 的显示版本则需要重新编译. 注意不要删除标语的第一部分(SSH-2.0). 客户端用它来确认您的软件包所支持的协议版本.


11.1.8 所有的 Debian 软件包都安全吗?

Debian 安全小组不可能分析 Debian 中所有的软件包的潜在漏洞, 因为没有足够的资金用于整个项目的源代码的安全审计. 但是, Debian 可受益于上游开发者.

实际上,Debian 开发者可能发布一个含有木马的软件包, 并且无法将其检查出来. 即使将其引入 Debian 的一个分支, 也不可能报告出木马可能运行的所有可能的状况. 这就是为什么 Debian 含有"无保证"条件许可的原因.

但是,Debian 用户事实上应当对有广泛用户的稳定版本有足够的信心, 其多数问题可以通过使用被发现. 对于一个重要的系统并不推荐安装未经测试的软件(如果无法提供必要的代码审计). 无论如何, 如果含有安全漏洞的软件被引入发行版, 通过包含软件包确认的使用过程, 这种问题最终可能将追踪到开发者. Debian 项目不轻易采取了这种方法.


11.1.9 为什么一些日志文件/配置文件设为完全可读(world-readable), 这样不是不安全吗?

当然,您可以修改系统的缺省 Debian 许可. 当前关于日志文件和配置文件的策略是完全可读(world readable), 除非它们提供的是高度机密的信息.

如果您作修改,那么就要小心:

FIXME: 检查策略里的写权限部分. 一些软件包(即, ftp 守护进程)似乎强制执行不同的权限.


11.1.10 为什么 /root/(或 UserX)的权限是755?

实际上,其他用户存在同样的问题. 因为 Debian 的安装不在这个目录下放置任何文件, 那里没有任何需要保护的机密信息. 对于您的系统来说, 如果您觉得权限过于宽松, 可以考虑设为750. 对于其他用户,参阅 限制用户对于其他用户信息的访问, 第 4.10.12.1 节.

Debian 安全邮件列表 thread 涉及许多这方面的问题.


11.1.11 在安装 grsec/防火墙后,我开始接收到许多控制信息! 怎么删除他们?

如果您正在接受控制台信息, 并已经配置了 /etc/syslog.conf 将日志信息转向其他文件或指定 TTY, 那么您可能会看到直接发送到控制台的信息.

任何一个内核的缺省控制台日志级别都为 7, 这意味着任何低优先级信息都会出现在控制台. 通常, 防火墙(日志规则)和一些其它的安全工具的日志优先级较低, 因此, 会被直接发送到控制台.

您可以使用 dmesg(-n 选项,参阅 dmesg(8)), 以减少控制台信息, 其检测和控制内核的 ring buffer. 可以通过修改 /etc/init.d/klogd 在下次重起后对其产生修改, 由:

       KLOGD=""

改为:

       KLOGD="-c 4"

如果仍然出现, 为 -c 设置更小的数字. 在 /usr/include/sys/syslog.h 中可以找到关于不同日志级别的描述:

       #define LOG_EMERG       0       /* system is unusable */
       #define LOG_ALERT       1       /* action must be taken immediately */
       #define LOG_CRIT        2       /* critical conditions */
       #define LOG_ERR         3       /* error conditions */
       #define LOG_WARNING     4       /* warning conditions */
       #define LOG_NOTICE      5       /* normal but significant condition */
       #define LOG_INFO        6       /* informational */
       #define LOG_DEBUG       7       /* debug-level messages */

11.1.12 操作系统的用户与组


11.1.12.1 所有系统用户都是必需的吗?

是也不是. Debian 使用预定义用户(如 Debian 策略 or /usr/share/doc/base-passwd/README中所述,用户id(UID) < 99) 以缓和安装某些服务时, 需要适当的 user/UID 的需求. 如果您不打算安装新的服务, 您可以将您系统中没拥有任何文件和运行任何服务的用户安全的删除. 无论如何, Debian 预留从0到99的 UID, 从100到999的 UID 由安装的软件包创建(当软件包被清除时也会被删除).

执行下面的命令(以 root 运行, 因为普通用户没有足够的权限遍历敏感目录) 可以很容易的找到不拥有任何文件的用户:

       cut -f 1 -d : /etc/passwd | \
       while read i; do find / -user "$i" | grep -q . && echo "$i"; done

这些用户由 base-passwd 提供. 更多有关 Debian 中如何处理用户的信息参阅相关文档. 下边是默认用户(带有一个对应组)的列表:

其它没有相关用户的组:


11.1.12.2 adm 组和 staff 组之间有什么区别?

'adm' 组的成员通常为管理员, 这个组的权限允许他们不用 su 就能读取日志文件. 'staff' 组则通常为 help-desk/junior sysadmins, 允许成员在 /usr/local 目录下操作, 和在 /home 目录下创建目录.


11.1.13 为什么我创建新用户时, 会同时出现一个新组?(或为什么 Debian 为每个用户创建一个所属组?)

在 Debian 中, 缺省设置为每个用户都有一个私有组. 传统的 UN*X 方案为每个用户指定了用户组. 创建的其它的组用于限制对不同项目目录下的共享文件的访问. 当单个用户操作多个项目时, 如果某个用户创建了一个文件, 文件的管理将变的困难, 它同它所属的主要组联系在一起(如,'users').

Debian 的方案是通过为每个用户指定一个他们自己的组解决了这一问题; 这样可以带有一个合适的 umask(0002)并且对给定项目目录设置了 SETGID 位, 在此目录下创建的文件都被正确的指定了组. 这使得处理多个项目更加简单, 因为不必切换所属的组或 umask.

然而, 您也可以通过修改 /etc/adduser.conf 来改变这一特性. 修改 USERGROUPS 变量为 'no', 这样当创建用户时就不会伴随产生一个新组了. 也可以设置 USERS_GID 为所有用户都属于的组的GID.


11.1.14 关于服务和开启端口的问题


11.1.14.1 为什么所有的服务安装后都被激活了?

这只是解决问题的一种方法, 既考虑到了安全性, 又兼顾对用户的友好. 除非管理员将其激活, OpenBSD 将禁用所服务. 与此不同除非将其禁用, Debian GNU/Linux 会激活所有安装的服务(更多信息参见 禁用守护进程服务, 第 3.6.1 节). 在您安装了服务之后, 不是这样吗?

对于标准安装, 哪个是更好的解决方案, 在 Debian 的邮件列表(debian-devel 和 debian-security)上有更多的讨论, 然而, 到目前为止(2002年3月), 仍然没有达成共识.


11.1.14.2 我能删除 inetd 吗?

Inetd 是不好删除的, 因为 netbase 依赖于提供它的软件包(netkit-inetd). 如果您想将其除去, 可以将其禁用(参见 禁用守护进程服务, 第 3.6.1 节),或者使用 equivs 软件包卸载这个包


11.1.14.3 为什么我的111端口是打开的?

端口111是 sunrpc 的 portmapper,它是 Debian 的基本安装的默认部分, 因为不必知道何时用户的程序需要 RPC 才能正确运行. 无论如何, 它主要由 NFS 使用. 如果您不需要它, 您可以依照 增强 RPC 服务的安全性, 第 5.13 节 的说明将其删除.

在 portmap 软件包的 5-5 以后版本中, 确实可以安装 portmapper 并使其只监听 localhost(通过修改 /etc/default/portmap)


11.1.14.4 identd(port 113)的主要用途是什么?

Identd 服务是一个认证服务, 用于鉴别某个 TCP/IP 远程服务连接的拥有者的身份. 一个典型的例子, 当用户连接到远程主机, 远程主机上的 inetd 向113端口发回一个查询到, 索取用户信息, 通常由 mail, FTP 和 IRC 服务器使用, 也可用于跟踪您本地系统中的哪个用户试图攻击一个远程系统.

关于 identd 安全性有更广泛的讨论(参见 mailing list archives). 通常, identd 在多用户系统上比在单用户工作站上更有用. 如果对您没用, 可将其禁用, 这样就不会对外部开放此服务了. 如果要用防火墙屏蔽 identd 端口, 使用一条 reject 策略,而不是 deny 策略, 否则, 使用 identd 的连接将会挂起, 直至超时(参见 reject 与 deny 的问题).


11.1.14.5 使用 1 到 6 端口的是什么服务,如果删除?

运行命令 netstat -an, 您会看到:

       Active Internet connections (servers and established)
       Proto Recv-Q Send-Q Local Address           Foreign Address         State
       PID/Program name
       raw        0      0 0.0.0.0:1               0.0.0.0:*               7
       -
       raw        0      0 0.0.0.0:6               0.0.0.0:*               7
       -

不会看到进程对 TCP/UDP 端口 1 到 6 的监听. 事实上, 您会发现一个进程监听 raw socket 协议1(ICMP)到6(TCP). 这通常是木马和一些入侵检测系统,如 iipl, iploggerportsentry 的特征. 如果您有这种软件包, 简单的将其删除. 如果没有, 尝试使用 netstat 的 -p(进程)选项查看那些进程使用了这些监听.


11.1.14.6 我发现端口 XYZ 打开了, 可以将其关闭吗?

是的,当然可以. 您所开放的端口应当遵循您的个人站点关于对其它网络提供公共服务的策略. 检查由 inetd 打开的端口(参见 禁用 inetd 服务, 第 3.6.2 节), 或由于安装的其它软件包打开的端口, 并采取适当的措施(即,配置 inetd, 删除这个软件包, 避免其启动时运行).


11.1.14.7 从 /etc/services 中删除服务, 是否对我的主机的安全有帮助?

, /etc/services 只是在真实名称和指定端口号之间提供一种映射. 从此文件中删除服务名并不能(通常)阻止运行的服务. /etc/services 修改后一些守护进程可能不能运行了, 但这样做并不规范. 正确的禁用服务的方法, 参见 禁用守护进程服务, 第 3.6.1 节.


11.1.15 常见安全问题


11.1.15.1 我的密码丢了,无法访问系统了!

您所需要做的恢复步骤与您是否采纳了限制访问 lilo 和系统的 BIOS 的建议有关.

如果您两个都做了限制, 则进行下一步前, 您需要禁用只能从硬盘启动的 BIOS 设定. 如果你连 BIOS 的密码也忘了, 就需要打开机箱, 取下BIOS 的电池, 将 BIOS 的设置复位.

一旦您设定了从 CD-ROM 或软盘启动,尝试以下步骤:

这将删除遗忘的 root 密码, 包含在用户名之后第一个冒号分割的部分. 保存修改, 重起系统, 以 root 使用空密码登录. 记得重新设置密码. 这样就可行了, 除非您更严谨的配置了系统, 即您不允许用户使用空密码登录, 或不允许 root 由控制台登录.

如果使用这些特性, 则您将需要以单用户模式进入. 如果对 LILO 做了限制, 则您需要在 root 重新设置了上述之后再次运行 lilo. 这相当棘手, 因为你的 /etc/lilo.conf 需要根据 root(/)文件系统来调整, 而不是真正的硬盘

一旦没有了 LILO 限制,尝试以下步骤:


11.1.16 如何配置不需要分配用户 shell 账号的服务?

例如,想配置 POP 服务, 并不一定非要为每个访问用户设置一个用户账号. 最好的方法是使用外部服务(象 Radius, LDAP 或 SQL 数据库), 配置基于目录的认证. 仅仅需要安装对应的 PAM 库(libpam-radius-auth, libpam-ldap, libpam-pgsqllibpam-mysql), 阅读文档(对于新手, 参阅 用户认证: PAM, 第 4.10.1 节), 并基于您的选择配置 PAM-enabled 服务. 编辑 /etc/pam.d/ 目录下对应您选择服务的文件, 修改

      
       auth   required    pam_unix_auth.so shadow nullok use_first_pass

为, 例如, 对于 ldap 来说:

       auth   required    pam_ldap.so

就 LDAP 目录而论,为了使用 LDAP 认证, 一些服务需要在您的目录中提供 LDAP 方案. 如果您使用关系数据库,可以在配置 PAM 模块时, 使用一个有趣的设定. 例如, 如果您有一个带有如下表属性的数据库:

       (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

通过标记服务的属性布尔字段, 就可以启用或禁用对于不同服务的访问, 仅仅需要在下列文件插入合适的内容:


11.2 我的系统存在漏洞!(您确认吗?)


11.2.1 漏洞评估扫描器 X 说我的 Debian 系统存在漏洞!

许多漏洞评估扫描器在 Debian 系统上使用不能给予肯定的回答, 因为它们通过版本检查来确定给定软件包是否存在漏洞, 并不真正的进行安全漏洞测试. 因为 Debian 在修正软件漏洞后并不修改软件版本信息 (很多时候, 修复一个更新版本仅仅是移植), 一些工具认为一个更新了的 Debian 系统是存在漏洞的, 即使并不是这样.

如果您认为您的系统已经更新了最新的安全补丁, 可以与 DSA(参见 Debian 安全公告, 第 7.2 节) 公布的安全漏洞数据库相参考, 识别虚假信息, 如果您使用的工具包括 CVE 参考.


11.2.2 我在系统日志中看到一次攻击. 我的系统被入侵了吗?

一条攻击记录并不意味着您的系统出现安全问题, 但您应当采取一些常见步骤来确定是否被入侵了 (参阅 攻陷之后(事件响应), 第 10 章). 同时, 应当注意这样一个事实, 查看日志中的攻击记录, 也许这就意味着您的系统已经存在漏洞了(执著的攻击者也许已经尝试了您所看到的以外的其它漏洞).


11.2.3 我在日志中发现了奇怪的 'MARK' 行: 我被入侵了吗??

您也许在系统日志中发现了如下内容:

       Dec 30 07:33:36 debian -- MARK --
       Dec 30 07:53:36 debian -- MARK --
       Dec 30 08:13:36 debian -- MARK --

这并不能表明任何入侵, 用户更换 Debian 发行版也许会奇怪的发现这种内容. 如果您的系统不是高负载(或者提供很多服务), 这些内容可能会出现在您的日志中. 这只表明您的 syslogd守护进程运行正常,摘自 syslogd(8):

            -m interval
                   The syslogd logs a mark timestamp  regularly.   The
                   default interval between two -- MARK -- lines is 20
                   minutes.  This can be  changed  with  this  option.
                   Setting the interval to zero turns it off entirely.

11.2.4 在日志中发现有用户使用'su': 我被入侵了?

有可能您在日志中发现如下类似内容:

       Apr  1 09:25:01 server su[30315]: + ??? root-nobody
       Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)

不必太担心. 检查这些内容是否与 cron 有关 (通常为 /etc/cron.daily/findlogrotate):

       $ grep 25 /etc/crontab
       25 6    * * *   root    test -e /usr/sbin/anacron || run-parts --report
       /etc/cron.daily
       $ grep nobody /etc/cron.daily/*
       find:cd / && updatedb --localuser=nobody 2>/dev/null

11.2.5 我在日志中发现 'possible SYN flooding': 我被攻击了?

如果您在日志中发现了如下类似内容:

       May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

netstat 检查服务器是否存在大量的连接, 例如:

       linux:~# netstat -ant | grep SYN_RECV | wc -l
          9000

这表明对您的系统的 X 端口(通常是对应公共服务, 如 web 服务器, 或邮件服务器)进行了拒绝服务(DoS)攻击. 您应当激活内核中的 TCP syncookies, 参阅 配置 Syncookies, 第 4.17.2 节. 但是, 应当注意, 这样即使您能避免系统被搞瘫, 一个 DoS 攻击仍能湮没您的网络(由于资源标示被耗尽, 系统也许暂时无法应答 TCP 连接, 直至超时). 最有效的解决方法是联系您的网络提供商.


11.2.6 在日志中发现了奇怪的 root 会话: 我被入侵了?

/var/log/auth.log 文件中, 也许您会发现如下类似内容:

       May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
       May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
       May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
       (UID=0)
       May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

这与执行的 cron 任务有关(在这个例子中,每5分钟一次). 确定哪个程序对应这些任务, 检查如下目录中的内容: /etc/crontab, /etc/cron.d, /etc/crond.daily 和 root 的 crontab 目录.


11.2.7 我被入侵了, 怎么办?

这种情况下,也许您应当采取如下措施:


11.2.8 如何跟踪攻击?

查看日志(如果还未被篡改), 使用入侵检测系统(参见 设置入侵检测, 第 9.3 节), traceroute, whois 和其它简单的工具(包括事故分析), 您也许能跟踪到攻击源. 这种方法是否有效与您的安全策略, 以及认为什么是攻击有关. 远程扫描是攻击吗? 漏洞探测是攻击吗?


11.2.9 Debian 系统中的程序 X 存在漏洞, 我该怎么办?

首先,花一点时间检查在公开的安全邮件列表(如 Bugtraq)或其它论坛上是否公布了这个漏洞. Debian 安全小组会跟踪这些列表, 也许他们也没有意识到这个问题. 如果您在 http://security.debian.org 看到相关通告, 就不必采取进一步行动了.

如果似乎没有公布什么相关信息, 请发送邮件至 team@security.debian.org, 包括受影响包的有关信息, 以及有关漏洞的详细描述信息(proof of concept code is also OK). 这样就会与 Debian 安全小组保持联系.


11.2.10 软件包的版本号表明我仍在使用一个存在漏洞的版本!

Debian 对引入稳定版的版本进行 back port 安全修复, 而不是升级到新的版本. 原因是要确保稳定版尽可能少的变动, 因为一个安全修复不会产生太大的变动或意想不到冲突. 您可以通过查看软件包的更新记录来确定是否在使用这个软件包的一个安全版本, 或者用 Debian 安全公告上声明的版本与其确切版本号(上游版本 -斜线- debian 版本)相比较.


11.2.11 特定软件


11.2.11.1 proftpd 存在拒绝服务攻击漏洞.

在您的配置文件中增加 DenyFilter \*.*/, 更多信息参见 http://www.proftpd.org/critbugs.html.


11.2.11.2 安装 portsentry 后,打开了很多端口.

这是 portsentry 的工作方式. 它打开大约二十个未使用的端口用于确定端口扫描.


11.3 有关 Debian 安全小组的问题

您可以从 Debian Security FAQ 获取相关信息. 这包括自11月19日以来信息, 以及在 debian 安全邮件列表中出现的其它常见问题.


11.3.1 什么是 Debian 安全公告(DSA)?

这是由 Debian 安全小组(参见下面)提供的有关 Debian GNU/Linux 的软件包中发现和修复安全漏洞的信息. 被签名的 DSA 信息由 Debian 小组发送到邮件列表 (debian-security-announce), 并在Debian的网站上张贴(首页和 security area).

DSAs 包括受影响的软件包, 被发现的安全漏洞, 从何处获更新软件包(以及它们的 MD5)等信息.


11.3.2 公告的署名未通过验证!

这是很可能是您用户端的问题. debian-security-announce 列表有一个过滤器只允许源自安全小组成员并含有正确签名的信息被张贴.

很有可能您使用的客户端邮件软件对信息有所改动, 因此破坏了签名. 确保您的软件没有做任何 MIME 编码或解码, 或 tab/space 转换.

已知的有 fetchmail(启用 mime 解码选项, formail (仅是源于 procmail 3.14 的) 和 evolution.


11.3.3 Debian 中如何处理安全问题?

一旦安全小组接受了事件通知, 一个或多个成员将对其检查, 看是否对 Debian 的稳定版本产生影响(即, 是否是一个漏洞). 如果我们的系统存在漏洞, 我们将修复这个问题. 如果软件包的维护者还未联系安全小组, 那么将与其取得联系. 最后, 对这个修补进行测试, 然后准备新的软件包, 它们是在稳定平台上编译的, 然后上载. 所有这些完成以后, 发布一个公告.


11.3.4 为什么您的系统中混有那个软件包的老版本?

在为修复安全问题制作一个新软件包时, 最重要的准则是尽可能少的变动. 我们的用户和开发者一旦确定下来就依靠一个确切的版本工作, 我们做的任何变动都可能使某个用户的系统崩溃. 对于库来说更是如此: 确保从未没修改应用程序接口(API)或应用级二进制接口(ABI), 不管变动多么细微.

这意味着, 更新为新的上游版本不是好的解决办法, 反而移植是更好的选择. 通常如果需要, 上游维护者都愿提供帮助, 如果 Debian 安全小组不能提供帮助的话.

在某些情况下, 移植一个安全修复是不太可能的, 例如, 当大量源码需要修改和重写时. 这时就不得不引入新的上游版本, 但是这必须由安全小组预先协调完成.


11.3.5 security.debian.org 的修复软件包的策略是什么?

在 stable 发行版中, Security breakage 只是证明一个软件包在 security.debian.org 上的正确性. 其它没有什么作用. 一个 breakage 的大小在这里并不是真正的问题. 通常安全小组会和软件包的维护者一起制定软件包. 一些人(相信)应当跟踪问题并且得全部需要的编译的软件包, 并提交给安全小组, 即使是细微也要提交给 security.debian.org. 参阅下边的内容.


11.3.6 软件包的版本号表明,我正在运行一个存在漏洞的版本!

我们将一个版本的移植安全修复引入稳定版, 而不是升级到新的版本. 我们这样做的原因是确保一个发行版的变动尽可能的少, 一个安全修复不至于改变或使现有系统崩溃. 您可以通过检查软件包的更新日志, 或比较在 Debian 安全公告中声明的确切版本号来确定您是否在使用一个软件包的安全版本


11.3.7 对于 testingunstable 版本其安全问题如何操作?

简单的回答: 没有. testing 和 unstabl 变动很快, 安全小组没有所需的资源来为其提供支持. 如果您需要一台安全(并且稳定)的服务器, 强烈建议您使用 stable 版. 当然, 安全人员在修复了 stable 版本中的问题后, 也会尽力修复 testing 和 unstable 中的问题.

然而,某些情况下,unstable 版中的安全问题会更快的得到解决, 因为通常可以更快的从上游得到修复(其它版本, 比如稳定版中, 则通常需要移植).


11.3.8 我使用的是旧版的 Debian, 还能从 Debian 安全小组获取支持吗?

不. 很不幸, 安全小组不能同时处理 stable 版(非官方的, 也是 unstable), 和其它老版本. 但是, 您可以期待新的 Debian 发行版发行后, 一段限制时间(通常为几个月)后的一个安全更新.


11.3.9 为什么没有 security.debian.org 的非官方镜像?

security.debian.org 的目的就是尽可能快, 尽可能简单的获取安全更新. 镜像会增加不必要的麻烦, 同时,如果非官方镜像没有及时更新的话,就可能会误事.


11.3.10 我已经查看了 DSA 100 和DSA 102,DSA 101的内容是?

一些供应商(主要是 GNU/Linux, 但也包括基于 BSD 的)协调一些问题的安全公告并协商一个时间表, 这样所有的供应商都可以在同一时间发布公告. 为了照顾需要更多时间的供应商(比如供应商需要对软件包进行冗长的 QA测试或需要提供对多个平台的支持或需要发行二进制代码). 我们自己的安全小组同时也需要提前准备公告. 时常,在张贴需要发布的公告以前,还时常需要涉及其它安全问题. 因此临时省略了一个或一些公告编号.


11.3.11 如何联系安全小组?

可以发送安全信息到 security@debian.org, 这将会被所有 Debian 开发者收到. 如果有机密信息, 请发送到 team@security.debian.org 这只有成员可以阅读. 如果需要对电子邮件加密, 可以使用Debian安全联络密钥 (密钥编号 0x363CCD95 ).


11.3.12 在 security@debian.org 和 debian-security@lists.debian.org 之间有什么不同?

当您发送邮件到 security@debian.org 时, 它们将被发送到开发者邮件列表(debian-private). 所有 Debian 开发者都订阅此邮件列表, 并且保密(即不会在公网公布). 公共邮件列表, debian-security@lists.debian.org, 对任何 订阅 此邮件列表的用户公开, 并提供文档 检索.


11.3.13 如何为 Debian 安全小组贡献力量?

任何一种情况, 在向 security@debian.org 提交报告之前, 请回顾每个问题. 如果您能提供补丁, 这个过程会更快. 不要简单的转发 Bugtraq 邮件, 因为已经接收了类似邮件. 当然, 提供附加信息也是不错的想法.


11.3.14 安全小组有哪些人组成?

Debian 安全小组当前由五名成员和两名秘书组成. 安全小组自己任命成员加入.


11.3.15 Debian 安全小组检查 Debian 中的每个新的软件包吗?

否, Debian 安全小组不对每个新软件包进行检查, 也没有完成检查恶意新软件包的自动(lintian)检查, 因为这些检查自动完成几乎不可能. 然而, 维护者对于其引入 Debian 的软件包负完全责任, 并且所有软件包首先有授权的开发者签名. 此开发者负责分析他们所维护的软件报的安全性.


11.3.16 Debian 修复漏洞 XXXX 需要多少时间?

一旦发现漏洞, Debian 安全小组就会迅速的张贴公告, 并为 stable 版构建修补程序. 张贴于 Debian 安全邮件列表 的报告显示2001年 Debian 安全小组修复安全相关漏洞的平均时间是35天. 但是, 超过50%的漏洞修复时间在10以内, 超过15%在公告发布的当天被修复.

但是,在问这个问题时, 可能忘了:

如果您想更加详尽的分析 Debian 安全小组在漏洞上消耗的时间, 应当考虑新的 DSA(参见Debian 安全公告, 第 7.2 节)在 安全站点 上的张贴, 使用 metadata 生成它们, 包括与漏洞数据库建立连接, 您应当从 web 服务器(从 CVS)上下载源代码或 使用 HTML 页面来确定 Debian 修复漏洞所花费的时间, 并且与公共数据库相比较.


[ 上一页 ] [ 目录 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ 下一页 ]

Securing Debian Manual

v3.2, Mon, 20 Jun 2005 08:01:11 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Translator: eTony etony@tom.com
作者, 第 1.1 节