内容


评论专栏

T.Rob Wyatt:WebSphere MQ 安全性炙手可热

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 评论专栏

敬请期待该系列的后续内容。

此内容是该系列的一部分:评论专栏

敬请期待该系列的后续内容。

维加斯发生了什么

IBM WebSphere MQ 安全性实现并非总是得到了其应有的重视或优先。正如我在之前的 developerWorks 专栏文章中提到的,很多 WebSphere MQ 安装都没有安全机制,或者更糟糕,实现了漏洞百出的安全措施却认为此安装是安全的。我去年一月撰写那篇文章的时候,WebSphere MQ 在其管理员和开发人员社区外还算不上非常重要的产品。从某种程度而言,您可以说我们所有的人都受到“未知”所带来的安全性的保护。所有这些于 2007 年 8 月 3 日在拉斯维加斯突然之间全改变了。

去年 7 月,WebSphere MQ 列表服务器充满了关于 Def Con 15 上即将举行详细讨论 WebSphere MQ 的安全漏洞利用的专题会议的信息。此专题会议由 MWR Infosecurity 的 Martyn Ruks 主讲,会议主题是“MQ Jumping”,其内容摘要包括以下描述:

此次演讲将揭示部署在实际环境中的 WebSphere MQ 安全性背后的真相,将了解攻击者如何滥用此软件来进行远程代码执行。演讲将重点讨论用于分析可用来保护 MQ 安装的安全控制的方法及其各自的局限。此后,将讨论用于通过 MQ 服务比较消息数据和操作系统的一系列方法。我们将演示演讲中提到的一些攻击,从而将此专题会议推向高潮,然后将讨论用于保护安装和确保不会出现安全违规的方法。

有的读者可能不了解 Def Con,宣称它是“世界上最大的地下黑客会议”。演讲摘要本身非常有诱惑力。其向这个特殊的受众宣传的概念显然非常可怕。第二天我预了班机飞往维加斯,并在会议举行的酒店订了房间。

听众如期而至,演讲按部就班举行。“MQ Jumping”部分尚未开始,甚至前一个演讲者尚未结束其演讲,主会场就开始拥挤起来。当 Ruks 先生登上讲台,会议室已经爆满,走廊和会议室后面挤满了与会人员。想像一下您曾经在所有电影电视中看到的每个中坚黑客分子:他们都在那里。

演讲的开始部分和我在 IMPACT 和 Transaction and Messaging 大会上的演讲非常相似。他讨论了默认通道以及如何利用这些通道,讨论了命令服务器、触发监视器以及初始队列。但随后他讨论了我们所不知道的一些东西。

在他的研究中,Ruks 先生发现了一个方法,可通过此方法使用管理权限启动客户端通道,即使使用了安全出口和硬编码 MCAUSER 对其进行了保护也可行。值得赞赏的是,他公开了漏洞,但并没有说明如何利用此漏洞的具体细节(虽然我有个想法,但我自己可能只是到场的缺少此说明信息而无法了解进一步工作的少数人之一)。

尽管您可能对安全漏洞在“黑客会议”上曝光而感到有些不舒服(您应该有这样的感觉),但如果知道在此次会议之前 IBM 就已经知道了这个问题,这应该会让您感到有几分安慰。另一个安全研究团队(National Australia Bank 的独立团队)发现了 Ruks 所说的相同漏洞,而事实上,IBM 认可是这个团队最先发现此问题。早在 Def Con 之前,这两个团队都已经将其发现报告给了 IBM,而且 IBM 于 8 月 6 日发布了相关的修复程序。

这些究竟意味着什么呢?Def Con 专题会议讨论的是入侵 WebSphere MQ 还是对其进行保护?最终看来,答案是,公开漏洞可以带来更好的安全性。这样会让提供商集中精力进行持续改进,而且让软件用户知道仅保护明显的漏洞并不够。通过独立安全咨询师和客户的反馈可以得到更安全和可靠的产品——但只有启用了才能实现此目标。正如 Ruks 先生和我在演讲中都指出的一样,我们所接触到的大部分公司都启用了 WebSphere MQ 安全性——而这正是我希望在这里讨论的问题。

