WebSphere Application Server V7、V8 和 V8.5 中的高级安全性加强4


4 显示了基于 Java ODR 服务器的放置,这与 IBM DataPower SOA Appliances 的应用程序优化 (AO) 功能所提供的按需路由功能截然不同。尽管 Java ODR 不应放在 DMZ 中,但 DataPower SOA 设备是一个适合放在 DMZ 中的加强的设备。

4. 对浏览器访问使用 HTTPS


虽然可以通过未加密的通道发送 LTPA 令牌,但是为了最大程度地保护它们,最好通过加密链接发送它们。如果 LTPA 令牌被成功截获,那么窃取者可以冒充该用户的身份,直到令牌到期为止。

如果站点要执行任何身份验证或者有任何应该保护的活动,则需要对从浏览器到 Web 服务器的访问使用 HTTPS。如果不使用 HTTPS,那么密码、用户活动、WebSphere Application Server 会话 cookie LTPA 安全令牌(参见边栏)等信息可能被入侵者看到,因为通信流要穿过外部网络。

对于在执行身份验证之前允许 HTTP 通信流的应用程序,一定要密切注意 cookie。如果某个 cookie(比如 JSESSIONID)是在使用 HTTPS 之前设置的,那么在使用 HTTPS 之后,该 cookie 可能带来风险,因为入侵者可能已经修改或捕获了它。这正是 WebSphere Application Server 对经过身份验证的用户使用单独的 cookie 的原因。另一种更狡猾的攻击方式是,入侵者可以修改通过 HTTP 返回的任何页面——甚至包括页面中嵌入的 URL。因此,用户可能会单击页面上看似安全的 URL,但他实际上会被转到入侵者的站点上。

5. 保持补丁和修复最新


本文假设您已应用了最新的补丁包(在撰写本文时,最新的补丁包是 7.0.0.258.0.0.4 8.5.0.0,请参阅 最新的 WebSphere Application Server 修复包),以及最近发布的所有安全 APAR。这些补丁包和 APAR 解决或堵住了本文未提到的其他漏洞,所以要确保系统处于最新的修复级别并确认应用了所有已知漏洞的补丁,这非常重要。当然,随着时间的推移,应该经常关注新发布的安全修复。毫无疑问,以后还会不断发现新问题。

与其他复杂产品一样,IBM 会不时地发现和修复 WebSphere Application ServerIBM HTTP Server 和其他产品中的安全性 bug。保持这些修复最新非常重要。建议订阅您使用的产品的支持公告板,对于 WebSphere Application Server,需要经常访问您的版本的 安全公告网站。这些公告板常常包含最近发现的安全性 bug 和修复通知。可以肯定的是,潜在的入侵者会很快得知那些安全性漏洞。您越早采取行动越好。

 WebSphere Application Server 安全 页面上,可以找到关于 WebSphere Application Server 安全性的一般性信息,包括对加强 WebSphere Application Server 基础架构的建议。

6. 启用应用程序安全性


在默认情况下,WebSphere Application Server 完整配置文件的定义中启用了管理安全性。因此,在大多数情况下,基础架构会在默认情况下为管理通信流提供合理的身份验证、授权和加密。在启用管理安全性时,部署管理器和应用服务器之间的 WebSphere Application Server 内部链接以及从管理客户端(Web 和命令行)到部署管理器的通信流是经过加密和身份验证的(参见图 3)。这意味着,在运行管理工具时,需要对管理员进行身份验证。后面会讨论一些例外情况。

除了在管理方面利用应用服务器的安全性之外,强烈建议在应用程序安全性方面利用它。这样做可以让应用程序能够访问强大、健壮且基于标准的安全基础架构。在没有利用应用服务器安全性的应用程序中,常常会发现很严重的安全性漏洞。设计和实现安全的分布式基础架构并不容易。

要想启用应用程序安全性,应该进入全局安全性面板,并选择 Enable application security(不需要启用 Java 2 安全性;正如后面讨论的,它通常不适用),参见图 6

5. 应用程序安全性


V8.5 Liberty 配置文件中,通过将清单 1 中所示的元素包含在配置文件的 server.xml 文件中来启用应用程序安全性。

清单 1. Liberty 中启用应用程序安全性

1

2

3

<featureManager>

     <feature>appSecurity-1.0</feature>

</featureManager>

警告:仅仅启用应用程序安全性并不能确保应用程序是安全的。这只是让应用程序能够利用应用服务器提供的安全特性(包括 Java EE 安全性)。后面会进一步讨论这个主题。

7. 使用 ldapRegistry 代替 quickStartSecurity basicRegistry 元素


Liberty 配置文件在设计时采用了极简理念。为了给希望测试其应用程序是否兼容安全性的开发人员提供轻松支持,可以使用一个包含单个用户 ID 和密码的 quickStartSecurity 注册表。basicRegistry 允许定义多个用户和组。这两个安全注册表都包含在 server.xml 内。

