讓我們告訴您一個關於「第三方」如何試圖幹擾我們客戶的工作以及如何解決這個問題的很酷的故事。
一切是如何開始的
這一切都始於 31 月 XNUMX 日早上，也就是這個月的最後一天，當時許多人迫切需要有時間來解決緊急且重要的問題。
一位合作夥伴在我們的雲端中保留了他所服務的客戶的多個虛擬機，他報告說，從9:10 到9:20，我們烏克蘭站點上運行的幾台Windows 伺服器不接受與遠端存取服務的連接，用戶無法訪問登入他們的桌面，但幾分鐘後問題似乎自行解決。
我們對通訊管道的運作進行了統計，但沒有發現流量激增或故障的情況。 我們查看了計算資源負載的統計資料 - 沒有異常。 那是什麼？
然後，另一個合作夥伴在我們的雲端中託管了大約一百多台伺服器，報告了他們的一些客戶指出的相同問題，結果證明伺服器通常是可以存取的（正確回應 ping 測試和其他請求），但是這些伺服器上的服務遠端存取要么接受新連接，要么拒絕新連接，我們討論的是不同站點上的伺服器，其流量來自不同的資料傳輸通道。
我們來看看這個流量。 帶有連接請求的資料包到達伺服器：
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
伺服器收到此資料包，但拒絕連線：
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
這意味著問題顯然不是由基礎設施運作中的任何問題引起的，而是由其他原因引起的。 也許所有使用者都遇到遠端桌面授權問題？ 也許某種惡意軟體設法滲透了他們的系統，今天它被啟動了，就像幾年前一樣 擴展數據 и 彼佳?
在我們整理過程中，我們收到了更多客戶和合作夥伴的類似請求。
這些機器上到底發生了什麼事？
事件日誌充滿了有關嘗試猜測密碼的消息：
通常，此類嘗試會在所有伺服器上註冊，其中標準連接埠 (3389) 用於遠端存取服務，並允許從任何地方進行存取。 網路上充滿了不斷掃描所有可用連接點並嘗試猜測密碼的機器人（這就是為什麼我們強烈建議使用複雜密碼而不是「123」）。 然而，那天這些嘗試的強度太高了。
我該怎麼辦？
建議客戶花費大量時間更改大量最終用戶的設定以切換到不同的連接埠？ 這不是一個好主意，客戶不會高興。 建議僅允許透過 VPN 存取？ 在匆忙和恐慌中，為那些沒有建立 IPSec 連接的人建立 IPSec 連接 - 也許這樣的幸福也不會在客戶身上微笑。 雖然，我必須說，無論如何，這都是一件神聖的事情，但我們始終建議將伺服器隱藏在專用網路中，並準備好幫助進行設置，對於那些喜歡自己解決問題的人，我們分享說明用於在我們的雲端中以網站到網站或道路模式設定IPSec/L2TP -warrior，如果有人想在自己的Windows 伺服器上設定VPN 服務，他們隨時準備分享如何設定VPN 服務的提示標準 RAS 或 OpenVPN。 但是，無論我們多麼酷，這都不是在客戶中進行教育工作的最佳時機，因為我們需要盡快解決問題，同時盡量減少使用者的壓力。
我們實施的解決方案如下。 我們對通過的流量進行了分析，以監視所有與連接埠 3389 建立 TCP 連接的嘗試，並從中選擇在 150 秒內嘗試與我們網路上超過 16 個不同伺服器建立連接的位址- 這些都是攻擊的來源（當然，如果其中一個客戶或合作夥伴確實需要與同一來源的如此多的伺服器建立連接，您可以隨時將此類來源添加到“白名單”中。此外，如果在一個C 類網路中，在這150秒內，識別出超過32 個位址，則封鎖整個網路是有意義的。封鎖設定為3 天，如果在此期間沒有給定來源的攻擊，則會自動從「黑名單」中刪除。被封鎖的來源清單每300 秒更新一次。
此清單可在以下地址取得： ，您可以基於它來建立您的 ACL。
我們準備好分享這樣一個系統的源代碼；它沒有什麼過於複雜的（這些是幾個簡單的腳本，實際上是在膝蓋上花了幾個小時編譯的），同時它可以適應和使用不僅可以防止此類別攻擊，還可以偵測並阻止任何掃描網路的嘗試：
此外，我們對監控系統的設定進行了一些更改，現在可以更密切地監控雲端中虛擬伺服器控制組對嘗試建立 RDP 連線的反應：如果反應在一定時間內沒有發生，其次，這是一個值得關注的理由。
事實證明，解決方案非常有效：客戶、合作夥伴以及監控系統都不再有投訴。 新地址和整個網路會定期添加到黑名單中，這表明攻擊仍在繼續，但不再影響我們客戶的工作。
人多才安全
今天我們獲悉，其他業者也遇到了類似的問題。 有些人仍然認為微軟對遠端存取服務的程式碼進行了一些更改（如果你還記得的話，我們第一天就懷疑過同樣的事情，但我們很快就拒絕了這個版本）並承諾盡一切可能快速找到解決方案。 有些人乾脆忽略這個問題，並建議客戶端自行保護自己（更改連接埠、將伺服器隱藏在專用網路等等）。 在第一天，我們不僅解決了這個問題，還為我們計劃開發的更俱全球性的威脅偵測系統奠定了一些基礎。
特別感謝客戶和合作夥伴，他們沒有保持沉默，沒有坐在河岸上等待敵人的屍體在河邊漂走，而是立即引起我們對問題的關注，這給了我們消除問題的機會。它在同一天。
來源： www.habr.com