安全性

精彩辩论:通过隐匿性来实现安全

Jesper M. Johansson and Roger Grimes

 

概览:

  • 定义通过隐匿性来实现安全
  • 评估通过隐匿性来实现安全措施
  • 评估重命名管理员帐户的价值
  • 制定明智的风险管理决策

“通过隐匿性来实现安全”这种说法经常遭到安全性人员(特别是那些喜欢以专家自居的人)的嘲笑。他们对此不屑一顾,认为很愚蠢。

根据 Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity) 的注释,通过隐匿性来实现安全体现了安全性真正有争议的一个方面。您经常可以看到一些人遭到嘲笑,他们的努力被否定为“只是通过隐匿性来实现安全”。

简而言之,通过隐匿性来实现安全违反了 Kerckhoffs 原理,该原理认为应该靠系统的设计来确保系统安全性,而不是让攻击者无法知晓系统的设计来确保系统安全性。Kerckhoffs 原理的基本前提是秘密迟早会被揭开。

Windows NT® LAN Manager (NTLM) 身份验证协议就是一个很好的例子,该协议最初被认为是设计机密。为了对基于 UNIX 操作系统实施 Samba 互操作性产品,Samba 小组不得不对该协议进行反向工程。结果导致有关 NTLM 最完备的文档全部泄露 (monyo.com/technical/samba/translation/ntlm.en.html),同时也发现了许多错误。由于加密产生了太多安全性问题,并且很多机密设计也被揭示,因此很多安全性实践人员都认为所有信息安全性都应遵循 Kerckhoffs 原理。

但通过隐匿性来实现安全总是有害吗?在这篇文章中,我们会解释什么是通过隐匿性来实现安全,阐述为什么许多人认为这是浪费时间(另外一些人则不以为然),并向您说明为什么答案总是比最初看起来要复杂得多。

通过隐匿性来实现安全简介

Steve Riley 的观点:不要更改默认设置

对于重命名问题,我的观点是“不要更改”。这实际上不是安全性问题,而是系统管理问题。随着我在研究系统管理空间上花费的时间越来越多(因为管理和安全性已成为一体),就越来越反对进行任何有可能增加系统易受攻击性的操作。更改默认设置就是这样一种肯定会增加易受攻击性的方法。人们更改默认设置的原因有两个(喔,确切地说是三个):

  • 通过更改可以实现某种已知的功能。
  • 认为更改可以提高安全性。
  • (警告:这是非常愚蠢的行为。)有人在杂志文章中看到过这方面的内容。

如果您基于第一个理由需要更改默认名称,完全可以这样做。这类更改通常很少造成系统不稳定,因为它们先前已经过测试。

如果您是基于第二个理由更改默认设置,请三思而后行。这些类型的更改几乎从未经软件制造商测试过,因此制造商无法预测更改后系统会有什么反应。此外,一般来说,还有更佳的替代方案可以为您提供真正的安全性。

如果攻击者刚好知道帐户名称,那该怎么办呢?这时只能靠密码和密码强度来保护系统。极力把管理员和来宾等默认帐户名称更改为不易猜测的内容,实际上往往是想逃避使用强密码和密码短语。解决真正的问题(不安全的密码),才可以避免受到攻击(更改默认名称)。

这里讨论的通过隐匿性来实现安全,并不包括对缓解问题完全没有任何实质作用的措施。例如,如果某组织在边界路由器处禁用了网络新闻传输协议 (NNTP) 以防止员工阅读新闻组,但是却允许出站 Secure Shell (SSH),则不算是通过隐匿性来实现安全。因为 SSH 允许通过每个协议,所以问题很明显;实施的愚蠢缓解措施除了防止合法用户在不违反安全性策略的前提下完成合法任务外,没有任何意义。这样的措施不算是通过隐匿性来实现安全;它们只是愚蠢的做法,没有任何意义。

