X-Forwarded-For

X-Forwarded-ForXFF)是用來辨識通過HTTP代理負載均衡方式連接到Web伺服器的客戶端最原始的IP位址HTTP頭欄位Squid快取代理伺服器的開發人員最早引入了這一HTTP頭欄位,並由IETF在HTTP頭欄位標準化草案[1]中正式提出。

當今多數快取伺服器的使用者為大型ISP,為了通過快取的方式來降低他們的外部頻寬,他們常常通過鼓勵或強制使用者使用代理伺服器來接入網際網路。有些情況下,這些代理伺服器是透明代理,使用者甚至不知道自己正在使用代理上網。

如果沒有XFF或者其他類似技術,所有通過代理伺服器的連接只會顯示代理伺服器的IP位址,而非連接發起的原始IP位址,這樣的代理伺服器實際上充當了匿名服務提供者的角色,如果連接的原始IP位址不可得,惡意訪問的檢測與預防的難度將大大增加。XFF的有效性依賴於代理伺服器提供的連接原始IP位址的真實性,因此,XFF的有效使用應該保證代理伺服器是可信的,比如可以通過建立可信伺服器白名單的方式。

格式

這一HTTP頭一般格式如下:

X-Forwarded-For: client1, proxy1, proxy2

其中的值通過一個 逗號+空格 把多個IP位址區分開, 最左邊(client1)是最原始客戶端的IP位址, 代理伺服器每成功收到一個請求,就把請求來源IP位址添加到右邊。 在上面這個例子中,這個請求成功通過了三台代理伺服器:proxy1、proxy2和proxy3。請求由client1發出,到達了proxy3(proxy3可能是請求的終點)。請求剛從client1中發出時,XFF是空的,請求被發往proxy1;通過proxy1的時候,client1被添加到XFF中,之後請求被發往proxy2;通過proxy2的時候,proxy1被添加到XFF中,之後請求被發往proxy3;通過proxy3時,proxy2被添加到XFF中,之後請求的的去向不明,如果proxy3不是請求終點,請求會被繼續轉發。

鑑於偽造這一欄位非常容易,應該謹慎使用X-Forwarded-For欄位。正常情況下XFF中最後一個IP位址是最後一個代理伺服器的IP位址, 這通常是一個比較可靠的資訊來源。

使用

代理轉發反向代理中經常使用X-Forwarded-For欄位。

代理轉發

代理轉發的場景中,你可以通過內部代理鏈以及記錄在閘道器裝置上的IP位址追蹤到網路中客戶端的IP位址。處於安全考慮,閘道器裝置在把請求傳送到外網(網際網路)前,應該去除X-Forwarded-For欄位里的所有資訊。這種情況下所有的資訊都表現為從內部網路公共IP生成,因此X-Forwarded-For欄位中的資訊應該是可靠的。

反向代理

反向代理的情況下,你可以追蹤到網際網路上連接到你的伺服器的客戶端的IP位址,即使你的網路伺服器和網際網路在路由上是不可達的。這種情況下你不應該信任所有X-Forwarded-For資訊,其中有部分可能是偽造的。因此需要建立一個信任白名單來確保X-Forwarded-For中哪些IP位址對你是可信的。

最後一次代理伺服器的位址並沒有記錄在代理鏈中,因此只記錄X-Forwarded-For欄位是不夠的。完整起見,Web伺服器應該記錄請求來源的IP位址以及X-Forwarded-For欄位資訊。

Web伺服器紀錄檔中的X-Forwarded-For

大多數Web伺服器可以通過組態在紀錄檔中記錄X-Forwarded-For。Apache中可以非常簡單地修改組態來實現,但MS IIS 6及以下的版本需要第三方軟體支援來實現。[2]IIS7使用者可以從IIS.net獲得免費的IIS相關組件來實現。[3]

參見

參照

  1. ^ draft-petersson-forwarded-for-02 - Forwarded HTTP Extension. [2015-10-31]. (原始內容存檔於2019-12-20). 
  2. ^ Winfrasoft X-Forwarded-For for IIS頁面存檔備份,存於網際網路檔案館) 是一個通過添加XFF資訊替換C-IP資訊的IIS 外掛程式。
  3. ^ blogs.iis.net. [2011-12-01]. (原始內容存檔於2015-03-26). 

外部連結