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 配置文件 (<root>/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 <bootstrap 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 安全性的定制的現場課 程。這個課程深入講解安全性加強、定制身份驗證、集成、單點登錄和各種其他相關主題。
