在預算範圍內處理網路伺服器安全威脅的正確方法

在預算範圍內處理網路伺服器安全威脅的正確方法

在我們的年度安全審查期間,我想起了今年早些時候的事件,當時我們的組織網路伺服器受到了威脅。這是一項組織政策,並對我們的網站造成 DDoS 威脅。幸運的是,這並沒有帶來什麼不好的結果,這只是一個空洞的威脅。然而,我們仍然立即通知了 CIO、CSO、CEO 和我們的託管提供商,他們對我們的回應表示讚賞。由於我們組織(教育領域)的性質,先發製人的回應涉及許多人,包括與當地執法部門的協調。

儘管我們的回應足以應對空洞的威脅,但這讓我意識到該網路應用程式的攻擊計劃是多麼少。現在的設定是:

  • 不在企業防火牆後面的 Linode VPS(這背後有一個很長的故事,不值得解釋)
  • 同一伺服器上的 PostgreSQL 資料庫僅允許本地連接
  • 我們目前正在遵循最佳實踐來保護 Nginx 伺服器 [1]
  • 我們正在遷移到證書身份驗證的 SSH 訪問
  • 備份 VPS 具有所有最新的伺服器設置,只需要推送最新版本的程式碼並遷移資料庫設定(現在用作測試伺服器,但也設想作為地理冗餘選項)

我想我的問題可能可以歸結為我應該採取哪些其他步驟來鎖定我的伺服器並防範 DDoS?我們很樂意使用Cloudflare 業務具有 DDoS 保護,但我們並不總是需要它,而且每月 200 美元對於組織來說有點貴。我還需要這個嗎?是否有允許臨時 DDoS 防護的解決方案?如果不是,在攻擊期間/之後保持穩定性的最佳方法是什麼?最後,應該實施什麼日誌記錄,以便我們可以在發生攻擊時協助執法?

答案1

我還應該採取哪些其他步驟來鎖定我的伺服器並防範 DDoS?

  1. 防火牆關閉任何未使用的連接埠和協定。在適用和可能的情況下,僅限制對受信任 IP 的存取。
  2. 及時應用所有安全性修補程式和更新
  3. 實施網路監視器,可以對可疑的活動爆發發出警報

每月 200 美元對於該組織來說有點貴。我還需要這個嗎?

不,除非它增加了價值並成為必備品。

是否有允許臨時 DDoS 防護的解決方案?

是的。他們可能需要投入大量的前期時間來解決實施 DDoS 服務的複雜問題。 http://www.blacklotus.net/protect/emergency-ddos-protection就是這樣一種按需服務。

如果不是,在攻擊期間/之後保持穩定性的最佳方法是什麼?

坐在那裡接受它。這就是 DDoS 的本質。您可以嘗試對 IP 進行防火牆,但如果攻擊確實是分散式的…那麼這就像用水槍撲滅野火一樣。

最後,應該實施什麼日誌記錄,以便我們可以在發生攻擊時協助執法?

維護傳入來源 IP 和時間戳記以及任何其他相關取證資料的日誌。例如,如果它是一個 Web 伺服器,請嘗試記錄使用者代理程式和請求的資源。流量速率(例如每秒資料包數和每秒請求數)很有幫助。

DDoS 歸結為數學分析。如果有人試圖勒索您,他們打賭他們可以擾亂您的業務,足以迫使您支付保護費來阻止這種情況發生。規模是一個因素,打敗較小的運營商更容易,但他們能夠支付更少的費用。如果您收到電子郵件威脅 - 最好的做法是忽略它。發動和維持 DDoS 攻擊需要大量的殭屍網路資源 - 他們不能像垃圾郵件發送者那樣直接攻擊所有人。他們很可能只是在進行大規模的網路釣魚攻擊,尋找容易恐嚇的目標。由於 DDoS 野獸的性質,受害者相當無助,除非他們能夠部署複雜的資料包過濾預防方案或有預算來簽署外部服務。

答案2

inetplumber的回答很棒。

我想補充一點,另一個選擇是將您的應用程式配置為可擴展,以便您可以在不影響用戶的情況下處理更大規模的攻擊。例如,您可以在 Amazon AWS 上設定虛擬私有雲 (VPC),並且只能從 VPC 內部存取 PostgreSQL 伺服器。您可以設定負載平衡器前端以在多個伺服器之間分配負載。

這樣做的好處是,您可以快速擴展到 100 台(或更多)伺服器,而無需前期投資,而且速度非常快(如果您已經配置),從而使您成為更困難的目標。您只需要在實際受到攻擊的時間內為這些伺服器付費。當您沒有受到攻擊時,您只需要為一台網頁伺服器和一台資料庫伺服器付費。

困難的部分是設置,它肯定比您當前的配置更複雜。要快速擴大規模,還需要做更多的工作。但如果你正在尋找一些可以做的計劃(特別是如果由於其他問題,你認為你可能成為未來的目標),那就是了。

答案3

我還應該採取哪些其他步驟來鎖定我的伺服器並防範 DDoS?

  1. 如果你的 web 應用程式不是互動式的,只是顯示內容:使用 nginx + 代理緩存,快取時間短(通常 1-5 分鐘就可以了)。這大大提高了性能並迫使攻擊者分配更多資源

  2. 設定一個限制防火牆來過濾所有不需要的東西進進出出將 INPUT/OUTPUT/FORWARD-Policy 設定為 DROP;請務必記錄每個嘗試發出的連線(UPD 連接埠 53 除外:)

  3. 如果您無法將 SSH 限制為靜態管理 IP,請使用備用高連接埠(例如 22222),這將防止大量「hello mcfyl - 有人在那裡」 - 門環

  4. 另外,使用fail2ban/denyhosts來保護ssh免受暴力攻擊

  5. 如果您有管理資源:使用 OSSEC 和輕量級 WAF(有用於 nginx 的 naxsi,輕量級,而不是像 mod_security 這樣的 PITA),但您需要有人來設定和維護此類安裝

  6. 實施備份並使用備用伺服器作為備份目標

  7. 保持您的 webapp 代碼是最新的;如果您使用開源項目,請註冊他們的安全郵件清單。

  8. 盡量避免使用已知有大量漏洞的軟體

  9. 如果您使用 admin-login 和/或 managament-webapps:為這些登入名稱 + ssl 建立基本驗證(自簽名憑證即可)。

  10. 如果可以的話,請使用 ssh 隧道來代替開啟端口,例如用於開發

如果不是,在攻擊期間/之後保持穩定的最佳方法是什麼

  1. 保持冷靜
  2. 有處理這種情況的經驗豐富的人
  3. 準備好一些應急計劃

你已經做過的最重要的事情:在事情發生之前考慮它(以及可能的對策)。

相關內容