中一個連接器時，必須向 Liberty 配置文件配置中添加一個管理用戶，否則連接器無法驗證和連接 Liberty。
基於基礎架構的預防措施
在保護基礎架構時，首先必須了解要保護的組件。與任何漏洞分析一樣，我們從確定組件及其外部通信路徑開始。（這一分析不會揭示內部應用程序漏洞，但會揭示其他大多數漏洞。）這有助於檢查標準的 WebSphere Application Server 拓撲（完整配置文件），並了解所有網路鏈接和協議（參見圖 2）。方框中帶陰影的項是與 Liberty 配置文件相關的組件。作為關注安全性的人員，您需要了解所有這些鏈接並專註於保護它們。這些鏈接代表前面提到的粗粒度系統邊界。
圖 2. 網路鏈接圖
在圖 2 中，鏈接上的字母表示在那些通信鏈接上使用的協議。對於每個協議，我們列出了其用途，並提供了一些關於防火牆友好性的信息，因為這對於後面的討論十分重要。協議如下：
H = 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 可以是防火牆友好的。
I = RMI/IIOP 通信
o 用途：EJB 客戶端（獨立的客戶端和 Web 容器）。
o 由於使用了動態埠和嵌入式 IP 地址（這會影響防火牆執行網路地址轉換），所以通常防火牆對其不太友好。
M = SIB 消息傳遞協議
o 用途：從 JMS 客戶端到消息傳遞引擎的通信。
o 協議：專有協議。
o 防火牆友好，因為可以指定使用的埠。防火牆很可能對 NAT 不友好。
MQ = WebSphere MQ 協議
o 用途：MQ 客戶端（實際客戶端和應用伺服器）。
o 協議：專有協議。
o 防火牆可用（有大量埠可供考慮）。請參閱 WebSphere MQ support pac MA86。
L = LDAP 通信
o 用途：WebSphere Application Server 對註冊表中的用戶信息進行驗證。
o 協議：按照 LDAP RFC 中的定義進行格式化的 TCP 流。
o 防火牆友好。
J = 通過廠商 JDBC 驅動程序進行的 JDBC 資料庫通信
o 用途：應用程序 JDBC 訪問和 WebSphere Application Server 會話資料庫訪問。
o 協議：每個資料庫專有的網路協議。
o 防火牆方面取決於資料庫（通常是防火牆友好的）。
S = 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
7. 使用 ldapRegistry 代替 quickStartSecurity 或 basicRegistry
12. 謹慎地配置和使用信任關聯攔截器 (trust association interceptor)
14. 考慮對 Web 伺服器到 WebSphere Application Server 的 HTTP 鏈接進行身份驗證
18. 加密從 WebSphere Application Server 到 LDAP 的鏈接
19. 確保只通過 HTTPS 傳輸 LTPA cookie
28. 加密 Distribution and Consistency Services (DCS) 傳輸鏈接
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 WebSEAL、WebSphere 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. 按需路由器放置
以下文章點擊率最高
Loading…