Hacking

如何處理受損的伺服器?

  • October 23, 2017

這是關於伺服器安全的規範問題- 響應違規事件(黑客攻擊)

另請參閱:

規範版本

我懷疑我的一台或多台伺服器受到黑客、病毒或其他機制的破壞:

  • 我的第一步是什麼?當我到達現場時,我應該斷開伺服器,保留“證據”,還有其他初步考慮嗎?
  • 如何讓服務重新上線?
  • 如何防止同樣的事情立即再次發生?
  • 是否有從該事件中學習的最佳實踐或方法?
  • 如果我想制定一個事件響應計劃,我應該從哪裡開始?這應該是我的災難恢復或業務連續性計劃的一部分嗎?

原版

2011.01.02 - 我在周日晚上 9.30 去上班,因為我們的伺服器以某種方式受到了破壞,導致對我們的提供商的 DOS攻擊。訪問 Internet 的伺服器已關閉,這意味著我們的 5-600 多個客戶站點現已關閉。現在這可能是 FTP 黑客攻擊,或某處程式碼中的一些弱點。在我到達那里之前我不確定。

我怎樣才能快速找到這個?如果我不盡快恢復伺服器,我們將面臨大量訴訟。任何幫助表示讚賞。我們正在執行 Open SU​​SE 11.0。


2011.01.03 - 感謝大家的幫助。幸運的是,我不是唯一負責此伺服器的人,只是最近的人。我們設法解決了這個問題,儘管它可能不適用於不同情況下的許多其他問題。我會詳細說明我們做了什麼。

我們從網路上拔下伺服器。它正在印度尼西亞的另一台伺服器上執行(試圖執行)拒絕服務攻擊,而犯罪方也在那裡。

我們首先嘗試確定伺服器上的哪個位置,考慮到我們在伺服器上有超過 500 個站點,我們預計會兼職一段時間。然而,在 SSH 訪問仍然存在的情況下,我們執行了一個命令來查找在攻擊開始時編輯或創建的所有文件。幸運的是,有問題的文件是在寒假期間創建的,這意味著當時在伺服器上創建的其他文件並不多。

然後,我們能夠辨識ZenCart網站內上傳的圖像文件夾中的違規文件。

短暫休息後,我們得出結論,由於文件位置的原因,它一定是通過未充分保護的文件上傳工具上傳的。經過一番Google搜尋,我們發現存在一個安全漏洞,允許在 ZenCart 管理面板中上傳文件,以獲取唱片公司的圖片。(它甚至從未真正使用過的部分),發布此表單只是上傳了任何文件,它沒有檢查文件的副檔名,甚至沒有檢查使用者是否登錄。

這意味著可以上傳任何文件,包括用於攻擊的 PHP 文件。我們在受感染的站點上使用 ZenCart 保護了漏洞,並刪除了有問題的文件。

工作完成了,我凌晨 2 點在家


The Moral

  • 始終為 ZenCart 或任何其他 CMS 系統應用安全更新檔。當安全更新發佈時,全世界都意識到了這個漏洞。- 始終進行備份,並備份您的備份。- 僱用或安排在這種情況下會在那裡的人。為了防止任何人依賴伺服器故障上的恐慌文章。

很難從你在這裡發布的內容中給出具體的建議,但我確實有一些基於我很久以前寫的一篇文章的一般性建議,當時我仍然可以打擾到部落格。

不要恐慌

首先,除了從入侵之前的備份中恢復系統之外,沒有“快速修復”,這至少有兩個問題。

  1. 很難確定入侵發生的時間。
  2. 它不能幫助您關閉允許他們上次闖入的“漏洞”,也不能處理可能也發生的任何“數據盜竊”的後果。

黑客入侵他們的網路伺服器的受害者不斷地問這個問題。答案很少改變,但人們一直在問這個問題。我不確定為什麼。也許人們只是不喜歡他們在尋求幫助時看到的答案,或者他們找不到他們信任的人來給他們建議。或者,也許人們閱讀了這個問題的答案,過分關注 5% 為什麼他們的案例很特殊,並且與他們可以在網上找到的答案不同,而錯過了 95% 的問題和答案,因為他們的案例足夠接近相同作為他們在網上閱讀的。

