2.1. 網(wǎng)絡(luò)基礎(chǔ)

2.1.1. 計(jì)算機(jī)通信網(wǎng)的組成

計(jì)算機(jī)網(wǎng)絡(luò)由通信子網(wǎng)和資源子網(wǎng)組成。其中通信子網(wǎng)負(fù)責(zé)數(shù)據(jù)的無差錯和有序傳遞，其處理功能包括差錯控制、流量控制、路由選擇、網(wǎng)絡(luò)互連等。

其中資源子網(wǎng)是計(jì)算機(jī)通信的本地系統(tǒng)環(huán)境，包括主機(jī)、終端和應(yīng)用程序等， 資源子網(wǎng)的主要功能是用戶資源配置、數(shù)據(jù)的處理和管理、軟件和硬件共享以及負(fù)載 均衡等。

總的來說，計(jì)算機(jī)通信網(wǎng)就是一個由通信子網(wǎng)承載的、傳輸和共享資源子網(wǎng)的各類信息的系統(tǒng)。

2.1.2. 通信協(xié)議

為了完成計(jì)算機(jī)之間有序的信息交換，提出了通信協(xié)議的概念，其定義是相互通信的雙方（或多方）對如何進(jìn)行信息交換所必須遵守的一整套規(guī)則。

協(xié)議涉及到三個要素，分別為：

• 語法：語法是用戶數(shù)據(jù)與控制信息的結(jié)構(gòu)與格式，以及數(shù)據(jù)出現(xiàn)順序的意義

• 語義：用于解釋比特流的每一部分的意義

• 時序：事件實(shí)現(xiàn)順序的詳細(xì)說明

2.1.3. OSI七層模型

2.1.3.1. 簡介

OSI（Open System Interconnection）共分為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層七層，其具體的功能如下。

2.1.3.2. 物理層

• 提供建立、維護(hù)和釋放物理鏈路所需的機(jī)械、電氣功能和規(guī)程等特性

• 通過傳輸介質(zhì)進(jìn)行數(shù)據(jù)流(比特流)的物理傳輸、故障監(jiān)測和物理層管理

• 從數(shù)據(jù)鏈路層接收幀，將比特流轉(zhuǎn)換成底層物理介質(zhì)上的信號

2.1.3.3. 數(shù)據(jù)鏈路層

• 在物理鏈路的兩端之間傳輸數(shù)據(jù)

• 在網(wǎng)絡(luò)層實(shí)體間提供數(shù)據(jù)傳輸功能和控制

• 提供數(shù)據(jù)的流量控制

• 檢測和糾正物理鏈路產(chǎn)生的差錯

• 格式化的消息稱為幀

2.1.3.4. 網(wǎng)絡(luò)層

• 負(fù)責(zé)端到端的數(shù)據(jù)的路由或交換，為透明地傳輸數(shù)據(jù)建立連接

• 尋址并解決與數(shù)據(jù)在異構(gòu)網(wǎng)絡(luò)間傳輸相關(guān)的所有問題

• 使用上面的傳輸層和下面的數(shù)據(jù)鏈路層的功能

• 格式化的消息稱為分組

2.1.3.5. 傳輸層

• 提供無差錯的數(shù)據(jù)傳輸

• 接收來自會話層的數(shù)據(jù)，如果需要，將數(shù)據(jù)分割成更小的分組，向網(wǎng)絡(luò)層傳送分組并確保分組完整和正確到達(dá)它們的目的地

• 在系統(tǒng)之間提供可靠的透明的數(shù)據(jù)傳輸,提供端到端的錯誤恢復(fù)和流量控制

2.1.3.6. 會話層

• 提供節(jié)點(diǎn)之間通信過程的協(xié)調(diào)

• 負(fù)責(zé)執(zhí)行會話規(guī)則（如：連接是否允許半雙工或全雙工通信）、同步數(shù)據(jù)流以及當(dāng)故障發(fā)生時重新建立連接

• 使用上面的表示層和下面的傳輸層的功能

2.1.3.7. 表示層

• 提供數(shù)據(jù)格式、變換和編碼轉(zhuǎn)換

• 涉及正在傳輸數(shù)據(jù)的語法和語義

• 將消息以合適電子傳輸?shù)母袷骄幋a

• 執(zhí)行該層的數(shù)據(jù)壓縮和加密

• 從應(yīng)用層接收消息，轉(zhuǎn)換格式，并傳送到會話層，該層常合并在應(yīng)用層中

2.1.3.8. 應(yīng)用層

• 包括各種協(xié)議，它們定義了具體的面向用戶的應(yīng)用：如電子郵件、文件傳輸?shù)?/p>

2.1.3.9. 總結(jié)

低三層模型屬于通信子網(wǎng)，涉及為用戶間提供透明連接，操作主要以每條鏈路（ hop-by-hop）為基礎(chǔ)，在節(jié)點(diǎn)間的各條數(shù)據(jù)鏈路上進(jìn)行通信。由網(wǎng)絡(luò)層來控制各條鏈路上的通信，但要依賴于其他節(jié)點(diǎn)的協(xié)調(diào)操作。

高三層屬于資源子網(wǎng)，主要涉及保證信息以正確可理解形式傳送。

傳輸層是高三層和低三層之間的接口，它是第一個端到端的層次，保證透明的端到端連接，滿足用戶的服務(wù)質(zhì)量（QoS）要求，并向高三層提供合適的信息形式。

2.2. UDP協(xié)議

2.2.1. 主要特點(diǎn)

• 協(xié)議開銷小、效率高。

• UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

• UDP使用盡最大努力交付，即不保證可靠交付。

• UDP沒有擁塞控制。

• UDP支持一對一、一對多、多對一和多對多交互通信。

• UDP的首部開銷小，只有8個字節(jié)。

2.3. TCP協(xié)議

2.3.1. 簡介

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由RFC 793定義。

2.3.2. TCP狀態(tài)

2.3.2.1. 三次握手

三次握手（Three-Way Handshake）是指建立一個TCP連接時，需要客戶端和服務(wù)端總共發(fā)送3個包以確認(rèn)連接的建立。

第一次握手客戶端將標(biāo)志位 SYN 置為1，隨機(jī)產(chǎn)生一個值 seq=s ，并將該數(shù)據(jù)包發(fā)送給服務(wù)端，客戶端進(jìn)入 SYN_SENT 狀態(tài)，等待服務(wù)端確認(rèn)。

第二次握手服務(wù)端收到數(shù)據(jù)包后由標(biāo)志位 SYN=1 知道客戶端請求建立連接，服務(wù)端將標(biāo)志位 SYN 和 ACK 都置為1，ack=s+1，隨機(jī)產(chǎn)生一個值 seq=k ，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請求，服務(wù)端進(jìn)入 SYN_RCVD 狀態(tài)。

第三次握手客戶端收到確認(rèn)后，檢查ack值是否為s+1，ACK標(biāo)志位是否為1，如果正確則將標(biāo)志位 ACK 置為1，ack=k+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)端，服務(wù)端檢查ack值是否為k+1，ACK標(biāo)志位是否為1，如果正確則連接建立成功，客戶端和服務(wù)端進(jìn)入 ESTABLISHED 狀態(tài)，完成三次握手。

2.3.2.2. 四次揮手

四次揮手（Four-Way Wavehand）指斷開一個TCP連接時，需要客戶端和服務(wù)端總共發(fā)送4個包以確認(rèn)連接的斷開。

第一次揮手客戶端發(fā)送一個 FIN ，用來關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送，客戶端進(jìn)入 FIN_WAIT_1 狀態(tài)。

第二次揮手服務(wù)端收到 FIN 后，發(fā)送一個 ACK 給客戶端，確認(rèn)序號為收到序號+1，服務(wù)端進(jìn)入 CLOSE_WAIT 狀態(tài)。

第三次揮手服務(wù)端發(fā)送一個 FIN ，用來關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送，服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)。

