X-Forwarded-For的一些理解
X-Forwarded-For 是一個 HTTP 擴充套件頭部,主要是為了讓 Web 伺服器獲取訪問使用者的真實 IP 地址(其實這個真實未必是真實的,後面會說到)。
那為什麼 Web 伺服器只有通過 X-Forwarded-For 頭才能獲取真實的 IP?
這裡用 PHP 語言來說明,不明白原理的開發者為了獲取客戶 IP,會使用 $_SERVER['REMOTE_ADDR'] 變數,這個伺服器變量表示和 Web 伺服器握手的 IP 是什麼(這個不能偽造)。
但是很多使用者都通過代理來訪問伺服器的,那麼假如使用該全域性變數,PHP獲取到的 IP 就是代理伺服器的 IP(不是使用者的)。
可能很多人看的暈乎乎的,那麼看看一個請求可能經過的路徑:
客戶端=>(正向代理=>透明代理=>伺服器反向代理=>)Web伺服器
其中正向代理、透明代理、伺服器反向代理這三個環節並不一定存在。
- 什麼是正向代理呢,很多企業會在自己的出口閘道器上設定代理(主要是為了加速和節省流量)。
- 透明代理可能是使用者自己設定的代理(比如為了FQ,這樣也繞開了公司的正向代理)。
- 伺服器反向代理是部署在 Web 伺服器前面的,主要原因是為了負載均衡和安全考慮。
現在假設幾種情況:
- 假如客戶端直接連線 Web 伺服器(假設 Web 伺服器有公網地址),則 $_SERVER['REMOTE_ADDR'] 獲取到的是客戶端的真實 IP 。
- 假設 Web 伺服器前部署了反向代理(比如 Nginx),則 $_SERVER['REMOTE_ADDR'] 獲取到的是反向代理裝置的 IP(Nginx)。
- 假設客戶端通過正向代理直接連線 Web 伺服器(假設 Web 伺服器有公網地址),則 $_SERVER['REMOTE_ADDR'] 獲取到的正向代理裝置的 IP 。
其實這裡的知識點很多,記住一點就行了,$_SERVER['REMOTE_ADDR'] 獲取到的 IP 是 Web 伺服器 TCP 連線的 IP(這個不能偽造,一般 Web 伺服器也不會修改這個頭)。
X-Forwarded-For
從上面大家也看出來了,因為有了各種代理,才會導致 REMOTE_ADDR 這個全域性變數產生了一定的歧義,為了讓 Web 伺服器獲取到真實的客戶端 IP,X-Forwarded-For 出現了,這個協議頭也是由 Squid 起草的(Squid 應該是最早的代理軟體之一)。
這個協議頭的格式:
X-Forwarded-For: client, proxy1, proxy2
client 表示使用者的真實 IP,每經過一次代理伺服器,代理伺服器會在這個頭增加使用者的 IP(有點拗口)。
注意最後一個代理伺服器請求 Web 伺服器的時候是不會將自己的 IP 附加到 X-Forwarded-For 頭上的,最後一個代理伺服器的 IP 地址應該通過$_SERVER['REMOTE_ADDR']獲取。
舉個例子:
使用者的 IP 為(A),分別經過兩個代理伺服器(B,C),最後到達 Web 伺服器,那麼Web 伺服器接收到的 X-Forwarded-For 就是 A,B。
那麼 PHP 如何獲取真實客戶端 IP 呢?
$ip = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? trim($_SERVER['HTTP_X_FORWARDED_FOR']) : '';
if (!$ip) {
$ip = isset($_SERVER['REMOTE_ADDR']) ? trim($_SERVER['REMOTE_ADDR']) : '';
}
$a = explode('|', str_replace(',', '|', $ip));
$ip = trim($a[0]);
這裡預先說明下,假設這兩個代理伺服器都是好的代理伺服器,沒有偽造 HTTP_X_FORWARDED_FOR。
配置反向代理
上面一直在說代理,大家可能覺得這到底有啥用?不同型別的代理有不同的目的,對於正向代理來說主要是為了加速並且讓區域網的使用者有一個真實的 IP 地址,而透明代理則主要是為了一些其他的目的(比如就是不想讓別人知道我的 IP),而反向代理主要是企業內部安全和負載均衡考慮,這裡主要說下如何配置反向代理。
現在只要是具備一定規模的網站(Web 伺服器大於 1 臺),為了安全和負載均衡考慮都會在 Web 伺服器前面部署反向代理,反向代理有 HAproxy,Nginx,Apache 等等。
這裡通過 Nginx 來部署反向代理:
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
簡單的解釋下:
- X-Forwarded-For 表示 Nginx 接收到的頭,原樣的轉發過來(假如不轉發,Web 伺服器就不能獲取這個頭)。
- X-Real-IP,這是一個內部協議頭(就是反向代理伺服器和 Web 伺服器約定的),這個頭表示連線反向代理伺服器的 IP 地址(這個地址不能偽造),其實個人覺得為了讓 PHP 程式碼保持無二義性,不應該這樣設定,可以修改為
proxy_set_header REMOTE_ADDR $remote_addr;
Apache WEB 伺服器的 Access 日誌如何獲取 X-Forwarded-For 頭
其實寫這篇文章主要是因為自己在 Apache Web 伺服器上獲取不到 X-Forwarded-For(上層的負載均衡裝置確定傳遞了),搜尋了下(在 Apache 官方文件並沒有找到解決方案),解決如下:
LogFormat "%{X-Forwarded-For}i %a %h %A %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combined
X-Forwarded-For 安全性
那麼很多同學會說,通過 X-Forwarded-For 就能獲取到使用者的真實 IP,是不是萬事大吉了,對於 Web 伺服器來說,安全有兩個緯度,第一個緯度是 REMOTE_ADDR 這個頭,這個頭不能偽造。第二個緯度就是 X-Forwarded-For,但是這個頭是可以偽造的。
那麼誰在偽造呢?,我們分別看下:
正向代理一般是公司加速使用的,假如沒有特殊的目的,不應該傳遞 X-Forwarded-For 頭,因為它的上層連線是內部 IP,不應該暴露出去,當然它也可以透明的傳遞這個頭的值(而這個值使用者可以偽造)。
透明代理,這個可能是使用者自己搭建的(比如FQ),而且在一個使用者的請求中,可能有多個透明代理,這時候透明代理就抓瞎了,為了讓自己儘量的正確,也會透明的傳遞這個頭的值(而這個值使用者可以偽造),當然一些不法企業或者人員,為了一些目的,會改下這個頭的值(比如來自世界各地的 IP 地址)。
反向代理,Web 伺服器前的反向代理伺服器是不會偽造的(同一個公司的),一般會原樣傳遞這個頭的值。
那麼對應用程式來說,既然這個值不能完全相信,該怎麼辦呢?這取決於應用的性質:
假如提供的服務可能就是一些非機密服務,也不需要知道使用者的真實 IP,那麼建議應用程式或者 Web 伺服器對 REMOTE_ADDR 做一些限制,比如進行限速等等,也可以放行一些白名單的代理 IP,但是這些白名單 IP 就太難衡量了。
假設你的服務很重要,比如抽獎(一個 IP 只能一次抽獎),這時候你可能想通過 X-Forwarded-For 來獲取使用者的真實 IP(假如使用 REMOTE_ADDR 則會誤殺一片),但是由於 X-Forwarded-For 可能會偽造,所以其實並沒有什麼好的辦法,只能在應用層進行處理了。