這讓我想到了第一個重要的資訊。我真的很感激你是一個特別獨特的雪花。我很欣賞您的網站也是如此,因為它反映了您和您的業務,或者至少反映了您代表雇主的辛勤工作。但是對於外面的人來說,無論是尋找問題的電腦安全人員試圖幫助你,還是攻擊者本人,你的問題很可能與他們遇到的所有其他案例至少 95% 相同曾經看過。

不要將攻擊視為個人,也不要將此處的建議或您從其他人那裡獲得的建議視為個人。如果您只是在成為網站黑客的受害者後閱讀本文,那麼我真的很抱歉,我真的希望您能在這裡找到一些有用的東西,但現在不是讓您的自我妨礙您需要做的事情的時候做。

您剛剛發現您的伺服器被黑了。怎麼辦?

不要恐慌。絕對不要倉促行事,也絕對不要假裝事情從未發生過,根本不採取行動。

第一:了解災難已經發生。現在不是否認的時候;是時候接受已經發生的事情,以現實的態度對待它,並採取措施管理影響的後果。

其中一些步驟會受到傷害,並且(除非您的網站包含我的詳細資訊的副本)我真的不在乎您是否忽略所有或部分這些步驟,這取決於您。但是正確地遵循它們最終會使事情變得更好。這種藥的味道可能很糟糕,但有時如果你真的想讓治療起作用,你就不得不忽略這一點。

阻止問題變得比現在更糟:

  1. 您應該做的第一件事是將受影響的系統與 Internet 斷開連接。無論您遇到什麼其他問題,讓系統連接到網路只會讓攻擊繼續進行。我的意思是字面意思;如果需要的話,讓某人親自訪問伺服器並拔下網路電纜,但在您嘗試做任何其他事情之前斷開受害者與搶劫者的連接。
  2. 更改與受感染系統位於同一網路的所有電腦上所有帳戶的所有密碼。不完全是。所有帳戶。所有電腦。是的,你是對的,這可能是矯枉過正;另一方面,它可能不會。兩種方式你都不知道,是嗎?
  3. 檢查您的其他系統。特別注意其他面向 Internet 的服務,以及那些持有金融或其他商業敏感數據的服務。
  4. 如果系統持有任何人的個人數據,請立即通知負責數據保護的人員(如果不是您)並敦促全面披露。我知道這個很難。我知道這個會很痛。我知道許多企業希望將此類問題隱藏在地毯下,但企業將不得不處理它 - 並且需要在關注任何和所有相關隱私法的情況下這樣做。

不管你的客戶對你告訴他們問題有多惱火,如果你不告訴他們,他們會更加惱火,而且他們只有在有人使用他們的信用卡詳細資訊收取價值 8,000 美元的商品後才會自己發現從你的網站偷來的。

還記得我之前說的話嗎?壞事已經發生了。現在唯一的問題是你如何處理它。

充分理解問題:

  1. 在這個階段完全完成之前,不要讓受影響的系統重新上線,除非你想成為那個文章是我真正決定寫這篇文章的引爆點的人。我不會連結到那個文章,這樣人們就可以得到一個廉價的笑聲,但真正的悲劇是人們無法從錯誤中吸取教訓。
  2. 檢查“被攻擊”的系統,了解攻擊如何成功地危及您的安全。盡一切努力找出攻擊的“來源”,以便您了解您有哪些問題以及需要解決哪些問題,以確保您的系統在未來安全。
  3. 再次檢查“被攻擊”的系統,這一次是為了了解攻擊的去向,以便您了解哪些系統在攻擊中受到損害。確保您跟進任何暗示受損系統可能成為進一步攻擊您的系統的跳板的指針。
  4. 確保完全了解任何和所有攻擊中使用的“網關”,以便您可以開始正確關閉它們。(例如,如果您的系統受到 SQL 注入攻擊的影響,那麼您不僅需要關閉它們侵入的特定有缺陷的程式碼行,您還需要審核所有程式碼以查看是否存在相同類型的錯誤是在別處製作的)。
  5. 了解攻擊可能會因為不止一個缺陷而成功。通常,攻擊的成功不是通過找到系統中的一個主要錯誤,而是通過將幾個問題(有時它們本身很小且微不足道)串在一起來破壞系統。例如,使用 SQL 注入攻擊向數據庫伺服器發送命令,發現您正在攻擊的網站/應用程序在管理使用者的上下文中執行,並使用該帳戶的權限作為墊腳石來破壞其他部分一個系統。或者黑客喜歡這樣稱呼它:“在辦公室裡利用人們常犯的錯誤的另一天”。