第四次揮手客戶端收到 FIN 后，客戶端進(jìn)入 TIME_WAIT 狀態(tài)，接著發(fā)送一個 ACK 給服務(wù)端，確認(rèn)序號為收到序號+1，服務(wù)端進(jìn)入 CLOSED 狀態(tài)，完成四次揮手。

2.3.3. 擁塞控制

擁塞是指網(wǎng)絡(luò)中報(bào)文數(shù)量過多，使得服務(wù)端來不及處理，以致引起這部分乃至整個網(wǎng)絡(luò)性能下降的現(xiàn)象，嚴(yán)重時甚至?xí)?dǎo)致網(wǎng)絡(luò)通信業(yè)務(wù)陷入停頓即出現(xiàn)死鎖現(xiàn)象。

TCP采用擁塞控制算法來減少或者避免擁塞現(xiàn)象的發(fā)生，TCP的擁塞算法有過多種實(shí)現(xiàn)，包括Tahoe、Reno、NewReno、Vegas、Hybla、BIC 、CUBIC、SACK、Westwood、PRR、BBR等。

2.3.4. 參考鏈接

• RFC 793 TRANSMISSION CONTROL PROTOCOL

• RFC 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms

• RFC 3390 Increasing TCP's Initial Window

• RFC 5681 TCP Congestion Control

• TCP congestion control wiki

2.4. DHCP協(xié)議

2.4.1. 簡介

動態(tài)主機(jī)配置協(xié)議 (Dynamic Host Configuration Protocol，DHCP) 是一個用于局域網(wǎng)的網(wǎng)絡(luò)協(xié)議，位于OSI模型的應(yīng)用層，使用UDP協(xié)議工作，主要用于自動分配IP地址給用戶，方便管理員進(jìn)行統(tǒng)一管理。

DHCP服務(wù)器端使用67/udp，客戶端使用68/udp。DHCP運(yùn)行分為四個基本過程，分別為請求IP租約、提供IP租約、選擇IP租約和確認(rèn)IP租約?？蛻舳嗽讷@得了一個IP地址以后，就可以發(fā)送一個ARP請求來避免由于DHCP服務(wù)器地址池重疊而引發(fā)的IP沖突。

2.4.2. DCHP 報(bào)文格式

2.4.3. 參考鏈接

• DHCP Wiki

2.4.3.1. RFC

• RFC 2131 Dynamic Host Configuration Protocol

• RFC 2132 DHCP Options and BOOTP Vendor Extensions

• RFC 3046 DHCP Relay Agent Information Option

• RFC 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option

• RFC 3442 Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

• RFC 3942 Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options

• RFC 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6

• RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

• RFC 4436 Detecting Network Attachment in IPv4 (DNAv4)

2.5. 路由算法

2.5.1. 簡介

路由算法是用于找到一條從源路由器到目的路由器的最佳路徑的算法。存在著多種路由算法，每種算法對網(wǎng)絡(luò)和路由器資源的影響都不同；由于路由算法使用多種度量標(biāo)準(zhǔn) (metric)，所以不同路由算法的最佳路徑選擇也有所不同。

2.5.2. 路由選擇算法的功能

源/宿對之間的路徑選擇，以及選定路由之后將報(bào)文傳送到它們的目的地。

路由選擇算法的要求：

• 正確性：確保分組從源節(jié)點(diǎn)傳送到目的節(jié)點(diǎn)

• 簡單性：實(shí)現(xiàn)方便，軟硬件開銷小

• 自適應(yīng)性：也稱健壯性，算法能夠適應(yīng)業(yè)務(wù)量和網(wǎng)絡(luò)拓?fù)涞淖兓?/p>

• 穩(wěn)定性：能長時間無故障運(yùn)行

• 公平性：每個節(jié)點(diǎn)都有機(jī)會傳送信息

• 最優(yōu)性：盡量選取好的路由

2.5.3. 自治系統(tǒng) AS (Autonomous System)

經(jīng)典定義：

• 由一個組織管理的一整套路由器和網(wǎng)絡(luò)。

• 使用一種AS 內(nèi)部的路由選擇協(xié)議和共同的度量以確定分組在該 AS 內(nèi)的路由。

• 使用一種 AS 之間的路由選擇協(xié)議用以確定分組在AS之間的路由。

盡管一個 AS 使用了多種內(nèi)部路由選擇協(xié)議和度量，但對其他 AS 表現(xiàn)出的是一個單一的和一致的路由選擇策略。

2.5.4. 兩大類路由選擇協(xié)議

因特網(wǎng)的中，路由協(xié)議可以分為內(nèi)部網(wǎng)關(guān)協(xié)議 IGP (Interior Gateway Protocol)和外部網(wǎng)關(guān)協(xié)議 EGP (External Gateway Protocol)。

IGP是在一個AS內(nèi)部使用的路由選擇協(xié)議，如RIP和OSPF協(xié)議，是域內(nèi)路由選擇 (interdomain routing)。當(dāng)源主機(jī)和目的主機(jī)處在不同的AS中，在數(shù)據(jù)報(bào)到達(dá)AS的邊界時，使用外部網(wǎng)關(guān)協(xié)議 EGP 將路由選擇信息傳遞到另一個自治系統(tǒng)中，如BGP-4，是域間路由選擇 (intradomain routing)。

2.5.5. RIP

路由信息協(xié)議 (Routing Information Protocol, RIP) 是一種基于距離 向量的路由選擇協(xié)議。RIP 協(xié)議要求網(wǎng)絡(luò)中的每一個路由器都要維護(hù)從它自己到自治系統(tǒng)內(nèi)其他每一個目的網(wǎng)絡(luò)的距離和下一跳路由器地址。

2.5.6. OSPF

開放最短路徑優(yōu)先(Open Shortest Path First，OSPF)，這個算法名為“最短路徑優(yōu)先”是因?yàn)槭褂昧?Dijkstra 提出的最短路徑算法SPF，只是一個協(xié)議的名字，它并不表示其他的路由選擇協(xié)議不是“最短路徑優(yōu)先”。

2.6. 域名系統(tǒng)

2.6.1. 簡介

DNS是一個簡單的請求-響應(yīng)協(xié)議，是將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便地訪問互聯(lián)網(wǎng)。DNS使用TCP和UDP協(xié)議的53端口。

2.6.2. 術(shù)語

2.6.2.1. mDNS

Multicast DNS (mDNS)，多播DNS，使用5353端口，組播地址為 224.0.0.251 或 [FF02::FB] 。在一個沒有常規(guī)DNS服務(wù)器的小型網(wǎng)絡(luò)內(nèi)可以使用mDNS來實(shí)現(xiàn)類似DNS的編程接口、包格式和操作語義。mDNS協(xié)議的報(bào)文與DNS的報(bào)文結(jié)構(gòu)相同，但有些字段對于mDNS來說有新的含義。

啟動mDNS的主機(jī)會在進(jìn)入局域網(wǎng)后向所有主機(jī)組播消息，包含主機(jī)名、IP等信息，其他擁有相應(yīng)服務(wù)的主機(jī)也會響應(yīng)含有主機(jī)名和IP的信息。

mDNS的域名是用 .local 和普通域名區(qū)分開的。

2.6.2.2. FQDN

FQDN (Fully-Qualified Domain Name) 是域名的完全形態(tài)，主要是包含零長度的根標(biāo)簽，例如 www.example.com. 。

2.6.2.3. TLD

Top-Level Domain (TLD) 是屬于根域的一個域，例如 com 或 jp 。

TLD一般可以分為 Country Code Top-Level Domains (ccTLDs) 、Generic Top-Level Domains (gTLDs) 以及其它。

2.6.2.4. IDN

Internationalized Domain Names for Applications (IDNA) 是為了處理非ASCII字符的情況。

2.6.2.5. CNAME

CNAME即Canonical name，又稱alias，將域名指向另一個域名。

2.6.2.6. TTL

Time To Live，無符號整數(shù)，記錄DNS記錄過期的時間，最小是0，最大是2147483647 (2^31 - 1)。

