☰

應對「殭屍網路」sshd 登入失敗率高得驚人的技巧？

tag-icon • tag-icon linux ssh ddos
應對「殭屍網路」sshd 登入失敗率高得驚人的技巧？

我剛剛立即設定了 2 個新的 Debian 12 VPS。

其中一個工作得很好；另一個，我似乎有間歇性的連結。我甚至寫了一半的支援票，認為這一定是他們資料中心的連接問題，但後來深入挖掘並發現了 sshd 的“MaxStartups”功能：一旦超過一定數量的連接，打開但尚未經過身份驗證，sshd將故意開始丟棄更多連接，這與我所看到的一致。

在運行良好的 VPS 上，日誌大約每兩分鐘顯示一次惡意嘗試，這正是我所期望的。麻煩的一上來，好像就一左右每一秒平均而言，預設的 LoginGraceTime 為 2 分鐘，這完全有道理我為什麼要努力進入。 （兩個 VPS 均已配置為僅接受公鑰身份驗證，因此惡意嘗試無論如何都無法成功。）

令我驚訝的是，針對這項麻煩的嘗試來得如此之快。它們似乎來自所有不同的來源 IP，因此顯然是一個殭屍網絡，而不是我可以輕易阻止的東西。例如，fail2ban 在這裡不會執行任何操作，因為它完全在來源 IP 上運行。

我打算在這個 VPS 上放置一個公共 HTTP 伺服器，所以我還擔心，如果它已經成為透過 SSH 的殭屍網路攻擊的目標，​​我的 HTTP 伺服器可能會在我開始之前就被 DDOS 淹沒，和/或吸引掃描漏洞以利用的某人或某物的注意力。 （另一個 VPS，每兩分鐘才看到一次嘗試，我計劃放置一個郵件伺服器 - 我不確定我應該更關心哪個協議！）

  • 我應該採取多少惡意嘗試率預計定向到隨機選擇的 IPv4 位址？
  • 我應該對此採取任何行動，還是只是忍受？
    • 詢問我的 VPS 提供者是否可以更改伺服器的 IP，因為也許我只是運氣不好，這個伺服器是針對某個隨機其他人的 DDOS 目標，這些人後來釋放了他們的 IP，最終分配給了我？
    • 阻止來自任何地方的 SSH，除了我可以透過它存取的另一個 VPS——儘管我最終會在它上面運行一個公共 HTTP 伺服器？ （當需要打開 HTTP 時，關閉防火牆 SSH 似乎毫無意義 - 這樣做會給我帶來一定的不便）
    • 只是對失敗的嘗試靜音日誌訊息嗎？ （假設有選項可以做到這一點 - 我還沒有檢查）
    • 我是否可以使用替代的 SSH 伺服器軟體包，這些軟體包對於處理高頻率的惡意嘗試進行了更優化？例如，sshd 在 auth 之前為每個新連線建立一個新進程，這似乎有許多不必要的開銷：理想情況下，它應該消耗盡可能少的資源，直到 auth 成功。
    • ……還有其他建議嗎？

答案1

針對隨機選擇的 IPv4 位址的惡意嘗試的發生率應該是多少？

互聯網的背景噪音：例行、自動、拉網（而不是專門針對您的 IPv4 位址）掃描大部分互聯網，掃描暴露的主機和服務。連續的探測流，很容易導致每天在暴露的sshd 上進行數百次登入/濫用嘗試（儘管數字可能從數十到（許多）數千，某些提供者的IP 位址範圍比其他提供者的IP地址範圍更容易成為目標）來源各不相同：

  • 勤奮的提供者（可能正在運行漏洞掃描程序，因為他們希望在客戶操作不安全/易受攻擊/受損的系統時發出警告/斷開連接）
  • 研究項目（例如shodan.io和其他人）和其他好奇的人
  • 惡意行為者（可能使用殭屍網路來執行探測）
  • 等等等等

我應該對此採取任何行動，還是只是忍受？

一般來說：當您向互聯網公開伺服器和服務時，您應該期待來自整個互聯網的連接，最重要的是濫用（嘗試）。

如果某項服務並非旨在作為公共服務然後它不應該暴露在整個互聯網上。
當可以時：最佳實踐是應用存取控制。這可以採取多種形式，但常見的是限制對已知 IP 位址和/或已知 IP 位址範圍的存取。或者，當您不完全了解良好的 IP 位址範圍時，可以封鎖不太可能具有有效存取要求的範圍。
儘管將 IP 位址（範圍）與地理位置連結起來遠非 100% 可靠或完全完整，但使用 Geo-IP 資料的存取清單在這方面非常有用。

可使用安全群組或防火牆設備等在主機外部設定存取控制。那麼伺服器本身就不需要提供任何資源來維護它們。