為什麼不直接“修復”您檢測到的漏洞利用程序或 rootkit 並將系統重新上線?

在這種情況下,問題在於您不再控制該系統。它不再是你的電腦了。

確定您已控制系統的唯一方法是重建系統。雖然發現和修復用於侵入系統的漏洞利用很有價值,但是一旦入侵者獲得控制權,您就無法確定係統還做了什麼(事實上,對於招募的黑客來說,這並非聞所未聞)系統進入殭屍網路,以修補他們自己使用的漏洞,保護“他們的”新電腦免受其他黑客攻擊,以及安裝他們的 rootkit)。

制定恢復計劃並使您的網站重新上線並堅持下去:

沒有人希望離線時間超過他們必須的時間。這是給定的。如果該網站是一個創收機制,那麼快速使其重新上線的壓力將是巨大的。即使唯一危在旦夕的是您/您公司的聲譽,這仍然會產生很大的壓力來迅速恢復。

但是,不要屈服於過快重新上線的誘惑。而是盡快採取行動,以了解導致問題的原因並在重新上線之前解決問題,否則您幾乎肯定會再次成為入侵的受害者,請記住,“被黑客入侵一次可以歸類為不幸;之後直接再次被黑客入侵看起來像是粗心大意”(向奧斯卡王爾德道歉)。

  1. 我假設您甚至在開始本節之前就已經了解了導致成功入侵的所有問題。我不想誇大這個案例,但如果你沒有先這樣做,那麼你確實需要這樣做。對不起。
  2. 永遠不要支付勒索/保護費。這是一個容易標記的標誌,你不希望那個片語曾經用來描述你。
  3. 不要試圖在沒有完全重建的情況下將相同的伺服器重新上線。在舊硬體上建構一個新盒子或“從軌道上對伺服器進行核對並進行全新安裝”應該比在舊系統上審核舊系統的每個角落以確保它在放回之前是乾淨的要快得多又上線了。如果您不同意這一點,那麼您可能不知道確保系統完全清潔的真正含義,或者您的網站部署程序一團糟。您可能擁有站點的備份和測試部署,您可以使用它們來建構實時站點,如果您沒有,那麼被黑客入侵並不是您最大的問題。
  4. 在重新使用黑客攻擊時系統上“實時”的數據時要非常小心。我不會說“永遠不要這樣做”,因為您會忽略我,但坦率地說,我認為您確實需要考慮在您知道無法保證其完整性時保留數據的後果。理想情況下,您應該從入侵之前的備份中恢復它。如果您不能或不會這樣做,您應該非常小心這些數據,因為它已被污染。如果這些數據屬於客戶或網站訪問者而不是直接屬於您,您應該特別注意對其他人的後果。
  5. 仔細監控系統。您應該下定決心在未來將其作為一個持續的過程(更多內容見下文),但在您的網站重新上線後的這段時間內,您會格外小心地保持警惕。入侵者幾乎肯定會回來,如果你能發現他們試圖再次闖入,你肯定會很快看到你是否真的關閉了他們之前使用的所有漏洞以及他們為自己製造的任何漏洞,並且你可能會收集到有用的資訊您可以傳遞給當地執法部門的資訊。

降低未來的風險。

您需要了解的第一件事是,安全是一個過程,您必須在設計、部署和維護面向 Internet 的系統的整個生命週期中應用它,而不是像廉價的那樣在程式碼上貼幾層之後畫。為了獲得適當的安全性,需要從一開始就設計服務和應用程序,並將其作為項目的主要目標之一。我意識到這很無聊,而且你以前都聽過,而且我“只是沒有意識到讓你的 beta web2.0 (beta) 服務在網路上進入 beta 狀態的壓力”,但事實是這一直被重複,因為它第一次被說是真的,它還沒有成為謊言。

你無法消除風險。你甚至不應該嘗試這樣做。但是,您應該做的是了解哪些安全風險對您很重要,並了解如何管理和降低風險的影響以及風險發生的可能性。

您可以採取哪些步驟來降低攻擊成功的可能性?