2.6.3. 請求響應(yīng)

2.6.3.1. DNS記錄

• A記錄 返回域名對應(yīng)的IPv4地址

• NS記錄 域名服務(wù)器 返回該域名由哪臺域名服務(wù)器解析

• PTR記錄 反向記錄 從IP地址到域名的記錄

• MX記錄 電子郵件交換記錄 記錄郵件域名對應(yīng)的IP地址

2.6.3.2. 響應(yīng)碼

• NOERROR

No error condition

• FORMERR

• SERVFAIL

Server failure - The name server was unable to process this query due to a problem with the name server

• NXDOMAIN

• NOTIMP

Not Implemented - The name server does not support the requested kind of query

• REFUSED

• NODATA

A pseudo RCODE which indicates that the name is valid, for the given class, but [there] are no records of the given type A NODATA response has to be inferred from the answer.

2.6.4. 域名系統(tǒng)工作原理

2.6.4.1. 解析過程

DNS解析過程是遞歸查詢的，具體過程如下：

• 用戶要訪問域名www.example.com時，先查看本機(jī)hosts是否有記錄或者本機(jī)是否有DNS緩存，如果有，直接返回結(jié)果，否則向遞歸服務(wù)器查詢該域名的IP地址

• 遞歸緩存為空時，首先向根服務(wù)器查詢com頂級域的IP地址

• 根服務(wù)器告知遞歸服務(wù)器com頂級域名服務(wù)器的IP地址

• 遞歸向com頂級域名服務(wù)器查詢負(fù)責(zé)example.com的權(quán)威服務(wù)器的IP

• com頂級域名服務(wù)器返回相應(yīng)的IP地址

• 遞歸向example.com的權(quán)威服務(wù)器查詢www.example.com的地址記錄

• 權(quán)威服務(wù)器告知www.example.com的地址記錄

• 遞歸服務(wù)器將查詢結(jié)果返回客戶端

2.6.4.2. 域傳送

DNS服務(wù)器可以分為主服務(wù)器、備份服務(wù)器和緩存服務(wù)器。域傳送是指備份服務(wù)器從主服務(wù)器拷貝數(shù)據(jù)，并使用得到的數(shù)據(jù)更新自身數(shù)據(jù)庫。域傳送是在主備服務(wù)器之間同步數(shù)據(jù)庫的機(jī)制。

2.6.5. 服務(wù)器類型

2.6.5.1. 根服務(wù)器

根服務(wù)器是DNS的核心，負(fù)責(zé)互聯(lián)網(wǎng)頂級域名的解析，用于維護(hù)域的權(quán)威信息，并將DNS查詢引導(dǎo)到相應(yīng)的域名服務(wù)器。

根服務(wù)器在域名樹中代表最頂級的 . 域， 一般省略。

13臺IPv4根服務(wù)器的域名標(biāo)號為a到m，即a.root-servers.org到m.root-servers.org，所有服務(wù)器存儲的數(shù)據(jù)相同，僅包含ICANN批準(zhǔn)的TLD域名權(quán)威信息。

2.6.5.2. 權(quán)威服務(wù)器

權(quán)威服務(wù)器上存儲域名Zone文件，維護(hù)域內(nèi)域名的權(quán)威信息，遞歸服務(wù)器可以從權(quán)威服務(wù)器獲得DNS查詢的資源記錄。

權(quán)威服務(wù)器需要在所承載的域名所屬的TLD管理局注冊，同一個權(quán)威服務(wù)器可以承載不同TLD域名，同一個域也可以有多個權(quán)威服務(wù)器。

2.6.5.3. 遞歸服務(wù)器

遞歸服務(wù)器負(fù)責(zé)接收用戶的查詢請求，進(jìn)行遞歸查詢并響應(yīng)用戶查詢請求。在初始時遞歸服務(wù)器僅有記錄了根域名的Hint文件。

2.6.6. DNS利用

2.6.6.1. DGA

DGA（Domain Generate Algorithm，域名生成算法）是一種利用隨機(jī)字符來生成C&C域名，從而逃避域名黑名單檢測的技術(shù)手段，常見于botnet中。一般來說，一個DGA域名的存活時間約在1-7天左右。

通信時，客戶端和服務(wù)端都運(yùn)行同一套DGA算法，生成相同的備選域名列表，當(dāng)需要發(fā)動攻擊的時候，選擇其中少量進(jìn)行注冊，便可以建立通信，并且可以對注冊的域名應(yīng)用速變IP技術(shù)，快速變換IP，從而域名和IP都可以進(jìn)行快速變化。

DGA域名有多種生成方式，根據(jù)種子類型可以分為確定性和不確定性的生成。不確定性的種子可能會選用當(dāng)天的一些即時數(shù)據(jù)，如匯率信息等。

2.6.6.2. DNS隧道

DNS隧道工具將進(jìn)入隧道的其他協(xié)議流量封裝到DNS協(xié)議內(nèi)，在隧道上傳輸。這些數(shù)據(jù)包出隧道時進(jìn)行解封裝，還原數(shù)據(jù)。

2.6.7. 加密方案

作為主流的防御方案，DNS加密有五種方案，分別是 DNS-over-TLS (DoT)、DNS-over-DTLS、DNS-over-HTTPS (DoH)、DNS-over-QUIC以及DNSCrypt。

2.6.7.1. DoT

DoT方案在2016年發(fā)表于RFC7858，使用853端口。主要思想是Client和Server通過TCP協(xié)議建立TLS會話后再進(jìn)行DNS傳輸，Client通過SSL證書驗(yàn)證服務(wù)器身份。

2.6.7.2. DNS-over-DTLS

DNS-over-DTLS和DoT類似，區(qū)別在于使用UDP協(xié)議而不是TCP協(xié)議。

2.6.7.3. DoH

DoH方案在發(fā)表RFC8484，使用
https://dns.example.com/dns-query{?dns} 來查詢服務(wù)器的IP，復(fù)用https的443端口，流量特征比較小。DoH會對DNS服務(wù)器進(jìn)行加密認(rèn)證，不提供fallback選項(xiàng)。目前Cloudflare、Google等服務(wù)商對DoH提供了支持。

2.6.7.4. DNS-over-QUIC

DNS-over-QUIC安全特性和DoT類似，但是性能更高，目前沒有合適的軟件實(shí)現(xiàn)。

2.6.7.5. DNSCrypt

DNSCrypt使用X25519-XSalsa20Poly1305而非標(biāo)準(zhǔn)的TLS，且DNSCrypt的Client需要額外的軟件，Server需要的專門的證書。

2.6.8. 相關(guān)漏洞

2.6.8.1. DNS劫持

DNS劫持有多種方式，比較早期的攻擊方式是通過攻擊域名解析服務(wù)器，或是偽造DNS響應(yīng)的方法，來將域名解析到惡意的IP地址。

隨著互聯(lián)網(wǎng)應(yīng)用的不斷發(fā)展，出現(xiàn)了基于廢棄記錄的劫持方式。這種方式發(fā)生的場景是次級域名的解析記錄指向第三方資源，而第三方資源被釋放后，解析記錄并沒有取消，在這種場景下，可以對應(yīng)申請第三方資源，以獲取控制解析記錄的能力。

2.6.8.2. 拒絕服務(wù)

DNS服務(wù)通常會開啟UDP端口，當(dāng)DNS服務(wù)器擁有大量二級域NS記錄時，通過DNS的UDP反射攻擊可以實(shí)現(xiàn)高倍的拒絕服務(wù)。

看到這里的大佬，動動發(fā)財(cái)?shù)男∈?點(diǎn)贊 + 回復(fù) + 收藏，能【 關(guān)注 】一波就更好了

我是一名滲透測試工程師，為了感謝讀者們，我想把我收藏的一些網(wǎng)絡(luò)安全/滲透測試學(xué)習(xí)干貨貢獻(xiàn)給大家，回饋每一個讀者，希望能幫到你們。