正如“通过隐匿性来实现安全”这种说法中的“安全性”所暗示的那样,您应该确实可以从这种措施中得到保护。然而,同时也暗示了实际上您并未采取任何措施来阻止对一个或多个平台的攻击,这也是问题所在。(攻击平台实质上是攻击者访问系统所采用的一种方法。)

例如,假定您有一个易受攻击的 Web 服务器,可以通过 TCP 端口 80 利用公开漏洞对此服务器进行攻击。要堵上这个漏洞,您可以修补 Web 服务器或者将其关闭;其中任一操作都将完全停止此平台。通过使用防火墙或 IPsec 来关闭除几台选定计算机之外的所有计算机的端口 80,可以在某种程度上停止攻击平台。此操作不能完全阻止攻击平台,但是可以极大地缓解问题。

另一方面,通过隐匿性来实现安全需要采取不停止攻击平台而只是隐藏它的措施。例如,您可以将 Web 服务器移动到端口 81 而不是端口 80,以便只有知道 Web 服务器所在位置的人才可以找到它。这也是争论焦点。实际上,将 Web 服务器移动到端口 81 只能停止一些攻击,主要还是给最终用户带来不便。强大的入侵者只需对大量端口运行端口扫描程序和 Web 标志获取程序即可发现位于非标准端口上的 Web 服务器。只要找到一个,就可以对服务器进行攻击,因为您实际上并未消除攻击平台,只是(临时)隐匿它而已。

这是否意味您根本不应该尝试?这要具体问题具体分析。与“信息安全性”领域的所有其他方面一样,全都与风险管理息息相关。为了理解要考虑的关键因素,我们将快速了解一下更多通过隐匿性来实现安全的措施,然后详细讨论其中一项 — 重命名管理员帐户。

评估安全策略

通过隐匿性来实现安全的例子很多。它们可以是系统和网络管理员采取的措施,也可以是由软件开发人员启动的操作。然而,它们的共同点都是通过对潜在攻击者隐藏漏洞来缓解问题。

这些做法难道一点好处也没有吗?断定通过隐匿性来实现安全都有害真的公平吗?对于其中一些措施,您肯定会找到支持者。例如,在 Windows® 的 Windows 资源管理器中隐藏驱动器名。许多环境,尤其是学校的计算机实验室,使用此技术防止用户将数据保存到硬盘驱动器。当然,多数应用程序能仍然可以将数据保存到隐藏的硬盘驱动器,因此它不能作为最终安全性措施。然而,实施这种措施的机构经常宣称它减少了硬盘驱动器中的数据。

Windows 上经常实施的另外一种类型的通过隐匿性来实现安全是关闭管理网络共享(如 C$,Admin$,等等)。这被认为可以防止攻击者从远程连接到计算机。实际上,这不仅不正确,而且,一旦攻击者知晓可使用管理共享的帐户,就可以从远程重新启用那些几乎完全相同的共享。但是许多组织却坚称禁用这些共享可以减少网络上出现的恶意软件。

对于这种把精力错放的情况,我们最津津乐道的一个示例便是 Windows 中的“允许在未登录的情况下移除”设置。如果将其设置为禁用,则将对登录屏幕隐藏“移除计算机”按钮。实施者认为这样可以防止攻击者轻松地移除计算机。当然,任何入侵者都可以轻松地将计算机和基座一同塞到袋子里带走,无论那个按钮是否可见。这种可能性甚至与通过隐匿性来实现安全毫无关系。

另一明显的示例是“允许服务器操作者安排任务”设置,顾名思义,此设置允许作为 Server Operators 组成员的用户安排任务。这是个敏感的问题,因为此类任务可以作为“本地系统”运行,并且应该只有管理员才能安排作为“本地系统”运行的任务。当然,服务器操作员可能会通过各种途径使其成为管理员,因此通过这种方式阻止系统操作员安排任务也没有多大价值。

然而许多组织喜欢此设置,因为它允许工程师作为服务器操作员而不是管理员,这意味着他们不太可能意外地损坏服务器。这本身多少有些好处。

