在閱讀本文前，大家要有一個概念，由于TCP需要三次握手連接，在實現正常的TCP/IP 雙方通信情況下，是無法偽造來源 IP 的，也就是說，在 TCP/IP 協議中，可以偽造數據包來源 IP ，但這會讓發送出去的數據包有去無回，無法實現正常的通信。

一些DDoS 攻擊，它們只需要不斷發送數據包，而不需要正常通信，它們就會采取這種“發射出去就不管”的行為來進行攻擊。

那么在HTTP 中， “ 偽造來源 IP”, 又是如何造成的？如何防御之？
先搞明白后端應用IP獲取來源
1.’REMOTE_ADDR’是遠端IP，默認來自tcp連接客戶端的Ip。可以說，它最準確，確定是，只會得到直接連服務器客戶端IP。如果對方通過代理服務器上網，就發現。獲取到的是代理服務器IP了。
如：a→b(proxy)→c ,如果c 通過’REMOTE_ADDR’ ，只能獲取到b的IP,獲取不到a的IP了。
這個值是無法修改的。

2.’HTTP_X_FORWARDED_FOR’，’HTTP_CLIENT_IP’ 為了能在大型網絡中，獲取到最原始用戶IP，或者代理IP地址。對HTTp協議進行擴展。定義了實體頭。
HTTP_X_FORWARDED_FOR = clientip,proxy1,proxy2其中的值通過一個 逗號+空格 把多個IP地址區分開, 最左邊(client1)是最原始客戶端的IP地址, 代理服務器每成功收到一個請求，就把請求來源IP地址添加到右邊。
HTTP_CLIENT_IP 在高級匿名代理中，這個代表了代理服務器IP。
其實這些變量，來自http請求的：X-Forwarded-For字段，以及client-ip字段。 正常代理服務器，當然會按rfc規范來傳入這些值。
但是，攻擊者也可以直接構造該x-forword-for值來“偽造源IP”,并且可以傳入任意格式IP.
這樣結果會帶來2大問題，其一，如果你設置某個頁面，做IP限制。 對方可以容易修改IP不斷請求該頁面。 其二，這類數據你如果直接使用，將帶來SQL注冊，跨站攻擊等漏洞。

這類問題，其實很容易出現，比如很多時候利用這個騙取大量偽裝投票。那么該如何修復呢？
在代理轉發及反向代理中經常使用X-Forwarded-For 字段。
X-Forwarded-For(XFF)的有效性依賴于代理服務器提供的連接原始IP地址的真實性，因此, XFF的有效使用應該保證代理服務器是可信的.
比如Nginx代理服務器，我們可以在其轉發/反向代理的時候主動配置X-Forwarded-For為正確的值。

location / {proxy_pass ....;proxy_set_header X-Forwarded-For $remote_addr ; }

$remote_addr 是 nginx 的內置變量，代表了客戶端真實（網絡傳輸層） IP 。通過此項措施，強行將 X-Forwarded-For 設置為客戶端 ip, 使客戶端無法通過本文所述方式“偽造 IP ”。

如果最前端（與用戶直接通信）代理服務器是與php fastcgi 直接通信，則需要在其上設定：

location ~ \.php$ { fastcgi_pass localhost:9000; fastcgi_param HTTP_X_FORWARD_FOR $remote_addr; }

但是更常用的配置如下：

proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

后臺代碼，通過X-Real-IP頭來獲取客戶真實IP

參考:
http://www.cnblogs.com/chengm...
http://zhangxugg-163-com.itey...
http://blog.csdn.net/lemon_tr...

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的IP伪造与防范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。