干貨主要有：

①　2000多本網(wǎng)安必看電子書（主流和經(jīng)典的書籍應(yīng)該都有了）

②　PHP標(biāo)準(zhǔn)庫資料（最全中文版）

③　項(xiàng)目源碼（四五十個有趣且經(jīng)典的練手項(xiàng)目及源碼）

④ 網(wǎng)絡(luò)安全基礎(chǔ)入門、Linux運(yùn)維，web安全、滲透測試方面的視頻（適合小白學(xué)習(xí)）

⑤ 網(wǎng)絡(luò)安全學(xué)習(xí)路線圖（告別不入流的學(xué)習(xí)）

⑥ 滲透測試工具大全

⑦ 2021網(wǎng)絡(luò)安全/Web安全/滲透測試工程師面試手冊大全

各位朋友們可以關(guān)注+評論一波 然后私信【W(wǎng)eb】 即可免費(fèi)獲取全部資料

2.6.9. 參考鏈接

2.6.9.1. RFC

• RFC 1034 DOMAIN NAMES CONCEPTS AND FACILITIES

• RFC 1035 DOMAIN NAMES IMPLEMENTATION AND SPECIFICATION

• RFC 1123 Requirements for Internet Hosts -- Application and Support

• RFC 2535 Domain Name System Security Extensions

• RFC 2930 Secret Key Establishment for DNS (TKEY RR)

• RFC 2931 DNS Request and Transaction Signatures ( SIG(0)s )

• RFC 3596 Legacy Resolver Compatibility for Delegation Signer (DS)

• RFC 3755 DNS Extensions to Support IP Version 6

• RFC 5001 Automated Updates of DNS Security (DNSSEC) Trust Anchors

• RFC 5936 DNS Zone Transfer Protocol

• RFC 5966 DNS Transport over TCP - Implementation Requirements

• RFC 6376 DomainKeys Identified Mail (DKIM) Signatures

• RFC 6762 Multicast DNS

• RFC 6891 Extension Mechanisms for DNS (EDNS(0))

• RFC 6895 DNS IANA Considerations

• RFC 7766 DNS Transport over TCP - Implementation Requirements

• RFC 7858 Specification for DNS over Transport Layer Security (TLS)

• RFC 8082 NXDOMAIN

• RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY

• RFC 8484 DNS Queries over HTTPS (DoH)

• RFC 8490 DNS Stateful Operations

• RFC 8499 DNS Terminology

2.6.9.2. 工具

• Unbound

• bind9

2.6.9.3. 研究文章

• DGA域名的今生前世：緣起、檢測、與發(fā)展

• DNSSEC原理和分析

• Plohmann D, Yakdan K, Klatt M, et al. A comprehensive measurement study of domain generating malware[C]//25th {USENIX} Security Symposium ({USENIX} Security 16). 2016: 263-278.

• An End-to-End Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?

2.6.9.4. 相關(guān)CVE

• SIGRed – Resolving Your Way into Domain Admin: Exploiting a 17 Year-old Bug in Windows DNS Servers

2.7. HTTP協(xié)議簇

內(nèi)容索引:

• 2.7.1. HTTP標(biāo)準(zhǔn)

• 2.7.1.1. 報(bào)文格式

• 2.7.1.2. 請求頭列表

• 2.7.1.3. 響應(yīng)頭列表

• 2.7.1.4. HTTP狀態(tài)返回代碼 1xx（臨時響應(yīng)）

• 2.7.1.5. HTTP狀態(tài)返回代碼 2xx （成功）

• 2.7.1.6. HTTP狀態(tài)返回代碼 3xx （重定向）

• 2.7.1.7. HTTP狀態(tài)返回代碼 4xx（請求錯誤）

• 2.7.1.8. HTTP狀態(tài)返回代碼 5xx（服務(wù)器錯誤）

• 2.7.2. HTTP 版本

• 2.7.2.1. HHTTP

• 2.7.2.2. HTTP 0.9

• 2.7.2.3. HTTP 1.0

• 2.7.2.4. HTTP 1.1

• 2.7.2.5. SPDY

• 2.7.2.6. HTTP/2

• 2.7.3. HTTPS

• 2.7.3.1. 簡介

• 2.7.3.2. 交互

• 2.7.3.3. CA

• 2.7.4. Cookie

• 2.7.4.1. 簡介

• 2.7.4.2. 屬性

• 2.7.5. WebDAV

• 2.7.5.1. 簡介

• 2.7.5.2. 相關(guān)CVE

• 2.7.6. 參考鏈接

• 2.7.6.1. RFC

• 2.7.6.2. Blog

2.7.1. HTTP標(biāo)準(zhǔn)

2.7.1.1. 報(bào)文格式

2.7.1.1.1. 請求報(bào)文格式

2.7.1.1.2. 響應(yīng)報(bào)文格式

<version><status><reason-phrase><headers><entity-body>

2.7.1.1.3. 字段解釋

• method HTTP動詞 常見方法：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE 擴(kuò)展方法：LOCK / MKCOL / COPY / MOVE

• version 報(bào)文使用的HTTP版本 格式為HTTP/<major>.<minor>

• url <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

2.7.1.2. 請求頭列表

• Accept 指定客戶端能夠接收的內(nèi)容類型 Accept: text/plain, text/html

• Accept-Charset 瀏覽器可以接受的字符編碼集 Accept-Charset: iso-8859-5

• Accept-Encoding 指定瀏覽器可以支持的web服務(wù)器返回內(nèi)容壓縮編碼類型 Accept-Encoding: compress, gzip

• Accept-Language 瀏覽器可接受的語言 Accept-Language: en,zh

• Accept-Ranges 可以請求網(wǎng)頁實(shí)體的一個或者多個子范圍字段 Accept-Ranges: bytes

• Authorization HTTP授權(quán)的授權(quán)證書 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Cache-Control 指定請求和響應(yīng)遵循的緩存機(jī)制 Cache-Control: no-cache

• Connection 表示是否需要持久連接 // HTTP 1.1默認(rèn)進(jìn)行持久連接 Connection: close

• Cookie HTTP請求發(fā)送時，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務(wù)器 Cookie: role=admin;ssid=1

• Content-Length 請求的內(nèi)容長度 Content-Length: 348

• Content-Type 請求的與實(shí)體對應(yīng)的MIME信息 Content-Type: application/x-www-form-urlencoded

• Date 請求發(fā)送的日期和時間 Date: Tue, 15 Nov 2010 08:12:31 GMT

• Expect 請求的特定的服務(wù)器行為 Expect: 100-continue

• From 發(fā)出請求的用戶的Email From: user@email.com

• Host 指定請求的服務(wù)器的域名和端口號 Host: www.github.com

• If-Match 只有請求內(nèi)容與實(shí)體相匹配才有效 If-Match: '737060cd8c284d8af7ad3082f209582d'

• If-Modified-Since 如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼 If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

• If-None-Match 如果內(nèi)容未改變返回304代碼，參數(shù)為服務(wù)器先前發(fā)送的Etag，與服務(wù)器回應(yīng)的Etag比較判斷是否改變 If-None-Match: '737060cd8c284d8af7ad3082f209582d'

• If-Range 如果實(shí)體未改變，服務(wù)器發(fā)送客戶端丟失的部分，否則發(fā)送整個實(shí)體。參數(shù)也為Etag If-Range: '737060cd8c284d8af7ad3082f209582d'

• If-Unmodified-Since 只在實(shí)體在指定時間之后未被修改才請求成功 If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

• Max-Forwards 限制信息通過代理和網(wǎng)關(guān)傳送的時間 Max-Forwards: 10

• Pragma 用來包含實(shí)現(xiàn)特定的指令 Pragma: no-cache

• Proxy-Authorization 連接到代理的授權(quán)證書 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Range 只請求實(shí)體的一部分，指定范圍 Range: bytes=500-999

