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


清单 9. wsadmin 证书警告

1

2

3

4

5

6

7

8

9

10

11

12

13

./wsadmin.bat

*** SSL SIGNER EXCHANGE PROMPT ***

SSL signer from target host localhost is not found in trust store

    C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12

Here is the signer information (verify the digest value matches what

    is displayed at the server):

Subject DN:    CN=keysbotzum, O=IBM, C=US

Issuer DN:     CN=keysbotzum, O=IBM, C=US

Serial number: 1151337276

Expires:       Tue Jun 26 11:54:36 EDT 2007

SHA-1 Digest:  53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6F

MD5 Digest:    29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19

Add signer to the trust store now? (y/n)

即使您不采纳这个建议,至少应该在第一次遇到警告时将证书导入客户端信任存储库。如果再次看到这类消息,一定要查明原因!在证书发生更改之前,提示应该不会再次出现。如果出乎意外地出现提示,一定存在很严重的错误。

32. 考虑限制 HTTP 数据的大小


一种常见的拒绝服务 (DOS) 工具是向应用程序发送非常大的 HTTP 头、很多 HTTP 头或很大的请求正文。我们非常支持进行深度防御。理想情况下,一个入侵检测系统、一个防火墙、一个 WebSphere DataPower SOA Appliance,甚至是应用服务器前面的 Web 服务器,都应该保护您的 WebSphere Application Server,使它们远离这些基于规模的 HTTP 攻击。WebSphere Application Server 中还有一些控件可保护它们远离这些攻击类型。

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求,这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。请参阅 信息中心 了解详细信息。

如果您希望限制任何请求正文的最大大小,也可以对其进行设置。有关的详细信息,请参阅 信息中心

33. 谨慎地限制可信的签署者


在使用证书身份验证(客户端或服务器)时,需要了解信任存储库中的每个签署者都代表一个可信的身份信息(证书)提供者。您信任的签署者应该尽可能少。否则,两个签署者颁发的证书有可能映射到同一个用户身份。这会在架构中造成严重的安全漏洞。

应该检查客户端和服务器上的信任存储库,删除任何不需要的签署者。在默认情况下,信任存储库包含的可信签署者比以前的版本少得多,这有助于提高默认情况下的安全性。但是,仍然有几个签署者问题可能需要解决:

     V7 中,默认的计算单元信任存储库和 CMS 密钥环文件包含一个 WebSphere DataPower 签名证书,这意味着所有 DataPower 计算机都可以颁发应用服务器所信任的证书。为了提高安全性,应该删除它。在安装最新的修复包后创建的 Truststore CMS 密钥环文件无需 DataPower 签名证书即可创建。您应在 truststore 或密钥环文件中检查这个不必要的 DataPower 签名文件,如果存在该文件则删除它。

     V8.0 V8.5 中,DataPower 签名证书已从生成的 truststore CMS 密钥环文件删除。

34. 强制 CSIv2 传输使用 SSL


(这一项默认情况下已在 V8 中解决,这是一项行为更改。因此,从更早的 WebSphere Application Server 版本迁移且未启用 CSIv2 SSL 的用户应该知道,SSL 身份验证失败可能在 V8 中引起问题。)

WebSphere Application Server 服务器和客户端使用 CSIv2 IIOP 进行通信时,它们会就传输安全性进行协商,选择对双方来说都可以接受的形式。一般来说,这是可行的,但应该注意一个潜在的漏洞。WebSphere Application Server 支持 CSIv2 over SSL 或明文。在默认情况下,双方通常会协商使用 SSL,确保建立一个经过加密的通信通道。然而,如果在协商中有任意一方请求使用明文,则将使用明文。您甚至可能不会意识到通信流是以明文方式发送的!这种问题是有可能出现的,例如,如果某个客户端配置出错的话。如果想要(也应该)保证通信流是加密的,更保险的做法是确保始终使用 SSL

通过在 CSlv2 入站传输面板中指明 SSL 是必需的而不是可选的,确保对 IIOP 使用 SSL。对 CSIv2 出站传输也应该这样做(图 17)。

17. 配置只使用 SSL


这一项不适用于 V8.5 中的 Liberty 配置文件,因为没有提供对 EJB CSIv2 的支持。