例如:

  1. 允許人們闖入您的站點的漏洞是否是供應商程式碼中的已知錯誤,並且有更新檔可用?如果是這樣,您是否需要重新考慮如何在面向 Internet 的伺服器上修補應用程序的方法?
  2. 允許人們闖入您的站點的漏洞是否是供應商程式碼中的未知錯誤,沒有更新檔可用?我當然不主張在遇到這樣的事情時更換供應商,因為他們都有自己的問題,如果你採取這種方法,你最多會在一年內用完平台。但是,如果一個系統經常讓您失望,那麼您應該遷移到更強大的系統,或者至少重新建構您的系統,以便易受攻擊的組件保持在棉花中並儘可能遠離敵對的眼睛。
  3. 該缺陷是您(或為您工作的承包商)開發的程式碼中的錯誤嗎?如果是這樣,您是否需要重新考慮如何批准將程式碼部署到實時站點的方法?是否可以通過改進的測試系統或更改您的編碼“標準”來擷取錯誤(例如,雖然技術不是萬能藥,但您可以通過使用有據可查的編碼技術來降低 SQL 注入攻擊成功的可能性)。
  4. 該漏洞是由於伺服器或應用程序軟體的部署方式問題造成的嗎?如果是這樣,您是否在可能的情況下使用自動化程序來建構和部署伺服器?這些對於在所有伺服器上保持一致的“基線”狀態非常有幫助,最大限度地減少必須在每台伺服器上完成的自定義工作量,從而最大限度地減少出錯的機會。程式碼部署也是如此——如果你需要做一些“特別”的事情來部署你的 web 應用程序的最新版本,那麼盡量自動化它並確保它總是以一致的方式完成。
  5. 通過更好地監控您的系統,是否可以更早地發現入侵?當然,為您的員工提供 24 小時監控或“隨叫隨到”系統可能不具有成本效益,但有些公司可以為您監控面向 Web 的服務,並在出現問題時提醒您。你可能會決定你買不起或不需要它,這很好……只要考慮到它。
  6. 在適當的情況下使用諸如tripwire 和nessus 之類的工具——但不要因為我說過就盲目地使用它們。花時間學習如何使用一些適合您環境的優秀安全工具,保持這些工具的更新並定期使用它們。
  7. 考慮聘請安全專家定期“審核”您的網站安全性。同樣,您可能會決定您買不起或不需要它,這很好……只要考慮到它。

您可以採取哪些步驟來減少成功攻擊的後果?

如果您認為您家的下層洪水的“風險”很高,但還不足以保證搬家,您至少應該將不可替代的傳家寶搬到樓上。對?

  1. 你能減少直接暴露在網際網路上的服務數量嗎?您能否在內部服務和麵向 Internet 的服務之間保持某種差距?這確保即使您的外部系統受到損害,使用它作為跳板攻擊您的內部系統的機會也是有限的。
  2. 您是否在儲存不需要儲存的資訊?當這些資訊可以存檔在其他地方時,您是否“線上”儲存這些資訊。這部分有兩點;顯而易見的一點是人們無法從您那裡竊取您沒有的資訊,第二點是您儲存的越少,您需要維護和編碼的就越少,因此錯誤溜進的機會就越少您的程式碼或系統設計。
  3. 您是否為您的網路應用程序使用“最少訪問”原則?如果使用者只需要從數據庫中讀取,請確保 Web 應用程序用於服務的帳戶僅具有讀取訪問權限,不允許其寫入訪問權限,當然也不允許系統級訪問權限。
  4. 如果您對某事不是很有經驗,並且它不是您業務的核心,請考慮將其外包。換句話說,如果您經營一個小型網站,談論編寫桌面應用程式碼並決定開始從該網站銷售小型桌面應用程序,那麼請考慮將您的信用卡訂購系統“外包”給像 Paypal 這樣的公司。
  5. 如果可能的話,將練習從受損系統中恢復作為災難恢復計劃的一部分。可以說,這只是您可能遇到的另一種“災難場景”,它有自己的一系列問題和問題,與通常的“伺服器機房著火”/“被巨型伺服器吃掉的小動物入侵”之類的事情不同。

…最後

我可能沒有遺漏其他人認為重要的東西,但如果你不幸成為黑客的受害者,上述步驟至少應該可以幫助你開始整理東西。

最重要的是:不要驚慌。三思而後行。一旦你做出決定,就堅定地行動,如果你有什麼要添加到我的步驟列表中,請在下面留下評論。

引用自:https://serverfault.com/questions/218005