那么结论是什么?很明显,这些问题当中有些可能非常复杂。我们花费了很多时间愉快地讨论这些类型的措施。Roger 坚定地认为这类做法有价值;Jesper 则深信大多数情况这些措施只是在浪费时间。我们来探讨一下通过隐匿性来实现安全的其中一个最常提及且最有争论的案例:重命名管理员帐户。Roger 支持此措施,Jesper 则反对。安全性方面的知名人士 Aaron Margosis 和 Steve Riley 也以辩论双方参加了这场有关“重命名管理员帐户”和“不要更改默认设置”的讨论。

隐藏管理员帐户

安全性专业人员常常建议将重命名管理员帐户 — 相对标识符 (RID) 500 — 更改为一般人不知道的名称,很多 Microsoft 强化指南中也提倡这种做法。组策略甚至包括重命名管理员帐户的设置,如图 1 所示。其理论基础是:如果重命名了管理员帐户,则攻击者就很难以真正的管理员身份登录。当然,使用组策略进行此操作的问题很明显,那就是经过重命名的管理员帐户在应用此组策略对象的每台计算机上都具有相同的名称。这无疑降低了该特定安全性措施的隐匿性价值。

图 1 重命名管理员帐户

图 1** 重命名管理员帐户 **(单击该图像获得较大视图)

在这里必须指出:任何使用合法帐户的用户都可以检索管理员帐户的名称,无论该帐户是否经过重命名。管理员帐户的 RID 始终为 500。只要直接搜索 RID 为 500 的帐户名称,任何拥有帐户的用户都可以看到它的真实名称,如图 2 所示。

图 2 查找重命名的管理员帐户

图 2** 查找重命名的管理员帐户 **(单击该图像获得较大视图)

Roger 的观点

我听到反对重命名管理员帐户的主要论据是:要将任何安全性主体帐户名称转换为相关安全标识符 (SID) 并找到它的 RID 非常简单,而且真正的管理员帐户的 RID 始终为 500。因此,如果攻击者可以很容易地将用户帐户名称转换为 SID/RID 组合,并找出 RID 500,实施攻击就太容易了!

但是事情并不那么简单。若要完成从用户帐户名称到 SID/RID 的转换,您必须具有访问 NetBIOS 或 LDAP 端口的权限。多数外围防火墙不允许通过 Internet 进行这种类型的访问,因此,除非攻击者完全绕过防火墙,否则他根本无法进行转换。此外,除了域控制器 (DC) 以外,Windows XP 以及更高的 Windows 版本并不能进行匿名 SID 转换。对于大多数面向外部的计算机(也就是风险最高的计算机),攻击者需要具有经过身份验证的凭据才能执行从名称到 SID 的转换。

因此,若要发动转换攻击,得绕过不少真正的深度防御障碍才行。即便攻击者克服了这些障碍,也不过是相当于这些帐户名称没有重命名。重命名管理员帐户只会提高安全性,而没有什么实质性的坏处。

另外一个秘密 如果攻击者不知道管理员帐户名称,它就变成了另一个“秘密”标签,跟密码类似,攻击者必须要知道才行。不可否认,用户帐户名称显然那不太可能像管理密码一样复杂,但它仍是一道障碍,极大地增加猜测/破解密码问题的复杂性。如果您曾经进行过密码渗透测试,一定知道同时猜出用户名和密码并不容易。这相当于难上加难。

阻挠自动恶意软件和脚本黑客 我研究 Windows 安全性防御至今已有 22 个年头,过去 5 年来运行了八个公开在 Internet 上的 Windows 蜜罐 (honeypot)。这段时间内,我从来没看过自动恶意软件(绝大多数的攻击都是由此构成)使用除管理员(在 *NIX 系统中称为根)以外的任何用户帐户标签。如果您重命名了管理员帐户,则所有依赖管理员名称的恶意软件会立即失效。换句话说,等于降低了安全性风险。

