亚洲乱色熟女一区二区三区丝袜,天堂√中文最新版在线,亚洲精品乱码久久久久久蜜桃图片,香蕉久久久久久av成人,欧美丰满熟妇bbb久久久

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

方式1: X-Forwarded-For

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

User --> Web Server

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

User --> CDN --> Web Server

在這種場(chǎng)景下， CDN 依舊可以拿到 User 的真實(shí) IP 地址，然而 Web Server 卻無(wú)法直接拿到。 為了解決這個(gè)問(wèn)題， 有人提出了 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 請(qǐng)求頭里附加下面的 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 地址，然后直接將請(qǐng)求發(fā)送給 Web Server？沒(méi)錯(cuò)，這就是非常簡(jiǎn)單的 X-Forwarded-For IP 偽造攻擊。一般這類問(wèn)題的解決思路是，校驗(yàn) 4 層協(xié)議的來(lái)源 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)，越來(lái)越多的開(kāi)源軟件（如 NGINX）， CDN 廠商（如 Cloudflare 和 Cloudfront 等）已經(jīng)支持 Proxy Protocol 了。 

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

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

User --> Load Balancer --> TCP Server

V1 的原理說(shuō)起來(lái)也非常簡(jiǎn)單， 當(dāng)用戶與 Load Balancer 的 4 層鏈接建立后（可能是 TCP ，也可能是 UDP）， Load Balancer 是知道用戶的真實(shí) IP 的。 Load Balancer 在和 TCP Server 建立 4 層鏈接后，不會(huì)直接透?jìng)饔脩舻恼?qǐng)求，而是提前發(fā)一個(gè) Proxy Protocol V1 的 header。 這個(gè) Header 具體長(zhǎng)這樣

PROXY TCP4 1.0.0.1 2.0.0.2 1001 2002\r\n

其中：

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

• 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ì)開(kāi)始透?jìng)?TCP 請(qǐng)求。而 TCP Server 需要做一些調(diào)整，解析完 Header 后，才開(kāi)始進(jìn)行業(yè)務(wù)邏輯。 幸運(yùn)的是，目前許多 Server，包含 NGINX，已經(jīng)支持了 V1 header 的解析，改改配置即可。

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

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

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

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

方式3: TOA (TCP Option Address)

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

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

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

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

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

寫在最后

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

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