IP 欺騙
IP 是什么?
在網絡中,所有的設備都會分配一個地址。這個地址就仿佛小藍的家地址「多少號多少室」,這個號就是分配給整個子網的,「室」對應的號碼即分配給子網中計算機的,這就是網絡中的地址。「號」對應的號碼為網絡號,「室」對應的號碼為主機號,這個地址的整體就是?IP 地址。
通過 IP 地址我們能知道什么?
通過 IP 地址,我們就可以知道判斷訪問對象服務器的位置,從而將消息發送到服務器。一般發送者發出的消息首先經過子網的集線器,轉發到最近的路由器,然后根據路由位置訪問下一個路由器的位置,直到終點
IP 頭部格式?:
IP 欺騙技術是什么?
騙唄,拐騙,誘騙!
IP 欺騙技術就是偽造某臺主機的 IP 地址的技術。通過 IP 地址的偽裝使得某臺主機能夠偽裝另外的一臺主機,而這臺主機往往具有某種特權或者被另外的主機所信任。
假設現在有一個合法用戶?(1.1.1.1)?已經同服務器建立正常的連接,攻擊者構造攻擊的 TCP 數據,偽裝自己的 IP 為?1.1.1.1,并向服務器發送一個帶有 RST 位的 TCP 數據段。服務器接收到這樣的數據后,認為從?1.1.1.1?發送的連接有錯誤,就會清空緩沖區中建立好的連接。
這時,如果合法用戶?1.1.1.1?再發送合法數據,服務器就已經沒有這樣的連接了,該用戶就必須從新開始建立連接。攻擊時,偽造大量的 IP 地址,向目標發送 RST 數據,使服務器不對合法用戶服務。雖然 IP 地址欺騙攻擊有著相當難度,但我們應該清醒地意識到,這種攻擊非常廣泛,入侵往往從這種攻擊開始。
如何緩解 IP 欺騙?
雖然無法預防 IP 欺騙,但可以采取措施來阻止偽造數據包滲透網絡。入口過濾?是防范欺騙的一種極為常見的防御措施,如 BCP38(通用最佳實踐文檔)所示。入口過濾是一種數據包過濾形式,通常在網絡邊緣設備上實施,用于檢查傳入的 IP 數據包并確定其源標頭。如果這些數據包的源標頭與其來源不匹配或者看上去很可疑,則拒絕這些數據包。一些網絡還實施出口過濾,檢查退出網絡的 IP 數據包,確保這些數據包具有合法源標頭,以防止網絡內部用戶使用 IP 欺騙技術發起出站惡意攻擊。
SYN Flood(洪水)
SYN Flood 是什么?
SYN Flood 是互聯網上最原始、最經典的 DDoS(Distributed Denial of Service,分布式拒絕服務)攻擊之一,旨在耗盡可用服務器資源,致使服務器無法傳輸合法流量
SYN Flood 利用了 TCP 協議的三次握手機制,攻擊者通常利用工具或者控制僵尸主機向服務器發送海量的變源 IP 地址或變源端口的 TCP SYN 報文,服務器響應了這些報文后就會生成大量的半連接,當系統資源被耗盡后,服務器將無法提供正常的服務。 增加服務器性能,提供更多的連接能力對于 SYN Flood 的海量報文來說杯水車薪,防御 SYN Flood 的關鍵在于判斷哪些連接請求來自于真實源,屏蔽非真實源的請求以保障正常的業務請求能得到服務。
TCP SYN Flood 攻擊原理是什么?
TCP SYN Flood?攻擊利用的是?TCP?的三次握手(SYN -> SYN/ACK -> ACK),假設連接發起方是 A,連接接受方是 B,即 B 在某個端口(Port)上監聽 A 發出的連接請求,過程如下圖所示,左邊是 A,右邊是 B。
A 首先發送?SYN(Synchronization)消息給 B,要求 B 做好接收數據的準備;B 收到后反饋?SYN-ACK(Synchronization-Acknowledgement) 消息給 A,這個消息的目的有兩個:
- 向 A 確認已做好接收數據的準備,
- 同時要求 A 也做好接收數據的準備,此時 B 已向 A 確認好接收狀態,并等待 A 的確認,連接處于半開狀態(Half-Open),顧名思義只開了一半;A 收到后再次發送?ACK?(Acknowledgement) 消息給 B,向 B 確認也做好了接收數據的準備,至此三次握手完成,「連接」就建立了,
大家注意到沒有,最關鍵的一點在于雙方是否都按對方的要求進入了可以接收消息的狀態。而這個狀態的確認主要是雙方將要使用的消息序號(SequenceNum),TCP 為保證消息按發送順序抵達接收方的上層應用,需要用消息序號來標記消息的發送先后順序的。
TCP是「雙工」(Duplex)連接,同時支持雙向通信,也就是雙方同時可向對方發送消息,其中?SYN?和?SYN-ACK?消息開啟了 A→B 的單向通信通道(B 獲知了 A 的消息序號);SYN-ACK?和?ACK?消息開啟了 B→A 單向通信通道(A 獲知了 B 的消息序號)。
上面討論的是雙方在誠實守信,正常情況下的通信。
但實際情況是,網絡可能不穩定會丟包,使握手消息不能抵達對方,也可能是對方故意不按規矩來,故意延遲或不發送握手確認消息。
假設 B 通過某?TCP?端口提供服務,B 在收到 A 的?SYN?消息時,積極的反饋了?SYN-ACK?消息,使連接進入半開狀態,因為 B 不確定自己發給 A 的?SYN-ACK?消息或 A 反饋的 ACK 消息是否會丟在半路,所以會給每個待完成的半開連接都設一個Timer,如果超過時間還沒有收到 A 的?ACK?消息,則重新發送一次?SYN-ACK?消息給 A,直到重試超過一定次數時才會放棄。
B 為幫助 A 能順利連接,需要分配內核資源維護半開連接,那么當 B 面臨海量的連接 A 時,如上圖所示,SYN Flood?攻擊就形成了。攻擊方 A 可以控制肉雞向 B 發送大量 SYN 消息但不響應 ACK 消息,或者干脆偽造 SYN 消息中的?Source IP,使 B 反饋的?SYN-ACK?消息石沉大海,導致 B 被大量注定不能完成的半開連接占據,直到資源耗盡,停止響應正常的連接請求。
SYN Flood 的常見形式有哪些?
惡意用戶可通過三種不同方式發起 SYN Flood 攻擊:
- 直接攻擊:?不偽造 IP 地址的 SYN 洪水攻擊稱為直接攻擊。在此類攻擊中,攻擊者完全不屏蔽其 IP 地址。由于攻擊者使用具有真實 IP 地址的單一源設備發起攻擊,因此很容易發現并清理攻擊者。為使目標機器呈現半開狀態,黑客將阻止個人機器對服務器的 SYN-ACK 數據包做出響應。為此,通常采用以下兩種方式實現:部署防火墻規則,阻止除 SYN 數據包以外的各類傳出數據包;或者,對傳入的所有 SYN-ACK 數據包進行過濾,防止其到達惡意用戶機器。實際上,這種方法很少使用(即便使用過也不多見),因為此類攻擊相當容易緩解 – 只需阻止每個惡意系統的 IP 地址。哪怕攻擊者使用僵尸網絡(如?Mirai 僵尸網絡),通常也不會刻意屏蔽受感染設備的 IP。
- 欺騙攻擊:?惡意用戶還可以偽造其發送的各個 SYN 數據包的 IP 地址,以便阻止緩解措施并加大身份暴露難度。雖然數據包可能經過偽裝,但還是可以通過這些數據包追根溯源。此類檢測工作很難開展,但并非不可實現;特別是,如果 Internet 服務提供商 (ISP) 愿意提供幫助,則更容易實現。
- 分布式攻擊(DDoS):?如果使用僵尸網絡發起攻擊,則追溯攻擊源頭的可能性很低。隨著混淆級別的攀升,攻擊者可能還會命令每臺分布式設備偽造其發送數據包的 IP 地址。哪怕攻擊者使用僵尸網絡(如 Mirai 僵尸網絡),通常也不會刻意屏蔽受感染設備的 IP。
如何緩解 SYN Flood?
擴展積壓工作隊列
目標設備安裝的每個操作系統都允許具有一定數量的半開連接。若要響應大量 SYN 數據包,一種方法是增加操作系統允許的最大半開連接數目。為成功擴展最大積壓工作,系統必須額外預留內存資源以處理各類新請求。如果系統沒有足夠的內存,無法應對增加的積壓工作隊列規模,將對系統性能產生負面影響,但仍然好過拒絕服務。
回收最先創建的 TCP 半開連接
另一種緩解策略是在填充積壓工作后覆蓋最先創建的半開連接。這項策略要求完全建立合法連接的時間低于惡意 SYN 數據包填充積壓工作的時間。當攻擊量增加或積壓工作規模小于實際需求時,這項特定的防御措施將不奏效。
SYN Cookie
此策略要求服務器創建 Cookie。為避免在填充積壓工作時斷開連接,服務器使用 SYN-ACK 數據包響應每一項連接請求,而后從積壓工作中刪除 SYN 請求,同時從內存中刪除請求,保證端口保持打開狀態并做好重新建立連接的準備。如果連接是合法請求并且已將最后一個 ACK 數據包從客戶端機器發回服務器,服務器將重建(存在一些限制)SYN 積壓工作隊列條目。雖然這項緩解措施勢必會丟失一些 TCP 連接信息,但好過因此導致對合法用戶發起拒絕服務攻擊。
UDP Flood(洪水)
UDP Flood 是什么?
UDP Flood?也是一種拒絕服務攻擊,將大量的用戶數據報協議(UDP)數據包發送到目標服務器,目的是壓倒該設備的處理和響應能力。防火墻保護目標服務器也可能因?UDP?泛濫而耗盡,從而導致對合法流量的拒絕服務。
UDP Flood 攻擊原理是什么?
UDP Flood?主要通過利用服務器響應發送到其中一個端口的?UDP?數據包所采取的步驟。在正常情況下,當服務器在特定端口接收到?UDP?數據包時,會經過兩個步驟:
- 服務器首先檢查是否正在運行正在偵聽指定端口的請求的程序。
- 如果沒有程序在該端口接收數據包,則服務器使用?ICMP(ping)數據包進行響應,以通知發送方目的地不可達。
舉個例子。假設今天要聯系酒店的小藍,酒店客服接到電話后先查看房間的列表來確保小藍在客房內,隨后轉接給小藍。
首先,接待員接收到呼叫者要求連接到特定房間的電話。接待員然后需要查看所有房間的清單,以確保客人在房間中可用,并愿意接聽電話。碰巧的是,此時如果突然間所有的電話線同時亮起來,那么他們就會很快就變得不堪重負了。
當服務器接收到每個新的?UDP?數據包時,它將通過步驟來處理請求,并利用該過程中的服務器資源。發送?UDP?報文時,每個報文將包含源設備的?IP?地址。在這種類型的?DDoS?攻擊期間,攻擊者通常不會使用自己的真實?IP?地址,而是會欺騙?UDP?數據包的源?IP?地址,從而阻止攻擊者的真實位置被暴露并潛在地飽和來自目標的響應數據包服務器。
由于目標服務器利用資源檢查并響應每個接收到的?UDP?數據包的結果,當接收到大量?UDP?數據包時,目標的資源可能會迅速耗盡,導致對正常流量的拒絕服務。
如何緩解 UDP Flooding?
大多數操作系統部分限制了?ICMP?報文的響應速率,以中斷需要 ICMP 響應的?DDoS?攻擊。這種緩解的一個缺點是在攻擊過程中,合法的數據包也可能被過濾。如果?UDP Flood?的容量足夠高以使目標服務器的防火墻的狀態表飽和,則在服務器級別發生的任何緩解都將不足以應對目標設備上游的瓶頸。
HTTP Flood(洪水)
HTTP Flood 是什么?
HTTP Flood 是一種大規模的 DDoS(Distributed Denial of Service,分布式拒絕服務)攻擊,旨在利用 HTTP 請求使目標服務器不堪重負。目標因請求而達到飽和,且無法響應正常流量后,將出現拒絕服務,拒絕來自實際用戶的其他請求。
HTTP Flood 的攻擊原理是什么?
HTTP 洪水攻擊是“第 7 層”DDoS 攻擊的一種。第 7 層是 OSI 模型的應用程序層,指的是 HTTP 等互聯網協議。HTTP 是基于瀏覽器的互聯網請求的基礎,通常用于加載網頁或通過互聯網發送表單內容。緩解應用程序層攻擊特別復雜,因為惡意流量和正常流量很難區分。
為了獲得最大效率,惡意行為者通常會利用或創建僵尸網絡,以最大程度地擴大攻擊的影響。通過利用感染了惡意軟件的多臺設備,攻擊者可以發起大量攻擊流量來進行攻擊。
HTTP 洪水攻擊有兩種:
- HTTP GET 攻擊:在這種攻擊形式下,多臺計算機或其他設備相互協調,向目標服務器發送對圖像、文件或其他資產的多個請求。當目標被傳入的請求和響應所淹沒時,來自正常流量源的其他請求將被拒絕服務。
- HTTP POST 攻擊:一般而言,在網站上提交表單時,服務器必須處理傳入的請求并將數據推送到持久層(通常是數據庫)。與發送 POST 請求所需的處理能力和帶寬相比,處理表單數據和運行必要數據庫命令的過程相對密集。這種攻擊利用相對資源消耗的差異,直接向目標服務器發送許多 POST 請求,直到目標服務器的容量飽和并拒絕服務為止。
如何防護 HTTP Flood?
如前所述,緩解第 7 層攻擊非常復雜,而且通常要從多方面進行。一種方法是對發出請求的設備實施質詢,以測試它是否是機器人,這與在線創建帳戶時常用的 CAPTCHA 測試非常相似。通過提出 JavaScript 計算挑戰之類的要求,可以緩解許多攻擊。
其他阻止 HTTP 洪水攻擊的途徑包括使用 Web 應用程序防火墻 (WAF)、管理 IP 信譽數據庫以跟蹤和有選擇地阻止惡意流量,以及由工程師進行動態分析。Cloudflare 具有超過 2000 萬個互聯網設備的規模優勢,能夠分析來自各種來源的流量并通過快速更新的 WAF 規則和其他防護策略來緩解潛在的攻擊,從而消除應用程序層 DDoS 流量。
DNS Flood(洪水)
DNS Flood 是什么?
域名系統(DNS)服務器是互聯網的“電話簿“;互聯網設備通過這些服務器來查找特定 Web 服務器以便訪問互聯網內容。DNS Flood 攻擊是一種分布式拒絕服務(DDoS)攻擊,攻擊者用大量流量淹沒某個域的 DNS 服務器,以嘗試中斷該域的 DNS 解析。如果用戶無法找到電話簿,就無法查找到用于調用特定資源的地址。通過中斷 DNS 解析,DNS Flood 攻擊將破壞網站、API 或 Web 應用程序響應合法流量的能力。很難將 DNS Flood 攻擊與正常的大流量區分開來,因為這些大規模流量往往來自多個唯一地址,查詢該域的真實記錄,模仿合法流量。
DNS Flood 的攻擊原理是什么?
域名系統的功能是將易于記憶的名稱(例如 example.com)轉換成難以記住的網站服務器地址(例如 192.168.0.1),因此成功攻擊 DNS 基礎設施將導致大多數人無法使用互聯網。DNS Flood 攻擊是一種相對較新的基于 DNS 的攻擊,這種攻擊是在高帶寬物聯網(IoT)僵尸網絡(如?Mirai)興起后激增的。DNS Flood 攻擊使用 IP 攝像頭、DVR 盒和其他 IoT 設備的高帶寬連接直接淹沒主要提供商的 DNS 服務器。來自 IoT 設備的大量請求淹沒 DNS 提供商的服務,阻止合法用戶訪問提供商的 DNS 服務器。
DNS Flood 攻擊不同于?DNS 放大攻擊。與 DNS Flood 攻擊不同,DNS 放大攻擊反射并放大不安全 DNS 服務器的流量,以便隱藏攻擊的源頭并提高攻擊的有效性。DNS 放大攻擊使用連接帶寬較小的設備向不安全的 DNS 服務器發送無數請求。這些設備對非常大的 DNS 記錄發出小型請求,但在發出請求時,攻擊者偽造返回地址為目標受害者。這種放大效果讓攻擊者能借助有限的攻擊資源來破壞較大的目標。
如何防護 DNS Flood?
DNS Flood 對傳統上基于放大的攻擊方法做出了改變。借助輕易獲得的高帶寬僵尸網絡,攻擊者現能針對大型組織發動攻擊。除非被破壞的 IoT 設備得以更新或替換,否則抵御這些攻擊的唯一方法是使用一個超大型、高度分布式的 DNS 系統,以便實時監測、吸收和阻止攻擊流量。
TCP 重置攻擊
在?TCP?重置攻擊中,攻擊者通過向通信的一方或雙方發送偽造的消息,告訴它們立即斷開連接,從而使通信雙方連接中斷。正常情況下,如果客戶端收發現到達的報文段對于相關連接而言是不正確的,TCP?就會發送一個重置報文段,從而導致?TCP?連接的快速拆卸。
TCP?重置攻擊利用這一機制,通過向通信方發送偽造的重置報文段,欺騙通信雙方提前關閉 TCP 連接。如果偽造的重置報文段完全逼真,接收者就會認為它有效,并關閉?TCP?連接,防止連接被用來進一步交換信息。服務端可以創建一個新的?TCP?連接來恢復通信,但仍然可能會被攻擊者重置連接。萬幸的是,攻擊者需要一定的時間來組裝和發送偽造的報文,所以一般情況下這種攻擊只對長連接有殺傷力,對于短連接而言,你還沒攻擊呢,人家已經完成了信息交換。
從某種意義上來說,偽造?TCP?報文段是很容易的,因為?TCP/IP?都沒有任何內置的方法來驗證服務端的身份。有些特殊的 IP 擴展協議(例如?IPSec
)確實可以驗證身份,但并沒有被廣泛使用。客戶端只能接收報文段,并在可能的情況下使用更高級別的協議(如?TLS
)來驗證服務端的身份。但這個方法對?TCP?重置包并不適用,因為?TCP?重置包是?TCP?協議本身的一部分,無法使用更高級別的協議進行驗證。
模擬攻擊
以下實驗是在?
OSX
?系統中完成的,其他系統請自行測試。
現在來總結一下偽造一個?TCP?重置報文要做哪些事情:
- 嗅探通信雙方的交換信息。
- 截獲一個?
ACK
?標志位置位 1 的報文段,并讀取其?ACK
?號。 - 偽造一個 TCP 重置報文段(
RST
?標志位置為 1),其序列號等于上面截獲的報文的?ACK
?號。這只是理想情況下的方案,假設信息交換的速度不是很快。大多數情況下為了增加成功率,可以連續發送序列號不同的重置報文。 - 將偽造的重置報文發送給通信的一方或雙方,時其中斷連接。
為了實驗簡單,我們可以使用本地計算機通過?localhost
?與自己通信,然后對自己進行 TCP 重置攻擊。需要以下幾個步驟:
- 在兩個終端之間建立一個 TCP 連接。
- 編寫一個能嗅探通信雙方數據的攻擊程序。
- 修改攻擊程序,偽造并發送重置報文。
下面正式開始實驗。
建立 TCP 連接
可以使用 netcat 工具來建立 TCP 連接,這個工具很多操作系統都預裝了。打開第一個終端窗口,運行以下命令:
nc -nvl 8000
這個命令會啟動一個 TCP 服務,監聽端口為?8000
。接著再打開第二個終端窗口,運行以下命令:
nc 127.0.0.1 8000
該命令會嘗試與上面的服務建立連接,在其中一個窗口輸入一些字符,就會通過 TCP 連接發送給另一個窗口并打印出來。
嗅探流量
編寫一個攻擊程序,使用 Python 網絡庫?scapy
?來讀取兩個終端窗口之間交換的數據,并將其打印到終端上。代碼比較長,下面為一部份,完整代碼后臺回復 TCP 攻擊,代碼的核心是調用?scapy
?的嗅探方法:
這段代碼告訴?scapy
?在?lo0
?網絡接口上嗅探數據包,并記錄所有 TCP 連接的詳細信息。
- iface?: 告訴 scapy 在?
lo0
(localhost)網絡接口上進行監聽。 - lfilter?: 這是個過濾器,告訴 scapy 忽略所有不屬于指定的 TCP 連接(通信雙方皆為?
localhost
,且端口號為?8000
)的數據包。 - prn?: scapy 通過這個函數來操作所有符合?
lfilter
?規則的數據包。上面的例子只是將數據包打印到終端,下文將會修改函數來偽造重置報文。 - count?: scapy 函數返回之前需要嗅探的數據包數量。
發送偽造的重置報文
下面開始修改程序,發送偽造的 TCP 重置報文來進行 TCP 重置攻擊。根據上面的解讀,只需要修改 prn 函數就行了,讓其檢查數據包,提取必要參數,并利用這些參數來偽造 TCP 重置報文并發送。
例如,假設該程序截獲了一個從(src_ip
,?src_port
)發往 (dst_ip
,?dst_port
)的報文段,該報文段的 ACK 標志位已置為 1,ACK 號為?100,000
。攻擊程序接下來要做的是:
- 由于偽造的數據包是對截獲的數據包的響應,所以偽造數據包的源?
IP/Port
?應該是截獲數據包的目的?IP/Port
,反之亦然。 - 將偽造數據包的?
RST
?標志位置為 1,以表示這是一個重置報文。 - 將偽造數據包的序列號設置為截獲數據包的 ACK 號,因為這是發送方期望收到的下一個序列號。
- 調用?
scapy
?的?send
?方法,將偽造的數據包發送給截獲數據包的發送方。
對于我的程序而言,只需將這一行取消注釋,并注釋這一行的上面一行,就可以全面攻擊了。按照步驟 1 的方法設置 TCP 連接,打開第三個窗口運行攻擊程序,然后在 TCP 連接的其中一個終端輸入一些字符串,你會發現 TCP 連接被中斷了!
進一步實驗
- 可以繼續使用攻擊程序進行實驗,將偽造數據包的序列號加減 1 看看會發生什么,是不是確實需要和截獲數據包的?
ACK
?號完全相同。 - 打開?
Wireshark
,監聽 lo0 網絡接口,并使用過濾器?ip.src == 127.0.0.1 && ip.dst == 127.0.0.1 && tcp.port == 8000
?來過濾無關數據。你可以看到 TCP 連接的所有細節。 - 在連接上更快速地發送數據流,使攻擊更難執行。
中間人攻擊
豬八戒要向小藍表白,于是寫了一封信給小藍,結果第三者小黑攔截到了這封信,把這封信進行了篡改,于是乎在他們之間進行搞破壞行動。這個馬文才就是中間人,實施的就是中間人攻擊。好我們繼續聊聊什么是中間人攻擊。
什么是中間人?
攻擊中間人攻擊英文名叫 Man-in-the-MiddleAttack,簡稱「MITM 攻擊」。指攻擊者與通訊的兩端分別創建獨立的聯系,并交換其所收到的數據,使通訊的兩端認為他們正在通過一個私密的連接與對方 直接對話,但事實上整個會話都被攻擊者完全控制。我們畫一張圖:
從這張圖可以看到,中間人其實就是攻擊者。通過這種原理,有很多實現的用途,比如說,你在手機上瀏覽不健康網站的時候,手機就會提示你,此網站可能含有病毒,是否繼續訪問還是做其他的操作等等。
中間人攻擊的原理是什么?
舉個例子,我和公司簽了一個一份勞動合同,一人一份合同。不曉得哪個可能改了合同內容,不知道真假了,怎么搞?只好找專業的機構來鑒定,自然就要花錢。
在安全領域有句話:我們沒有辦法杜絕網絡犯罪,只好想辦法提高網絡犯罪的成本。既然沒法杜絕這種情況,那我們就想辦法提高作案的成本,今天我們就簡單了解下基本的網絡安全知識,也是面試中的高頻面試題了。
為了避免雙方說活不算數的情況,雙方引入第三家機構,將合同原文給可信任的第三方機構,只要這個機構不監守自盜,合同就相對安全。
如果第三方機構內部不嚴格或容易出現紕漏?
雖然我們將合同原文給第三方機構了,為了防止內部人員的更改,需要采取什么措施呢
一種可行的辦法是引入?摘要算法?。即合同和摘要一起,為了簡單的理解摘要。大家可以想象這個摘要為一個函數,這個函數對原文進行了加密,會產生一個唯一的散列值,一旦原文發生一點點變化,那么這個散列值將會變化。
有哪些常用的摘要算法呢?
目前比較常用的加密算法有消息摘要算法和安全散列算法(SHA)。MD5?是將任意長度的文章轉化為一個 128 位的散列值,可是在 2004 年,MD5?被證實了容易發生碰撞,即兩篇原文產生相同的摘要。這樣的話相當于直接給黑客一個后門,輕松偽造摘要。
所以在大部分的情況下都會選擇?SHA 算法?。
出現內鬼了怎么辦?
看似很安全的場面了,理論上來說杜絕了篡改合同的做法。主要某個員工同時具有修改合同和摘要的權利,那搞事兒就是時間的問題了,畢竟沒哪個系統可以完全的杜絕員工接觸敏感信息,除非敏感信息都不存在。所以能不能考慮將合同和摘要分開存儲呢
那如何確保員工不會修改合同呢?
這確實蠻難的,不過辦法總比困難多。我們將合同放在雙方手中,摘要放在第三方機構,篡改難度進一步加大
那么員工萬一和某個用戶串通好了呢?
看來放在第三方的機構還是不好使,同樣存在不小風險。所以還需要尋找新的方案,這就出現了?數字簽名和證書。
數字證書和簽名有什么用?
同樣的,舉個例子。Sum 和 Mike 兩個人簽合同。Sum 首先用?SHA?算法計算合同的摘要,然后用自己私鑰將摘要加密,得到數字簽名。Sum 將合同原文、簽名,以及公鑰三者都交給 Mike
如果 Sum 想要證明合同是 Mike 的,那么就要使用 Mike 的公鑰,將這個簽名解密得到摘要 x,然后 Mike 計算原文的 sha 摘要 Y,隨后對比 x 和 y,如果兩者相等,就認為數據沒有被篡改
在這樣的過程中,Mike 是不能更改 Sum 的合同,因為要修改合同不僅僅要修改原文還要修改摘要,修改摘要需要提供 Mike 的私鑰,私鑰即 Sum 獨有的密碼,公鑰即 Sum 公布給他人使用的密碼
總之,公鑰加密的數據只能私鑰可以解密。私鑰加密的數據只有公鑰可以解密,這就是?非對稱加密?。
隱私保護?不是嚇唬大家,信息是透明的兄 die,不過盡量去維護個人的隱私吧,今天學習對稱加密和非對稱加密。
大家先讀讀這個字"鑰",是讀"yao",我以前也是,其實讀"yue"
什么是對稱加密?
對稱加密,顧名思義,加密方與解密方使用同一鑰匙(秘鑰)。具體一些就是,發送方通過使用相應的加密算法和秘鑰,對將要發送的信息進行加密;對于接收方而言,使用解密算法和相同的秘鑰解鎖信息,從而有能力閱讀信息。
常見的對稱加密算法有哪些?
DES
DES 使用的密鑰表面上是 64 位的,然而只有其中的 56 位被實際用于算法,其余 8 位可以被用于奇偶校驗,并在算法中被丟棄。因此,DES?的有效密鑰長度為 56 位,通常稱?DES?的密鑰長度為 56 位。假設秘鑰為 56 位,采用暴力破 Jie 的方式,其秘鑰個數為 2 的 56 次方,那么每納秒執行一次解密所需要的時間差不多 1 年的樣子。當然,沒人這么干。DES?現在已經不是一種安全的加密方法,主要因為它使用的 56 位密鑰過短。
IDEA
國際數據加密算法(International Data Encryption Algorithm)。秘鑰長度 128 位,優點沒有專利的限制。
AES
當 DES 被破解以后,沒過多久推出了?AES?算法,提供了三種長度供選擇,128 位、192 位和 256,為了保證性能不受太大的影響,選擇 128 即可。
SM1 和 SM4
之前幾種都是國外的,我們國內自行研究了國密?SM1和?SM4。其中 S 都屬于國家標準,算法公開。優點就是國家的大力支持和認可
總結:
常見的非對稱加密算法有哪些?
在對稱加密中,發送方與接收方使用相同的秘鑰。那么在非對稱加密中則是發送方與接收方使用的不同的秘鑰。其主要解決的問題是防止在秘鑰協商的過程中發生泄漏。比如在對稱加密中,小藍將需要發送的消息加密,然后告訴你密碼是 123balala,ok,對于其他人而言,很容易就能劫持到密碼是 123balala。那么在非對稱的情況下,小藍告訴所有人密碼是 123balala,對于中間人而言,拿到也沒用,因為沒有私鑰。所以,非對稱密鑰其實主要解決了密鑰分發的難題。如下圖
其實我們經常都在使用非對稱加密,比如使用多臺服務器搭建大數據平臺 hadoop,為了方便多臺機器設置免密登錄,是不是就會涉及到秘鑰分發。再比如搭建 docker 集群也會使用相關非對稱加密算法。
常見的非對稱加密算法:
-
RSA(RSA 加密算法,RSA Algorithm):優勢是性能比較快,如果想要較高的加密難度,需要很長的秘鑰。
-
ECC:基于橢圓曲線提出。是目前加密強度最高的非對稱加密算法
-
SM2:同樣基于橢圓曲線問題設計。最大優勢就是國家認可和大力支持。
總結:
常見的散列算法有哪些?
這個大家應該更加熟悉了,比如我們平常使用的 MD5 校驗,在很多時候,我并不是拿來進行加密,而是用來獲得唯一性 ID。在做系統的過程中,存儲用戶的各種密碼信息,通常都會通過散列算法,最終存儲其散列值。
MD5(不推薦)
MD5 可以用來生成一個 128 位的消息摘要,它是目前應用比較普遍的散列算法,具體的應用場景你可以自行 參閱。雖然,因為算法的缺陷,它的唯一性已經被破解了,但是大部分場景下,這并不會構成安全問題。但是,如果不是長度受限(32 個字符),我還是不推薦你繼續使用?MD5?的。
SHA
安全散列算法。SHA?分為?SHA1?和?SH2?兩個版本。該算法的思想是接收一段明文,然后以一種不可逆的方式將它轉換成一段(通常更小)密文,也可以簡單的理解為取一串輸入碼(稱為預映射或信息),并把它們轉化為長度較短、位數固定的輸出序列即散列值(也稱為信息摘要或信息認證代碼)的過程。
SM3
國密算法SM3。加密強度和 SHA-256 算法 相差不多。主要是受到了國家的支持。
總結:
大部分情況下使用對稱加密,具有比較不錯的安全性。如果需要分布式進行秘鑰分發,考慮非對稱。如果不需要可逆計算則散列算法。?因為這段時間有這方面需求,就看了一些這方面的資料,入坑信息安全,就怕以后洗發水都不用買。謝謝大家查看!
第三方機構和證書機制有什么用?
問題還有,此時如果 Sum 否認給過 Mike 的公鑰和合同,不久 gg 了
所以需要 Sum 過的話做過的事兒需要足夠的信譽,這就引入了?第三方機構和證書機制?。
證書之所以會有信用,是因為證書的簽發方擁有信用。所以如果 Sum 想讓 Mike 承認自己的公鑰,Sum 不會直接將公鑰給 Mike ,而是提供由第三方機構,含有公鑰的證書。如果 Mike 也信任這個機構,法律都認可,那 ik,信任關系成立
如上圖所示,Sum 將自己的申請提交給機構,產生證書的原文。機構用自己的私鑰簽名 Sum 的申請原文(先根據原文內容計算摘要,再用私鑰加密),得到帶有簽名信息的證書。Mike 拿到帶簽名信息的證書,通過第三方機構的公鑰進行解密,獲得 Sum 證書的摘要、證書的原文。有了 Sum 證書的摘要和原文,Mike 就可以進行驗簽。驗簽通過,Mike 就可以確認 Sum 的證書的確是第三方機構簽發的。
用上面這樣一個機制,合同的雙方都無法否認合同。這個解決方案的核心在于需要第三方信用服務機構提供信用背書。這里產生了一個最基礎的信任鏈,如果第三方機構的信任崩潰,比如被黑客攻破,那整條信任鏈條也就斷裂了
為了讓這個信任條更加穩固,就需要環環相扣,打造更長的信任鏈,避免單點信任風險
上圖中,由信譽最好的根證書機構提供根證書,然后根證書機構去簽發二級機構的證書;二級機構去簽發三級機構的證書;最后有由三級機構去簽發 Sum 證書。
如果要驗證 Sum 證書的合法性,就需要用三級機構證書中的公鑰去解密 Sum 證書的數字簽名。
如果要驗證三級機構證書的合法性,就需要用二級機構的證書去解密三級機構證書的數字簽名。
如果要驗證二級結構證書的合法性,就需要用根證書去解密。
以上,就構成了一個相對長一些的信任鏈。如果其中一方想要作弊是非常困難的,除非鏈條中的所有機構同時聯合起來,進行欺詐。
中間人攻擊如何避免?
既然知道了中間人攻擊的原理也知道了他的危險,現在我們看看如何避免。相信我們都遇到過下面這種狀況:
出現這個界面的很多情況下,都是遇到了中間人攻擊的現象,需要對安全證書進行及時地監測。而且大名鼎鼎的 github 網站,也曾遭遇過中間人攻擊:
想要避免中間人攻擊的方法目前主要有兩個:
- 客戶端不要輕易相信證書:因為這些證書極有可能是中間人。
- App 可以提前預埋證書在本地:意思是我們本地提前有一些證書,這樣其他證書就不能再起作用了。
DDOS
通過上面的描述,總之即好多種攻擊都是?DDOS?攻擊,所以簡單總結下這個攻擊相關內容。
其實,像全球互聯網各大公司,均遭受過大量的?DDoS。
2018 年,GitHub 在一瞬間遭到高達 1.35Tbps 的帶寬攻擊。這次 DDoS 攻擊幾乎可以堪稱是互聯網有史以來規模最大、威力最大的 DDoS 攻擊了。在 GitHub 遭到攻擊后,僅僅一周后,DDoS 攻擊又開始對 Google、亞馬遜甚至 Pornhub 等網站進行了 DDoS 攻擊。后續的 DDoS 攻擊帶寬最高也達到了 1Tbps。
DDoS 攻擊究竟是什么?
DDos 全名 Distributed Denial of Service,翻譯成中文就是分布式拒絕服務。指的是處于不同位置的多個攻擊者同時向一個或數個目標發動攻擊,是一種分布的、協同的大規模攻擊方式。單一的 DoS 攻擊一般是采用一對一方式的,它利用網絡協議和操作系統的一些缺陷,采用欺騙和偽裝的策略來進行網絡攻擊,使網站服務器充斥大量要求回復的信息,消耗網絡帶寬或系統資源,導致網絡或系統不勝負荷以至于癱瘓而停止提供正常的網絡服務。
舉個例子
我開了一家有五十個座位的重慶火鍋店,由于用料上等,童叟無欺。平時門庭若市,生意特別紅火,而對面二狗家的火鍋店卻無人問津。二狗為了對付我,想了一個辦法,叫了五十個人來我的火鍋店坐著卻不點菜,讓別的客人無法吃飯。
上面這個例子講的就是典型的 DDoS 攻擊,一般來說是指攻擊者利用“肉雞”對目標網站在較短的時間內發起大量請求,大規模消耗目標網站的主機資源,讓它無法正常服務。在線游戲、互聯網金融等領域是 DDoS 攻擊的高發行業。
攻擊方式很多,比如?ICMP Flood、UDP Flood、NTP Flood、SYN Flood、CC 攻擊、DNS Query Flood等等。
如何應對 DDoS 攻擊?
高防服務器
還是拿開的重慶火鍋店舉例,高防服務器就是我給重慶火鍋店增加了兩名保安,這兩名保安可以讓保護店鋪不受流氓騷擾,并且還會定期在店鋪周圍巡邏防止流氓騷擾。
高防服務器主要是指能獨立硬防御 50Gbps 以上的服務器,能夠幫助網站拒絕服務攻擊,定期掃描網絡主節點等,這東西是不錯,就是貴~
黑名單
面對火鍋店里面的流氓,我一怒之下將他們拍照入檔,并禁止他們踏入店鋪,但是有的時候遇到長得像的人也會禁止他進入店鋪。這個就是設置黑名單,此方法秉承的就是“錯殺一千,也不放一百”的原則,會封鎖正常流量,影響到正常業務。
DDoS 清洗
DDos?清洗,就是我發現客人進店幾分鐘以后,但是一直不點餐,我就把他踢出店里。
DDoS?清洗會對用戶請求數據進行實時監控,及時發現?DOS?攻擊等異常流量,在不影響正常業務開展的情況下清洗掉這些異常流量。
CDN 加速
CDN 加速,我們可以這么理解:為了減少流氓騷擾,我干脆將火鍋店開到了線上,承接外賣服務,這樣流氓找不到店在哪里,也耍不來流氓了。
在現實中,CDN 服務將網站訪問流量分配到了各個節點中,這樣一方面隱藏網站的真實 IP,另一方面即使遭遇?DDoS?攻擊,也可以將流量分散到各個節點中,防止源站崩潰。