Security

黑客預防、取證、審計和對策

  • March 1, 2015

最近(但這也是一個經常出現的問題)我們看到了 3 個關於黑客和安全的有趣主題:

如何處理受損的伺服器?.

查找被黑伺服器是如何被黑的

文件權限問題

最後一個沒有直接關係,但它強調了搞亂 Web 伺服器管理是多麼容易。

由於有幾件事是可以做的,所以在發生不好的事情之前,我想就限制攻擊的背後影響以及如何在可悲的情況發生時做出反應的良好做法提出建議。

這不僅僅是保護伺服器和程式碼的問題,還包括審計、日誌記錄和對策。

您是否有任何好的實踐列表,或者您更喜歡依賴軟體或專家來持續分析您的 Web 伺服器(或根本沒有)?

如果是,你能分享你的清單和你的想法/意見嗎?

更新

我收到了幾個很好且有趣的回饋。

我想要一個簡單的列表,這樣既方便 IT 安全管理員,也方便網路*專家*。

即使大家都給出了好的和正確的答案,目前我更喜歡羅伯特的一個,因為它是最簡單、清晰和簡潔的,而sysadmin1138是最完整和精確的。

但是沒有人考慮使用者的觀點和感知,我認為這是首先要考慮的。

使用者何時會訪​​問我被黑的網站會怎麼想,如果您擁有有關他們的敏感數據,則更多。這不僅僅是在哪裡儲存數據的問題,而是如何讓憤怒的使用者平靜下來的問題。

數據、媒體、權威和競爭對手呢?

有兩個大領域需要關注:

  1. 讓人很難進去。
  2. 制定政策和程序,以冷靜有效地處理有人超過第 1 點的事件。

讓人難以進入

這是一個非常複雜的話題,其中很多都集中在確保您有足夠的資訊來弄清楚 WTF 事後發生。為簡單起見,抽象的要點:

  • 保留日誌(另請參閱安全資訊事件管理)

    • 任何授權嘗試,無論成功與否,最好保持源資訊完整。
    • 防火牆訪問日誌(如果正在使用,這可能必須包括每台伺服器的防火牆)。
    • 網路伺服器訪問日誌
    • 數據庫伺服器身份驗證日誌
    • 特定於應用程序的使用日誌
    • 如果可能,SIEM 可以針對可疑模式發出警報。
  • 實施適當的訪問控制

    • 確保在任何地方都正確設置了權限,並在可能的情況下避免“懶惰的權利”(“哦,讓每個人都閱讀”)。
    • 定期審核 ACL 以確保實際遵循程序,並在故障排除完成後正確刪除臨時故障排除步驟(“讓每個人都閱讀,然後看看它是否有效”)。
    • 所有防火牆直通規則都需要證明合理,並定期進行審核。
    • 還需要審核 Web 伺服器訪問控制,包括 Web 伺服器和文件系統 ACL。
  • 實施變更管理

    • 安全環境的任何變化都需要由多人集中跟踪和審查。
    • 更新檔應該包含在這個過程中。
    • 擁有一個通用的作業系統建構(模板)將簡化環境並使更改更易於跟踪和應用。
  • 禁用訪客帳戶。

  • 確保所有密碼均未設置為預設值。

    • 現成的應用程序可以為使用者設置預定義的密碼。改變它們。
    • 許多 IT 設備都帶有眾所周知的使用者/密碼對。改變那些,即使你每年只登錄一次。
  • 練習最小特權。為使用者提供他們實際需要的訪問權限。

    • 對於管理員使用者,兩個帳戶設置是明智的。一個用於電子郵件和其他辦公任務的正常帳戶,另一個用於提升隱私的工作。虛擬機使這更容易使用。
    • 不要鼓勵經常使用通用管理員/root 帳戶,很難跟踪誰在什麼時候做了什麼。

制定政策和程序以冷靜有效地處理有人進入的事件