基於主機的存取控制通常更靈活，但也需要主機本身的資源，例如基於主機的防火牆（在 Linux netfilter/iptables/nftables 上）或應用程式本身的存取控制。例如，這通常是為不同使用者設定不同 IP 位址限制的唯一方法。

當打算提供服務時為公共服務，例如帶有您的公共網站的網頁伺服器，通常您不應用存取控制，因為歡迎來自世界各地的真正的網站訪客。
通常，此類公共服務採取的方法是：允許從任何地方訪問，但是偵測惡意行為並（暫時）封鎖不良行為者使用的 IP 位址。像這樣的工具失敗2禁止就是這樣一種方法，IDS 和 IPS 系統其他。

例子：假設我的家鄉阿姆斯特丹的一家當地餐廳的外帶訂單頁面和線上預訂系統上有存取控制清單。您不會將其設定為僅允許來自阿姆斯特丹的 IP 位址存取。這可能會過於嚴格，例如拒絕使用手機造訪網站的有效當地訪客。
但另一方面，阻止已知在歐洲以外分配和使用的IP 位址範圍以及在非洲、亞太地區、北美和南美洲等地區使用的IP 位址範圍應該會大大減少濫用嘗試的次數，但這種可能性不大影響預訂/外帶訂單的數量。
相較之下，同一網路伺服器上的 SSH 存取的存取控制清單可以輕鬆地限制為網站管理員的靜態 IP 位址、其辦公室的網關和/或當他們沒有靜態 IP 位址或VPN 伺服器，其ISP 使用的範圍。

我是否可以使用替代的 SSH 伺服器軟體包，這些軟體包對於處理高頻率的惡意嘗試進行了更優化？例如，sshd 在 auth 之前為每個新連線建立一個新進程，這似乎有許多不必要的開銷：

我認為並希望您大大高估了這些登入嘗試的實際資源需求和影響。在方案中，與真實的應用程式負載相比，我所看到的暴露的 VPS 系統上「正常」等級的 ssh 濫用嘗試產生的負載可以忽略不計。

當 HTTP 需要開啟時，關閉防火牆 SSH 似乎毫無意義

安全的一般方法是最小特權原則;在防火牆規則中翻譯為：

  • 預設阻止一切
  • 只允許有需要的人存取所需的內容

因此，僅允許從某些 IP 位址而不是整個世界進行 ssh 存取並允許全世界存取連接埠 80（將普通重定向到 https）和 443（預設 https 連接埠）並不是毫無意義的。

答案2

我以前沒有見過對 ssh 的 Slowloris 類型的攻擊。查看文檔，MaxStartups 似乎並不關心這些是否來自同一客戶端（即您可以使用它來促進 DOS）。我的第一個反應（取決於攻擊的模式）是使用 iptables connlimit （限制每個客戶端 IP 的連線數）。

Fail2ban 是大多數 ssh 攻擊的明顯解決方案（我也將其用於 HTTP[S] 流量），但請確保將其配置為使用 ipset。

從長遠來看，更改 IP 位址不太可能有幫助。

阻止來自任何地方的 SSH，除了我可以透過它存取的另一個 VPS

是的 - 使用跳線盒是很常見的做法。再次強調，這是您可以自己做的事情。只需為連接埠 22 設定預設防火牆規則，然後將您的 Jumpbox 列入白名單即可。 ssh 甚至具有內建功能，使使用透明，例如

ssh -J [email protected] [email protected]

或者你可以在 ssh_config 中設定它，然後ssh targethost.example.com：

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

只是對失敗的嘗試靜音日誌訊息嗎？

我不提倡這樣做。如果您已採取合理措施來防止未經授權的訪問，請隨意忽略它們。

正如 pepoluan 所建議的，您還可以使用非標準端口和端口敲門（順便說一句，後者可以是純粹在 iptables 中實現無需使用 Knockd）

答案3

我的建議：

  1. 將 SSH 連接埠從 22 變更為其他連接埠。
  2. 如果機器人仍然可以找到您的端口，請安裝knockd並配置您的伺服器以實施端口敲門。

答案4

如果您透過公用 IP 公開 SSH，它遲早會被掃描，無論 VPS 提供者或網路為何，威脅參與者都會嘗試進行身分驗證。

我會使用 ansible playbook 來強化你的 ssh 配置，如下圖： https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

或者這個劇本，可以強化整個伺服器： https://github.com/konstruktoid/ansible-role-hardening

我還推薦fail2ban。 Fail2Ban：禁止導致多個驗證錯誤的主機 Fail2Ban 掃描 /var/log/auth.log 等日誌文件，並禁止進行過多失敗登入嘗試的 IP 位址。它透過更新系統防火牆規則以在可設定的時間內拒絕來自這些 IP 位址的新連線來實現此目的

或者，您可以建立到 VPS 網路的 VPN 連線/使用 OpenVPN（例如）在 VPS 中建立 VPN 伺服器，並將 SSH 放在 VPN 後面，而不是將其暴露到網際網路。

相關內容