• Referer 先前網(wǎng)頁的地址，當(dāng)前請求網(wǎng)頁緊隨其后,即來路 Referer: http://www.zcmhi.com/archives/71.html

• TE 客戶端愿意接受的傳輸編碼，并通知服務(wù)器接受接受尾加頭信息 TE: trailers,deflate;q=0.5

• Upgrade 向服務(wù)器指定某種傳輸協(xié)議以便服務(wù)器進(jìn)行轉(zhuǎn)換（如果支持） Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

• User-Agent User-Agent的內(nèi)容包含發(fā)出請求的用戶信息 User-Agent: Mozilla/5.0 (Linux; X11)

• Via 通知中間網(wǎng)關(guān)或代理服務(wù)器地址，通信協(xié)議 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

• Warning 關(guān)于消息實(shí)體的警告信息 Warn: 199 Miscellaneous warning

2.7.1.3. 響應(yīng)頭列表

• Accept-Ranges 表明服務(wù)器是否支持指定范圍請求及哪種類型的分段請求 Accept-Ranges: bytes

• Access-Control-Allow-Origin 配置有權(quán)限訪問資源的域 Access-Control-Allow-Origin: <origin>|*

• Age 從原始服務(wù)器到代理緩存形成的估算時間（以秒計(jì)，非負(fù)） Age: 12

• Allow 對某網(wǎng)絡(luò)資源的有效的請求行為，不允許則返回405 Allow: GET, HEAD

• Cache-Control 告訴所有的緩存機(jī)制是否可以緩存及哪種類型 Cache-Control: no-cache

• Content-Encoding web服務(wù)器支持的返回內(nèi)容壓縮編碼類型。 Content-Encoding: gzip

• Content-Language 響應(yīng)體的語言 Content-Language: en,zh

• Content-Length 響應(yīng)體的長度 Content-Length: 348

• Content-Location 請求資源可替代的備用的另一地址 Content-Location: /index.htm

• Content-MD5 返回資源的MD5校驗(yàn)值 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

• Content-Range 在整個返回體中本部分的字節(jié)位置 Content-Range: bytes 21010-47021/47022

• Content-Type 返回內(nèi)容的MIME類型 Content-Type: text/html; charset=utf-8

• Date 原始服務(wù)器消息發(fā)出的時間 Date: Tue, 15 Nov 2010 08:12:31 GMT

• ETag 請求變量的實(shí)體標(biāo)簽的當(dāng)前值 ETag: '737060cd8c284d8af7ad3082f209582d'

• Expires 響應(yīng)過期的日期和時間 Expires: Thu, 01 Dec 2010 16:00:00 GMT

• Last-Modified 請求資源的最后修改時間 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

• Location 用來重定向接收方到非請求URL的位置來完成請求或標(biāo)識新的資源 Location: http://www.zcmhi.com/archives/94.html

• Pragma 包括實(shí)現(xiàn)特定的指令，它可應(yīng)用到響應(yīng)鏈上的任何接收方 Pragma: no-cache

• Proxy-Authenticate 它指出認(rèn)證方案和可應(yīng)用到代理的該URL上的參數(shù) Proxy-Authenticate: Basic

• Refresh 應(yīng)用于重定向或一個新的資源被創(chuàng)造，在5秒之后重定向（由網(wǎng)景提出，被大部分瀏覽器支持） Refresh: 5; url=http://www.zcmhi.com/archives/94.html

• Retry-After 如果實(shí)體暫時不可取，通知客戶端在指定時間之后再次嘗試 Retry-After: 120

• Server web服務(wù)器軟件名稱 Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

• Set-Cookie 設(shè)置Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

• Strict-Transport-Security 設(shè)置瀏覽器強(qiáng)制使用HTTPS訪問 max-age: x秒的時間內(nèi) 訪問對應(yīng)域名都使用HTTPS請求 includeSubDomains: 網(wǎng)站的子域名也啟用規(guī)則 Strict-Transport-Security: max-age=1000; includeSubDomains

• Trailer 指出頭域在分塊傳輸編碼的尾部存在 Trailer: Max-Forwards

• Transfer-Encoding 文件傳輸編碼 Transfer-Encoding:chunked

• Vary 告訴下游代理是使用緩存響應(yīng)還是從原始服務(wù)器請求 Vary: *

• Via 告知代理客戶端響應(yīng)是通過哪里發(fā)送的 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

• Warning 警告實(shí)體可能存在的問題 Warning: 199 Miscellaneous warning

• WWW-Authenticate 表明客戶端請求實(shí)體應(yīng)該使用的授權(quán)方案 WWW-Authenticate: Basic

• X-Content-Type-Options 配置禁止MIME類型嗅探 X-Content-Type-Options: nosniff

• X-Frame-Options 配置頁面是否能出現(xiàn)在 <frame>, <iframe>, <embed>, <object> 等標(biāo)簽中，防止點(diǎn)擊劫持 X-Frame-Options: deny

• X-XSS-Protection 配置XSS防護(hù)機(jī)制 X-XSS-Protection: 1; mode=block

2.7.1.4. HTTP狀態(tài)返回代碼 1xx（臨時響應(yīng)）

表示臨時響應(yīng)并需要請求者繼續(xù)執(zhí)行操作的狀態(tài)代碼。

2.7.1.5. HTTP狀態(tài)返回代碼 2xx （成功）

表示成功處理了請求的狀態(tài)代碼。

2.7.1.6. HTTP狀態(tài)返回代碼 3xx （重定向）

表示要完成請求，需要進(jìn)一步操作。 通常，這些狀態(tài)代碼用來重定向。

2.7.1.7. HTTP狀態(tài)返回代碼 4xx（請求錯誤）

這些狀態(tài)代碼表示請求可能出錯，妨礙了服務(wù)器的處理。

2.7.1.8. HTTP狀態(tài)返回代碼 5xx（服務(wù)器錯誤）

這些狀態(tài)代碼表示服務(wù)器在嘗試處理請求時發(fā)生內(nèi)部錯誤。 這些錯誤可能是服務(wù)器本身的錯誤，而不是請求出錯。

2.7.2. HTTP 版本

2.7.2.1. HHTTP

HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口。

2.7.2.2. HTTP 0.9

HTTP 0.9最早在1991年發(fā)布，僅支持GET命令，請求格式只有簡單的 GET /url ，服務(wù)端僅響應(yīng)HTML，響應(yīng)完畢后關(guān)閉TCP連接。

2.7.2.3. HTTP 1.0

1996年5月，HTTP/1.0 版本發(fā)布，豐富了傳輸?shù)母袷胶蛢?nèi)容，還引入了POST、HEAD兩個動詞。從1.0開始，必須在尾部添加協(xié)議版本。在1.0中，也引入了狀態(tài)碼(status code)、多字符集支持、多部分發(fā)送(multi-part type)、權(quán)限(authorization)、緩存(cache)、內(nèi)容編碼(content encoding)等內(nèi)容。

HTTP 1.0 版的主要缺點(diǎn)是，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接。

TCP連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時發(fā)送速率較慢(slow start)，所以，HTTP 1.0版本的性能比較差。

2.7.2.4. HTTP 1.1

1997年1月，HTTP/1.1 版本發(fā)布，進(jìn)一步完善了 HTTP 協(xié)議。1.1版本主要是引入了持久連接、管道機(jī)制、Content-Length、分塊傳輸編碼等內(nèi)容。管道機(jī)制即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求，這樣就改進(jìn)了HTTP協(xié)議的效率。PUT、PATCH、HEAD、 OPTIONS、DELETE等動詞方法也是在HTTP 1.1版本引入的。另外1.1版本新增了Host字段，用于指定服務(wù)器的域名，這也是后來虛擬主機(jī)得以發(fā)展的基礎(chǔ)。

雖然1.1版允許復(fù)用TCP連接，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)器只有處理完一個回應(yīng)，才會進(jìn)行下一個回應(yīng)。如果有一個請求很慢，就會阻塞后面的請求。

2.7.2.5. SPDY

