您应当经常的进行系统安全更新. 就如 paper by Bill
Arbaugh
(发表于2001 IEEE 关于安全和保密的讨论会)中所述, 多数的
Exploit 源于已知漏洞没有及时的打上补丁. 更新的描述参见 进行安全更新, 第 4.2 节.
Debian 提供了一个用于检查系统是否需要更新的工具(参见后边的 Tiger), 但是很多用户更愿意手动检查是否有有效的安全更新.
如果您如 进行安全更新, 第 4.2 节 所述, 配置了系统. 那么, 仅需要:
# apt-get update # apt-get upgrade -s
第一行将从您配置的源下载可用软件包列表. -s 将做一个模拟运行, 即并不真的下载, 并安装软件包, 而只是告诉您将会下载/安装哪些. 从输出中, 您可以知道 Debian 对哪些软件包做了修补, 可以做为一个安全更新. 例如:
# apt-get upgrade -s Reading Package Lists... Done Building Dependency Tree... Done 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable) Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
在这个例子中, 您可以看到系统需要更新 cvs 和 cupsys 软件包, 其在 woody
的安全站点上得到了修补. 如果您想要了解为什么需要这些软件包, 可以浏览 http://security.debian.org
,
检索与这些软件相关的最近张贴的安全公告. 在这个例子中,相关的安全公告是 DSA-233
(for cvs)
和 DSA-232
(for
cupsys)
自动安全更新的另一个办法是使用 cron-apt
.
此软件包提供了一个定期更新系统的工具(使用 cron job).
它将按照默认更新软件包列表, 并下载新的软件包.
我也可以将其配置为发送邮件给系统管理员.
注意, 如果您打算自动更新系统(甚至仅仅下载软件包), 您也许想检查发行版, 如 发行版检查, 第 7.4.2 节 所述. 否则, 您无法确保下载的软件包真的来自一个可信任的源.
如果您正在寻找一个能够快速检查并报告系统安全漏洞的工具, 可以试试
tiger
软件包. 它提供了一套 Bourne shell 脚本, C 程序,
和用于完成安全审查的数据文件. Debian GNU/Linux 软件包针对 Debian 发行版,
做了一定的改进, 比 TAMU(甚至 TARA, ARSC 发行的一个 tiger 版本)的 Tiger
脚本提供了更多的功能. 更多信息,参见 README.Debian 文件和联机手册
tiger(8)
.
deb_checkadvisories 脚本就是其中一个. 此脚本采用 DSA 列表, 检测 against the installed package base ,并依据 Debian 安全小组报告所有的存在漏洞的软件包. 除了轻微的变化外, 此 Tiger check_signatures 脚本将检查已知漏洞程序的 MD5sums 值.
因为 Debian 的当前版本并不提供已知漏洞程序的 MD5sums 值列表(被其它操作系统,如 sun Solaris 所使用 ), 故只能使用 check-against-DSA 方法. DSA 方法和 MD5sums 方法都存在签名必须经常更新的问题.
当前的解决方法是, 使用最新版本的 Tiger 软件包, 但是软件包的维护者可能不能在每个
DSA 发布时都产生一个新的版本. 还未被使用, 但可能将被使用的一个好的解决办法是,
从网上下载 DSAs, 制做列表, 然后运行检测. 这个 DSAs 是从维护者本地
CVS更新到最新, 其源自用于创建http://security.debian.org
(这是
web 服务器)的 WML 源.
用程序去分析通过电子邮件或者由 security.debian.org 获取的 DSAs, 然后用
'deb_checkadvisories' 生成的文件, 来确认漏洞是否值得注意. 并将其作为一个
tiger
的报告发送.
提到的检测, 是指通过运行安装时完成配置的标准程序来完成(参阅
/etc/tiger/cronrc
):
# Check for Debian security measures every day at 1 AM # 1 * * deb_checkmd5sums deb_nopackfiles deb_checkadvisories #
您可能还要增加一个附加的检查, 它并不是标准 cron
脚本的一部分.
这是一个脚本检查补丁, 用下边的方法运行:
如果您正在运行一个 stable 系统, 添加 security.debian.org
apt
源到 /etc/apt/sources.list
(如< ref
id="security-update"> 所述),
这个脚本会告诉您是否有您需要安全的新软件包.
因为只有修改了的软件包才会安全更新, 故而您只会得到想要的
当然,如果您使用的是 testing 或 sid/unstable 系统, 将不能这样做, 因为当前新包可能比安全更新要多.
您可以添加下边的脚本用以检查 cron
的工作(在前面的配置文件中), 并且
tigercron
将会 mail(给在 /etc/tiger/tigerrc
中
Tiger_Mail_RCPT 项设置的用户)新的软件包:
# Check for Debian security measures every day at 1 am # 1 * * deb_checkmd5sums deb_nopackfiles check_patches #
您也许还想查看一下 secpack
, 这是一个由
Fruhwirth Clemens 完成的非官方的程序, 用于从 security.debian.org 完成安全更新,
带有签名检查.
除非您想在漏洞出现的时候自己修补, 否则您不应该在生产级系统上使用 Debian 的 unstable 分支. 主要原因是 unstable 不存在安全更新(参见对于 testing 和 unstable 版本其安全问题如何操作?, 第 11.3.7 节).
事实上, 一些安全问题可能出现在 unstable 中,但在 stable 版中没有. 这归结于那里提供的程序经常增加新的功能. 并且可能有些新的程序并未通过测试.
为了对 unstable 分支进行安全更新, 您可能必须全部更新到新版本(其影响远远不止对软件包). 尽管存在一些例外, 安全补丁通常只进入 stable 分支. 其主要想法是在更新之间不再加入新的代码, 主要进行修补重大问题.
如果您正在使用 testing 分支,那么您则必须考虑一些有关可用安全更新的问题:
根据发行版的发行状态, 这种方式可能会改变. 当一个发行版将要放出时, 安全小组或软件包维护者可能对 testing 直接提供更新.
首先,并不十分推荐自动更新, 因为管理员应当查阅 DSA, 并了解每次安全更新的影响.
如果要自动完成系统的更新, 您应该:
apt
, 使您不想升级的软件包保持当前版本, 使用 apt
的 pinning 特性, 或者用 dpkg
或 dpkg
将其标记为hold.
你可以通过在 /etc/apt/preferences
(参见
apt_preferences(5)
)中加入以下内容,将软件 pin 在指定版本之下:
Package: * Pin: release a=stable Pin-Priority: 100
FIXME: 检查这种配置的正确性.
cron
条目, 使其每天运行更新, 例如:
apt-get update && apt-get -y upgrade
-y 选项将使得在更新过程中所有可能出现的提示 apt
都假设为 'yes'. 在某些情况下, 您可能想使用 --trivial-only
选项取代 --assume-yes(等同于 -y). [39]
cron
使 debconf
在升级过程中不再要求任何输入,
以便 debconf 不会请求任何输入在升级期间,就象不需要交互一样. [40]
cron
的执行结果, 它将会通过mail发送给超级用户(除非修改了与
MAILTO 环境变量相关的脚本).
使用 -d(或 --download-only)选项也许会更加安全,
这样只下载所需的软件包, 而并不安装. 然后如果 cron
执行的结果显示系统需要更新, 就手动完成.
为了完成这些工作, 需要正确配置系统以下载安全更新如进行安全更新, 第 4.2 节中建议的.
但是,如果没有经过仔细的分析, 并不推荐在 unstable 中这样做, 因为如果您安装到系统中的一个重要的软件包中存在严重 bug, 可能会使系统崩溃. 对于这种问题, testing 相对要好一点. 因为严重的 bug 在进入 testing 分支前有更多机会被检测出来.(尽管,您可能没有任何安全更新可用).
如果您使用一个混合版本, 即在 stable 版中安装有更新到 testing
或 unstable 版本的软件包, 您即可以使用 apt-get
升级时加入
--target-release 以 只升级您升级过的软件包,也可以修改
pinning 参数完成. [41]
通常完成安装后, 一条基本准则是(即, 如 生成系统快照, 第 4.18 节 所描述)应当经常进行系统完整性检查. 完整性检查有助于发现入侵者对文件系统的改动, 或系统管理的操作失误.
如果可能, 完整性检查应当在离线状态[42]下完成. 这样, 就没有其它系统对操作系统形成干扰, 以避免导致错误的安全信息(即, false negatives), 例如被安装了 rootkits. 系统完整性检查依赖的数据库同样应当保存在只读介质上.
您可以考虑使用有效的文件系统完整性检查工具(如 ref id="check-integ"> 中所述)在线完成完整性检查, 如果离线完成这一工作不太可能. 但是, 除了使用只读数据库这一预防措施, 还要确保完整性检查工具(和操作系统内核)未被篡.
在完整性检测部分提到的一些工具, 比如 aide
, integrit
或 samhain
已经可以完成周期性检查(在第一第二方案可通过 crontab,
samhain
可以通过独立的守护进程)并可在文件系统发生改变时通过不同的渠道(通常为 e-mail,
samhain 还可以发送页面, SNMP traps 或系统日志警告) 给管理员发送警告.
当然, 如果您对系统进行了安全更新, 应当重新制作系统快照, 以包容安全更新所产生的改动.
Debian GNU/Linux 中提供入侵检测工具, 用于检测您本地系统或您私有网站中其他系统的不恰当或恶意活动. 如果系统非常重要, 或者您非常偏执, 这种预防是非常重要的. 入侵检测常用的方法有异常收集和特征匹配.
谨记, 为了使用介绍的工具真正改善系统的安全性, 您需要到位的报警和响应机制. 如果没有报警, 入侵检测将会非常费时.
当检测到一次特殊的攻击时, 多数的入侵检测工具要么使用 syslogd
记录事件, 要么要么发送邮件到 root 用户(邮件接收者是可以配置的).
管理员必须正确的配置这些工具, 以便错误的信息不会触发报警.
报警也许还表明当一次持续的攻击, 也许一天以后已经没用了, 因为攻击可能已经成功了.
因此要确保正确的处理报警的策略以及相应的技术机制应当到位.
CERT's
Intrusion Detection Checklist
提供了很多有趣的信息.
基于网络的入侵检测工具监测在网络上传送的数据段, 并将其作为数据源. 具体就是审查网上的数据包, 看是否与某些特征匹配.
Snort
是一个轻量级的数据包嗅探器或记录器,
使用攻击特征字典检测攻击. 它可以检测出各种各样的攻击和探测, 譬如缓冲溢出,
端口扫描, CGI 攻击, SMB 探测, 等等. snort
还有实时报警的能力.
您可以将 snort
象用于主机一样用于您的网络. 使用 apt-get
install snort 完成, 回答紧跟的问题, 并查看日志.
更大一点的安全框架Prelude
Debian 的 snort
软件包默认可以用于许多安全检测.
但您应当根据运行在您系统上的服务来定制设定. 您也许想添加针对这些服务的设定.
注意: woody 提供的 snort 软件包有点老, 并且有很多 问题
,
您可以使用维护者在 http://people.debian.org/~ssmeenk/snort-stable-i386/
处提供的 Snort 移植软件包
还有一些相对简单的工具可以用来检测网络入侵. portsentry
是一个很有趣的软件包, 它可以发现端口扫描并对端口扫描作出反应. 其它类似
ippl
或 iplogger
的一些工具也能检测一些 IP(TCP 和
ICMP)攻击, 即使他们不如 snort
性能高.
您可以用 Debian 提供的 idswakeup
软件包测试这些工具, 它是一个shell
脚本, 可以产生假警报, 并包括许多常见的攻击特征.
基于主机的入侵检测包括在被检测的系统中加载软件, 其使用日志文件和/或系统的检测程序作为数据源. 它搜寻可疑的进程, 监视主机的访问, 也许甚至监控对重要文件的修改.
Tiger
是一个较老的入侵检测工具, 从 Woody 开始就引入 Debian 了.
Tiger
提供与安全侵入有关的常规问题检查, 如密码强度, 文件系统问题,
通信进程, 以及其它可能危及 root 安全的方面. 这个软件包含的新的 Debian
相关安全检查有: 安装软件包, 不属于软件包的本地文件的 MD5sums 检查,
以及本地监听进程的分析. 默认的安装设置 tiger
每天运行,
并生成关于可能危及系统的问题报告发送给超级用户.
日志分析工具,譬如 logcheck
也可用于检测试图的入侵. 参见 使用和定制 logcheck
, 第
4.12.1 节.
另外,用于监测文件系统完整性的软件包(参见 文件系统的完整性检查, 第 4.16.3 节)在检查一个安全系统的异常现象时也非常有用. 一个有效的侵入很可能会 修改一些本地文件系统中的文件以绕过本地安全策略, 安装木马, 或创建用户. 这些事件通常可以通过使用文件系统完整性检查工具检测到.
可加载内核模块是指包含动态可加载内核组件的文件, 用于扩展内核功能. 使用模块最大的好处是在添加另外的设备时, 如网卡或声卡, 不必修补内核源码, 并重新编译整个内核. 然而, 现在黑客将 LKMs 用于 root-kits(knark 和 adore),在 GNU/Linux 系统中开启后门.
LKM 后门比传统的 root-kits 更加先进和隐蔽. 可以隐藏进程, 文件, 目录,
甚至连接而不必修改二进制源码. 例如, 一个恶意的 LKM 可以迫使内核隐藏源自
procfs
的进程, 这样即使是著名的 ps
也不能列出关于系统的当前进程的准确信息.
有两种方法保护您的系统免受 LKM 伤害, 主动防护和被动防护. 检测工作可能是简单和轻松的, 或是麻烦和繁重的, 这和采取的方法有关.
这种防护的好处是首先避免了对系统的破坏. 首先装载一个设计好的 LKM,
以保护系统不受其它恶意 LKM 的破坏. 然后解除内核自身的能力. 例如,
完全解除可加载内核模块的能力. 注意, 但在这种情况下有些 rootkits 仍然可以运行,
有些是直接修改 /dev/kmem
(kernel memory) 使其自身不会被探测到.
Debian GNU/Linux 仅提供很少的软件包用于挂载一个主动防御防护:
kernel-patch-2.4-lsm
- LSM 是 Linux 的安全模块框架.
lcap
-
一个用于解除内核的能力(基于内核的访问控制)的友好用户界面,
使得系统更加安全. 例如, 运行 lcap CAP_SYS_MODULE [43] 将会解除模块加载能力(即使是
root 用户). [44]
关于能力的更多信息请翻阅 Jon Corbet 的 Kernel development
的LWM部分(1999年12月)
如果您的 GNU/Linux 系统确实不需要那么多的内核特性,
您可能想在内核配置阶段取消可加载模块支持. 禁用可加载模块支持,
只要在构建内核的配置阶段或者在 .config
文件中设置 CONFIG_MODULES=n
就可以了. 这将能防止 LKM root-kits, 但是你也将丧失 Linux 内核的强大特性.
同时, 有时对可加载的支持是必须的, 禁用可加载模块可能会引起内核过载.
被动防护的优点是不必重载系统资源. 其通过将系统与一个已知干净系统的清单
System.map
相比较. 当然, 被动防护只能在系统被攻克以后通知管理员.
可以使用 chkrootkit
软件包来完成对Debia中一些 root-kits 的检测.
Chkrootkit
程序检查目标系统中的一些已知 root-kits 的特征, 不过检测结果并不是决定性的.
由 S0ftproject 小组提供的 KSTAT
(Kernel Security
Therapy Anti Trolls) 是另一个很有用的工具. KSTAT
检查目标主机的内核的内存区(/dev/kmem
),
以协助系统管理员发现和删除恶意的 LKMs.
这大概是最不稳定和滑稽的部分, 因为我希望一些 "咄, 这听起来疯狂的" 的想法可以变成现实. 下边仅仅是一些增加安全的一些想法 — 天才, 偏执, 疯狂还是灵感, 这取决于您的视角.
chattr
修改文件属性(源自 Jim Dennis 的 Tips-HOWTO).
安装一个干净的系统, 完成初始化配置后, 使用 chattr
程序带有
+i 属性将文件设为不可修改(文件不能删除, 重命名, 连接, 或写入).
考虑将 /bin
, /sbin/
, /usr/bin
,
/usr/sbin
, /usr/lib
目录下的文件 和内核文件由 root
设置为此属性. 您也可以使用 tar
或类似的命令将 /etc/
目录下的所有文件制作一个备份, 并将其标记为不可修改.
这个策略有助于您缩小以 root 登录所能造成的损害. 您不能直接重写一个文件,
您也不能用不慎使用的 rm -fr
命令(这仍会对您的数据造成很大破坏
— 但是您的 libraries 和 binaries 是安全的)将系统弄瘫痪.
这个策略也可使系统免受拒绝服务攻击(DoS), 或使其更加困难(因为大多数基于通过激活一些 SETUID 程序, 来重写一个文件,这并不能避免随意的 shell 命令).
在构建和安装各种系统程序期间不便使用此策略. 另一方面, 它会阻止 make
install
重写文件. 当您忘记阅读 Makefile 文件,并用 chattr
-i
将文件(和您要添加文件的目录)置为可读时 - make 命令将会失败,
您只能使用 chattr
命令, 然后重新运行. 您还可以很好的使用这种方法,
例如将您的旧程序和库文件, 移入一个 .old/ 目录或进行 tar 归档.
注意这个策略将会使您无法升级系统, 因为被更新的文件是无法重写的.
您也许需要一个脚本或机制使得在 apt-get update
前取消所有程序的不可修改标志.
FIXME: 需要更多针对 Debian 的具体内容.
蜜罐(honeypot)是一个设计来让系统管理员用于学习黑客如何探测和利用一个系统的系统. 这个系统的设置目的是希望被探测, 攻击, 和潜在的利用. 通过学习黑客使用的工具和方法, 系统管理员可以更好的保护他们的系统和网络.
一个 Debian GNU/Linux 系统, 如果您花时间实施和监测它, 可以很容易地配置成一个蜜罐(honeypot). 简单的设定带有防火墙的假定服务, 和网络入侵探测器. 并把它放到互联网上, 然后等待. 注意如果系统被利用, 您应该及时获取警告(参见 日志与警告的重要性, 第 4.12 节)以便您采取适当的措施和 如果您觉得可以了时, 终止攻击. 当您配置蜜罐时, 有些软件包和问题需要考虑:
syslog-ng
, 可用来从蜜罐发送日志到远程 syslog 服务器.
snort
, 用于抓取目标为蜜罐的网络流量, 并检测攻击.
osh
, 一个 SETUID root, 提高安全性, 限制 shell 的登录(参见后边的
Lance Spitzner 的文章).
Deception Toolkit
tct
).
在 Lanze Spitzner 的很棒的文章 To
Build a Honeypot
(源自 了解你的敌人 系列), 或 David Raikow 的
Building
your own honeypot
中, 您可以学到很多构建蜜罐的知识. 并且,Honeynet Project
也提供了珍贵的关于构建蜜罐和攻击检测的资料.
Securing Debian Manual
v3.2, Mon, 20 Jun 2005 08:01:11 +0000jfs@debian.org
etony@tom.com