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

中一个连接器时,必须向 Liberty 配置文件配置中添加一个管理用户,否则连接器无法验证和连接 Liberty

基于基础架构的预防措施

在保护基础架构时,首先必须了解要保护的组件。与任何漏洞分析一样,我们从确定组件及其外部通信路径开始。(这一分析不会揭示内部应用程序漏洞,但会揭示其他大多数漏洞。)这有助于检查标准的 WebSphere Application Server 拓扑(完整配置文件),并了解所有网络链接和协议(参见图 2)。方框中带阴影的项是与 Liberty 配置文件相关的组件。作为关注安全性的人员,您需要了解所有这些链接并专注于保护它们。这些链接代表前面提到的粗粒度系统边界。

2. 网络链接图


在图 2 中,链接上的字母表示在那些通信链接上使用的协议。对于每个协议,我们列出了其用途,并提供了一些关于防火墙友好性的信息,因为这对于后面的讨论十分重要。协议如下:

    = HTTP 通信流

o    用途:浏览至 Web 服务器、从 Web 服务器到应用服务器的通信以及管理 Web 客户端。

o    防火墙友好。

    W= WebSphere Application Server 内部通信

o    用途:管理客户端和 WebSphere Application Server 内部服务器管理通信流。WebSphere Application Server 内部通信使用以下几种协议之一:

    RMI/IIOP SOAP/HTTP:管理客户端协议是可配置的。

    文件传输服务(dmgr 到节点代理):使用 HTTP(S)

    DCS (Distributed Consistency Service):使用专有协议。用于内存到内存复制、有状态会话 EJB、动态缓存和高可用性管理器。

o    SOAP/HTTP 防火墙友好。DCS 可以是防火墙友好的。

    = RMI/IIOP 通信

o    用途:EJB 客户端(独立的客户端和 Web 容器)。

o    由于使用了动态端口和嵌入式 IP 地址(这会影响防火墙执行网络地址转换),所以通常防火墙对其不太友好。

    = SIB 消息传递协议

o    用途:从 JMS 客户端到消息传递引擎的通信。

o    协议:专有协议。

o    防火墙友好,因为可以指定使用的端口。防火墙很可能对 NAT 不友好。

    MQ = WebSphere MQ 协议

o    用途:MQ 客户端(实际客户端和应用服务器)。

o    协议:专有协议。

o    防火墙可用(有大量端口可供考虑)。请参阅 WebSphere MQ support pac MA86

    = LDAP 通信

o    用途:WebSphere Application Server 对注册表中的用户信息进行验证。

o    协议:按照 LDAP RFC 中的定义进行格式化的 TCP 流。

o    防火墙友好。

    = 通过厂商 JDBC 驱动程序进行的 JDBC 数据库通信

o    用途:应用程序 JDBC 访问和 WebSphere Application Server 会话数据库访问。

o    协议:每个数据库专有的网络协议。

o    防火墙方面取决于数据库(通常是防火墙友好的)。

    = SOAP

o    用途:SOAP 客户端。

o    协议:通常为 SOAP/HTTP

o    当使用 SOAP/HTTP 时防火墙友好。

如图 2 所示,典型的 WebSphere Application Server 配置有大量网络链接。WebSphere Application Server V8.5 包含按需路由器 (ODR),以前仅在 IBM WebSphere eXtreme Scale 中提供。ODR 引入了一些必须考虑的新网络链接。

尽可能地保护每个链接上的通信流以防范入侵者,这是非常重要的。在这部分剩下的内容中,将讨论保护刚刚描述的基础架构所需的步骤。下面的列表按优先级次序列出每个步骤。最重要(最关键)的措施列在最前面。靠后的措施重要性逐渐降低。由您决定您的组织应该完成这个列表中的哪些措施。

1.     Web 服务器放在 DMZ 中,但是不放置 WebSphere Application Server

2.    将生产网络与内部网隔离开

3.    不要将 ODR 放在 DMZ

4.    对浏览器访问使用 HTTPS

5.    保持补丁和修复最新

6.    启用应用程序安全性

7.    使用 ldapRegistry 代替 quickStartSecurity basicRegistry

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

9.    加强 Web 服务器和主机

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

11.    加强代理

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

13.    谨慎地使用证书身份验证

14.    考虑对 Web 服务器到 WebSphere Application Server HTTP 链接进行身份验证

15.    不要在生产环境中运行示例

16.    选择合适的进程身份

17.    保护配置文件和私钥

18.    加密从 WebSphere Application Server LDAP 的链接

19.    确保只通过 HTTPS 传输 LTPA cookie

20.    确保定期改变 LTPA 加密密钥

21.    不要在命令行上指定密码

22.    为基于文件的 VMM 密码增加附加数据

