當前位置:
首頁 > 新聞 > 獲取來源IP地址的正確姿勢

獲取來源IP地址的正確姿勢

*本文原創作者:戒賢,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載


背景



筆者從去年6月份開始研究IP地址,陸續踩了很多很多坑,也結識了一大批同行業的前輩。

我能說我是這個圈子裡年齡最小的么…..我一直在承受我這個年紀不該有的智慧和經歷。


關於IP地址的研究,此前我寫過一個完整的系列,先後被未央網、雷鋒網和先知社區轉載。如果你想看的話,可以戳這裡:反欺詐專欄


我們首次建模完成之後,迫不及待地讓同事幫忙把數據提取出來,進行人工審核評估,卻發現結果中有很多很多保留IP,心裡哇涼

哇涼的。每次和客戶對接,我都花很長的時間跟對方的技術人員解釋如何正確地獲取來源IP地址,但是每家公司的情況都有所差別,沒有一個標準方法。也有一些公司,由於相關的代碼已經存在了很久,沒有人維護,而業務系統的架構已經變更了多次,原有的代碼,獲取出來的IP都是錯的。


想像一下,每天都有人在問你:127.0.0.1這個IP是啥?這個IP怎麼發了那麼多請求?這是不是個基站?還是伺服器IP?難不成是代理?還是我們被攻擊了?誒你說話啊?


關於保留IP


下面是從維基百科上摘錄的保留IP地址段,共計16個(最後兩個段一般會合併,也可以認為是15個)。
























































































保留地址段 地址起始 IP地址數量 用途
0.0.0.0/8 0.0.0.0 – 0.255.255.255 16,777,216 軟體
10.0.0.0/8 10.0.0.0 – 10.255.255.255 16,777,216 內網
100.64.0.0/10 100.64.0.0 – 100.127.255.255 4,194,304 內網
127.0.0.0/8 127.0.0.0 – 127.255.255.255 16,777,216 主機(本機)
169.254.0.0/16 169.254.0.0 – 169.254.255.255 65,536 本地子網(DHCP Failed)
172.16.0.0/12 172.16.0.0 – 172.31.255.255 1,048,576 內網
192.0.0.0/24 192.0.0.0 – 192.0.0.255 256 內網
192.0.2.0/24 192.0.2.0 – 192.0.2.255 256 「TEST-NET」
192.88.99.0/24 192.88.99.0 – 192.88.99.255 256 6to4 anycast
192.168.0.0/16 192.168.0.0 - 192.168.255.255 65,536 內網
198.18.0.0/15 198.18.0.0 – 198.19.255.255 131,072 內網
198.51.100.0/24 198.51.100.0 – 198.51.100.255 256 「TEST-NET-2」
203.0.113.0/24 203.0.113.0 – 203.0.113.255 256 「TEST-NET-3」
224.0.0.0/4 224.0.0.0 - 239.255.255.255 268,435,455 預留
240.0.0.0/4 240.0.0.0 – 255.255.255.254 268,435,455 預留
255.255.255.255/32 255.255.255.255 1 廣播

我經常拿這個問題去刁難人,能說出三個段的人,至少是具備網路基礎知識的,說出5個以上的,一般我會請他喝酒。


連保留IP是啥都不知道的,我就得嘗試用另外一種方式去跟他解釋這個問題了。


保留IP可以說是TCP/IP協議的約定吧,每一個段都有相應的使用說明,都有與之對應的RFC文檔。


比如,中國境內,移動設備在 4G 環境下獲取到的內網IP,一般是 10.0.0.0/8 或者 

100.64.0.0/10 的。


非物理隔離的網路系統,一般會是用 192.168.0.0/16,

172.16.0.0/12,10.0.0.0/8 內劃分內網地址,比較常見。


據@高春輝說,除了這些之外,還有一些很小的保留 IP 段,如果不詳細去看完整的 whois 數據,可能都不會發現。


聊聊XFF

X-Forwarded-For(XFF)是用來識別通過HTTP代理或負載均衡方式連接到Web伺服器的客戶端最原始的IP地址的HTTP請求頭欄位。 Squid緩存代理伺服器的開發人員最早引入了這一HTTP頭欄位,並由IETF在HTTP頭欄位標準化草案中正式提出。


XFF的工作機制是,每經過一層代理,由代理伺服器,把tcp報文中的Source IP,添加到XFF的末尾,多個IP以逗號分隔。這裡說的代理是廣義的,包括負載均衡(比如阿里雲SLB),反向代理(比如Nginx),緩存伺服器(比如Squid)。


