伺服器運維環境安全體系(上篇)

融雲RongCloud發表於2022-06-07


(點選報名)


總有一些突發事件提醒我們,網路安全的重要性。關注【融雲全球網際網路通訊雲】瞭解更多

5 月 25 日,“搜狐全體員工遭遇工資補助詐騙”的新聞衝上熱搜,令人咋舌。當天下午,搜狐釋出宣告稱,不法分子冒充財務部盜發郵件,24 名員工被騙 4 萬餘元。從額度和手法上看,這個事件都算是普通級別,但人們的譁點在於,它發生在知名的網際網路企業。也從另一個角度說明,大眾對於網路安全的關注程度正在提升。

網路安全問題伴隨著網際網路的高速發展日益嚴峻,新經濟業態使得各關鍵行業和重要系統對網路安全保障的需求不斷增加,安全已成為網路強國建設的基礎保障。同時,企業的安全生產也離不開安全相關的技術保障,因此每一個企業都需要構建一套自上而下完善的安全解決方案。

本文圍繞伺服器運維環境安全體系展開,通過上、下兩篇,分析網路安全現狀並提出應對之策。


網路安全現狀

當下硬體、軟體和協議或系統安全策略的具體實現上存在的缺陷,使入侵者可以在未經許可的情況下非法訪問和破壞系統及系統中資料。同時,從訪問的角度來看,當系統執行與系統安全發生衝突時,也會產生安全漏洞。

漏洞問題也與時間密切相關,隨著軟體的深入使用,軟體漏洞將不斷暴露。老漏洞不斷被攻克,新漏洞不斷出現,漏洞問題會長期存在。隨著數字化程式的不斷演進,大量新型網際網路產品和服務應運而生。安全漏洞、資料洩露、網路詐騙、勒索病毒等網路安全威脅也日益凸顯,有組織、有目的的網路攻擊形勢愈加嚴重。

如以下圖片所示,惡意程式捕獲、計算機惡意程式使用者感染、安全漏洞、DDoS 攻擊等威脅不容小覷,為網路安全防護工作帶來更多挑戰。

(惡意程式捕獲情況,來源:國家網際網路應急中心)


(計算機惡意程式使用者感染情況,來源:國家網際網路應急中心)


(安全漏洞情況,來源:國家網際網路應急中心)

圖片
(DDoS 攻擊情況,來源:中國網際網路絡資訊中心)

因為攻擊成本低、效果明顯,DDoS 攻擊是目前網際網路使用者面臨的較常見、影響較嚴重的網路安全威脅之一。

為降低 DDoS 攻擊對我國基礎網路和基礎設施的威脅,國家網際網路應急中心持續對境內目標遭大流量攻擊情況做監測跟蹤,針對所發現的被用於進行 DDoS 攻擊的網路資源重點開展治理。

境內目標遭大流量 DDoS 攻擊情況:
2020 年在監測發現的境內目標遭峰值流量超過 1 Gbit/s 的大流量攻擊事件中,攻擊方式為 TCP SYN Flood、UDP Flood、NTP Amplifi cation、DNS Amplifi cation、SSDP Amplification 的佔比達 91.6%;

攻擊目標主要位於浙江省、山東省、江蘇省、廣東省、北京市、上海市、福建省等 7 個地區的事件佔比達 81.8%;

12 月是全年攻擊最高峰,攻擊異常活躍。
經分析發現,攻擊時長不超過 30 分鐘的攻擊佔比達 94.4%,表明當前攻擊者傾向於綜合使用攻擊資源,利用大流量攻擊瞬時打癱攻擊目標,以對外提供更多服務並非法獲利。

被用於進行 DDoS 攻擊的網路資源活躍情況:
根據國家網際網路應急中心的《我國 DDoS 攻擊資源季度分析報告》,與 2019 年相比,境內各類被用於進行 DDoS 攻擊的網路資源(簡稱“攻擊資源”)數量持續減少,境內活躍控制端數量同比減少 47.6%,受控端數量同比減少 39.9%,活躍反射伺服器同比減少 20.4%,跨域偽造路由器同比減少 59.1%;

與此同時,境外各類攻擊資源數量不斷增加,境外活躍控制端數量同比增加 27.6%,受控端數量同比增加 37.0%,活躍反射伺服器同比增加 0.3%,攻擊資源向境外遷移趨勢明顯。


我們如何應對

安全技術架構

按照雲端計算安全架構核心實施過程:入口防護、流量審計、堡壘約束,部署從雲網路層、虛擬機器層、應用層直至資料層的全面安全防護方案。

