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

方式1: X-Forwarded-For

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

User --> Web Server

但是上了規(guī)模的網(wǎng)站，其網(wǎng)絡(luò)模型不會(huì)這么簡單，它可能長這樣：

User --> CDN --> Web Server

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

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

假設(shè) User 的真實(shí) IP 地址是 1.0.0.1， CDN 節(jié)點(diǎn)的 IP 地址是 2.0.0.2，那么 CDN 會(huì)在 HTTP 請求頭里附加下面的 Header，通知 Web Server 用戶的真實(shí) IP 地址。 Web Server 根據(jù)這個(gè) Header 解析出 User 的 IP。

X-Forwarded-For: 1.0.0.1, 2.0.0.2

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

方式2: Proxy Protocol

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

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

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

User --> Load Balancer --> TCP Server

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

PROXY TCP4 1.0.0.1 2.0.0.2 1001 2002\r\n

其中：

• PROXY 表示當(dāng)前是一個(gè)4層代理請求

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

• 1.0.0.1 為 User 的 IP， 2.0.0.2 為目標(biāo) IP

• 1001 為 User 的端口， 2002 為目標(biāo)端口

當(dāng) V1 header 發(fā)送到 TCP Server 后， Load Balancer 才會(huì)開始透傳 TCP 請求。而 TCP Server 需要做一些調(diào)整，解析完 Header 后，才開始進(jìn)行業(yè)務(wù)邏輯。 幸運(yùn)的是，目前許多 Server，包含 NGINX，已經(jīng)支持了 V1 header 的解析，改改配置即可。

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

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

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

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

方式3: TOA (TCP Option Address)

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

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

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

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

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

寫在最后

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

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