2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，用于解決 HTTP/1.1 效率不高的問題，而后被當(dāng)做 HTTP/2 的基礎(chǔ)。

2.7.2.6. HTTP/2

2015年，HTTP/2 發(fā)布，HTTP/2是一個二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，統(tǒng)稱為幀(frame)，幀分為頭信息幀和數(shù)據(jù)幀。HTTP/2 復(fù)用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應(yīng)，而且不用按照順序回應(yīng)。

2.7.3. HTTPS

2.7.3.1. 簡介

HTTPS (HyperText Transfer Protocol over Secure Socket Layer)可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL。

2.7.3.2. 交互

2.7.3.2.1. 證書驗(yàn)證階段

• 瀏覽器發(fā)起 HTTPS 請求

• 服務(wù)端返回 HTTPS 證書 其中證書包含： 頒發(fā)機(jī)構(gòu)信息 公鑰 公司信息 域名 有效期 指紋

• 客戶端驗(yàn)證證書是否合法，如果不合法則提示告警

2.7.3.2.2. 數(shù)據(jù)傳輸階段

• 當(dāng)證書驗(yàn)證合法后，在本地生成隨機(jī)數(shù)

• 通過公鑰加密隨機(jī)數(shù)，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端

• 服務(wù)端通過私鑰對隨機(jī)數(shù)進(jìn)行解密

• 服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對稱加密算法，對返回結(jié)果內(nèi)容進(jìn)行加密后傳輸

2.7.3.3. CA

CA (Certificate Authority) 是頒發(fā)數(shù)字證書的機(jī)構(gòu)。是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機(jī)構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗(yàn)的責(zé)任。

2.7.4. Cookie

2.7.4.1. 簡介

Cookie（復(fù)數(shù)形態(tài)Cookies），類型為「小型文本文件」，指某些網(wǎng)站為了辨別用戶身份而儲存在用戶本地終端上的數(shù)據(jù)。

2.7.4.2. 屬性

2.7.4.2.1. name

cookie的名稱。

2.7.4.2.2. value

cookie的值。

2.7.4.2.3. expires

當(dāng) Expires 屬性缺省時，表示是會話性 Cookie，在用戶關(guān)閉瀏覽器時失效。

2.7.4.2.4. max-age

max-age 可以為正數(shù)、負(fù)數(shù)、0。如果 max-age 屬性為正數(shù)時，瀏覽器會將其持久化，當(dāng) max-age 屬性為負(fù)數(shù)，則表示該 Cookie 只是一個會話性 Cookie。當(dāng) max-age 為 0 時，則會立即刪除這個 Cookie。Expires 和 max-age 都存在的條件下，max-age 優(yōu)先級更高。

2.7.4.2.5. domain

指定Cookie的域名，默認(rèn)是當(dāng)前域名。domain設(shè)置時可以設(shè)置為自身及其父域，子域可以訪問父域的Cookie，反之不能。

2.7.4.2.6. path

指定一個 URL 路徑，這個路徑必須出現(xiàn)在要請求的資源的路徑中才可以發(fā)送對應(yīng)的 Cookie。

2.7.4.2.7. secure

只能通過 HTTPS 傳輸。

2.7.4.2.8. httponly

限制Cookie僅在HTTP傳輸過程中被讀取，一定程度上防御XSS攻擊。

2.7.4.2.9. SameSite

SameSite 支持 Strict / Lax / None 三種值。Strict最為嚴(yán)格，完全禁止第三方 Cookie，跨站點(diǎn)時，任何情況下都不會發(fā)送 Cookie。Lax 允許部分第三方請求攜帶 Cookie，主要是鏈接、預(yù)加載、GET 表單三種情況。Cookie 的 SameSite 屬性為 None ，且設(shè)置了 Secure 時，無論是否跨站都會發(fā)送 Cookie。

2.7.5. WebDAV

2.7.5.1. 簡介

WebDAV （Web-based Distributed Authoring and Versioning） 一種基于 HTTP 1.1協(xié)議的通信協(xié)議。它擴(kuò)展了HTTP 1.1，在GET、POST、HEAD等幾個HTTP標(biāo)準(zhǔn)方法以外添加了一些新的方法，使應(yīng)用程序可對Web Server直接讀寫，并支持寫文件鎖定、解鎖，以及版本控制等功能。

支持的方法具體為：

• OPTIONS 獲取服務(wù)器的支持

• GET / PUT / POST / DELETE 資源操作

• TRACE 跟蹤服務(wù)器

• HEAD

• MKCOL 創(chuàng)建集合

• PROPFIND / PROPPATCH

• COPY / MOVE

• LOCK / UNLOCK

2.7.5.2. 相關(guān)CVE

• CVE-2015-1833 Apache Jacrabbit WebDav XXE http://www.securityfocus.com/archive/1/535582

• CVE-2015-7326 Milton WebDav XXE http://www.securityfocus.com/archive/1/536813

2.7.6. 參考鏈接

2.7.6.1. RFC

• RFC 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

• RFC 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol

• RFC 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol

• RFC 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources

• RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

• RFC 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH

• RFC 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)

2.7.6.2. Blog

• What should a hacker know about WebDav

• Cookie 的 SameSite 屬性

• HTTP 協(xié)議入門

2.8. 郵件協(xié)議族

2.8.1. 簡介

2.8.1.1. SMTP

SMTP (Simple Mail Transfer Protocol) 是一種電子郵件傳輸?shù)膮f(xié)議，是一組用于從源地址到目的地址傳輸郵件的規(guī)范。不啟用SSL時端口號為25，啟用SSL時端口號多為465或994。

2.8.1.2. POP3

POP3 (Post Office Protocol 3) 用于支持使用客戶端遠(yuǎn)程管理在服務(wù)器上的電子郵件。不啟用SSL時端口號為110，啟用SSL時端口號多為995。

2.8.1.3. IMAP

IMAP (Internet Mail Access Protocol)，即交互式郵件存取協(xié)議，它是跟POP3類似郵件訪問標(biāo)準(zhǔn)協(xié)議之一。不同的是，開啟了IMAP后，您在電子郵件客戶端收取的郵件仍然保留在服務(wù)器上，同時在客戶端上的操作都會反饋到服務(wù)器上，如：刪除郵件，標(biāo)記已讀等，服務(wù)器上的郵件也會做相應(yīng)的動作。不啟用SSL時端口號為143，啟用SSL時端口號多為993。

2.8.2. 防護(hù)策略

2.8.2.1. SPF

發(fā)件人策略框架 (Sender Policy Framework, SPF) 是一套電子郵件認(rèn)證機(jī)制，用于確認(rèn)電子郵件是否由網(wǎng)域授權(quán)的郵件服務(wù)器寄出，防止有人偽冒身份網(wǎng)絡(luò)釣魚或寄出垃圾郵件。SPF允許管理員設(shè)定一個DNS TXT記錄或SPF記錄設(shè)定發(fā)送郵件服務(wù)器的IP范圍，如有任何郵件并非從上述指明授權(quán)的IP地址寄出，則很可能該郵件并非確實(shí)由真正的寄件者寄出。

2.8.2.2. DKIM

域名密鑰識別郵件 (DomainKeys Identified Mail, DKIM) 是一種檢測電子郵件發(fā)件人地址偽造的方法。發(fā)送方會在郵件的頭中插入DKIM-Signature，收件方通過查詢DNS記錄中的公鑰來驗(yàn)證發(fā)件人的信息。

2.8.2.3. DMARC

基于網(wǎng)域的消息認(rèn)證、報(bào)告和一致性 (Domain-based Message Authentication, Reporting and Conformance, DMARC) 是電子郵件身份驗(yàn)證協(xié)議，用于解決在郵件欄中顯示的域名和驗(yàn)證的域名不一致的問題。要通過 DMARC 檢查，必須通過 SPF 或/和 DKIM 的身份驗(yàn)證，且需要標(biāo)頭地址中的域名必須與經(jīng)過身份驗(yàn)證的域名一致。

