Paranoid Penguin - Linux 安全的未来

作者:Mick Bauer

您知道我撰写这个专栏已经有五年多的时间了吗?这五年真是充满了各种事件!在这段时间里,我们看到 Linux 的一些最大的前竞争对手拥抱了它,并且 Linux 作为桌面平台也取得了显著的进展。

在 Linux 安全领域,也取得了显著的进步。Linux 的防火墙功能现在已经非常成熟,它已经成为许多嵌入式防火墙设备的基础,更不用说无数与安全无关的设备了。Linux 支持种类繁多的安全工具,使其成为安全审计员和顾问的最爱。此外,Linux 已经成为几种超安全的角色based access control (RBAC)操作系统的基础,最著名的是 NSA 的 SELinux。

但是 Linux 安全的未来会怎样呢?我已经写了很多关于 Linux 当前和过去的安全问题,但从未写过关于未来的内容,除了我对具有前瞻性的 Richard Thieme 的采访。本月,我想稍微放纵一下,进行一些推测和评论,谈谈我认为 Linux 安全将走向何方,以及我认为它应该走向何方。

当前的问题是什么?

很多人最近对 Linux 安全的认识是,典型的 Linux 系统并不比典型的 Microsoft Windows 系统安全多少。在电子邮件的口水战开始之前,请允许我解释一下这句话。首先,就我个人而言,我确实认为 Linux 比 Windows 更安全,并且多年来我已经在本专栏中多次说过。用户对他们的 Linux 系统的行为的控制权比他们对同等的 Windows 系统的控制权更大。

问题在于,Linux 用户和 Windows 用户一样,往往将大部分精力集中在使他们的系统做他们需要做的事情上,并且他们对系统内置或默认的安全设置过于信任。然后,当不可避免的软件漏洞出现时,这些漏洞的影响往往比采取更多预防措施时更大。

例如,如果我运行 BIND v9 来提供名称服务,则需要一些工作和研究才能使事情正常运行。要使 BIND 在 chroot 监狱中运行,还需要更多的工作,这样 named 进程只能看到和使用服务器文件系统的一个子集。因此,许多(如果不是大多数)BIND 用户倾向于在 chroot 监狱中运行 BIND。当 BIND 漏洞在野外出现时,大多数 BIND 用户可能会比他们做了 chroot 的事情遭受更多的痛苦。这可能与他们运行一个安全功能比 BIND 少的 Microsoft 名称服务器所遭受的痛苦程度相同。

所有这一切都只是想说,Linux 的许多安全特性和功能都没有被其用户利用。最终结果是,至少根据我的经常进行专业渗透测试的朋友的说法,您的平均 Red Hat Enterprise 系统并不比您的平均 Windows 2003 Server 系统更难攻破。

这令人遗憾,也许令人惊讶。鉴于其代码库的完全透明性,Linux 似乎仍然容易出现与 Windows 相同类型的软件错误,数量和频率大致相同。但是,如果您仔细想想,为什么不会这样呢?与 Windows 一样,Linux 代表着由数百个不同的人产生的惊人复杂的代码集合。代码越多,可能存在的错误就越多,对吗?

我最近接受了 SearchSecurity.com 的采访,为一篇关于 Security Innovation, Inc. 进行的 Microsoft 资助研究的文章。该研究的结论是 Windows 比 Linux 更安全,该结论主要基于安全错误的频率和发布补丁的平均时间。我认为我正确地批评了该研究仅关注这些易于量化的安全方面,而没有考虑到 Linux 的其他安全优势,例如可定制性和更多软件软件包的选择。换句话说,我认为该研究在比较默认安装场景时最相关,而与每个操作系统被其用户保护的潜力无关。

但是,我越想这件事,就越担心,除非大多数运行该平台的系统实际上达到了该潜力,否则平台的安全潜力就毫无意义。这不仅仅是最终用户行为的功能;我并不是想指责系统管理员。正如我稍后详细阐述的那样,我认为 Linux 的开发者和发行商必须继续找出使安全功能更加普遍、透明且易于配置和使用的方法。顺便说一句,因为我将 Linux 与 Windows 进行比较,为了公平起见,我应该指出 Windows 也有许多安全功能,但其用户通常不会利用这些功能。

好的,Linux 和 Windows 的默认安全性都比它们可能达到的水平低得多,而且两者都面临着软件错误和安全补丁之间一场无法取胜的竞赛。我们还面临着什么?

唉,这两个操作系统都使用相当原始的自主访问控制模型,其中整个类别的安全设置和行为都是可选的。在这个模型中,一个超级用户帐户——Linux 中的 root,Windows 中的 Administrator——对整个系统拥有上帝般的权力,包括其他用户的文件。在两个操作系统中,可以使用组成员身份来创建不同的访问级别,例如,委派各种 root 权限。然而,在实践中,在大多数系统上,您必须以超级用户身份登录或暂时成为该用户才能执行任何重要的操作。