一方面,XFF提供了向後端業務系統傳遞用戶IP的機制,後端業務系統,可以通過XFF感知到訪問者的真實IP。


另一方面,XFF非常易於偽造。很多瀏覽器插件,可以隨機填充XFF欄位,如果沒有一套正確的機制來處理XFF欄位,而盲目地提取XFF中第一個IP作為訪問者的IP,就一定會出問題。


前面提到了,來源IP是保留IP的情況,其實大多數是由於業務系統直接以TCP報文中的remote address作為來源IP使用了。而這個IP,一般是企業自己的反向代理伺服器。


除此之外,XFF偽造的過程中,IP地址是隨機生成的,可能會出線保留IP,非法IP,有少數情況可能會出現「未啟用IP」,也就是說這個IP已經分配給特定的運營商,但是運營商還沒有添加這個IP的路由,這個IP無法被外界訪問,也不會訪問任何人。


這些IP是動態變化的,據老高說,只有分析BGP數據的時候,才能看到哪些IP是沒有被啟用的。


業務系統獲取來源IP的正確姿勢


下面是一個簡單的示意圖,簡單地把整個訪問鏈路劃分成可信區域和不可信區域。

可信區域,就是平台自己,或者友商建立的系統,可以保證從這些系統中獲取並傳遞的數據是真實的、可信的。


獲取來源IP的正確方式,是提取並記錄本次請求首次進入可信區域時的remote address。不論這個IP是不是代理。



XFF偽造的情況其實非常普遍,也陸續地出現了一些替代方案,我司目前使用的,是設置一個專用的欄位來傳遞這個IP,不會和XFF相覆蓋。


此外,某些CDN服務商,會有自己定製化的Header欄位,情況比較多,建議結合具體的情況來決定如何獲取用戶的來源IP。


比如,之前遇到一個客戶,使用了阿里雲的SLB負載均衡,SLB會給每一個請求都加上X-Forwarded-For欄位,他們自己的反向代理又加一次。那麼其實只要獲取XFF中倒數第三個IP,作為來源IP即可。


一種參考方式如下:


在反向代理(Nginx)上配置,增加Real-IP欄位:



業務系統中,獲取來源IP的代碼如下(Java示例):



這個問題實在是簡單到爆炸,懂技術的同學看到,肯定會噴我,居然寫這種沒水平的文章。


但是呢,作為一個數據分析師,看著每天系統里辣么多保留IP,非法IP傳進來,真的很憋屈。體諒下咯~


而且,每每看別人說攻擊溯源….我滿腦子想的都是:你連獲取到的IP是不是真的你都不知道,你在追溯個啥?


By the way,歡迎有興趣深入研究IP地址的童鞋一起交流,沒準能帶你跟老高一塊兒喝羊湯。


*本文原創作者:戒賢,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 FreeBuf 的精彩文章:

無線鍵盤易被監聽,不知不覺導致信息泄露
社交平台上的桃色陷阱:殭屍網路SIREN侵襲Twitter
AlphaBay是怎麼垮掉的?解密全球最大黑市AlphaBay被查封全過程
BadUSB防禦初探
htcap:一款實用的遞歸型Web漏洞掃描工具

TAG:FreeBuf |

您可能感興趣

可佩戴式設備逐漸成新趨勢 或取代iPhone成為蘋果最重要營收來源
Google 搜索結果頁面有新變化,將比之前更加突出信息來源
搞笑GIF:動力來源於配合,這樣鍛煉就不覺得累了
一水洋裝備!俄軍展示繳獲的敘利亞IS分子武器,來源顯而易見
「魑魅魍魎」的來源和故事,漲姿勢
《GTA5》關於UFO你絕對不知道的細節,一切都來源於現實?
為了定向狙擊爸媽群謠言,whatAPP決定顯示轉發信息來源
作為ADC請不要剝奪輔助的經濟來源,因為他們為了你不容易
準確的斷命,來源於更全面的方法,更豐富的閱歷
原來這些中文常用詞都來源於日本!漲姿勢了
UFO是時代未來人?眾說紛紜的UFO來源之謎
Facebook正在測試一項功能:告知用戶信息來源
沒有鐵血戰士,NASA找到了南極矩形冰山的確切來源
真正的安全感,一向來源於自己
職業選手ID來源出爐,Uzi的名字原來是這樣!
為什麼核聚變可以成為取之不盡的能量來源?
外星來的UFO或許只是個謊言,最早的飛碟可能來源於這裡
LPL你看了多久,你知道LPL里戰隊的來源嗎?
血型有ABO型,為什麼不直接按順序排成ABC?看完才明白O型的來源
Facebook發現用戶更相信有信譽的來源認證