本文剩下的部分将说明如何使用上面提到的 WebSphere MQ 通道更新您的安装,并提供用于保证队列安全的其他步骤。我们还在参考资料部分中提供了关于 WebSphere MQ 的更多信息。

战略性修复

更新通道代码

您将要进行的第一件事是升级到 WebSphere MQ V6.0.2.2 或应用通道安全修复程序。如果您无法升级或应用修复程序,可以采用避开这个问题的方法,即在未使用的通道上设置无效的 SSLCIPH 值。这将导致在执行可利用的代码前任何连接尝试都失败。没有任何办法消除合法使用的通道上的这个漏洞,但对于这些通道,启用 SSL 并对特定的 SSLPEER 值进行筛选至少能够限制潜在的攻击者数量。

身份验证

应用了修复程序或升级后,您可以采取哪些步骤来保证队列管理器的安全?如果有用户或应用程序以绑定模式连接(使用共享内存),操作系统将使用 ID 和密码对其进行身份验证。如果服务器具有合理的安全性,则本地登录也是安全的。问题在于,您如何对远程连接用户、以客户端模式连接的应用程序以及来自其他队列管理器的连接进行身份验证。

到队列管理器的远程连接通常通过通道进行。没有为通道提供用户 ID 时,身份验证检查将针对与运行通道的进程关联的用户 ID 进行——该 ID 总是具有所需的相应权限。MCA 通道(两个队列管理器之间的通道)可以配置为基于消息 Header 中包含的 ID 进行授权,但没有身份验证,消息 Header 中的 ID 无法得到信任。

MQI(客户端)通道的情况也是类似。WebSphere MQ 客户端代码将传递用于对其进行调用的登录用户 ID,但这只是一个缺省值。编程接口允许从应用程序内设置在客户端连接请求中出现的 ID。这将覆盖从系统获得的 ID。显然,除非能够安排对其进行身份验证,否则这些 ID 也无法获得信任。

您可能此时会认为,启用 SSL 将提供所需的身份验证。这也对,也不对。使用客户机通过 SSL 通道连接时,SSL 协议将使用通道代理启动和终止。SSL 提供的身份验证并没有扩展到 API 调用。建立连接之后,SSL 交换之外的所有东西(连接请求、API 调用)都会像没有 SSL 时一样工作。因此,即使队列管理器配置为仅接受来自 John Doe 的 SSL 身份验证连接,MQ API 仍然允许 John 在其连接请求中断言一个不同的身份。如果 John 断言 Jane Doe 的身份,队列管理器将毫无疑问地接受,甚至在启用 SSL 的通道上也是如此。如果 John 选择断言 mqm ID,则将获得管理权限。

总之,必需在接收到队列管理器时在本地执行身份验证。如果 SSL 通道是身份验证的基础,则必须使用出口将 SSL 证书标识绑定到 MCAUSER,以便向 API 调用应用访问策略。基于密码的身份验证也需要出口。或者,WebSphere MQ Extended Security Edition 可以用于签署各个消息,并执行端到端访问策略。

战术性修复

但我现在就需要修复!

我进行过很多安全评估,我必须向公司报告他们允许通过不安全通道对其消息传递系统进行匿名管理访问。自然地,他们都迫不及待地想堵上这个漏洞,但跨整个消息传递网络部署出口可能是非常艰巨的任务,而出口仅仅是开始而已。在访问从来没有得到安全保护的地方,经常会发现很多应用程序和用户使用管理权限连接。锁定通道将导致所有这些用户无法访问。后续工作可能会很麻烦,需要断开所有应用程序的访问,逐个队列确定所需的实际权限,然后修复问题。由于这些原因,经常有人问我是否有这样的选项:可以有效锁定管理访问但对应用程序或用户的影响极小,不需要出口或 SSL 而且可以尽可能快部署。