35. 考虑端口过滤


有时候,希望根据网络信息限制谁可以连接。尽管这样的配置对于安全性不一定有价值,但是为了提供完整的说明,这里仍将对它们进行讨论。WebSphere Application Server 中的大多数传输(IIOP 除外)使用 Channel Framework,因此可以使用包含或排除列表,根据 IP 地址或 DNS 名称来过滤入站通信流。

18. 端口过滤


警告:伪造 IP 地址是相当容易的,所以依靠 IP 地址保证安全性是不明智的。在应用层上根据 IP 地址进行过滤尤其不明智。更好的做法是装备防火墙和交换机,识别来自无效 IP 地址的数据包。它们还可以检查 MAC 地址。

36. 考虑在传出 SSL 连接上执行主机名验证


当一个 SSL 客户端打开一个与 SSl 服务器的 SSL 连接时,服务器将它的证书发送给客户端。预期结果是 SSL 服务器的证书将在它的常用名中包含主机名。一些客户端会确认所提供的证书上的常用名是否与 URL 中的主机名匹配(比如 Web 浏览器会执行此检查)。这称为主机名验证。

在某些情况下,此验证的一次失败可能表明存在 SSL 中间人攻击:

    当证书由于是自签名证书而受信任时,没有必要执行主机名验证。SSL 握手不会通过,除非提供的证书与受信任的证书完全匹配。

    当证书由于是由一个受信任 CA 颁发而受信任时,MITM 攻击者可以返回同一个受信任 CA 为它颁发的合法证书来代替真正的证书。假设 CA 没有颁发多个具有相同 CN 的证书,那么主机名验证就可以检测到 MITM 攻击者。

要启用主机名验证,必须设置一个安全自定义属性 com.ibm.ssl.performURLHostNameVerification=true

RFC 2818 Section 3.1 Server Identity 中要求执行主机名验证。总体来讲:

    如果 URI 被指定为一个 IP 地址,而不是主机名,那么认证可在证书中使用 iPAddress subjectAltName 执行,并且必须与 URI 中的 IP 准确匹配。

    如果 URI 是使用一个给定的 DNS 名称指定的,那么验证可使用证书的 dNSName 类型的 subjectAltName 扩展(如果存在)来执行。否则,(最明确的方法)将使用证书的 Subject 字段中的 Common Name 字段。尽管现在的做法是使用 Common Name,但已不推荐使用它,建议证书颁发机构使用 dNSName

匹配使用 RFC2459 所指定的匹配规则来执行。如果证书中存在多个具有给定类型的证书(例如,多个 dNSName 名称),那么任何集合中的匹配值均被视为可接受。)

设置此属性时的考虑因素:

    此属性会影响计算单元中所有基于 URL 的通信流,包括 IIOP WebSphere Application Server 内部通信。

    在创建 WebSphere Application Server 配置文件期间,可以为配置文件配置节点的主机名。您可以覆盖配置文件创建工具所确定的值。请确保它与主机名匹配。

    如果您的系统是多宿主的,则具有多个主机名,请记住只会返回 SSL 配置的密钥库的默认证书的单个主机名。可以使用替代的主机名创建一个证书;在从一个 CA 获取证书时,就可以这么做。

换句话说,尽管启用此属性可加强针对中间人攻击的安全防御,您的 SSL 证书和主机名解析必须是无瑕疵的。如果不是,那么您的计算单元将无法再通过 SSL 进行通信,因为内部通信可能使主机名验证失败。

37. 禁用不使用的端口


加强安全性的基本原则是使潜在攻击的攻击面最小化。当给定的服务没有已知的安全问题时尤其应该这样。如果该服务对系统的正常运转是不必要的,则应该将其删除,从而尽可能地降低攻击者在将来的某个时候利用这个多余的功能进行攻击的可能性。查看图 20,您会看到典型的 WebSphere Application Server 应用服务器正在监听大量端口。

19. Network Deployment 应用服务器的默认端口

以下文章点击率最高

Loading…

     

如果这文章对你有帮助,请扫左上角微信支付-支付宝,给于打赏,以助博客运营

发表评论

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