安全事件策略是所有組織都必須具備的。它極大地減少了“被砍掉腦袋到處亂跑”的反應階段,因為人們在面對此類事件時往往會變得不理性。入侵是大而可怕的事情。對遭受入侵感到羞恥可能會導致頭腦冷靜的系統管理員開始做出錯誤的反應。

組織的所有級別都需要了解這些政策。事件越大,高層管理人員就越有可能以某種方式介入,制定處理事情的程序將極大地幫助抵禦來自高層的“幫助”。它還為直接參與事件響應的技術人員提供了一定程度的保障,以中層管理人員與組織其他部門互動的程序的形式。

理想情況下,您的災難恢復策略已經定義了在災難恢復策略生效之前某些服務可能不可用的時間。這將有助於事件響應,因為這些類型的事件災難。如果事件屬於無法滿足恢復視窗的類型(例如:熱備份 DR 站點獲取更改數據的實時饋送,並且入侵者刪除了一堆在被複製到 DR 站點之前被複製的數據)注意到。因此,需要使用冷恢復程序)然後高層管理人員需要參與風險評估會談。

任何事件響應計劃的一些組成部分:

  • 辨識受感染的系統和暴露的數據。

  • 儘早確定是否需要保留法律證據以供最終起訴。

    • 如果要保留證據*,除非絕對需要,否則不要觸及有關該系統的任何內容*。不要登錄它。不要篩選日誌文件。做。不是。觸碰。

    • 如果要保留證據,則需要將受感染的系統保持線上斷開連接,直到經過認證的電腦取證專家能夠以與證據處理規則兼容的方式剖析系統。

      • 關閉受感染的系統可能會污染數據。
      • 如果您的儲存系統允許此(離散 SAN 設備)在斷開連接之前對受影響的 LUN 進行快照並將其標記為只讀。
    • 證據處理規則很複雜,而且很容易搞砸。除非您接受過有關它們的培訓,否則不要這樣做。大多數一般的系統管理員都沒有接受過這種培訓。

    • 如果要保留證據,請將服務失去視為硬體失去災難,並使用新硬體開始恢復過程。

  • 預先設定了什麼樣的災難需要什麼樣的通知的規則。法律法規因地區而異。

    • 有關“暴露”和“經證實的妥協”的規則確實有所不同。
    • 通知規則將要求通信部門參與。
    • 如果所需的通知足夠大,則必須涉及高層管理人員。
  • 使用 DR 數據,確定在使服務重新上線成為更高優先級之前可以花費多少“WTF 剛剛發生”的時間。

    • 服務恢復時間可能需要弄清楚發生了什麼是次要的。如果是這樣,則在服務恢復後拍攝受影響設備的驅動器圖像以進行解剖(這不是證據副本,而是供技術人員進行逆向工程)。
    • 計劃您的服務恢復任務,包括全面重建受影響的系統,而不僅僅是清理混亂。
    • 在某些情況下,服務恢復時間非常緊迫,以至於需要在辨識出危害發生後立即獲取磁碟映像,並且不保留法律證據。重建服務後,就可以開始弄清楚發生了什麼的工作。
  • 篩選日誌文件以獲取有關攻擊者如何進入以及他們可能曾經做過什麼的資訊。

  • 篩選更改的文件以獲取有關他們如何進入的資訊,以及他們進入後做了什麼。

  • 篩選防火牆日誌以獲取有關它們來自何處、可能將數據發送到何處以及可能發送了多少數據的資訊。

在妥協之前製定政策和程序,並為在發生妥協時實施它們的人所熟知,這是需要做的事情。它為每個人提供了一個響應框架,在人們不會思考的時候。高層管理人員可以對訴訟和刑事指控大發雷霆,但實際上將案件放在一起是一個昂貴的過程,並且事先知道這可以幫助平息憤怒。

我還注意到,這類事件確實需要納入整體災難響應計劃。妥協很可能觸發“失去硬體”響應策略,也可能觸發“數據失去”響應。了解您的服務恢復時間有助於設定安全響應團隊在服務恢復需要之前將其傾倒在實際受損系統(如果不保留法律證據)上的預期時間。

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