上述两个简单的注册表在开发人员的个人环境中已经够用。在测试环境外,这些 Liberty 配置文件应配置为使用 ldapRegistry 功能。

8. 限制对 WebSphere MQ 消息传递的访问


如果使用 WebSphere MQ 作为消息传递提供者,则需要通过其他技术来提供队列授权。在使用客户端/服务器模式时(绑定模式依赖于计算机中的进程到进程身份验证),默认情况下 WebSphere MQ 不会执行任何用户身份验证。事实上,当您在连接工厂上为 WebSphere MQ 指定用户 ID 和密码时,这些值会被 WebSphere MQ 忽略。

WebSphere MQ 安全警告

因为本文主要关注 WebSphere Application Server 安全性,所以这一节只讨论如何保护从应用服务器到 WebSphere MQ 的链接。这并不能保证 WebSphere MQ 本身是安全的。关于如何正确地保护 WebSphere MQ,请参阅 WebSphere MQ 安全性炙手可热

解决这个问题的一种方法是,在 WebSphere MQ 服务器端实现自己的自定义 WMQ 身份验证插件,对 WebSphere Application Server 发送的用户 ID 和密码进行验证。第二种(可能更简单的)方法是,将 WebSphere MQ 配置为使用 SSL 进行客户端身份验证,然后确保只有 WebSphere Application Server 服务器持有用于连接 WebSphere MQ 的证书。(有关的更多信息,请参阅 保证 WebSphere Application Server WebSphere MQ 之间连接的安全;本文有点儿过时,但相同的原理和技术也适用于这两个产品的新版本。在实现其中提到的技术时,应该考虑到产品的变化。)

9. 加强 Web 服务器和主机


如果采用 步骤 1 中推荐的标准拓扑,那么 Web 服务器是在 DMZ 中运行的。因为 DMZ 是防范潜在入侵者的第一道防线,所以必须特别注意加强此服务器。

本文不讨论加强 Web 服务器 的具体方法,但您应该在操作系统加强、限制装载的 Web 服务器模块和其他 Web 服务器配置步骤上下足功夫。(有关的更多信息,请参阅 Apache hardening information 和图书 Building Secure Servers with LINUX。)

在加强 Web 服务器时,有一个 WebSphere Application Server 特有的问题需要考虑。通过 WebSphere Application Server 管理基础架构来管理 Web 服务器是有可能的。虽然它便于使用看似是一件好事,但这却带来了严重的安全问题。有两种方式可以管理 Web 服务器:

    使用托管节点要求在 Web 服务器(通常位于 DMZ 中)上放置一个节点代理,而且要求使用该代理作为 WebSphere Application Server 计算单元的一部分。这从安全角度来看是完全不可接受的,因此不应该使用,除非在极少数不需要 DMZ 的情况下。这种方式不可接受的原因有两点:

o    首先,节点代理是计算单元的一个全功能成员,因此它有完全的管理权限。如果它在 DMZ 中遭到攻破,那么整个计算单元都会受到侵害。

o    第二,WebSphere Application Server 是一个强大的大型产品,因此很难加强安全性,这样的产品不应该放在 DMZ 中。

    第二种方式要求使用 IBM HTTP Server 和配置 HTTP 管理服务器。在这种情况下,部署管理器将管理请求发送给在 Web 服务器主机上运行的 HTTP 管理服务器。尽管这是一种比采用基于 Java 的节点代理更好的方法,但是许多人仍然认为这种做法存在风险,最好根本不在 DMZ 中提供管理功能。

10. 删除 Web 服务器和插件安装程序遗留的 JRE


在安装 IBM HTTP Server 时,安装程序会遗留一个 JRE。应该删除此 JRE,因为它提供的功能是 Web 服务器或插件在正常情况下所不需要的。请记住,这样做之后,将不能在此 Web 服务器上运行 ikeyman 等工具。我们不认为这个问题很重要,因为在 DMZ 中运行这样的工具并不合适。

当使用 IBM 安装程序安装 WebSphere Application Server HTTP Server 插件时,也会遗留一个 JRE。同样,在完成安装后,应该删除此 JRE

如果您决定删除 JRE,那么应该做一下备份,以防将来使用。一种方法是对该 JRE 执行 zip tar,并在以后需要时将它放回原处(例如,在应用补丁时,WebSphere Application Server 更新安装程序需要它),然后对其执行 zip/tar,并在过程结束时再次将其删除。

11. 加强代理


如果把安全代理服务器放在 DMZ 中,替代 Web 服务器(或与 Web 服务器共存),那么前面的建议也适用于这个代理,但是这里并不打算提供具体细节,因为具体的加强方法与代理相关。

