看看在Hardening WebSphere MQ呈现为V7.0和更早版本。要记住的是WMQ不认证任何东西。它授权基于操作系统身份和组,但没有进行密码检查。
对于QMgrs和客户端位于Windows网络中的情况,连接使用SID,因此似乎执行了一些有用的身份验证。但是如果尝试从非Windows平台进行连接,Windows QMgr会使用ID的字符串表示形式。例如,如果某人在桌面上安装了Linux VM,则可以轻松创建名为MUSR_MQADMIN的用户标识,并且Windows QMgr将接受该连接。有一种设置可以使Windows QMgr只接受与SIDS可以解决的连接,但即使在那里它也只是知道SID值在连接上欺骗它们的问题。
这里的教训是,任何 QMgr,即使是Windows上的一个,都必须配置为验证远程连接。使用WMQ v7.1及更高版本,QMgr具有将X.509证书DN映射到用户ID或执行IP筛选的功能。在v7.1之前,这些功能需要退出,例如BlockIP2。 Capitalware销售MQAUSX,它具有BlockIP2的功能,并且会执行身份验证和密码验证并且受支持。
第一个建议是使用v7.1 QMgr,以便获得用于映射和过滤的CHLAUTH
规则。即使您不使用证书v7.1也会限制管理连接,因此攻击者难以获得完全的管理权限。然后,如果您需要密码验证,请使用SSL通道(加密密码并防止简单重播攻击)以及可以自行编写或购买的退出。
请注意,允许来自域外的连接不会带来任何新的挑战。在通道定义或退出中未设置MCAUSER的v7.1之前的Windows QMgr允许远程管理访问,即使是源自本地Windows域的连接也是如此。有总是需要强化QMgr,即使诚实的用户在管理员没有为他们设置认证时也会收到授权错误。
摘要:
始发管理域之外的客户,我建议相互验证TLS/SSL通道。我上面链接的同一页面还包含WMQ安全实验指南和脚本,其中介绍了如何创建和交换WMQ证书以及如何配置WMQ资源管理器。
无论您做什么,任何合法渠道上的MCAUSER
都必须在配置中或通过退出进行设置。如果客户端被允许指定ID,则没有什么可以阻止它指定管理ID。对于未使用的通道,如SYSTEM.DEF.*
和SYSTEM.AUTO.*
,请将MCAUSER设置为不能为本地ID的值,例如no!body
或v7.1及更高版本*NOACCESS
。
一如既往,您的回答无价。谢谢T.Rob。如果我有进一步的问题,我会创建一个新的SO请求 – scarpacci 2012-04-13 21:37:37