本教程的第二部分將介紹如何設置和保護多服務器CrowdSec安全引擎的安裝。在第一部分中，我們講解瞭如何在多台服務器上設置CrowdSec安全引擎，其中一台服務器作為父服務器，另外兩台服務器將警報轉發給它。
本部分將解決先前多服務器安全引擎安裝中明文HTTP通信帶來的安全問題。為了解決這個問題，我們建議通過加密通道建立安全引擎之間的通信。此解決方案允許服務器2或服務器3信任服務器1的身份，並避免中間人攻擊。
創建證書首先，您需要創建一個證書。這可以通過以下單行命令實現：
openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"
目前，安全引擎在啟動時無法請求私鑰的密碼。因此，您可以選擇每次啟動或重新加載安全引擎時手動解密私鑰，或者將密鑰未加密地存儲。無論哪種方式，要刪除密碼，您可以使用以下命令：
openssl rsa -in encrypted-key.pem -out key.pem
然後，在安全引擎啟動後，可以安全地刪除未加密的密鑰文件。
配置安全引擎以使用自簽名證書在服務器1上，您需要配置安全引擎以使用生成的證書。如下所示，以下/etc/crowdec/config.yaml摘錄中api.server部分的tls.cert_file和tls.key_file選項設置為生成的證書文件。
api:
server:
log_level: info
listen_uri: 10.0.0.1:8080
profiles_path: /etc/crowdsec/profiles.yaml
online_client: # Crowdsec API credentials (to push signals and receive bad
tls:
cert_file: /etc/crowdsec/ssl/cert.pem
key_file: /etc/crowdsec/ssl/key.pem在客戶端，配置更改發生在兩個文件中。首先，修改/etc/crowdec/config.yaml以接受自簽名證書，方法是將insecure_skip_verify設置為true。
您還需要在/etc/crowdsec/local_api_credentials.yaml文件中將HTTP更改為HTTPS以反映這些更改。此小的更改必須在所有三台服務器（服務器1、服務器2和服務器3）上完成。
注意：請記住，如果服務器1也用作日誌處理器，則也必須在此服務器上進行此LAPI配置。
url: https://10.0.0.1:8080/ login: <login> password: <password></password></login>
旁注：顯然，使用自簽名證書不會對LAPI服務器的所有權提供任何保證。使用該服務的服務器（在此設置中為服務器2或服務器3）仍然容易受到中間人攻擊，但至少此設置提供了加密通信。這就是需要InsecureSkipVerify選項的原因。
Let's Encrypt或Amazon ACM等服務可以通過為可以添加到/etc/hosts或本地DNS服務器的完全限定域名頒發證書來解決InsecureSkipVerify問題。然後，可以使用此指定的完全限定域名填充/etc/crowdsec/local_api_credentials.yaml。
這確實有效，並防止設置InsecureSkipVerify選項。只要可以信任DNS配置，這就能確保客戶端和服務器之間的通信不會被篡改，但這仍然應該被視為一種變通方法。
配置和管理SSL公鑰基礎設施（PKI）的過程不在本教程的範圍內，但我強烈建議您查看OpenSSL官方文檔。簡單的PKI方案足以滿足此安全引擎設置的需求。
根據OpenSSL文檔，有一些值得一提的事情。
要在我們的CrowdSec TLS方案中使用，證書請求必須使用與Crowdsec LAPI服務器的IP相對應的主題替代名稱發出。這可以通過在調用OpenSSL進行證書請求時定位SAN環境變量來完成（請參閱OpenSSL簡單PKI方案中的步驟3.3）。
openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"
在啟動CrowdSec安全引擎之前，必須將根證書和簽名證書的公共部分（在OpenSSL簡單PKI方案的步驟4.5中創建的捆綁文件）添加到本地證書存儲區。在此設置中，這是連接到LAPI服務器所必需的。有很多方法可以做到這一點，golang源代碼指定了預期證書的位置，或者您可以在systemd服務文件中使用SSL_CERT_FILE環境變量來指定啟動安全引擎時查找證書的位置。
在本文首次發表後，我們在安全引擎中添加了一項新功能，您現在不僅可以保護TLS上的通信，還可以使用證書確保身份驗證。在官方文檔中，您可以找到一個很好的示例，該示例顯示瞭如何在安全引擎之間或安全引擎和補救組件之間使用證書進行TLS身份驗證。
本文重點介紹瞭如何保護不同CrowdSec安全引擎安裝之間的通信。所考慮的用例是在私有網絡中的安全引擎安裝，但這也可以在具有互聯網通信的公共網絡上部署。在這種情況下，第三方證書很容易就能解決問題。
根據需要，我們提出了三種不同的方法來實現安全引擎之間的安全TLS通信——使用自簽名證書、使用證書頒發機構頒發的證書和使用SSL公鑰基礎設施。
第一種方案（使用自簽名證書）僅適用於您希望確保加密通信而無需身份驗證的情況。當您可以修改本地DNS解析時，才可以考慮第二種方案。第三種方案是最複雜的，但它適合大多數用例，並且在安全問題嚴重時可能是最佳選擇。
希望本教程對您有所幫助。感謝您的閱讀，敬請期待！
如果您有任何疑問或反饋，請隨時通過我們的Discord和Discourse社區平台與我們聯繫。
以上是使用https保護多服務器安全引擎安裝的詳細內容。更多資訊請關注PHP中文網其他相關文章！