对于脚本黑客,情况也一样。我所知的每本“畅销”的 Windows 入侵手册都提到了将名称转换成 SID 的方法,但要是我基于某种原因同时设置了一个“假”的管理员帐户来分散注意力,在蜜罐上就完全看不到这种情况。优秀的黑客应该随时确认他们找到的管理员帐户是真正的管理员帐户 (RID 500),但他们通常忘了这一点。我也不清楚具体原因,但应该是由于黑客的懒惰和人的本性。

大多数专业人士也不进行转换 这令大部分人感到惊讶。只要执行蜜罐几年的时间,您就可以很快区分自动攻击、脚本黑客和专业人士之间的差异。过去五年以来,系统报告了上百万次对我的蜜罐的攻击,我却从来没看过专业人士在有假管理员帐户时进行 SID 转换。

我敢肯定某些专业罪犯会进行 SID 转换,但我同样敢肯定那只是极少数人,连我专门研究此类问题的人都从来没有遇到过。为什么专业人士不这么做呢?我猜是他们觉得绝大部分的人都不这么做,他们也没有理由这么做。

简化警报 现在另一方争议,如果重命名管理员帐户开始盛行的话,则可能会失去它作为隐匿方法的价值。争论在于恶意软件、脚本黑客和专业人员会改变一贯战术,寻找管理员以外的名称。言之有理。幸运的是,它并不会改变基本情况。首先,如果未将 Windows 超级权限帐户命名为 Administrator,恶意黑客就必须多下点功夫。事实就是如此,而且如果恶意黑客必须多下点功夫的话,他就更不可能采取这种攻击途径,从而其他弥补深层防御手段能够更快地检测到恶意活动。

这就谈到了我赞同重命名的最后一个观点。如果您的管理员帐户的名称从来不是 Administrator,而且您使用该名称创建了另一个帐户,如图 3 所示,您将拥有一个良好的警报机制。如果事件监视检测到有人尝试使用默认名称登录,则会立即调查该事件。

图 3 尝试以名为 Administrator 的引诱帐户登录可能是前期攻击行为

图 3** 尝试以名为 Administrator 的引诱帐户登录可能是前期攻击行为 **(单击该图像获得较大视图)

我们的事件日志中记录了大量没有任何意义的“不良”登录。这通常不过是指用户(或 Windows)使用错误的密码尝试登录等类似情况。不过,如果您的管理员帐户的名称为 Administrator,如何轻松分辨正常和恶意的登录尝试呢?如果您从来没有名为 Administrator 的登录帐户名,却检测到有人尝试使用该帐户名登录,则它可能是恶意登录。争议很少的早期警告在当今的防御环境下具有重要价值。

Jesper 反驳

Aaron Margosis 对重命名管理员帐户的论点

Jesper,在理想条件下,您绝对没有错。密码的安全级别足以抵御暴力猜测,而也只有在紧急恢复时才会使用 -500 本地管理员帐户。但在现实生活中,情况并非如此。

尽管您在宣传卓越安全性方面做出了很多努力,特别是您编写的密码短语系列太棒了(“精彩辩论:密码短语与密码”第 1、2 和第 3 部分,网址分别为 go.microsoft.com/fwlink/?LinkId=113157go.microsoft.com/fwlink/?LinkId=113159go.microsoft.com/fwlink/?LinkId=113160),许多系统管理员对怎样才是强密码的理解并没有更新。

不久前,从多个字符中随机挑出八个字符构成的密码还被视为强密码,而摩尔定律证明这种情况维持不久。用户(和系统管理员)教育的欠缺是罪魁祸首,而且未来很有可能还是如此,这恐怕到密码强度成为有线电视新闻频道的热门话题时才会有所改观。

所以,假设现在猜测密码不会花费 6000 亿年的时间,通常在午餐时间即可完成,那么,我们将这段时间乘以 1000,显然时间就够长了!与许多以 Administrator 帐户为目标的自动攻击相比,将帐户重命名可使它不易受到攻击。