让人高兴的是,答案是“有!”您可以将 MCAUSER 硬编码在通道定义中,并在其中提供能够访问所有 WebSphere MQ 资源(管理资源除外)的用户 ID。但注意这是有代价的。通过缺省设置,您能够为不同的用户授予不同权限,如果用户尝试进入彼此的队列,用户将收到授权错误。但是没有身份验证,任何用户都可以冒充管理员。硬编码 MCAUSER 时,可以锁定管理访问权限,但失去了区分每个用户的能力。不会再有授权错误。我认为,有一个可以信任和执行的 ID 要比拥有大量不能信任和执行的 ID 要好得多。在准备好实现真正的身份验证模式之前,这是一个很好的折衷办法。

准备工作

开始锁定通道前,将有必要提供两个每个队列管理器都可以访问的专用用户 ID 和组。对于本文,我将假定使用的是用户 ID 和组名称可以完全相同的 UNIX 环境。这些应该是标准应用程序服务帐户;我这里所指的是不由任何其他应用程序或用户共享的非登录帐户。每个组中应该有且仅有一个 ID。每个 ID 应该为一个且仅一个组的成员。一个 ID 和组用于 MCA 通道,另一个用于 MQI 通道,因此我们可以将其命名为 mqmmca:mqmmca 和 mqmmqi:mqmmqi。

MCA 通道

用于将队列管理器连接到另一个队列管理器的通道称为 MCA 通道,因为它们使用消息通道代理。入站 MCA 通道可以为接收方、请求方或集群接收方。如果仔细阅读一下系统管理手册,可能会注意到 runmqsc 和 WMQ Explorer 之类的工具可以使用一个队列管理器作为代理来通过 MCA 通道管理其他队列管理器。这就意味着,在缺省配置中,任何队列管理器都可以由任何相邻的队列管理器进行管理。

显然,如果您希望限制管理访问权限,您需要考虑 MCA 通道。以下是 setmqaut 命令的脚本,此脚本阻止了 MCA 通道上的管理访问权限。这将应用于队列管理器上的所有非缺省通道。(您的缺省通道应该早就设置为 MCAUSER('nobody'),但本文将不对本文予以讨论。)

# Allow MCAUSER to connect. Needs +set and +setall per IBM docs. setmqaut -m QMGR -g mqmmca -t qmgr -all +connect +inq +set +setall # Grant MCAUSER default policy of "allow all" to all queues. Channels # put messages so no need for get, browse, etc. Also needs +setall. setmqaut -m QMGR -g mqmmca -n '**' -t queue -all +put +setall # Now deny access to administrative queues setmqaut -m QMGR -g mqmmca -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +none setmqaut -m QMGR -g mqmmca -n SYSTEM.DEFAULT.INITIATION.QUEUE -t queue -all +none # Restrict access to any additional initiation queues as well.

这当然是最小设置,仅仅限制管理访问权限。相邻的队列管理器仍然可以将消息放到 SYSTEM.* 队列和任意应用程序队列上,但这对信任队列管理器网络可能已经足够好了。

MQI 通道

一旦其他队列管理器的连接按照您的要求锁定后,您将需要考虑 MQI 通道。这些通过 SVRCONN 定义进行表示。希望您的 SYSTEM.DEF.SVRCONN 和 SYSTEM.AUTO.SVRCONN 已经设置而且未使用。如果不是这样,这些通道将需要接收此处所述的更新。无论您怎么做,都不要让这些通道保持没有 MCAUSER 集的情况。

我们还应该暂时停下来讨论一下 SYSTEM.ADMIN.SVRCONN。如果 WebSphere MQ 管理团队使用桌面客户端访问队列管理器,此处所建议的配置将阻止此访问。但在没有身份验证的情况下,如果让通道处于未受保护的状态,则任何人都可以拥有管理权限。这里有两个选项:以有限的方式仅仅为管理团队实现身份验证,或者要求管理员登录到服务器进行配置更改。为了简化此讨论,我们将假定采用后一种方法。不过,如果您首先准备考虑转向 SSL 和/或出口,则不会考虑此选项。