(全面安全防護架構)

技術棧解析

HTTPS,TLS/SSL

服務連線均採用 HTTPS 安全加密。HTTPS 在 HTTP 下加入 TLS/SSL 層對傳輸的資料進行加密,保證會話過程中的安全性。

使用 TCP 埠預設為 443

(HTTPS 安全加密)

TLS: (Transport Layer Security,傳輸層安全協議),用於兩個應用程式之間提供保密性和資料完整性。

SSL: (Secure Socket Layer,安全套接字層),位於可靠的面向連線的網路層協議和應用層協議之間的一種協議層。SSL 通過互相認證、使用數字簽名確保完整性、使用加密確保私密性,以實現客戶端和伺服器之間的安全通訊。

SSL 協議既用到了對稱加密也用到了非對稱加密(公鑰加密),在建立傳輸鏈路時,SSL 首先對對稱加密的金鑰使用公鑰進行非對稱加密,鏈路建立好之後,SSL 對傳輸內容使用對稱加密。

說到這裡,我們就不得不說說對稱加密、非對稱加密、證書機構(CA)、證書、數字簽名、私鑰、公鑰。

對稱加密

指雙方持有相同的金鑰進行通訊,加密速度快,但存在金鑰傳輸的安全問題。常見的對稱加密演算法有 DES、3DES、AES 等。

非對稱加密

又稱為公開金鑰加密,由公鑰(public key)和私鑰(private key)組成。

公鑰(public key)是對外開放的,私鑰(private key)是自己擁有的。

公鑰(public key)加密的資料,只能用私鑰(private key)解密。

私鑰(private key)加密的資料,只能用公鑰(public key)解密。

非對稱加密為了解決對稱加密中的安全問題而誕生,但加密速度相比對稱加密較慢。

資訊保安問題

在資訊保安性問題中,我們常常要做到三點才能保證資訊的安全:保密性、完整性、身份識別。

資訊的保密性(加密演算法)

通用的方法是使用非對稱加密+對稱加密來完成資訊的保密性。

客戶端使用公鑰對對稱加密的金鑰進行加密,然後傳遞給服務端,服務端使用私鑰進行解密確認金鑰,開始傳輸資料。

(非對稱加密+對稱加密確保資訊保密性)

資訊的完整性(數字簽名)

資訊在傳輸過程中,很有可能被第三方劫持篡改,所以我們需要保證資訊的完整性,通用方法是使用雜湊演算法如 SHA1、MD5。

將傳輸內容 Hash 一次獲得 Hash 值,即摘要。

客戶端使用服務端的公鑰對摘要和資訊內容進行加密,傳輸給服務端;服務端使用私鑰進行解密獲得原始內容和摘要值;服務端使用相同的 Hash 演算法對原始內容進行 Hash,然後與摘要值比對。如果一致,說明資訊是完整的。

(資訊完整性演算法流程)

身份識別(數字證書)

傳輸資訊我們通常需要驗證資訊傳送方的身份,轉化一下思路即可完成。傳送端使用私鑰加密自己的內容然後傳送給接收端,接收端只要用傳送端的公鑰解密,自然就驗證了傳送端的身份。

(身份識別流程)

數字證書

想象一下,如果一開始服務端傳送公鑰到客戶端時,被第三方劫持,然後第三方自己偽造一對金鑰,將公鑰傳送給客戶端。

這樣,當伺服器傳送資料給客戶端時,中間人用一開始劫持的公鑰解密資訊後,使用自己的私鑰將資料加密傳送給客戶端,而客戶端收到後使用公鑰解密。整個過程中間人是透明的,但資訊洩露卻不得而知。

(公鑰被篡改可能導致資訊洩露)

為了防止這種情況,數字證書就出現了,原理就是基於上面所說的私鑰加密資料,公鑰解密來驗證其身份。

數字證書由權威的 CA(Certificate Authority)機構給服務端進行頒發,CA 機構通過服務端提供的相關資訊生成證書,證書內容包含了持有人的相關資訊,伺服器的公鑰,簽署者簽名資訊(數字簽名)等,最重要的是公鑰在數字證書中

數字證書如何保證公鑰來自請求的伺服器呢?
數字證書上有持有人的相關資訊,通過這點可以確定其不是一箇中間人。但是,證書也可以偽造,如何保證證書為真呢?

一個證書中含有三個部分:證書內容、雜湊演算法、加密密文,證書內容會被雜湊演算法 Hash 計算出 Hash 值,然後使用 CA 機構提供的私鑰進行 RSA 加密。

