我的目標是在伺服器公共 IP 上的單一連接埠上建立 VPN 隧道，並能夠透過 SSH 存取具有附加 VPN 加密層的伺服器。
伺服器配置的詳細資訊：
我在伺服器和客戶端上運行 CentOS 7。到目前為止我讀過的文檔似乎主要關注透過瀏覽器運行併中繼互聯網流量的配置。我不需要伺服器來中繼任何東西。我可以透過 VPN 存取伺服器的 SSH 連接埠並將網路流量 (80/443) 單獨保留在伺服器和用戶端上嗎？伺服器必須仍然能夠透過 Apache 向公眾提供 80/443 服務，且用戶端能夠正常存取網際網路。
答案1
如果可以的話，我將冒昧地分解您的問題，退後一步，幫助逐步完成整個解決方案設計過程，以便我們為您確定可行的解決方案。您的問題中關於 SSH 協定、VPN 以及我們如何設計安全系統的問題存在許多不準確之處。讓我們在這裡研究一下它們。
目前，您的問題需要實施特定技術的指導。但是，您的問題陳述並未評估您面臨的具體威脅，因此設計解決方案還為時過早；在這方面，你有XY 有問題我們。
您所做的任何實現要么無法解決問題（因為實際上問題出在其他地方），要么會增加複雜性，而更簡單的解決方案就足夠了。此外，不必要的複雜性是不可取的，因為它可能是進一步安全漏洞的根源。
嚴格定義您的問題
我們應該目標集中，不注重解決方案。我們應該定義問題領域的對象，確定需要考慮的任何影響因素，了解我們面臨的威脅，只有這樣我們才能開始確定可以選擇哪些技術和流程來解決手邊的問題。我們可以遵循的流程：
- 找出問題所在– 我們尋求解決的具體困難是什麼？困難應該是一個客觀的、可衡量的問題，並且有實地觀察的確鑿證據支持其存在。
- 確定假設和約束– 是否有我們可以假設處於特定狀態的特定項目，以及提議的解決方案是否有其他條件？重要的限制必須包括實施解決方案的直接成本（購買硬體、軟體或諮詢時間）和間接成本（進行流程變更、培訓員工、適應生產力損失）。
識別威脅行為者（針對安全問題）-沒有系統或流程是 100% 安全的。我們需要仔細確定所有可能發動攻擊的對手的性質，以確定我們的解決方案是否足以防止此類攻擊。這不僅適用於設計現實世界的實體安全系統，也適用於技術成果的設計。
例如，在您的評估中，您可以考慮以下因素：
- 你對手的能力– 他們的知識有多豐富，他們是否有權訪問特定資源來幫助攻擊等。
- 他們的立場– 住宅網路服務最後一哩的腳本小子與能夠存取網路中可以進行中間人攻擊的位置的國家行為者之間存在顯著差異
你的風險和風險恆溫器– 是什麼促使攻擊者專門攻擊您或您的組織？例如，您的系統是否儲存或處理通常具有受限性質且可能對其他人有價值的敏感和/或特權資料（個人資料、公司機密等）？它在網路中是否擁有可以發動進一步分析或攻擊的特權位置（例如 ISP 中的核心路由器、大公司中敏感網路外圍的邊界網關）？
這有助於確定我們是否正在與尋求攻擊目標的高級持續威脅 (APT) 參與者打交道你具體來說，或者我們是否在捍衛機會主義者。透過適度的保護措施，讓您相對於競爭對手看起來更安全，從而更容易防禦過路的機會主義者。
此外，確定您的風險偏好（您的風險恆溫器）有助於優化結果，以適當涵蓋已識別的風險，但又不會過度。
- 實施決定– 使用從此過程中收集的信息，考慮所描述的限制和我們對風險的立場，確定合適的技術和處理進行更改以解決問題，如果無法確定解決方案，則修改約束或風險狀況。
在整個過程中，我們牢記安全是一個過程，而不是目的地。我們不能「購買」安全作為現成的商品，任何提出這種建議的人都是在撒謊或別有用心（可能是為了金錢致富）。
您的具體問題
您的問題非常全面，因此我們可以根據您的特定問題概述我們的流程：
問題
我經歷過基於 rkhunter 分析的伺服器入侵，並希望減少再次發生這種情況的可能性。
具體問題是機器過去的妥協，您希望盡量減少此類問題的再次發生。
我從您的問題中可以確定的主要目標是強化機器以防止公共網路（例如互聯網）上可能發生的遠端危害事件。第二個目標是確保遠端電腦的遠端 shell 會話的機密性和完整性。
假設和約束
讓我們記錄這些要點來指導我們的解決方案：
- 機器公開的公共網站服務是安全的
- 您發動遠端連線的工作站不是攻擊相關伺服器電腦的代理程式。例如，它們本身並未被滲透（因此它們不是密鑰洩漏或被修改的向量，也不是用於建立連接的二進位檔案被篡改的向量）。您可能希望單獨探索任何客戶端電腦的安全弱點，或將它們匯總到單一評估中。
- 伺服器機器在物理上是安全的，並且親自參與該機器的人不太可能或很少篡改硬體或軟體配置。 （攻擊者物理訪問過的機器不太可能再是您的機器。）
- 假設網路受到損害。可能有人有能力攔截或轉移我們的資料包。
- 我們希望使用免費軟體來實現我們解決方案的技術方面。
- 我們假設使用者經過充分的培訓，從而可以減少對濕軟體（人類操作員）的攻擊（例如社會工程威脅）。同樣，原則上，這些問題很少得到充分緩解，並且是大多數組織的弱點，但這是伺服器故障，因此除了順便提及之外，我將忽略攻擊模型的非技術方面。
- 如果解決方案需要在首次連線之前離線分發或驗證金鑰，這是可以接受的。
- 眾所周知的加密原語被認為不會受到後門或非公開披露的攻擊。
威脅模型
我無法充分確定您的威脅模型，因為我無法了解您的組織和基礎設施，也無法了解您處理的資料組合或您可能在內部連接的專用網路。從您個人資料中的公開資訊中，我可以看到您可能在代表他人處理敏感智慧財產權的地方工作，這將構成針對特定攻擊威脅的中等到高風險的資料收集。 （這種威脅可能會擴展到您操作的個人系統。）
執行
讓我們設計一個滿足我們目標的解決方案。為了加固機器，我們需要考慮公共攻擊路線。它公開了兩個服務，我們假設 Web 服務不易受到攻擊。因此，必須考慮遠端shell連線。
以此目的，SSH 不僅有能力無需添加 VPN 會話包裝即可滿足您的要求。幾乎所有 Unix 機器都能夠運行 SSH 守護進程，並且大量直接或間接暴露於敵對網路而沒有滲透。
SSH 如何滿足我們的目標？
Secure Shell (SSH) 旨在提供遠端 shell 會話的機密性和完整性。它使用加密方法來實現這一點；特別地，主機被分配了一個或多個主機金鑰，這些主機金鑰可用於明確識別要連接的用戶端機器的主機。
SSH 的中間人攻擊
正如您所正確識別的那樣，SSH 在特定情況下容易受到中間人攻擊：大多數使用者在初始連接時不會檢查機器提供的主機金鑰；他們部署了一個首次使用時信任政策。如果 MitM 此時可以提供替代主機金鑰，則可以在不進一步偵測的情況下攔截現在和將來的連線的 SSH 工作階段。在不檢查快取的主機金鑰的情況下進行偵測將需要消除 MitM 威脅，或從未受損的網路進行連接，以便可以呈現遠端主機的真實主機金鑰。
由於我們擔心 MitM，我們必須設計一個解決方案來緩解這種情況。可供您選擇的選項包括（非詳盡）：
- 僅透過受信任的網路進行連線。這是行不通的，因為它不符合我們關於公共網路連結的目標或假設。
- 在初始連接之前分發主機金鑰的指紋（或其整個公鑰）。使用
ssh-keygen伺服器上的命令獲取指紋，將其分發給用戶，並讓他們將首次連接時顯示的指紋與伺服器上的版本進行比較。只有當指紋匹配時，他們才必須登入。 - 在 DNS 中發布主機金鑰並使用 DNSSEC 對區域進行簽署。確保所有連線用戶端都使用 DNSSEC 驗證解析器並驗證基於 DNS 的主機金鑰。更多資訊請點這裡。這種方法避免了分發和手動驗證主機金鑰的負擔，但需要特定的技術元件，而這些技術元件在許多網路上尚未廣泛使用。
暴力密碼攻擊
正在運行的 SSH 守護程式的另一個漏洞是暴力密碼攻擊。攻擊者通常會偵測您的裝置以取得 SSH 服務，並嘗試使用通用的使用者名稱和密碼清單進行身份驗證。使用者名稱位於公共清單且密碼較弱的郵箱可能會外洩。緩解這種情況的方法包括：
- 將 SSH 守護程式切換為使用基於金鑰的身份驗證並停用來自公共網際網路的密碼驗證。使用大量（例如 >2048）位數為您的使用者帳戶產生 RSA 金鑰對
ssh-keygen，或使用其他加密系統簽署的金鑰對使用適當的位數。 - 使用諸如
fail2ban查看日誌之類的軟體並添加防火牆規則，以在達到失敗登入閾值後阻止來自相同位址的進一步連線嘗試。
VPN 有幫助嗎？
VPN 解決方案可能會解決與您透過 SSH 隧道尋求解決的相同問題。他們可能使用不同的技術方法或不同的加密系統，但兩者都足以履行您的安全義務。兩者也會產生類似的開銷（例如，預先預先向各方分發或驗證金鑰的義務是相同的）。
如果您想要操作的只是遠端 shell 伺服器，那麼在這種特定情況下，VPN 提供的附加功能似乎是不必要的。執行 VPN 可能會帶來額外的風險其他在您的機器上運行的守護程序和更大的攻擊向量。