因此,获得对任何 Linux 或 Windows 系统的完全控制权,就是攻陷任何以超级用户权限运行的进程的问题。但是等等,您说,我已经配置了我的重要守护进程以非特权用户身份运行;这些守护进程中的错误不会导致完全的妥协,对吗?不,不是直接的,但其他软件中的错误可能会使非 root 进程有可能提升其权限。例如,假设您有一个运行 Apache 的 Web 服务器,有一天攻击者设法利用了未修补的 Apache 缓冲区溢出漏洞,导致攻击者在您的服务器上获得了一个 shell 会话。此时,攻击者以 www 身份运行,因为那是 Apache 运行的用户。但是,假设该系统还有一个未修补的内核漏洞,该漏洞涉及本地权限提升。

您,系统管理员,甚至可能知道这个漏洞,但选择不修补它,因为毕竟,这严格来说是一个本地漏洞,除了您之外,没有人在这个系统上拥有 shell 帐户,而且谁想在修补内核后必须重新启动?但是现在远程攻击者确实拥有本地 shell 访问权限,如果她成功利用了这个内核漏洞,她就是 root 了!这个非常常见的场景说明,错误已经够糟糕了,但当它们与 root-takes-all 安全模型结合在一起时,情况会更糟。

简而言之,这就是 Linux 安全的现状。保护 Linux 需要我们付出相当大的努力来充分利用有时很复杂的安全功能,这些功能通常默认情况下不启用,要始终保持所有安全补丁的最新状态,并在 Linux 简单安全模型的限制范围内完成所有这些工作。但是我们并不孤单:大多数常用的现代操作系统都具有完全相同的限制和挑战。

强制访问控制

我已经暗示过,Linux、一般 UNIX 和 Windows 上的访问控制或文件权限是自主的,这是一种薄弱的安全模型。那么,SELinux 呢?它不是使用了 RBAC 和类型强制 (TE) 吗?这两者都是强制访问控制的例子。是的,的确如此。但我恐怕这可能不是 Linux 安全的未来,原因与 SELinux 不是当前 Linux 安全的巨大组成部分的原因相同。

RBAC 根据精心定义的角色来限制用户的行为和对系统资源的访问,这些角色类似于但比传统的 UNIX 组机制更广泛。类似地,类型强制根据进程预定义的运行域来限制进程的活动。RBAC 和 TE 的最终效果是创建隔离的孤岛(我的术语),用户和进程在其中运行,并且只允许在孤岛之间进行严格限制的交互。

这是一个优雅而有效的安全模型。但是,对于大多数人来说,RBAC、TE 和其他强制访问控制过于复杂,并且涉及过多的管理开销。在许多人看来,这注定了 SELinux 和类似的操作系统只能成为利基解决方案:对于具有特定需求和能力的人们有用的操作系统,但注定不会被广泛采用。尽管我欣赏 SELinux 的安全架构,并且是 RBAC 概念的拥护者,但我认为强制访问控制本身不太可能彻底改变 Linux 安全。

虚拟机监控器和虚拟机

如果 RBAC 和 TE 确实被证明过于笨拙,无法在操作系统级别隔离安全漏洞,那么虚拟机监控器和虚拟机 (VM) 可能会在更高的级别实现这一点。我们已经熟悉两种不同上下文中的虚拟机:运行时虚拟机环境(例如 Java 程序使用的环境)和虚拟平台(例如 VMware、plex86 和 VirtualPC),它们允许您在虚拟化硬件环境中运行整个操作系统。

Java 虚拟机在设计时考虑了特定的安全功能,最著名的是 Java 沙箱。总的来说,Java 安全性来自于 Java 小程序与原始或真实系统资源隔离运行的事实;一切都由 Java 虚拟机进行调解。除了是一个良好的安全模型之外,对于程序员和最终用户而言,安全使用它也相对简单。Java 也因多种原因而已经无处不在。

虚拟平台通过不仅调解单个程序,还调解运行它们的操作系统,将这个概念更进一步。然而,这种情况下的安全架构不如 Java 虚拟机成熟。在大多数情况下,安全留给了在虚拟环境中运行的 guest 操作系统。因此,在 VMware 上运行的 SUSE Linux 虚拟机与在自己的硬件上运行的真实 SUSE 系统相比,安全性既不高也不低。

虚拟机监控器技术解决了隔离在同一硬件上运行的虚拟机彼此隔离、限制它们的交互以及防止一个虚拟机上的安全漏洞影响其他虚拟机的需求。IBM 为虚拟机监控器创建了一个名为 sHype 的安全架构。一个名为 Xen 的开源虚拟机监控器/虚拟机项目也可用。