(數字證書如何保真)

當客戶端發起請求時,伺服器將該數字證書傳送給客戶端,客戶端通過 CA 機構提供的公鑰對加密密文進行解密獲得雜湊值(數字簽名),同時將證書內容使用相同的雜湊演算法進行 Hash 得到另一個雜湊值,比對兩個雜湊值,如果兩者相等則說明證書沒問題。

(身份驗證流程)

一些常見的證書檔案型別如下:

X.509#DER 二進位制格式證書,常用字尾.cer/.crt
X.509#PEM 文字格式證書,常用字尾.pem
有的證書內容是隻包含公鑰(伺服器的公鑰),如.cer/.crt/.pem
有的證書既包含公鑰又包含私鑰(伺服器的私鑰),如.pfx、.p12

HTTPS 單向認證

HTTPS 在建立 Socket 連線之前,需要進行握手,具體過程如下:

(單向認證)

①客戶端向服務端傳送 SSL 協議版本號、加密演算法種類、隨機數等資訊。
②服務端給客戶端返回 SSL 協議版本號、加密演算法種類、隨機數等資訊,同時也返回伺服器端的證書,即公鑰證書。
③客戶端使用服務端返回的資訊驗證伺服器的合法性,包括:

• 證書是否過期;
• 發行伺服器證書的 CA 是否可靠(通過查詢瀏覽器或本機內的 CA 證書獲知);
• 返回的公鑰是否能正確解開返回證書中的數字簽名(通過使用本機或瀏覽器內建的 CA 公鑰進行解密);
• 伺服器證書上的域名是否和伺服器的實際域名相匹配;
• 驗證通過後繼續進行通訊,否則終止通訊。

④客戶端向服務端傳送自己所能支援的對稱加密方案,供伺服器端進行選擇。
⑤伺服器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
⑥伺服器將選擇好的加密方案通過明文方式返回給客戶端。
⑦客戶端接收到服務端返回的加密方式後,使用該加密方式生成產生隨機碼,用作通訊過程中對稱加密的金鑰,使用服務端返回的公鑰進行加密,將加密後的隨機碼傳送至伺服器。
⑧伺服器收到客戶端返回的加密資訊後,使用自己的私鑰進行解密,獲取對稱加密金鑰。
⑨在接下來的會話中,伺服器和客戶端將會使用該密碼進行對稱加密,保證通訊過程中資訊的安全。

HTTPS 雙向認證

雙向認證和單向認證類似,但額外增加了服務端對客戶端的認證。

(雙向認證)

①客戶端向服務端傳送 SSL 協議版本號、加密演算法種類、隨機數等資訊。
②服務端給客戶端返回 SSL 協議版本號、加密演算法種類、隨機數等資訊,同時也返回伺服器端的證書,即公鑰證書。
③客戶端使用服務端返回的資訊驗證伺服器的合法性,包括:

• 證書是否過期;
• 發行伺服器證書的 CA 是否可靠(通過查詢瀏覽器或本機內的 CA 證書獲知);
• 返回的公鑰是否能正確解開返回證書中的數字簽名(通過使用本機或瀏覽器內建的CA公鑰進行解密);
• 伺服器證書上的域名是否和伺服器的實際域名相匹配;
• 驗證通過後繼續進行通訊,否則終止通訊;

④服務端要求客戶端傳送客戶端的證書即客戶端證書公鑰,客戶端會將自己的證書傳送至服務端。
⑤驗證客戶端的證書,通過驗證後,會獲得客戶端的公鑰。
⑥客戶端向服務端傳送自己所能支援的對稱加密方案,供伺服器端進行選擇。
⑦伺服器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
⑧將加密方案通過使用之前獲取到的公鑰進行加密,返回給客戶端。
⑨客戶端收到服務端返回的加密方案密文後,使用自己的私鑰進行解密,獲取具體加密方式,而後,產生該加密方式的隨機碼,用作加密過程中的金鑰,使用之前從服務端證書中獲取到的公鑰進行加密後,傳送給服務端。
⑩服務端收到客戶端傳送的訊息後,使用自己的私鑰進行解密,獲取對稱加密的金鑰,在接下來的會話中,伺服器和客戶端將會使用該密碼進行對稱加密,保證通訊過程中資訊的安全。


至此,本文分享了目前我們面對的主要網路安全問題,及在此情況下的安全技術架構和相關技術棧解析。下週,我們將分享應對之策的核心——落地實踐方案和防護策略,敬請期待。

相關文章