您可能已经注意到,重命名管理员帐户一般只需投入极少的时间和精力,它只是一项简单的 GPO 设置。事实上,美国政府的联邦桌面核心配置(Federal Desktop Core Configuration,csrc.nist.gov/fdcc)要求必须重命名 -500 帐户。重命名不过是许多必要的设置之一,而且不会花费太多的时间或精力。也没有人过高估计重命名的安全性意义 — 我还没听过有人这么说:“我们不需要补丁管理,因为我们已经重命名了管理员帐户”。

如果整个组织中将帐户重命名为相同的名称,重命名还有意义吗?意义不大,但多少还是有一点:首先,它会阻止以 Administrator 为目标的自动攻击;其次,潜在攻击者未必知道新名称。(当本地管理员帐户 — 无论是否经过重命名 — 在组织内共享公用密码时,风险更大。管理这些密码一直比较棘手,也比较重要。禁用 -500 帐户是解决这种问题的办法之一,但是这在无法使用域帐户时会封锁重要的恢复渠道。)我还要指出,我们的安全指南长期以来就建议重命名默认帐户,因此这种做法不仅经过测试,而且完全受支持。

到目前为止,我们应该都知道隐匿式措施本身所构成的防御并不充足。但它们可以强化其他安全措施,并且 Roger 的数据也清楚地阐明了这一点。只要实施的成本不高,组织就不应该把它们排除在外。

与支持重命名一样,反对重命名管理员帐户也有根据。不过,在继续讨论之前,我必须承认 Roger 的最后一个论点蛮有效力的。但是,在高度托管的环境中,应该调查任何使用管理员帐户的登录,因为除了紧急恢复的情况之外,完全不应该使用该帐户。

多此一举 重命名管理员帐户应当缓解的主要风险是有人从远程猜测它的密码。但重命名管理员帐户只会阻止在计算机上没有其他授权帐户的用户。这类攻击者通常会尝试一连串随机的密码登录管理员帐户。不过,无论攻击者是猜错帐户名还是猜错密码,都会收到相同的错误消息。

这就表明重命名管理员帐户的主要论据之一(脚本黑客会放弃)并不完全正确。他们并不会因为管理员帐户经过重命名而比使用原始名称时消失得更快,因为他们无法分辨!无论如何,他们猜测的都是一组相同的随机密码,然后继续攻击下一个对象。

这表示只要管理员帐户密码的安全级别足以击退攻击,重命名帐户就没有更多意义了。假设管理员帐户的密码包含 15 个字符,由从整个键盘挑选出的大小写字母、数字和符号组成。通过网络猜测该密码大概需要 591,310,404,907 年的时间。呵呵,比宇宙存在的时间长 43 倍。

现在,假设我们对管理员帐户进行重命名,将其命名为 1,000 个可能的值之一。这样一来,我们可将猜测密码的时间延长到 591,310,404,906,787 年,即比宇宙存在的时间长 43,161 倍。这样就比较安全吗?当然,我们安全多了。我们降低了攻击者猜测我们的密码的可能性吗?嗯,根本没有。换句话说,无论是否更改管理员帐户名,被攻击者猜测的可能性是一样的。重命名帐户会抵御尝试使用该帐户名的恶意软件,但不重命名帐户未必就会让恶意软件得逞。事实上,如果您使用强密码(您应该这么做),无论帐户名是什么,都可保证它不会得逞。

很明显,许多安全指南要求重命名管理员帐户,但这并不表示它就是有意义、甚至是有效的安全措施。它只是妨碍了您对安全性做出适当的风险管理决策。安全指南通常要求进行没有什么意义的设置,而且在许多情况下,甚至要求进行根本不存在的设置。最后,要在安全性领域中稳定前进,我们必须突破安全指南要求的限制,实际分析问题,然后评估缓解措施是否有意义。在此,要特别注意一点 — 攻击者以功能为目标本身并不足以构成修改该功能的充分理由。只有在不修改功能会使攻击得逞的情况下,才应修改功能。