2.8.3. 參考鏈接

2.8.3.1. RFC

• RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

• RFC 6376 DomainKeys Identified Mail (DKIM) Signatures

• RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

• RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)

• RFC 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)

• RFC 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)

• RFC 8616 Email Authentication for Internationalized Mail

• RFC 8611 Mail

2.8.3.2. 相關(guān)文檔

• Sender Policy Framework wikipedia

• DomainKeys Identified Mail wikipedia

• DMARC wikipedia

2.8.3.3. 研究文章

• Composition Kills:A Case Study of Email Sender Authentication

2.9. SSL/TLS

2.9.1. 簡介

SSL全稱是Secure Sockets Layer，安全套接字層，它是由網(wǎng)景公司(Netscape)在1994年時設(shè)計(jì)，主要用于Web的安全傳輸協(xié)議，目的是為網(wǎng)絡(luò)通信提供機(jī)密性、認(rèn)證性及數(shù)據(jù)完整性保障。如今，SSL已經(jīng)成為互聯(lián)網(wǎng)保密通信的工業(yè)標(biāo)準(zhǔn)。

SSL最初的幾個版本(SSL 1.0、SSL2.0、SSL 3.0)由網(wǎng)景公司設(shè)計(jì)和維護(hù)，從3.1版本開始，SSL協(xié)議由因特網(wǎng)工程任務(wù)小組(IETF)正式接管，并更名為TLS(Transport Layer Security)，發(fā)展至今已有TLS 1.0、TLS1.1、TLS1.2、TLS1.3這幾個版本。

如TLS名字所說，SSL/TLS協(xié)議僅保障傳輸層安全。同時，由于協(xié)議自身特性(數(shù)字證書機(jī)制)，SSL/TLS不能被用于保護(hù)多跳(multi-hop)端到端通信，而只能保護(hù)點(diǎn)到點(diǎn)通信。

SSL/TLS協(xié)議能夠提供的安全目標(biāo)主要包括如下幾個：

• 認(rèn)證性 借助數(shù)字證書認(rèn)證服務(wù)端端和客戶端身份，防止身份偽造

• 機(jī)密性 借助加密防止第三方竊聽

• 完整性 借助消息認(rèn)證碼(MAC)保障數(shù)據(jù)完整性，防止消息篡改

• 重放保護(hù) 通過使用隱式序列號防止重放攻擊

為了實(shí)現(xiàn)這些安全目標(biāo)，SSL/TLS協(xié)議被設(shè)計(jì)為一個兩階段協(xié)議，分為握手階段和應(yīng)用階段：

握手階段也稱協(xié)商階段，在這一階段，客戶端和服務(wù)端端會認(rèn)證對方身份(依賴于PKI體系，利用數(shù)字證書進(jìn)行身份認(rèn)證)，并協(xié)商通信中使用的安全參數(shù)、密碼套件以及MasterSecret。后續(xù)通信使用的所有密鑰都是通過MasterSecret生成。 在握手階段完成后，進(jìn)入應(yīng)用階段。在應(yīng)用階段通信雙方使用握手階段協(xié)商好的密鑰進(jìn)行安全通信。

2.9.2. 協(xié)議

TLS 包含幾個子協(xié)議，比較常用的有記錄協(xié)議、警報(bào)協(xié)議、握手協(xié)議、變更密碼規(guī)范協(xié)議等。

2.9.2.1. 記錄協(xié)議

記錄協(xié)議(Record Protocol)規(guī)定了 TLS 收發(fā)數(shù)據(jù)的基本單位記錄(record)。

2.9.2.2. 警報(bào)協(xié)議

警報(bào)協(xié)議(Alert Protocol)用于提示協(xié)議交互過程出現(xiàn)錯誤。

2.9.2.3. 握手協(xié)議

握手協(xié)議(Handshake Protocol)是 TLS 里最復(fù)雜的子協(xié)議，在握手過程中協(xié)商 TLS 版本號、隨機(jī)數(shù)、密碼套件等信息，然后交換證書和密鑰參數(shù)，最終雙方協(xié)商得到會話密鑰，用于后續(xù)的混合加密系統(tǒng)。

2.9.2.4. 變更密碼規(guī)范協(xié)議

變更密碼規(guī)范協(xié)議(Change Cipher Spec Protocol)是一個“通知”，告訴對方，后續(xù)的數(shù)據(jù)都將使用加密保護(hù)。

2.9.3. 交互過程

2.9.3.1. Client Hello

Client Hello 由客戶端發(fā)送，內(nèi)容包括客戶端的一個Unix時間戳(GMT Unix Time)、一些隨機(jī)的字節(jié)(Random Bytes)，還包括了客戶端接受的算法類型(Cipher Suites)。

2.9.3.2. Server Hello

Server Hello 由服務(wù)端發(fā)送，內(nèi)容包括服務(wù)端支持的算法類型、GMT Unix Time以及Random Bytes。

2.9.3.3. Certificate

由服務(wù)端或者客戶端發(fā)送，發(fā)送方會會將自己的數(shù)字證書發(fā)送給接收方，由接收方進(jìn)行證書驗(yàn)證，如果不通過的話，接收方會中斷握手的過程。一般跟在Client / Server Hello報(bào)文之后。

2.9.3.4. Server Key Exchange

由服務(wù)端發(fā)送，將自己的公鑰參數(shù)傳輸給了客戶端，一般也和Server Hello與Certificate在一個TCP報(bào)文中。

2.9.3.5. Server Hello Done

服務(wù)端發(fā)送，一般也和Server Hello、Certificate和Server Key Exchange在一個TCP報(bào)文中。

2.9.3.6. Client Key Exchange

客戶端發(fā)送，向服務(wù)端發(fā)送自己的公鑰參數(shù)，與服務(wù)端協(xié)商密鑰。

2.9.3.7. Change Cipher Spec

客戶端或者服務(wù)端發(fā)送，緊跟著Key Exchange發(fā)送，代表自己生成了新的密鑰，通知對方以后將更換密鑰，使用新的密鑰進(jìn)行通信。

2.9.3.8. Encrypted Handshake Message

客戶端或者服務(wù)端發(fā)送，緊跟著Key Exchange發(fā)送。進(jìn)行測試，一方用自己的剛剛生成的密鑰加密一段固定的消息發(fā)送給對方，如果密鑰協(xié)商正確無誤的話，對方可以正確解密。

2.9.3.9. New Session Ticket

服務(wù)端發(fā)送，表示發(fā)起會話，在一段時間之內(nèi)(超時時間到來之前)，雙方都以剛剛交換的密鑰進(jìn)行通信。從這以后，加密通信正式開始。

2.9.3.10. Application Data

使用密鑰交換協(xié)議協(xié)商出來的密鑰加密的應(yīng)用層的數(shù)據(jù)。

2.9.3.11. Encrypted Alert

客戶端或服務(wù)端發(fā)送，意味著加密通信因?yàn)槟承┰蛐枰袛啵鎸Ψ讲灰侔l(fā)送敏感的數(shù)據(jù)。

2.9.4. 版本更新內(nèi)容

2.9.4.1. TLS 1.3

• 引入了PSK作為新的密鑰協(xié)商機(jī)制

• 支持 0-RTT 模式，以安全性降低為代價，在建立連接時節(jié)省了往返時間

• ServerHello 之后的所有握手消息采取了加密操作，可見明文減少

• 不再允許對加密報(bào)文進(jìn)行壓縮、不再允許雙方發(fā)起重協(xié)商

• DSA 證書不再允許在 TLS 1.3 中使用

• 刪除不安全的密碼算法 RSA 密鑰傳輸 - 不支持前向安全性 CBC 模式密碼 - 易受 BEAST 和 Lucky 13 攻擊 RC4 流密碼 - 在 HTTPS 中使用并不安全 SHA-1 哈希函數(shù) - 建議以 SHA-2 取而代之 任意 Diffie-Hellman 組- CVE-2016-0701 漏洞 輸出密碼 - 易受 FREAK 和 LogJam 攻擊

