獲取來源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原創獎勵計劃,未經許可禁止轉載
※無線鍵盤易被監聽,不知不覺導致信息泄露
※社交平台上的桃色陷阱:殭屍網路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發現用戶更相信有信譽的來源認證