14. 考虑对 Web 服务器到 WebSphere Application Server 的 HTTP 链路进行身份验证
WebSphere Application Server Web 服务器插件将来自 Web 服务器的请求转发到目标应用 服务器。在默认情况下，如果到 Web 服务器的通信是通过 HTTPS 完成的，则插件在将请求转 发到应用服务器时会自动地使用 HTTPS，从而保护其机密性。
另外，更谨慎的做法是将应用服务器（它包含一个小的嵌入式 HTTP 监听器）配置为只接受 来自已知 Web 服务器的请求。这可以防止各种绕过 Web 服务器前或 Web 服务器中的任何安全 性检查的暗中攻击，创建一个可信的网络路径。这种情况看似不太可能出现，但确实存在这种 可能性。无法一一列举所有场景，下面是一些例子：
有一个身份验证代理服务器，它仅仅将用户 ID 作为 HTTP 头发送出去，而不发送任何身份 验证信息。可以直接访问 Web 容器的入侵者只需要提供这一相同的头，就可以成为任何人。（ IBM Tivoli Access Manager WebSEAL 不存在这种漏洞。）
有一个代理服务器，它执行重要的授权，以很粗的粒度限制谁可以访问什么应用程序。
有一个代理服务器，它执行重要的审计，不希望它被绕过。
像前一小节讨论的一样，使用客户机证书向 Web 服务器验证身份。
要创建从 Web 服务器到应用服务器的可信网络路径，需要配置应用服务器 Web 容器 SSL 配置以使用客户机身份验证。一旦确保了正在使用客户机身份验证，就需要确保只有可信的 Web 服务器才能联系 Web 容器。要实现这一点，必须通过应用 只使用 SSL 限制访问 中介绍 的 SSL 技巧来限制具有访问权限的群体。具体地说，需要执行以下操作：
为 Web 容器创建一个密钥存储库和信任存储库，为 Web 服务器插件创建一个密钥存储库。
从所有密钥存储库（包括信任存储库）删除所有现有的签名证书。此时，不能使用任何密钥 存储库来检验证书。这样做是有意的。
在这两个密钥存储库中创建自签名证书，并只导出该证书（而不是私钥）。一定要记录这些 证书的到期时间。当插件证书到期之后，它就不能联系 Web 容器了！将从 Web 容器密钥存储 库中导出的证书导入到插件密钥存储库中。将插件证书导入到 Web 容器信任存储库中。现在， 每一端都只包含一个签名证书。这意味着只能使用它们检验一个证书 —— 为对方创建的自签 名证书。
将新创建的密钥存储库安装到 Web 容器和 Web 服务器插件中。
15. 不要在生产环境中运行示例
WebSphere Application Server 附带了几个非常好的示例，它们演示 WebSphere Application Server 的各个部分。这些示例不是为在生产环境中使用准备的。不要在生产环境 中运行它们，因为它们会带来严重的安全风险。特别是 showCfg 和 snoop Servlet 会向外部 人员提供大量关于您的系统的信息。这正是您不希望潜在的入侵者获得的信息。只要不在生产 环境中运行 server1（它包含这些示例），就很容易解决这个问题。如果使用的是 WebSphere Application Server Base，实际上应该从 server1 中删除这些示例。
16. 选择合适的进程身份
WebSphere Application Server 进程是在操作系统上运行的，因此必须在某个操作系统身 份下运行。有三种运行 WebSphere Application Server 的方式与操作系统身份有关：
以 root 身份运行一切程序。
以单一用户身份（例如 “was”）运行一切程序。
以 root 身份运行节点代理，以应用服务器自己的身份运行各个应用服务器。
IBM 测试过并完全支持前面两种方法。第三种方法看似很有吸引力，因为那样就可以利用操 作系统权限，但它在实践中不是非常有效，这有以下几点原因：
配置它非常困难，而且过程没有文档说明。许多 WebSphere Application Server 进程都需 要对无数文件具有读访问权限，并对 log 和 transaction 目录具有写访问权限。
通过以 root 身份运行节点代理，实际上会向 WebSphere Application Server 管理员和在 WebSphere Application Server 中运行的任何应用程序授予 root 权限。
这种方法的主要价值在于控制应用程序对文件系统的访问。但是，使用 Java 2 权限也可以 实现这一点。
这种方法会造成应用程序互相隔离的错觉。其实不是。WebSphere Application Server 内 部安全模型基于 J2EE 和 Java 2 安全性，不受操作系统权限的影响。因此，如果选择使用这 种方法来保护自己免受 “恶意” 应用程序的侵害，则方法的方向错了。
第一种方法明显是不可取的，因为作为一般的最佳实践，如果可以的话，最好避免以 root 身份运行任何进程。这样就只剩下第二种方法，它是完全受支持的。在某些很少见的情况下， 并不关心应用程序隔离，但是希望以不同的操作系统身份运行应用程序以便审计，那么可以使 用第三种方法。这从安全性的角度来看没有价值，而且实际上会略微增加风险，但是有可能使 用操作系统级审计。
17. 保护配置文件和私钥
对于限制权限也不要过于走极端。我们见过非常多这种情况：在开发期间，甚至不允许开发 人员查看应用服务器日志文件。这种极端做法完全没有必要。当然，在生产期间，应该尽可能 地保护 WebSphere Application Server。但是，在开发期间，实现最大的安全性是不必要的， 会影响开发人员的生产力。
应该利用操作系统文件权限来限制对 WebSphere Application Server 文件的文件系统访问 。与任何复杂的系统一样，WebSphere Application Server 使用和维护大量敏感信息。一般来 讲，不应该有人对大多数 WebSphere Application Server 信息具有读或写权限（见边栏）。 特别是 WebSphere Application Server 配置文件 (/config)，它既包含配置信 息，也包含密码。
另外，应该注意避免不小心共享密钥。例如，不要在生产环境中使用与其他环境中相同的密 钥。许多人对开发和测试计算机及他们自己的密钥有访问权限。应该谨慎地保护生产环境用的 密钥。
如果不谨慎地控制谁对文件系统有写访问权限，用户只需手工编辑配置文件，就可以破坏产 品的安全性控制（比如审计）。
18. 加密从 WebSphere Application Server 到 LDAP 的链路
当使用 LDAP 注册表时，WebSphere Application Server 会使用标准的 ldap_bind 来验证 用户密码。这要求 WebSphere Application Server 将用户密码发送到 LDAP 服务器。如果该 请求没有加密，则黑客可以使用网络嗅探器来窃取用于身份验证的用户密码（包括管理密码！ ）。大多数 LDAP 目录都支持 LDAP over SSL，并且可以把 WebSphere Application Server 配置为使用它。在 LDAP 用户注册表面板中（请参见图 7），选中 SSL enabled 选项，然后配 置适合您的 LDAP 目录的 SSL 配置。很可能需要将用于 LDAP 服务器证书的签名密钥（证书） 放在信任存储库中。最好是创建只供 LDAP 使用的新的 SSL 配置，以避免给当前使用 SSL 的 其他领域造成问题。
图 7. 启用 LDAP SSL
如果使用定制的注册表，显然需要使用任何可用的机制来保护该通信流。
19. 确保只通过 HTTPS 传输 LTPA cookie
Web 应用程序使用 cookie 跨请求跟踪用户。尽管这些 cookie 本身通常不包含敏感信息， 但是它们把用户与后端系统上用户的现有状态联系起来，如果入侵者捕获了您的 cookie，他们 就有可能使用这个 cookie 伪装成您。因为网络通信流常常通过不可信的网络传输（考虑一下 您喜欢的 WiFi 热区），数据包很容易被捕获，所以应该使用 SSL 加密重要的 Web 通信流。 这包括重要的 cookie。显然，如果所有请求都使用 SSL，cookie 就会得到保护。但是，许多 应用程序（可能偶尔）通过 HTTP 发送请求，而没有使用 SSL，这就可能暴露 cookie。幸运的 是，HTTP 规范允许指定浏览器只通过 SSL 发送 cookie。
对于 WebSphere Application Server，最重要的 cookie 是 LTPA cookie，因此，它应该 配置为只通过 SSL 发送。
图 8. 把 LTPA cookie 限制为只使用 SSL
通过在会话管理面板上指定相似的设置，还可以把 HTTP Session（默认情况下是 JSESSION ） cookie 限制为只使用 SSL。
警告：在安装 APAR PM00610 之前，Requires SSL 标志在 WebSphere Application Server V7 中无效。一定要安装它。
20. 确保定期改变 LTPA 加密密钥
WebSphere Application Server 使用 LTPA 加密密钥加密各种用户令牌（包括 LTPA cookie）。与任何密码术密钥一样，应该定期改变这些密钥。根据 WebSphere Application Server 和补丁级别不同，自动密钥生成在默认情况下可能启用了，也可能关闭了；版本越新， 默认情况下它关闭的可能性越大。
应该确保定期改变 LTPA 加密密钥。可以启用自动 LTPA 密钥替换（见图 9），也可以手工 地重新生成密钥（见图 10）。无论选择哪种方式，一定要考虑 LTPA 密钥不一致的问题：
首先，如果计算单元中的某些节点在一段时间（比如密钥寿命的两倍）内一直停机，它们就 会丧失通信能力。
第二，如果与其他组件（比如另一个计算单元或 WebSphere DataPower）共享 LTPA 密钥， 那么在改变密钥时，就需要在所有地方更新它们，这通常会造成停机。
图 9. 启用自动 LTPA 密钥更新
图 10. 手工生成新的 LTPA 密钥
21. 不要在命令行上指定密码
一旦启用了安全性，WebSphere Application Server 管理工具就要求您只有通过身份验证 才能使用它。执行身份验证的明显方式就是在命令行中指定用户 ID 和密码，将其作为参数传 递给该工具。请不要这样做。这会向在您身边窥探的任何人暴露您的管理密码。而且在许多操 作系统中，任何可以看到进程列表的人都可以看到命令行上的参数。相反，应该确保由管理工 具提示输入用户 ID 和密码。从 WebSphere Application Server V6.0.2 起，如果在命令行上 没有提供用户 ID 和密码，所有管理工具会自动提示输入。不需要其他的操作。
如果使用以前版本的 WebSphere Application Server，则可以通过让这些工具使用 RMI（ 默认是 SOAP）通信来强制它们提示输入用户 ID 和密码。RMI 引擎在需要时会显示提示。要实 现这一点，只需指定：
–conntype RMI –port
下面的示例以这种方式启动 wsadmin，连接到监听默认端口的部署管理器：
wsadmin.sh –connectype RMI –port 9809
如果觉得命令行工具以图形方式提示输入用户 ID 和密码非常烦人，可以改变该行为，让工 具使用基于文本的简单提示。要实现这一点，应该通过编辑合适的配置文件，将 loginSource 从 prompt 改为 stdin。在默认情况下，管理工具使用 SOAP，因此应该编辑 soap.client.props 文件。如果使用的是 RMI，则编辑 sas.client.props。请在适当的文件中 查找 loginSource 属性，并更改它以指定 stdin。
22. 创建单独的管理用户 ID
主管理 ID 与用于服务器到服务器通信的安全性服务器 ID 并不相同。从 V6.1 开始，注册 表中不再需要有这个身份，甚至不必有相关联的密码。它在默认情况下只用于内部通信。如果 需要，可以指定服务器 ID 和密码，但是不建议这么做，除非绝对必要 —— 比如使用包含不 同版本的计算单元（包括 V6.0 和更低版本），或者涉及 V6.0 或更低版本的跨计算单元 SSO 。
当为 WebSphere Application Server V6.1 和更高版本配置安全性时，在开始时会配置一 个主管理 ID（见边栏）。这个 ID 实际上等同于 WebSphere Application Server 中的根用户 ，它能够执行任何管理操作（包括下一节提到的所有管理角色）。由于这个 ID 很重要，所以 最好不要随便共享其密码。理想情况下，在最初配置之后不应该再使用这个 ID。
与大多数系统一样，WebSphere Application Server 允许多个主体担任管理员。只需使用 管理应用程序并进入系统管理控制台用户（或用户组）部分，指定应该授予管理权限的其他用 户或用户组。当进行这样的授权之后，在管理 WebSphere Application Server 时每个人都可 以以自己的身份进行身份验证。从 WebSphere Application Server 5.0.2 开始，会导致更改 WebSphere Application Server 配置的所有管理操作都需要经过部署管理器的审核，包括执行 更改的主体的身份。从 V7 开始，引入了一个新的审计框架，它可以提供更详细的管理操作审 计信息。显然，如果每个管理员有单独的身份，这些审计记录会更有用。
在由中心管理员管理多个 WebSphere Application Server 计算单元的环境中，为每个管理 员授予单独的管理访问权限会非常方便。虽然每个计算单元都有自己的本地 “根” ID 和密码 ，但是可以配置所有这些计算单元以共享公共注册表，这样管理员就可以使用相同的 ID 和密 码来管理每个计算单元。
23. 利用管理角色
根据版本不同，WebSphere Application Server 允许不同的管理角色：Administrator、 Operator、Monitor、Configurator、 AdminSecurityManager、iscadmins、Deployer、 Auditor。这些角色使得授予个人（和自治系统）适当的访问权限成为可能。强烈建议尽可能利 用角色。通过使用权限较少的 Monitor 和 Operator 角色，可以限制管理员能够执行的操作。 例如，可以只授予较为低级的管理员启动和停止服务器的能力；只授予夜间操作员监视系统的 能力（Monitor）。这些操作让人员只具有他们需要的权限，从而极大地限制了损害风险。
在 WebSphere Application Server Information Center 中可以找到关于角色及其拥有的 权限的完整文档。但是，应该特别注意下面三个角色：
Monitor：授予用户或系统这个访问级别，就意味着他们只能监视系统状态；不能更改状态 ，也不能更改配置。例如，如果您开发用于检查系统运行状况的监视脚本，并且必须用该脚本 在本地保存用户 ID 和密码，则应该使用具有 Monitor 角色的 ID。即使该 ID 被窃取，所造 成的损害也不会很严重。
AdminSecurityManager：（V6.1 中增加的）具有此角色的用户可以授予其他用户管理角色 。Administrator 角色本身没有这个权限。现在，可以向用户授予各种权限（甚至包括 Administrator 权限），同时仍然确保他们无法把这些权限再授予别人。
Auditor：（V7 中增加的）具有此角色的用户可以配置审计系统，但是没有其他任何权限。 另一方面，Administrator 可以配置除审计系统之外的任何东西。这提供明确的职责分隔。 Administrator 可以更改配置，但是无法 “掩盖” 操作痕迹，因为他无法禁用审计。
24. 考虑加密 Web 服务器到 Web 容器的链路
即使不对从 Web 服务器到 Web 容器的链路进行身份验证，也可能希望考虑对它进行加密。 Web 服务器插件通过 HTTP 把来自 Web 服务器的信息传输到 Web 容器。如果到达 Web 服务器 的请求使用的是 HTTPS，那么在默认情况下插件使用 HTTPS 转发请求。如果到达的请求使用的 是 HTTP，那么插件使用 HTTP。这些默认行为对于大多数环境是合适的。但是，有一种例外情 况。
在某些环境中，当请求到达您的网络之后，会在其中添加敏感信息。例如，一些身份验证代 理服务器（比如 WebSEAL）会在请求中添加密码信息。Web 服务器中的定制代码可能做相似的 事情。如果是这种情况，应该采取额外步骤保护从 Web 服务器到 Web 容器的通信流。要想迫 使从此插件发出的所有通信流都使用 HTTPS，只需在每个应用服务器上的 Web 容器中禁用 HTTP 传输，然后重新生成和部署插件（图 11）。现在，此插件只能使用 HTTPS，所以无论通 信流如何到达 Web 服务器，它都使用 HTTPS 执行转发。
图 11. 确保只使用 HTTPS
25. 只使用新的 LTPA cookie 格式
（在 V7 中默认情况下已经解决。）
WebSphere Application Server V5.1.1 为支持 主题传播 引入了一种新的 LTPA cookie 格式 (LTPAToken2)。在引入新格式的同时，也解决了旧格式中一些理论上的缺点。请记住，这 些缺点只是在理论上存在的；还没有出现已知的威胁。无论如何，应该使用新的更强的格式， 除非不得不使用旧格式。
新的 LTPA 令牌使用以下强加密技术：
Random salt
强 AES 密码
对数据签名
对数据加密
出于好奇，我们使用 1024 位 RSA 密钥对进行签名，使用 128 位机密密钥 (AES) 进行加密。用于加密的密码是 AES/CBC/PKCS5Padding。
在 V7 之前，默认情况下 同时支持新旧 cookie 格式，以确保在创建 LTPA cookie 时与其他系统相兼容，例如较老版本 的 WebSphere Application Server、IBM Lotus® Domino®（V8 以前的版本）和 Tivoli Access Manager WebSEAL（V6 以前的版本）。如果您不需要这种兼容性，则应该禁用 它。要禁用它，请进入 Security > Authentication Mechanisms > LTPA > SSO configuration 面板并取消选择 interoperability mode（图 12）。
图 12. SSO 互操作模式设置
警告：在 V7 以前，不能同时禁用互操 作性和安全属性传播（也称为主题传播）。如果同时禁用它们，身份验证就会失败。
26. 加密 WebSphere MQ 消息传递链路
如果您使用的是 WebSphere MQ 而非默 认的消息传递提供者，当然应该对 WebSphere MQ 使用 SSL。 在 WebSphere Application Server V7 中，WebSphere MQ 客户机 SSL 配置是第一类构造，可以像其他 SSL 配置一样通过 管理控制台设置。
27. 加密 Distribution and Consistency Services (DCS) 传输链路
核心组依赖于 DCS，它使用可靠的多播消息 (RMM) 系统来进行传输。RMM 可以使用几种有 线传输技术之一。根据环境不同，可以通过 DCS 传输敏感信息。例如，使用 DCS 传输 DynaCache 和安全性主题缓存中的数据。为了确保这一点，需要选择一种通道框架传输类型， 并选择 DCS-Secure 作为每个核心组的通道链（图 13）。
图 13. 配置 DCS 以使用受保护的链路
请注意，当启用全局安全性时，DCS 始终对消息进行身份验证。一旦传输被加密，就有了一 个高度安全的通道。
一旦做到这一点，所有依赖于 DCS 的服务都将使用加密且经过身份验证的传输。这些服务 是 DynaCache、内存到内存会话复制、核心组、Web 服务缓存和有状态会话 bean 持久化。
28. 保护从应用服务器到数据库的链路
与其他任何网络链路一样，机密信息可以被写入数据库或从数据库中读取。大多数数据库都 支持某种形式的身份验证，您应该利用它。
这里是一个 IBM DB2 示例。
29. 考虑把 cookie 限制为 HTTP Only
如果黑客能够通过在浏览器中插入恶意的 JavaScript 攻破 Web 应用程序（这通常称为跨 站点脚本攻击），就可以执行许多恶意操作，应用程序实际上完全被攻破了。他们可以执行的 恶意操作之一是窃取 LTPA cookie 等敏感的 cookie。大多数现代 Web 浏览器都支持 HTTP Only cookie 概念。
WebSphere Application Server 提供一种确保把 LTPA cookie 标为 HTTP Only 的方法。 这需要把安全性定制属性 com.ibm.ws.security.addHttpOnlyAttributeToCookies 设置为 true。（这是最近通过 APAR PK82764（V6.0 或 V6.1）或 PM03760（V7）增加的。）
目前，这个属性只用 HTTP Only 标志保护 LTPA cookie。对于使用 Java EE 安全性并启用 会话安全性（稍后讨论）的以正确方式编写的应用程序，这应该足够了。
但是，即将发布的一个 APAR (PK98436) 将支持在任意 cookie 上设置 HTTP Only 标志。 当这个新特性推出之后，应该使用它而不是老特性，因为它更灵活更完整。这个 APAR 允许通 过 Web 容器属性 com.ibm.ws.webcontainer.httpOnlyCookies 控制要保护的 cookie。这个属 性的值是要保护的 cookie 的逗号分隔列表（* 表示所有 cookie）。
警告：尽管这个 APAR 看起来是防御跨站点脚本攻击的解决方案，但它不是。如果黑客可以 在您的浏览器中执行任意代码，他们能够造成的危害远远不只是窃取 cookie。他们实际上可以 看到浏览器屏幕上的所有内容，可以捕获每次击键，这比窃取 cookie 严重多了。
30. 通过培训让用户正确地理解证书警告
当使用 SSL 进行通信时，安全地交换信息的关键之一是根据客户机信任存储库检验服务器 的证书。如果由于在信任存储库中没有相应的签署者，服务器提供的证书不可信，那么大多数 客户机（Web 浏览器、SSH、wsadmin 等）会提示用户决定应该怎么做。这些客户机通常会向用 户警告这是一个未知的证书，提供证书的指纹（通常是 SHA），并询问 should I trust this? 。遗憾的是，大多数用户会盲目地单击 yes。这是一个可怕的决定。如果这么做，就不知道您 将与什么服务器通信。对于 WebSphere Application Server 管理客户机，下一步就是把管理 用户 ID 和密码发送到未知的服务器。
相反，管理员应该检查指纹信息，判断它是否是正确的指纹（理想情况下最终用户也应该这 么做）。管理工具提供了查看证书指纹的方法。在管理控制台中选择一个个人证书，显示它的 指纹。
图 14. 证书指纹
用户（尤其是管理员）应该了解指纹信息，当客户机（无论是 Web 浏览器还是 wsadmin） 提示时理想情况下应该检验指纹。
图 15. Web 服务器证书警告，第一部分
图 16. Web 服务器证书警告，第二部分
清单 2. wsadmin 证书警告
./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)
即使您不采纳这个建议，至少应该在第一次遇到警告时把证书导入客户机信任存储库。如果 再次看到消息，一定要查明原因！在证书更改之前，提示应该不会再次出现。如果出乎意外地 出现提示，一定有很严重的错误。
31. 谨慎地限制可信的签署者
在使用证书身份验证（客户机或服务器）时，需要理解信任存储库中的每个签署者都代表一 个可信的身份信息（证书）提供者。您信任的签署者应该尽可能少。否则，有可能两个签署者 颁发的证书映射到同一个用户身份。这会在架构中造成严重的安全漏洞。
应该检查客户机和服务器上的信任存储库，删除任何不需要的签署者。在默认情况下，信任 存储库包含的可信签署者比以前的版本少得多，这有助于提高默认情况下的安全性。但是，仍 然有几个签署者问题可能需要解决：
在默认情况下，信任存储库中有 dummyclientsigner 和 dummyserversigner，它们用于与 使用这些默认签署者的以前版本兼容（我们一直建议不使用它们）。在 V7 中默认情况下没有 这些签署者。
在默认情况下，KDB/CMS 密钥存储库包含大多数众所周知的 CA 的签署者。没有合理的理由 这么做，应该删除它们。
在 V7 中，默认的计算单元信任存储库包含一个 WebSphere DataPower 签名证书，这意味 着所有 DataPower 计算机都可以颁发应用服务器所信任的证书。为了提高安全性，应该删除它 。
32. 限制为强密码
（在 V7 中默认情况下已经解决。）
当通过 SSL 通信时，通信流会加密。为了更好地保护通信流，应该使用强密码。遗憾的是 ，在 V7 之前，默认的 SSL 强密码选择包含一些明显非常弱的密码。应该删除这些密码，否则 客户机可能会选用它们。正常情况下，如果 Web 服务器支持强密码，客户机会隐式地选择强密 码，但是最好确保这么做。
图 17. SSL 密码
尽管这里不详细讨论，但是还应该确保把 Web 服务器配置为只接受使用强密码的通信流。
33. 强制 CSIv2 传输使用 SSL
当 WebSphere Application Server 服务器和客户机使用 CSIv2 IIOP 进行通信时，它们之 间协商传输安全性。选择对双方来说都可接受的形式。一般来说，这是可以的，但应该注意一 个潜在的漏洞。WebSphere Application Server 支持 CSIv2 over SSL 或明文方式。在默认情 况下，双方通常会协商使用 SSL，从而建立加密的通信通道。然而，如果在协商中有任意一方 请求使用明文，则将使用明文。您甚至可能不会意识到通信流是以明文方式发送的！这种问题 可能出现，例如如果一个客户机配置错误的话。如果想要（也应该）保证通信流是加密的，更 保险的做法是确保始终使用 SSL。
可以通过在 CSlv2 入站传输面板中指明 SSL 是必需而不是可选的，从而确保对 IIOP 使用 SSL。对 CSIv2 出站传输也应该这样做（图 18）。
图 18. 配置只使用 SSL
34. 考虑端口过滤
有时候，希望根据网络信息限制谁可以连接。尽管这样的配置对于安全性不一定有价值，但 是为了完整，这里仍然讨论一下。WebSphere Application Server 中的大多数传输（IIOP 除 外）使用 Channel Framework，因此可以使用包含或排除列表根据 IP 地址或 DNS 名称过滤入 站通信流。
图 19. 端口过滤
警告：伪造 IP 地址是相当容易的，所以依靠 IP 地址保证安全性是不明智的。在 WebSphere Application Server 中根据 IP 地址进行过滤尤其不明智。更好的方法是装备防火 墙和交换机，从而识别来自无效 IP 地址的数据包。它们还可以检查 MAC 地址。
35. 禁用不使用的端口
加强安全性的基本原则是使潜在攻击的攻击面最小化。当给定的服务没有已知的安全问题时 尤其应该这样。如果该服务对系统的正常运转是不必要的，则应该将其删除，从而尽可能降低 攻击者在将来的某个时候利用这个多余的功能进行攻击的可能性。查看图 20，您会看到典型的 WebSphere Application Server 应用服务器正在监听大量端口。
图 20. Network Deployment 应用服务器的默认端口
如果给定的服务不是必需的，则可以禁用其监听的端口。查看此列表，可以考虑禁用的端口 是：
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS：用于与 WebSphere Application Server V4 和更 早版本兼容。这是旧的 IIOP 安全性协议。从 V5 开始，CSIv2 替代它了。
SIB_ENDPOINT_*：供内置的消息传递引擎使用。如果没有使用消息传递，则不需要使用它们 。
SIB_MQ_*：供消息传递引擎在与 WebSphere MQ 连接时使用。
WC_adminhost*：用于管理性 Web 浏览器访问。如果应用服务器没有部署管理器，应该确保 禁用这些端口。遗憾的是，即使服务器上没有管理应用程序，大多数应用服务器 Web 容器仍然 要监听两个管理端口。这是因为服务器常常是基于 server1 模板创建的，这个模板包含这些端 口。应该在所有应用服务器上禁用或删除这些端口。
WC_defaulthost*：默认的 Web 容器监听端口。如果已经添加了定制的监听端口，则可能不 需要这些。
不同的端口需要使用不同的技术来禁用，这取决于它们的实现方式：
可以通过在全局安全性面板中选择 CSI 作为活动协议，将 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 从服务中除去。在 V7 中，在默认情况下禁用 SAS， 但是仍然监听这个端口。
WC_* 端口都是用于 Web 容器的。最好在 Web 容器传输链配置面板 (Application servers > servername > Web container > transport chain) 中删除、修改或禁用它们。只 需要监听应用程序使用的那些 Web 端口。
除非启用了消息传递引擎，否则不会启动 SIB_* 端口，所以不需要对它们采取措施。
警告：在决定要禁用哪些端口时以及在实际禁用它们时，应该特别谨慎。否则，可能无意间 禁用管理端口，这样就会禁用管理进程的机制，无法删除和重新创建进程（例如服务器）定义 。
36. 考虑禁用密码缓存
在执行基于密码的身份验证时，运行时会以单向散列的形式缓存密码，供以后检验时使用。 因为这个散列是不可逆的，所以密码没有被截获（甚至包括通过内存转储截获）的危险，但是 这个缓存对安全性有影响。如果以后到达的请求要求身份验证，而且它们使用相同的用户 ID 和密码组合，就会使用缓存的密码数据（和用户信息）。这意味着，即使注册表中的用户密码 更改了，他仍然能够使用旧的密码通过身份验证，直到缓存到期为止（默认情况下是 10 分钟 ）。
一些人认为这是一个安全性漏洞（作者并不认同）。如果您担心这个问题，可以通过设置 JVM 级属性 com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled 禁 用密码缓存。设置之后，就不再缓存密码，对于所有密码身份验证，都要查询注册表。请记住 ，这对性能有显著的消极影响。如果使用每个请求都要求身份验证的无状态协议（比如使用 UserNameTokens 的 WS-security），这会产生很大的注册表身份验证通信流。
37. 考虑启用 FIPS 遵从性
在执行加密时，有多种密码学算法可供选择。另外，在建立 SSL 连接时，实际上有三个选 择：SSL V2（在默认情况下禁用）、SSL V3 和 TLS。美国政府已经定义了与计算机安全性有关 的标准 (Federal Information Processing Standards)，涵盖许多领域。在这些标准中，认证 了符合 FIPS 标准的密码技术，还认证了 TLS（但是没有认证 SSL V3）。
如果用户希望把应用程序限制为只使用符合 FIPS 的密码技术和 TLS，可以手工配置每个端 点，也可以使用管理工具启用 FIPS 遵从性。启用 FIPS 之后，就只使用 符合 FIPS 的密码技 术。
结束语
这篇分两部分的文章的第 1 部分讨论了安全性的几个方面，主要关注加强 WebSphere Application Server 环境的核心方案。希望这些信息能够向您提供切实保护 Java EE 环境所 需的基础知识。
第 2 部分将讨论更广泛的主题，包括基于应用程序的预防措施、计算单元信任、跨计算单 元信任、管理和应用程序隔离、身份传播、桌面开发安全性等等。
如果希望进一步了解 WebSphere Application Server 安全性，请联系 IBM Software Services for WebSphere，参加关于 WebSphere Application Server 安全性的定制的现场课 程。这个课程深入讲解安全性加强、定制身份验证、集成、单点登录和各种其他相关主题。
626
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
