本章介绍源自 Debian 安全邮件列表中的一些常见问题, 当您准备发送邮件, 甚至别人告诉您去 RTFM 时, 您可以阅读它们.
一个系统只会和其管理员设置的一样安全. Debian 中服务的默认安装是安全的, 但是可能不象有些偏执的操作系统那样其安装的服务默认是被禁用的. 无论如何, 系统管理员都需要根据本地安全策略来配置系统的安全.
http://securityfocus.com/vulns/stats.shtml
处搜集了很多操作系统安全漏洞的相关数据. 这些数据有用吗? 当解释数据时,
站点列举了一些应当考虑的事实和警告, 不同操作系统间的漏洞数据无法相互比较. [48] 并且记住一些关于 Debian 的
Bugtraq 漏洞只适用于 unstable 分支.
各个 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 在安全方面还有以下方面值得考虑:
Ramen 或 Lion worms
).
Debian 的安装并不象 OpenBSD 那样受限(缺省守护进程是未被激活的),
但这是一个很好的折中方案. [49]
Debian 发行版号称拥有最多的软件包, 可能比任何一个操纵系统都多. 安装的软件包越多, 潜在的安全问题就越大.
越来越多的人测试原代码的缺陷. 在 Debian 中许多公告与主要软件组件的源码审计有关. 每当诸如此类的源码审计出现漏洞, 它们将会被修复, 并向如 Bugtraq 的列表发送一个公告.
通常在 Debian 中发现的 bug 同样会影响到其它发行版和开发商. 检查每个公告 (DSA) 顶端的 "Debian specific: yes/no" 部分.
简短的回答: 没有.
详细的回答: 证书需要花钱(特别是重要的安全认证), 但没有人出资来验证
Debian GNU/Linux 对应于某个等级, 例如 Common Criteria
.
如果您对拥有一个获取证书的 GNU/Linux 发行版感兴趣, 请提供完成认证的必需的资金.
当前至少有两个对应不同的EAL
级别的发行版认证.
注意一些 CC 测试已经被整合到 Linux
Testing Project
, 其可以从 Debian 的 ltp
软件包中找到.
是的. Bastille Linux
,
最初是针对其它发行版(RedHat 和 Mandrake)的, 现在用于 Debian.
将对上游版本的修改集成到了 Debian 软件包中, 命名为 bastille
.
但是, 有些人认为一个安全设置工具并不能满足一个好的管理员的需求.
Debian 的一个强大之处在于对于相同功能( DNS 服务器, 邮件服务器, ftp服务器, web 服务器, 等等) 有很多软件包可供选择. 对于新管理员确定哪个软件包更适合来说很容易被搞糊涂. 对于给定条件的最好的选择是基于您的特点与安全需求之间的平衡. 当您在相似的软件包之间作选择时, 应当问自己这么几个问题:
在本文档中您会找到一些在 Debian GNU/Linux 中使一些服务(FTP,Bind)更安全的方法. 这里所没有提供的, 您可以查看程序的文档, 或常用的 Linux 信息. 大多数的用于 Unix 系统的安全指南同样适用于 Debian. 很多情况下, Debian 中服务 X 的安全设置于在其它 Linu x发行版相同行(或 Un*x ,就此而言).
例如, 如果您不希望用户连接到您的 POP3 进程, 并检索您系统的信息,
您或许想删除(或修改)服务所显示给用户的标语.[50]所用方法与您运行的指定服务的软件有关. 例如
postfix
, 你可以在 /etc/postfix/main.cf
中设置 SMTP
标语:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
其它软件并不象这样容易修改. 如果要修改 OpenSSH
的显示版本则需要重新编译. 注意不要删除标语的第一部分(SSH-2.0).
客户端用它来确认您的软件包所支持的协议版本.
Debian 安全小组不可能分析 Debian 中所有的软件包的潜在漏洞, 因为没有足够的资金用于整个项目的源代码的安全审计. 但是, Debian 可受益于上游开发者.
实际上,Debian 开发者可能发布一个含有木马的软件包, 并且无法将其检查出来. 即使将其引入 Debian 的一个分支, 也不可能报告出木马可能运行的所有可能的状况. 这就是为什么 Debian 含有"无保证"条件许可的原因.
但是,Debian 用户事实上应当对有广泛用户的稳定版本有足够的信心, 其多数问题可以通过使用被发现. 对于一个重要的系统并不推荐安装未经测试的软件(如果无法提供必要的代码审计). 无论如何, 如果含有安全漏洞的软件被引入发行版, 通过包含软件包确认的使用过程, 这种问题最终可能将追踪到开发者. Debian 项目不轻易采取了这种方法.
当然,您可以修改系统的缺省 Debian 许可. 当前关于日志文件和配置文件的策略是完全可读(world readable), 除非它们提供的是高度机密的信息.
如果您作修改,那么就要小心:
/etc/samba/smb.conf
的完全可读权限, 普通用户将无法运行
smbclient
程序.
FIXME: 检查策略里的写权限部分. 一些软件包(即, ftp 守护进程)似乎强制执行不同的权限.
实际上,其他用户存在同样的问题. 因为 Debian 的安装不在这个目录下放置任何文件, 那里没有任何需要保护的机密信息. 对于您的系统来说, 如果您觉得权限过于宽松, 可以考虑设为750. 对于其他用户,参阅 限制用户对于其他用户信息的访问, 第 4.10.12.1 节.
Debian 安全邮件列表 thread
涉及许多这方面的问题.
如果您正在接受控制台信息, 并已经配置了 /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 */
是也不是. 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
中如何处理用户的信息参阅相关文档. 下边是默认用户(带有一个对应组)的列表:
portmap
,
atd
, 或许还有其它)一样对磁盘文件进行写操作. 守护进程以
nobody.nogroup 运行时不需要拥有任何文件.
更复杂或更安全的守护进程以指定用户运行. daemon 用户也可用于本地安装 daemon.
/var/spool/cups
.
/bin/sync
.
因而,如果它的密码被设置对容易事猜测(譬如 "" )
,任何人都可以通过控制台 sync 系统. 既使他们没有帐户.
/var/cache/man
.
/var/mail
目录下的信箱由 mail 组拥有, 这是策略中的解释.
用户和组同时也被其它各种各样的 MTA 使用.
suck
)以各种各样的方式使用 news 用户和组. 在 news spool
中的文件通常为 news 用户和组拥有. 用于投递新闻的程序,如 inews 就是典型的
SETGID news.
pdnsd
使用, squid
以proxy用户运行.
Majordomo
有一个静态分配的 UID. 新的系统中没有.
Postgresql
数据库由这个用户和组拥有. 因为安全的原因,
目录 /var/lib/postgresql
下的所有文件由此用户拥有.
ircd
的一个 bug,
需要分配一个静态用户, 启动时, 它将自身 SETUID() 给一个指定 UID.
其它没有相关用户的组:
/var/log
下的许多日志文件有读权限. 并且可以使用 xconsole. 过去, /var/log
就是 /usr/adm
(后来是 /var/adm
).
这是这个组名字的由来.
ppp
, dip
, wvdial
,
等一类的工具, 进行拨号连接. 这个组的用户不允许配置调制解调器,
但是可以运行使用它的程序.
sudo
时, 这个组的成员不需要键入密码. 参阅
/usr/share/doc/sudo/OPTIONS
.
/usr/src
目录下的文件.
可以用来在本地给用户分配管理系统源代码的能力.
/etc/shadow
.
需要访问这个文件的一些程序需要 SETGID 为 shadow.
/var/run/utmp
和类似的文件进行写操作.
需要对此类文件进行写操作的程序需要 SETGID 为 utmp.
/usr/local
,
/home
)的本地修改, 而不需要特权. 与 "adm" 组相比, 更
monitoring/security.
'adm' 组的成员通常为管理员, 这个组的权限允许他们不用 su
就能读取日志文件. 'staff' 组则通常为 help-desk/junior sysadmins, 允许成员在
/usr/local
目录下操作, 和在 /home
目录下创建目录.
在 Debian 中, 缺省设置为每个用户都有一个私有组. 传统的 UN*X 方案为每个用户指定了用户组. 创建的其它的组用于限制对不同项目目录下的共享文件的访问. 当单个用户操作多个项目时, 如果某个用户创建了一个文件, 文件的管理将变的困难, 它同它所属的主要组联系在一起(如,'users').
Debian 的方案是通过为每个用户指定一个他们自己的组解决了这一问题; 这样可以带有一个合适的 umask(0002)并且对给定项目目录设置了 SETGID 位, 在此目录下创建的文件都被正确的指定了组. 这使得处理多个项目更加简单, 因为不必切换所属的组或 umask.
然而, 您也可以通过修改 /etc/adduser.conf
来改变这一特性. 修改
USERGROUPS 变量为 'no', 这样当创建用户时就不会伴随产生一个新组了.
也可以设置 USERS_GID 为所有用户都属于的组的GID.
这只是解决问题的一种方法, 既考虑到了安全性, 又兼顾对用户的友好. 除非管理员将其激活, OpenBSD 将禁用所服务. 与此不同除非将其禁用, Debian GNU/Linux 会激活所有安装的服务(更多信息参见 禁用守护进程服务, 第 3.6.1 节). 在您安装了服务之后, 不是这样吗?
对于标准安装, 哪个是更好的解决方案, 在 Debian 的邮件列表(debian-devel 和 debian-security)上有更多的讨论, 然而, 到目前为止(2002年3月), 仍然没有达成共识.
inetd
吗?
Inetd
是不好删除的, 因为 netbase
依赖于提供它的软件包(netkit-inetd
). 如果您想将其除去,
可以将其禁用(参见 禁用守护进程服务, 第
3.6.1 节),或者使用 equivs
软件包卸载这个包
端口111是 sunrpc 的 portmapper,它是 Debian 的基本安装的默认部分, 因为不必知道何时用户的程序需要 RPC 才能正确运行. 无论如何, 它主要由 NFS 使用. 如果您不需要它, 您可以依照 增强 RPC 服务的安全性, 第 5.13 节 的说明将其删除.
在 portmap 软件包的 5-5 以后版本中, 确实可以安装 portmapper 并使其只监听
localhost(通过修改 /etc/default/portmap
)
identd
(port 113)的主要用途是什么?
Identd 服务是一个认证服务, 用于鉴别某个 TCP/IP 远程服务连接的拥有者的身份.
一个典型的例子, 当用户连接到远程主机, 远程主机上的 inetd
向113端口发回一个查询到, 索取用户信息, 通常由 mail, FTP 和 IRC 服务器使用,
也可用于跟踪您本地系统中的哪个用户试图攻击一个远程系统.
关于 identd
安全性有更广泛的讨论(参见 mailing
list archives
). 通常, identd
在多用户系统上比在单用户工作站上更有用. 如果对您没用, 可将其禁用,
这样就不会对外部开放此服务了. 如果要用防火墙屏蔽 identd 端口,
请使用一条 reject 策略,而不是 deny 策略, 否则, 使用
identd
的连接将会挂起, 直至超时(参见 reject 与 deny
的问题
).
运行命令 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
, iplogger
和
portsentry
的特征. 如果您有这种软件包, 简单的将其删除. 如果没有,
尝试使用 netstat 的 -p(进程)选项查看那些进程使用了这些监听.
是的,当然可以.
您所开放的端口应当遵循您的个人站点关于对其它网络提供公共服务的策略. 检查由
inetd
打开的端口(参见 禁用
inetd
服务, 第 3.6.2 节), 或由于安装的其它软件包打开的端口,
并采取适当的措施(即,配置 inetd, 删除这个软件包, 避免其启动时运行).
/etc/services
中删除服务, 是否对我的主机的安全有帮助?
否, /etc/services
只是在真实名称和指定端口号之间提供一种映射.
从此文件中删除服务名并不能(通常)阻止运行的服务. /etc/services
修改后一些守护进程可能不能运行了, 但这样做并不规范. 正确的禁用服务的方法, 参见
禁用守护进程服务, 第 3.6.1 节.
您所需要做的恢复步骤与您是否采纳了限制访问 lilo
和系统的 BIOS
的建议有关.
如果您两个都做了限制, 则进行下一步前, 您需要禁用只能从硬盘启动的 BIOS 设定. 如果你连 BIOS 的密码也忘了, 就需要打开机箱, 取下BIOS 的电池, 将 BIOS 的设置复位.
一旦您设定了从 CD-ROM 或软盘启动,尝试以下步骤:
ae
编辑器, Debian3.0 提供与
vi
很相似的 nano-tiny
)/etc/shadow
并修改:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
为:
root::XXXX:X:XXXX:X:::
这将删除遗忘的 root 密码, 包含在用户名之后第一个冒号分割的部分. 保存修改, 重起系统, 以 root 使用空密码登录. 记得重新设置密码. 这样就可行了, 除非您更严谨的配置了系统, 即您不允许用户使用空密码登录, 或不允许 root 由控制台登录.
如果使用这些特性, 则您将需要以单用户模式进入. 如果对 LILO 做了限制, 则您需要在
root 重新设置了上述之后再次运行 lilo
. 这相当棘手, 因为你的
/etc/lilo.conf
需要根据 root(/)文件系统来调整, 而不是真正的硬盘
一旦没有了 LILO 限制,尝试以下步骤:
# mount -o remount,rw /
passwd
命令修改超级用户密码(因为您就是超级用户,
所有不会要求您提供原密码).
例如,想配置 POP 服务, 并不一定非要为每个访问用户设置一个用户账号.
最好的方法是使用外部服务(象 Radius, LDAP 或 SQL 数据库), 配置基于目录的认证.
仅仅需要安装对应的 PAM 库(libpam-radius-auth
,
libpam-ldap
, libpam-pgsql
和
libpam-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)
通过标记服务的属性布尔字段, 就可以启用或禁用对于不同服务的访问, 仅仅需要在下列文件插入合适的内容:
/etc/pam.d/imap
:where=imap=1.
/etc/pam.d/qpopper
:where=pop=1.
/etc/nss-mysql*.conf
:users.where_clause = user.sys =
1;.
/etc/proftpd.conf
:SQLWhereClause "ftp=1".
许多漏洞评估扫描器在 Debian 系统上使用不能给予肯定的回答, 因为它们通过版本检查来确定给定软件包是否存在漏洞, 并不真正的进行安全漏洞测试. 因为 Debian 在修正软件漏洞后并不修改软件版本信息 (很多时候, 修复一个更新版本仅仅是移植), 一些工具认为一个更新了的 Debian 系统是存在漏洞的, 即使并不是这样.
如果您认为您的系统已经更新了最新的安全补丁, 可以与 DSA(参见 Debian 安全公告, 第 7.2 节) 公布的安全漏洞数据库相参考, 识别虚假信息, 如果您使用的工具包括 CVE 参考.
一条攻击记录并不意味着您的系统出现安全问题, 但您应当采取一些常见步骤来确定是否被入侵了 (参阅 攻陷之后(事件响应), 第 10 章). 同时, 应当注意这样一个事实, 查看日志中的攻击记录, 也许这就意味着您的系统已经存在漏洞了(执著的攻击者也许已经尝试了您所看到的以外的其它漏洞).
您也许在系统日志中发现了如下内容:
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.
有可能您在日志中发现如下类似内容:
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/find
或 logrotate
):
$ 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
如果您在日志中发现了如下类似内容:
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 连接, 直至超时). 最有效的解决方法是联系您的网络提供商.
在 /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
目录.
这种情况下,也许您应当采取如下措施:
SANS 排名前20的安全漏洞
的链接.
CERT
(如果有的话,
您也许可以直接与其取得联系). 这可能对您没有什么帮助, 但至少通知 CERT
正在进行的攻击. 这些信息对于确定 blackhat
社区使用何种工具或攻击非常有用.
查看日志(如果还未被篡改), 使用入侵检测系统(参见 设置入侵检测, 第 9.3 节),
traceroute
, whois
和其它简单的工具(包括事故分析),
您也许能跟踪到攻击源. 这种方法是否有效与您的安全策略,
以及您认为什么是攻击有关. 远程扫描是攻击吗? 漏洞探测是攻击吗?
首先,花一点时间检查在公开的安全邮件列表(如
Bugtraq)或其它论坛上是否公布了这个漏洞. Debian 安全小组会跟踪这些列表,
也许他们也没有意识到这个问题. 如果您在 http://security.debian.org
看到相关通告, 就不必采取进一步行动了.
如果似乎没有公布什么相关信息, 请发送邮件至 team@security.debian.org
,
包括受影响包的有关信息, 以及有关漏洞的详细描述信息(proof of concept code is
also OK). 这样就会与 Debian 安全小组保持联系.
Debian 对引入稳定版的版本进行 back port 安全修复, 而不是升级到新的版本. 原因是要确保稳定版尽可能少的变动, 因为一个安全修复不会产生太大的变动或意想不到冲突. 您可以通过查看软件包的更新记录来确定是否在使用这个软件包的一个安全版本, 或者用 Debian 安全公告上声明的版本与其确切版本号(上游版本 -斜线- debian 版本)相比较.
proftpd
存在拒绝服务攻击漏洞.
在您的配置文件中增加 DenyFilter \*.*/, 更多信息参见 http://www.proftpd.org/critbugs.html
.
portsentry
后,打开了很多端口.
这是 portsentry
的工作方式.
它打开大约二十个未使用的端口用于确定端口扫描.
您可以从 Debian
Security FAQ
获取相关信息. 这包括自11月19日以来信息, 以及在 debian
安全邮件列表中出现的其它常见问题.
这是由 Debian 安全小组(参见下面)提供的有关 Debian GNU/Linux
的软件包中发现和修复安全漏洞的信息. 被签名的 DSA 信息由 Debian
小组发送到邮件列表 (debian-security-announce), 并在Debian的网站上张贴(首页和
security area
).
DSAs 包括受影响的软件包, 被发现的安全漏洞, 从何处获更新软件包(以及它们的 MD5)等信息.
这是很可能是您用户端的问题. debian-security-announce
列表有一个过滤器只允许源自安全小组成员并含有正确签名的信息被张贴.
很有可能您使用的客户端邮件软件对信息有所改动, 因此破坏了签名. 确保您的软件没有做任何 MIME 编码或解码, 或 tab/space 转换.
已知的有 fetchmail(启用 mime 解码选项, formail (仅是源于 procmail 3.14 的) 和 evolution.
一旦安全小组接受了事件通知, 一个或多个成员将对其检查, 看是否对 Debian 的稳定版本产生影响(即, 是否是一个漏洞). 如果我们的系统存在漏洞, 我们将修复这个问题. 如果软件包的维护者还未联系安全小组, 那么将与其取得联系. 最后, 对这个修补进行测试, 然后准备新的软件包, 它们是在稳定平台上编译的, 然后上载. 所有这些完成以后, 发布一个公告.
在为修复安全问题制作一个新软件包时, 最重要的准则是尽可能少的变动. 我们的用户和开发者一旦确定下来就依靠一个确切的版本工作, 我们做的任何变动都可能使某个用户的系统崩溃. 对于库来说更是如此: 确保从未没修改应用程序接口(API)或应用级二进制接口(ABI), 不管变动多么细微.
这意味着, 更新为新的上游版本不是好的解决办法, 反而移植是更好的选择. 通常如果需要, 上游维护者都愿提供帮助, 如果 Debian 安全小组不能提供帮助的话.
在某些情况下, 移植一个安全修复是不太可能的, 例如, 当大量源码需要修改和重写时. 这时就不得不引入新的上游版本, 但是这必须由安全小组预先协调完成.
在 stable 发行版中, Security breakage 只是证明一个软件包在 security.debian.org 上的正确性. 其它没有什么作用. 一个 breakage 的大小在这里并不是真正的问题. 通常安全小组会和软件包的维护者一起制定软件包. 一些人(相信)应当跟踪问题并且得全部需要的编译的软件包, 并提交给安全小组, 即使是细微也要提交给 security.debian.org. 参阅下边的内容.
我们将一个版本的移植安全修复引入稳定版, 而不是升级到新的版本. 我们这样做的原因是确保一个发行版的变动尽可能的少, 一个安全修复不至于改变或使现有系统崩溃. 您可以通过检查软件包的更新日志, 或比较在 Debian 安全公告中声明的确切版本号来确定您是否在使用一个软件包的安全版本
简单的回答: 没有. testing 和 unstabl 变动很快, 安全小组没有所需的资源来为其提供支持. 如果您需要一台安全(并且稳定)的服务器, 强烈建议您使用 stable 版. 当然, 安全人员在修复了 stable 版本中的问题后, 也会尽力修复 testing 和 unstable 中的问题.
然而,某些情况下,unstable 版中的安全问题会更快的得到解决, 因为通常可以更快的从上游得到修复(其它版本, 比如稳定版中, 则通常需要移植).
不. 很不幸, 安全小组不能同时处理 stable 版(非官方的, 也是 unstable), 和其它老版本. 但是, 您可以期待新的 Debian 发行版发行后, 一段限制时间(通常为几个月)后的一个安全更新.
security.debian.org 的目的就是尽可能快, 尽可能简单的获取安全更新. 镜像会增加不必要的麻烦, 同时,如果非官方镜像没有及时更新的话,就可能会误事.
一些供应商(主要是 GNU/Linux, 但也包括基于 BSD 的)协调一些问题的安全公告并协商一个时间表, 这样所有的供应商都可以在同一时间发布公告. 为了照顾需要更多时间的供应商(比如供应商需要对软件包进行冗长的 QA测试或需要提供对多个平台的支持或需要发行二进制代码). 我们自己的安全小组同时也需要提前准备公告. 时常,在张贴需要发布的公告以前,还时常需要涉及其它安全问题. 因此临时省略了一个或一些公告编号.
可以发送安全信息到 security@debian.org
, 这将会被所有
Debian 开发者收到. 如果有机密信息, 请发送到 team@security.debian.org
这只有成员可以阅读. 如果需要对电子邮件加密, 可以使用Debian安全联络密钥
(密钥编号 0x363CCD95
).
当您发送邮件到 security@debian.org 时,
它们将被发送到开发者邮件列表(debian-private). 所有 Debian
开发者都订阅此邮件列表, 并且保密(即不会在公网公布). 公共邮件列表,
debian-security@lists.debian.org, 对任何 订阅
此邮件列表的用户公开, 并提供文档 检索
.
WNPP bug
,
申请您认为有用但当前没有提供的程序.
Linux Kernel Security Audit
Project
或 Linux Security-Audit
Project
都能增加 Debian GNU/Linux 的安全性,
因此为这些项目提供帮助最终也是有益的.
任何一种情况, 在向 security@debian.org 提交报告之前, 请回顾每个问题. 如果您能提供补丁, 这个过程会更快. 不要简单的转发 Bugtraq 邮件, 因为已经接收了类似邮件. 当然, 提供附加信息也是不错的想法.
Debian 安全小组当前由五名成员和两名秘书组成. 安全小组自己任命成员加入.
否, Debian 安全小组不对每个新软件包进行检查, 也没有完成检查恶意新软件包的自动(lintian)检查, 因为这些检查自动完成几乎不可能. 然而, 维护者对于其引入 Debian 的软件包负完全责任, 并且所有软件包首先有授权的开发者签名. 此开发者负责分析他们所维护的软件报的安全性.
一旦发现漏洞, Debian 安全小组就会迅速的张贴公告, 并为 stable 版构建修补程序.
张贴于
Debian 安全邮件列表
的报告显示2001年 Debian
安全小组修复安全相关漏洞的平均时间是35天. 但是, 超过50%的漏洞修复时间在10以内,
超过15%在公告发布的当天被修复.
但是,在问这个问题时, 可能忘了:
如果您想更加详尽的分析 Debian 安全小组在漏洞上消耗的时间, 应当考虑新的
DSA(参见Debian 安全公告, 第 7.2 节)在
安全站点
上的张贴, 使用
metadata 生成它们, 包括与漏洞数据库建立连接, 您应当从 web 服务器(从 CVS
)上下载源代码或 使用 HTML 页面来确定
Debian 修复漏洞所花费的时间, 并且与公共数据库相比较.
Securing Debian Manual
v3.2, Mon, 20 Jun 2005 08:01:11 +0000jfs@debian.org
etony@tom.com