WebSphere Application Server V7高級安全性增強，第1部分：（下）

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 安全性的定製的現場課 程。這個課程深刻講解安全性增強、定製身份驗證、集成、單點登陸和各類其餘相關主題。