如果设有强密码,那么无论是否重命名帐户,攻击成功的可能性实际上为零。因此,只要您设置强密码,就没有特定的安全性理由需要重命名帐户。此外,如果您像我一样认同“对计算机所做的调整和更改越少,计算机越稳定”这一原则,则不对管理员帐户进行重命名才是更合理的。

将注意力转移到低价值缓解措施上 通过隐匿性来实现安全的低价值缓解措施存在一个问题,就是它们可能会转移组织对高价值缓解措施的注意力。例如,在重命名管理员帐户上投入大量时间和精力后,就不能执行其他操作了。如果其他操作比重命名管理员帐户更有意义,则组织就错失了一次机会。听起来好像实际上不需要这样的代价,然而想象重命名 50,000 个管理员帐户,您就会开始产生这种想法。

更糟糕的是,一旦实施低价值缓解措施,组织的领导便会停下来休息,这种可能性非常大。管理层不一定始终能了解通过隐匿性缓解措施来实现安全的意义非常小,因此可能不再采取其他措施。这实际上为组织带来另一个重大风险,只要管理层花费一些时间和精力来了解实施的缓解措施的意义,即可在很大程度上避免这种风险。

高管理成本 最后,根据缓解措施的实施程度,管理成本可能会变得相当大。如果只是通过设置组策略对象 (GPO) 来重命名管理员帐户,则成本非常低。每个人都将知道此名称,因此部署成本几乎为零。然而,它却没什么意义,如上所述,每个拥有帐户的人都会知道此名称。因此,要真正实现此缓解措施的价值,需要对不同的主机使用不同的名称,这样管理系统的成本就会非常高。

使用类似 passgen (protectyourwindowsnetwork.com/tools.htm) 的工具对网络上的所有管理员帐户设置 100 个字符的完全随机密码并使用不同的帐户进行日常管理的效果可能会更好。考虑到管理员帐户专用于灾难恢复(Windows Small Business Server 2003 除外),这对网络管理系统不会产生任何影响。此外,攻击者正确猜测出任意管理员帐户的密码简直比大海捞针还难。设置独特的强密码最能保护系统,让脚本黑客一直猜密码去吧!

归根结底为风险管理

实际上,任何隐匿式安全措施都可以按照我们此处提供的方法进行分析。任何方案都各有利弊,适合于某个组织的正确方法不一定适合其他组织。最后,这就成了风险管理问题。风险是否超过了实施解决方案的成本?在保护信息资产方面做出的每个决策都必须是明智的风险管理决策,很少是选择黑或白这样简单的决策。

的确,已经为您做出了一些决策。例如,您当然可以选择不加密信用卡信息或存储信用卡验证代码,但这样可能让您的信用卡很快被别人破解和透支!风险太大,所以您别无选择,只能对这些信息进行加密。换句话说,这当然也是一项风险管理决策,只不过非常容易做出罢了。

同样,任何一个头脑清醒的人都不会将开放式无线网络连接到物理存储中存储网络的后端。但这并不表示此决策不是风险管理决策。它是。一个人可以选择这样做,并且如果真的做出了这样的选择,他应该承担后果(很遗憾,后果总是无人承担)。

在此,关键是清楚地表述您需要解决的问题、问题的建议解决方案以及每种方案的利与弊。然后,即可获得做出明智的风险管理决策所需的信息。如果没有这些信息,则只能凭直觉做出决策,这样的决策往往很糟糕。

Jesper M. Johansson 是研究安全软件的软件架构师,还是《TechNet 杂志》的特约编辑。他拥有管理信息系统博士学位,具有 20 多年安全方面的经验,并且是企业安全性领域的一位 Microsoft MVP。Jesper 的最新著作是《Windows Server 2008 安全资源工具包》。

Roger Grimes (CPA、CISSP、MCSE:安全性),Microsoft ACE 团队的高级安全顾问,已经编写或与人合著了八本计算机安全性方面的书籍,并且撰写了 200 多篇杂志文章。他经常在安全性会议上演讲,并且是 InfoWorld 安全性方面的专栏作家。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利;未经允许不得复制本文的部分或全部内容.