狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

最近剛好看到一段視頻，講述關于 IP 偽造的內容。視頻中并沒有具體描述如何進行的 IP 偽造。借此機會，小黑屋來嘮嘮偽造 IP 的幾種常見方式。

方式1: X-Forwarded-For

這個是最為認知的 IP 偽造方法，早年的 CTF 題目也經常涉及，然而現在知道的人太多， CTF 都不屑于出這類題目。 X-Forwarded-For 誕生的原因比較簡單粗暴。 對于一個非常簡單的網絡模型， 一個網絡請求通常只有兩方，即請求方與被請求方，如下所示。這樣的網絡模型下， Web Server 是可以拿到 User 的真實 IP 地址的，即使拿到的可能是路由器的地址。

User --> Web Server

但是上了規模的網站，其網絡模型不會這么簡單，它可能長這樣：

User --> CDN --> Web Server

在這種場景下， CDN 依舊可以拿到 User 的真實 IP 地址，然而 Web Server 卻無法直接拿到。 為了解決這個問題， 有人提出了 X-Forwarded-For， 它作為 HTTP Header 傳遞給后端的 Web Server，其格式如下：

X-Forwarded-For: <client>, <proxy1>, <proxy2>

假設 User 的真實 IP 地址是 1.0.0.1， CDN 節點的 IP 地址是 2.0.0.2，那么 CDN 會在 HTTP 請求頭里附加下面的 Header，通知 Web Server 用戶的真實 IP 地址。 Web Server 根據這個 Header 解析出 User 的 IP。

X-Forwarded-For: 1.0.0.1, 2.0.0.2

細心的朋友可能會發現， 我是不是可以直接將 1.0.0.1 改成任意 IP 地址，然后直接將請求發送給 Web Server？沒錯，這就是非常簡單的 X-Forwarded-For IP 偽造攻擊。一般這類問題的解決思路是，校驗 4 層協議的來源 IP，判斷是否為可信 IP，比如是否為 CDN 的 IP。如果可信，才會嘗試解析 X-Fowarded-For Header。

方式2: Proxy Protocol

眼尖的朋友可能已經注意到了，X-Forwarded-For 只支持 HTTP 協議，那么 TCP 或者其它 4 層協議怎么辦？這時候 Proxy Protocol 應運而生了。它最早于 2010 年被提出，并首先運用于 HAProxy 。 由于 Proxy Protocol 解決了實際應用中的痛點，越來越多的開源軟件（如 NGINX）， CDN 廠商（如 Cloudflare 和 Cloudfront 等）已經支持 Proxy Protocol 了。 

目前 Proxy Protocol 共有兩個版本，分別為 v1 和 v2。

Proxy Protocol v1 協議非常簡單易懂。由于本文只是介紹，不會寫過多的技術細節，力求用最簡單的言語讓讀者知道它是怎么工作的。我們假定網絡模型如下所示：

User --> Load Balancer --> TCP Server

V1 的原理說起來也非常簡單， 當用戶與 Load Balancer 的 4 層鏈接建立后（可能是 TCP ，也可能是 UDP）， Load Balancer 是知道用戶的真實 IP 的。 Load Balancer 在和 TCP Server 建立 4 層鏈接后，不會直接透傳用戶的請求，而是提前發一個 Proxy Protocol V1 的 header。 這個 Header 具體長這樣

PROXY TCP4 1.0.0.1 2.0.0.2 1001 2002\r\n

其中：

• PROXY 表示當前是一個4層代理請求

• TCP4 表示 User 使用 TCP v4 與 Load Balancer 建立的 4 層鏈路

• 1.0.0.1 為 User 的 IP， 2.0.0.2 為目標 IP

• 1001 為 User 的端口， 2002 為目標端口

當 V1 header 發送到 TCP Server 后， Load Balancer 才會開始透傳 TCP 請求。而 TCP Server 需要做一些調整，解析完 Header 后，才開始進行業務邏輯。 幸運的是，目前許多 Server，包含 NGINX，已經支持了 V1 header 的解析，改改配置即可。

類似的， Proxy Protocol 也有 IP 偽造問題。攻擊者是可以直接構造一個 V1 header， 直接發送給 TCP Server 的，造成 TCP 來源 IP 地址偽造問題。

Proxy Protocl V2 版本實際上是針對 V1 版本的升級優化。 V1 版本是一個純文本協議，其最大的缺點是 Header 占用的字節太多了，比如上面的例子中就占用了 38 個字節。然而 Header 是給機器看的，又不是給人看的，可讀性這么高有卵用？ 因此，V2 實際上是將 V1 升級成了一個二進制版本。它的構造相對來說沒那么直觀。以 IPv4 版本為例，其格式如下：

V2 Header 在 IPv4 版本中， 只固定占用了 28 字節， 比 V1 版本少了約 10 字節（此處注意是“約”， v1 版本是變長的）。

Proxy Protocol V2 本質上只是變更了 Header 的編碼方式，還是存在 IP 地址偽造問題。

方式3: TOA (TCP Option Address)

相比前兩種協議，TOA 的知名度并沒有那么高。 TOA 的原理是利用 TCP 協議中的一個未使用字段。 講述原理之前，先回顧一下 TCP Header 的格式：

可以看到， TCP Header 中是有一個叫 Options 的 Segment 的。 TOA 正是利用這個 Options 。Load Balancer 在接收到用戶的請求后，會將用戶的 IP 信息塞到 Options 里，其格式如下：

struct toa_data {
  __u8 opcode;
  __u8 opsize;
  __u16 port;
  __u32 ip;
};

TOA 最大的優勢在于，其并沒有變更協議，不會有兼容性問題。比如 TCP Server 如果不支持 TOA 協議，它依舊可以正常工作，只是獲取不到真實的用戶 IP 信息。

TOA 也好， Proxy Protocol 也罷，他們的本質都是 Load Balancer 主動將用戶 IP 信息傳遞給 TCP Server。因此， TOA 協議也是有 IP 偽造問題的。在和 TCP Server 建立連接的階段，我們可以將偽造的 IP 地址塞到 Options 里。

寫在最后

以上就是小黑屋總結的 IP 偽造技術。真實世界上，偽造來源 IP 的技術肯定不止這些， 小黑屋只是拋磚引玉。

另外這類 IP 偽造問題的根因都是相似的，即后端服務無條件地信任了別人傳遞過來的 IP 信息。 解決方式說起來也簡單，即判斷上一條 IP 是否是可信的，如果不在可信名單里，則停止解析這些 IP 信息。具體做法可閱讀 Gin 框架的代碼。