应用了更改后,SYSTEM.ADMIN.SVRCONN 将仍然可用,WebSphere MQ Explorer 之类的桌面工具一定程度上将仍然可以工作。用户将能够浏览、获取或发出消息、查询任意对象甚至还能够设置对象(例如,启用触发),但将不能够创建或删除对象,也不能控制通道。

# Allow MCAUSER to connect to QMgr setmqaut -m QMGR -g mqmmqi -t qmgr -all +connect +allmqi +dsp # Allow inquire/display of non-queue objects # Some of these object types are new for v6 setmqaut -m QMGR -g mqmmqi -n '**' -t namelist -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t process -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t authinfo -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t channel -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t service -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t listener -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t clntconn -all +dsp # Default allow-all to all queues setmqaut -m QMGR -g mqmmqi -n '**' -t queue -all +allmqi +dsp # This gets us back to almost full admin but positions us to set # additional restrictions. # Restrict access to SYSTEM.** queues. Browsing and display of these # queues is reasonable but not PUT, SET, ALTUSR, etc. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.**' -t queue -all +inq +browse +dsp # Allow limited access to command queue. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue -all +inq +put +dsp # Allow access to SYSTEM.MQEXPLORER.REPLY.MODEL.QUEUE if it exists. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.MQEXPLORER.REPLY.MODEL.QUEUE' -t queue -all +inq +dsp +put # Allow access to SYSTEM.DEFAULT.MODEL.QUEUE. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue -all +allmqi +dsp # Restrict access to DLQ. This assumes SYSTEM DLQ is used. If not, # you might want to script this to inquire on the QMgr DLQ property # and set that. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.DEAD.LETTER.QUEUE' -t queue -all +put +inq +browse +dsp

需要注意的一些事项:

  • 上面所示的 setmqaut 命令将允许用户进行之前可以进行的几乎所有操作,但管理命令和 SYSTEM.* 队列上的更新类型命令除外。不过请注意,仅允许 mqm 组的用户对 SYSTEM.AUTH.DATA.QUEUE 进行查询。这对大多数应用程序而言不是问题,但会在远程运行时导致 saveqmgr (MS03 SupportPac) 失败。

  • 对于脚本命令,通配符参数应始终用引号括起来。如果没有这样处理,Shell 将尝试使用当前目录中的文件名对其进行扩展。如果没有匹配的文件名,命令将传入并按预期的方式工作。如果仅找到了一个匹配文件名,会将此文件名替换为队列名称,setmqaut 命令将执行并失败,但不会有任何提示。如果找到两个或更多匹配文件名,setmqaut 命令将直接失败。这可能会影响调试工作,因为授权脚本可能在某一天正常工作,而在第二天失败,但脚本本身却没有发生任何变化。

  • 在上面列出的每个 setmqaut 命令中,权限始终在最开始时为 –all,因为后续命令以追加方式处理。使用 +dsp 运行一次 setmqaut,然后再使用 +inq 运行一次,所得到的权限为 +dsp +inq。从 -all 开始可以确保列出的权限仅为命令行执行之后的权限。确保不会出现不希望的权限设置的唯一其他方法是进行转储并与您的脚本进行比较。-all 可避免这个额外的步骤。

致力于提高安全性

您已经了解如何在不能直接采用 SSL 或通道安全出口之类的强身份验证方法时锁定管理访问权限。以这种方式锁定管理访问权限的代价是,通道将使用单个用户 ID 和组对所有消息进行授权。此方法仅适合在能够实现有意义的身份验证之前作为有限使用的解决办法使用。我们强烈建议实现此配置的任何人将其作为长期计划的第一阶段,以最终实现远程连接的强身份验证机制。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=295279
ArticleTitle=评论专栏: T.Rob Wyatt:WebSphere MQ 安全性炙手可热
publish-date=03172008