关于 WebSphere DataPower 的一个要点是:Web 安全代理通常并不适用于代理 Web 服务通信流,因为它们无法阻止在传输 XML 时可能出现的威胁。要提供安全的 Web 服务(或任何基于 XML 的协议),可 使用 XML 防火墙,比如 WebSphere DataPower

12. 谨慎地配置和使用信任关联拦截器 (trust association interceptor)


TAI 经常用于让 WebSphere Application Server 能够识别来自 Web SSO 代理服务器(例如 Tivoli Access Manager WebSEAL)的现有身份验证信息。这通常没什么问题。然而,在开发、选择和配置 TAI 时需要特别注意。TAI 会扩展信任域。目前 WebSphere Application Server 信任 TAI 以及 TAI 所信任的所有内容。如果 TAI 开发或配置不正确,就有可能彻底危害 WebSphere Application Server 的安全性。如果您自行开发 TAI,则需要确保 TAI 仔细检验请求中传递的参数,并确保以可靠的方式进行检验。我们曾经见过 TAI 做蠢事,比如直接接受 HTTP 头中的用户名。这是没用的,除非确保 WebSphere Application Server 收到的所有通信流都是通过身份验证代理发送的。例如,使用 前面 描述的技术。这样身份验证代理总是会覆盖客户端设置的 HTTP 头,因为可以伪造 HTTP 头。

    WebSEAL TAI 配置

为了说明仔细配置的重要性,本文将详细讨论 IBM 提供的遗留 WebSEAL TAI,但任何 TAI 都需要认真设计和配置才能获得安全性。对 WebSphere Application Server Tivoli Access Manager WebSEAL 之间的信任关系进行合理的配置是创建安全配置的关键。要创建安全配置,就必须对 WebSphere Application Server WebSEAL 都执行一些步骤。在 WebSphere Application Server 中,必须对 Web 容器配置和 WebSEAL TAI 配置都进行合理的设置。

这两种产品之间的信任关系是很重要的,因为 WebSphere Application Server 中的 WebSEAL TAI 接受来自 WebSEAL 的身份断言。如果可以攻破该链接,入侵者就可以断言任何身份,并彻底破坏基础架构的安全性。WebSphere Application Server WebSEAL 之间的信任关系可以通过以下两种机制之一建立:相互 SSL 身份验证和基于密码的身份验证。这两种机制在安全的环境中都适用。然而,每一种机制都必须进行合理的配置,否则可能会出现严重的安全问题。在每种机制中,WebSEAL 都将最终用户的用户 ID 作为 iv-user 头在 HTTP 请求中发送。这两种配置的区别在于 WebSEAL 向应用服务器证明自身的方式。

    WebSEAL 密码配置

在使用密码身份验证时,WebSEAL 会将其用户 ID 和密码作为基本的 auth 头在 HTTP 请求中发送(该用户的用户 ID 位于 iv_user 头)。基于密码的身份验证在两个地方配置。首先,对于要配置的汇合点,必须配置 TAM WebSEAL,以便将其用户 ID 和密码发送给应用服务器。当然,此密码是机密的,必须小心保护。WebSEAL TAI 在收到密码时会根据注册表对其进行检验。

然而,这一点很不起眼,容易被忽视。如果在 WebSEAL TAI 属性中没有设置 LoginId 属性,TAI 就会检验从 WebSEAL 发送出来的用户 ID 和密码组合;如果它是任何有效的用户 ID 和密码组合,则会信任它。这种配置是不安全的,因为这意味着知道任何有效用户 ID 和密码组合的任何人都可以连接到 WebSphere Application Server,并断言任何用户的身份。在指定 LoginId 属性时,WebSEAL TAI 会忽略基本 auth 头中的入站用户 ID,并检验 LoginId WebSEAL 密码组合。在这种情况下,能够从 WebSEAL 发出的有效密码只有一个(大概接近于受保护的机密)。当然,应该配置从 WebSEAL 到应用服务器的 SSL,以确保该机密密码不会以明文形式发送。

    WebSEAL mutualSSL 配置

Mutual SSL 是通过三个单独的非常重要的步骤配置的:

1.    必须把 WebSEAL 配置为使用 SSL WebSphere Application Server 进行通信,而且该 SSL 配置必须包含只有 WebSEAL 才知道其私钥的客户端证书。

2.    必须配置应用服务器 Web 容器,以便执行客户端证书身份验证。还必须更改其信任存储库,使之仅包含 WebSEAL 正在使用的客户端证书。这个步骤至关重要,因为只有这样才能保证对应用服务器 Web 容器的请求仅来自 WebSEAL,而非某个入侵者(仅仅使用相互身份验证的 SSL 是不够的)。还必须将非 HTTPS 传输从 Web 容器中删除,确保在与服务器联系时只使用相互身份验证的 SSL

以下文章点击率最高

Loading…


发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注