2.9.5. 子協(xié)議

SSL/TLS協(xié)議有一個高度模塊化的架構(gòu)，分為很多子協(xié)議，主要是：

• Handshake 協(xié)議 包括協(xié)商安全參數(shù)和密碼套件、服務(wù)端身份認(rèn)證(客戶端身份認(rèn)證可選)、密鑰交換

• ChangeCipherSpec 協(xié)議 一條消息表明握手協(xié)議已經(jīng)完成

• Alert 協(xié)議 對握手協(xié)議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續(xù)，只是會給出錯誤警告

• Record 協(xié)議 包括對消息的分段、壓縮、消息認(rèn)證和完整性保護(hù)、加密等

2.9.6. 參考鏈接

2.9.6.1. RFC

• RFC 2246 The TLS Protocol Version 1.0

• RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1

• RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2

• RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0

• RFC 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0

• RFC 7568 Deprecating Secure Sockets Layer Version 3.0

• RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3

2.9.6.2. Document

• Wikipedia Transport Layer Security

2.10. IPsec

2.10.1. 簡介

IPsec（IP Security）是IETF制定的三層隧道加密協(xié)議，它為Internet上傳輸?shù)臄?shù)據(jù)提供了高質(zhì)量的、可互操作的、基于密碼學(xué)的安全保證。特定的通信方之間在IP層通過加密與數(shù)據(jù)源認(rèn)證等方式，提供了以下的安全服務(wù)：

• 數(shù)據(jù)機(jī)密性（Confidentiality） IPsec發(fā)送方在通過網(wǎng)絡(luò)傳輸包前對包進(jìn)行加密。

• 數(shù)據(jù)完整性（Data Integrity） IPsec接收方對發(fā)送方發(fā)送來的包進(jìn)行認(rèn)證，以確保數(shù)據(jù)在傳輸過程中沒有被篡改。

• 數(shù)據(jù)來源認(rèn)證（Data Authentication） IPsec在接收端可以認(rèn)證發(fā)送IPsec報(bào)文的發(fā)送端是否合法。

• 防重放（Anti-Replay） IPsec接收方可檢測并拒絕接收過時或重復(fù)的報(bào)文。

2.10.2. 優(yōu)點(diǎn)

IPsec具有以下優(yōu)點(diǎn)：

• 支持IKE（Internet Key Exchange，因特網(wǎng)密鑰交換），可實(shí)現(xiàn)密鑰的自動協(xié)商功能，減少了密鑰協(xié)商的開銷?？梢酝ㄟ^IKE建立和維護(hù)SA的服務(wù)，簡化了IPsec的使用和管理。

• 所有使用IP協(xié)議進(jìn)行數(shù)據(jù)傳輸?shù)膽?yīng)用系統(tǒng)和服務(wù)都可以使用IPsec，而不必對這些應(yīng)用系統(tǒng)和服務(wù)本身做任何修改。

• 對數(shù)據(jù)的加密是以數(shù)據(jù)包為單位的，而不是以整個數(shù)據(jù)流為單位，這不僅靈活而且有助于進(jìn)一步提高IP數(shù)據(jù)包的安全性，可以有效防范網(wǎng)絡(luò)攻擊。

2.10.3. 構(gòu)成

IPsec由四部分內(nèi)容構(gòu)成：

• 負(fù)責(zé)密鑰管理的Internet密鑰交換協(xié)議IKE（Internet Key Exchange Protocol）

• 負(fù)責(zé)將安全服務(wù)與使用該服務(wù)的通信流相聯(lián)系的安全關(guān)聯(lián)SA（Security Associations）

• 直接操作數(shù)據(jù)包的認(rèn)證頭協(xié)議AH（IP Authentication Header）和安全載荷協(xié)議ESP（IP Encapsulating Security Payload）

• 若干用于加密和認(rèn)證的算法

2.10.4. 安全聯(lián)盟（Security Association，SA）

IPsec在兩個端點(diǎn)之間提供安全通信，端點(diǎn)被稱為IPsec對等體。

SA是IPsec的基礎(chǔ)，也是IPsec的本質(zhì)。SA是通信對等體間對某些要素的約定，例如，使用哪種協(xié)議（AH、ESP還是兩者結(jié)合使用）、協(xié)議的封裝模式（傳輸模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保護(hù)數(shù)據(jù)的共享密鑰以及密鑰的生存周期等。建立SA的方式有手工配置和IKE自動協(xié)商兩種。

SA是單向的，在兩個對等體之間的雙向通信，最少需要兩個SA來分別對兩個方向的數(shù)據(jù)流進(jìn)行安全保護(hù)。同時，如果兩個對等體希望同時使用AH和ESP來進(jìn)行安全通信，則每個對等體都會針對每一種協(xié)議來構(gòu)建一個獨(dú)立的SA。

SA由一個三元組來唯一標(biāo)識，這個三元組包括SPI（Security Parameter Index，安全參數(shù)索引）、目的IP地址、安全協(xié)議號（AH或ESP）。

SPI是用于唯一標(biāo)識SA的一個32比特?cái)?shù)值，它在AH和ESP頭中傳輸。在手工配置SA時，需要手工指定SPI的取值。使用IKE協(xié)商產(chǎn)生SA時，SPI將隨機(jī)生成。

2.10.5. IKE

IKE（RFC2407，RFC2408、RFC2409）屬于一種混合型協(xié)議，由Internet安全關(guān)聯(lián)和密鑰管理協(xié)議（ISAKMP）和兩種密鑰交換協(xié)議OAKLEY與SKEME組成。IKE創(chuàng)建在由ISAKMP定義的框架上，沿用了OAKLEY的密鑰交換模式以及SKEME的共享和密鑰更新技術(shù)，還定義了它自己的兩種密鑰交換方式。

IKE使用了兩個階段的ISAKMP：

第一階段，協(xié)商創(chuàng)建一個通信信道（IKE SA），并對該信道進(jìn)行驗(yàn)證，為雙方進(jìn)一步的IKE通信提供機(jī)密性、消息完整性以及消息源驗(yàn)證服務(wù)； 第二階段，使用已建立的IKE SA建立IPsec SA（V2中叫Child SA）。

2.11. Wi-Fi

2.11.1. 簡介

Wi-Fi又稱“無線熱點(diǎn)”或“無線網(wǎng)絡(luò)”，是Wi-Fi聯(lián)盟的商標(biāo)，一個基于IEEE 802.11標(biāo)準(zhǔn)的無線局域網(wǎng)技術(shù)。

2.11.2. 攻擊

2.11.2.1. 暴力破解

WiFi密碼是基于預(yù)置的秘鑰，可以通過抓取報(bào)文的方式在本地快速的批量進(jìn)行密碼爆破嘗試。

2.11.2.2. 偽造熱點(diǎn)

AP可以動態(tài)的廣播自己，客戶也可以主動發(fā)送探針請求?？梢詡卧霢P發(fā)送對探針請求的響應(yīng)包，來讓客戶端錯誤的識別。

2.11.2.3. 秘鑰重裝攻擊

該漏洞由Vanhoef發(fā)現(xiàn)。Wi-Fi在握手時雙方會更新秘鑰，該攻擊通過重放握手信息，令客戶端重新安裝相同的秘鑰。

2.11.2.4. Dragonblood

最新版的WPA3標(biāo)準(zhǔn)在實(shí)現(xiàn)上存在一些問題，同樣由Vanhoef發(fā)現(xiàn)。包含拒絕服務(wù)攻擊、降級攻擊、側(cè)信道泄露等。

2.11.3. 參考鏈接

• Wi-Fi Alliance

• Dragonblood : Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd

• Improving Privacy through Fast Passive Wi-Fi Scanning

• Practical Side-Channel Attacks against WPA-TKIP

• Key Reinstallation Attacks: Breaking the WPA2 Protocol

• RFC 7664 Dragonfly Key Exchange