虽然虚拟机监控器的驱动目的是防止任何一个虚拟机干扰在同一硬件上运行的其他虚拟机——例如,通过垄断共享硬件资源——但在这一级别拥有某种智能管理系统的想法非常强大。它甚至有可能超越或至少显著增强传统的入侵检测系统 (IDS) 作为检测和遏制系统漏洞的手段。

强制访问控制和虚拟机监控器/虚拟机并非相互排斥。一方面,我坚信,我的朋友和安全分析师同事 Tony Stieber 对此有很大影响,虚拟机监控器比 MAC 更有可能塑造 Linux 安全的未来。但另一方面,两者可以一起使用。想象一下一个大型、强大的服务器系统,运行着由虚拟机监控器控制的多个虚拟机。一个虚拟机可以运行通用操作系统,例如 Linux,充当 Web 服务器。另一个虚拟机,充当敏感信息的数据库,可以运行基于 MAC 的操作系统,例如 SELinux。两个虚拟机都将受益于虚拟机监控器强制执行的安全控制,而 SELinux 则提供额外的安全级别。

基于异常的入侵检测和防病毒

另一种技术,与 MAC 和虚拟机监控器一样,今天已经存在,但可能会对未来产生更大的影响:基于异常的入侵检测系统。基于异常的 IDS 的想法很简单:它涉及创建正常网络或系统活动的基线,并在检测到任何意外或异常行为时发送警报。

如果这个想法很简单,并且技术已经存在,为什么这种方法不常用呢?因为它远不如签名匹配成熟或易于使用。我们都熟悉基于签名的 IDS;它们维护攻击签名的数据库,并将其与观察到的网络数据包或一系列数据包进行比较。如果给定的数据包与攻击数据库中的一个数据包匹配,则该数据包被判断为攻击的一部分,并发送警报。

这种方法的优点是它易于使用,并且通常涉及很少的误报或误报警报。基于签名系统的致命弱点是,如果攻击太新或太复杂,以至于您的 IDS 的签名数据库中没有相应的签名,则无法检测到它。

相比之下,使用基于异常的 IDS,任何与正常行为有足够差异的新攻击都会被检测到。权衡是 IDS 管理员必须训练并定期重新训练 IDS 系统,以便创建正常行为基线。这会导致一段时间内频繁的误报,直到基线被微调。

我在 1999 年左右参加了 Marcus Ranum 的一次讲座,他在讲座中将基于异常的系统描述为 IDS 的未来。显然,我们还没有达到那个目标。Lancope 和 Arbor Networks 等供应商提供了此类产品。但我仍然希望有人能找出如何以比当前系统更便宜且更易于使用的方式来做这类事情。潜在地,这可能会导致一种网络虚拟机监控器,它为网络提供与虚拟机监控器为虚拟平台提供的相同类型的智能,无论网络是由虚拟机器还是真实机器组成。

顺便说一句,病毒扫描程序与 IDS 一样,也需要并且可以从异常检测技术中受益。绝大多数使用现代病毒扫描程序(几乎完全依赖病毒签名匹配)的组织仍然遭受重大病毒/木马/蠕虫爆发的事实充分说明了这一点。当前的基于签名的防病毒工具显然不够有效。

结论——以及暂别

这些就是我对 Linux 安全未来的看法。与此同时,继续使用本专栏多年来一直关注的技术:防火墙、病毒扫描程序、自动补丁/更新工具、VPN 和特定于应用程序的安全控制,例如 chroot 监狱和审计跟踪。

说到这里,我向您告别,不仅是本月,而且是无限期地告别。现在是我专注于其他事情至少一段时间,并让新鲜的声音接管 Paranoid Penguin 的时候了。我将继续担任安全编辑的角色,并将继续尽我所能帮助Linux Journal为您带来出色的安全内容。我也会尝试时不时地自己撰写一篇文章,以临时的方式。但是您现在正在阅读的文章是我作为本专栏的独家作者的最后一篇文章。

感谢大家五年来的支持、鼓励和教诲——我从未在本专栏中犯过错误,而没有被外面的某个人注意到并纠正,而且总是对我有益。这真是美好的五年,我感谢这家出色的杂志的工作人员和读者们为我所做的一切!

本文的资源: /article/8329

Mick Bauer,CISSP,是Linux Journal的安全编辑,也是明尼苏达州明尼阿波利斯市的 IS 安全顾问。O'Reilly & Associates 最近发布了他的著作 Linux Server Security 第二版(2005 年 1 月)。Mick 还创作工业波尔卡音乐,但有良好的品味,很少演奏。

加载 Disqus 评论