23.    为生成的证书使用更长的密钥

24.    创建单独的管理用户 ID

25.    利用管理角色

26.    考虑加密 Web 服务器到 Web 容器的链接

27.    加密 WebSphere MQ 消息传递链接

28.    加密 Distribution and Consistency Services (DCS) 传输链接

29.    保护从应用服务器到数据库的链接

30.    考虑把 cookie 限制为 HTTP Only

31.    通过培训让用户正确地理解证书警告

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

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

34.    强制 CSIv2 传输使用 SSL

35.    考虑端口过滤

36.    考虑 SSL 主机名验证

37.    禁用不使用的端口

38.    考虑禁用密码缓存

39.    考虑启用 FIPS 140-2 SP800-131 遵从性

1. Web 服务器放在 DMZ 中,但是不放置 WebSphere Application Server


在典型的 DMZ 配置中,有一个外部防火墙、一个包含尽可能少的组件的 DMZ 网络以及一个保护内部生产网络的内部防火墙。

DMZ(参见边栏)有三个基本原则需要考虑:

    来自外部的入站网络通信流必须终止于 DMZ 中。网络传输负载平衡器(例如 Network Dispatcher)自身并不满足这个要求。

     DMZ 到内部网的通信流类型和开放端口数量必须进行限制。

    必须对在 DMZ 中运行的组件进行加强,并遵循最少功能和最低复杂度的原则。

因此,一般将 Web 服务器放在 DMZ 中,将 WebSphere Application Server 应用服务器放在内部防火墙内。这种做法比较理想,因为这可以使 Web 服务器具有非常简单的配置,需要的软件也很少。DMZ 的另一个作用是终止入站请求。最后,内部防火墙上必须开放的惟一端口是用于目标应用服务器的 HTTP(S) 端口。这些步骤使 DMZ 对攻击者的防范非常严格。如果愿意,也可以把安全的代理服务器放在 DMZ 中,替代 Web 服务器或与 Web 服务器共存。

如果把 WebSphere Application Server 放在 DMZ 中的计算机上,则必须在那些计算机上安装更多的软件,并且必须在内部防火墙上开放更多的端口,使 WebSphere Application Server 可以访问生产网络。这极大地降低了 DMZ 的价值。

可以在 DMZ 中放置 Web 服务器以外的其他组件。将安全代理放在 DMZ 中也是合理的,比如 IBM Tivoli® Access Manager WebSEALWebSphere Application Server V7 安全代理或 IBM WebSphere DataPower® 等加强了安全保护的组件。关键是放在 DMZ 中的组件不能是复杂的应用服务器,必须加强安全保护,还必须终止入站连接。

2. 将生产网络与内部网隔离开


现在,大多数组织都了解 DMZ Internet 上的外人与内部网隔离开的价值。然而,很多组织没有意识到许多入侵者都来自内部。正如前面所提到的,需要同时防范来自内部和外部的威胁。正如保护自己免受来自大量不可信的 Internet 用户的攻击一样,您还应该保护生产系统免受大量不可信的内部网用户的攻击。

可以使用防火墙将生产网络与内部网络隔离开。这些防火墙看似比面向 Internet 的防火墙随意得多,但仍然能够防御许多形式的攻击。通过应用这一步骤和前一步骤,应该可以建立图 3 所示的防火墙拓扑。(有关 WebSphere Application Server 防火墙端口分配的更多信息,请参阅 WebSphere Application Server V5 中的防火墙端口分配。)

请注意,我们在防火墙的边缘放置了 wsadmin。这样做是为了试图说明,虽然最好只在生产网络中(受保护的区域内)运行 wsadmin,但也可以将 wsadmin 访问限制为与管理员桌面对应的特定地址,从而轻松地穿过防火墙访问 wsadmin。图 3 还在边缘上显示了 EJB 客户端,因为它们可能位于防火墙的任意一侧。

3. 推荐的防火墙配置


这里只显示了单个防火墙,并没有显示面向内部网的整个 DMZ,因为这是最常见的拓扑。但是,完整的 DMZ(以及内部 DMZ 中的 Web 服务器)越来越常见,它们保护生产网络免受来自非生产内部网的攻击。这的确是一种合理的方法。

如果使用按需路由器功能,请查看下一个加强技巧。

3. 不要将 ODR 放在 DMZ


WebSphere Application Server V8.5 包含按需路由器 (ODR),以前仅在 WebSphere eXtreme Scale 中提供。ODR 是一个基于 Java 的系统,具有上一个主题中提及的所有问题。使用 ODR 的安全拓扑如图 4 所示。而且,不支持将 ODR 放在 DMZ

4. 按需路由器放置

     

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

发表评论

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