引言 對
IP地址盜用
的解決方案絕大多數都是采取MAC與IP地址綁定策略
這種做法是十分危險的
本文將就這個問題進行探討
在這裡需要聲明的是
本文是處於對對MAC與IP地址綁定策略安全的憂慮
不帶有任何黑客性質
為什麼要綁定MAC與IP 地址
影響網絡安全的因素很多
IP地址盜用或地址欺騙就是其中一個常見且危害極大的因素
現實中
許多網絡應用是基於IP的
比如流量統計
賬號控制等都將IP地址作為標志用戶的一個重要的參數
如果有人盜用了合法地址並偽裝成合法用戶
網絡上傳輸的數據就可能被破壞
竊聽
甚至盜用
造成無法彌補的損失
盜用外部網絡的IP地址比較困難
因為路由器等網絡互連設備一般都會設置通過各個端口的IP地址范圍
不屬於該IP地址范圍的報文將無法通過這些互連設備
但如果盜用的是Ethernet內部合法用戶的IP地址
這種網絡互連設備顯然無能為力了
道高一尺
魔高一丈
對於Ethernet內部的IP地址被盜用
當然也有相應的解決辦法
綁定MAC地址與IP地址就是防止內部IP盜用的一個常用的
簡單的
有效的措施
MAC與IP 地址綁定原理
IP地址的修改非常容易
而MAC地址存儲在網卡的EEPROM中
而且網卡的MAC地址是唯一確定的
因此
為了防止內部人員進行非法IP盜用（例如盜用權限更高人員的IP地址
以獲得權限外的信息）
可以將內部網絡的IP地址與MAC地址綁定
盜用者即使修改了IP地址
也因MAC地址不匹配而盜用失敗
而且由於網卡MAC地址的唯一確定性
可以根據MAC地址查出使用該MAC地址的網卡
進而查出非法盜用者
目前
很多單位的內部網絡
尤其是學校校園網都采用了MAC地址與IP地址的綁定技術
許多防火牆（硬件防火牆和軟件防火牆）為了防止網絡內部的IP地址被盜用
也都內置了MAC地址與IP地址的綁定功能
從表面上看來
綁定MAC地址和IP地址可以防止內部IP地址被盜用
但實際上由於各層協議以及網卡驅動等實現技術
MAC地址與IP地址的綁定存在很大的缺陷
並不能真正防止內部IP地址被盜用
破解MAC與IP地址綁定策略 IP地址和MAC地址簡介
現行的TCP/IP網絡是一個四層協議結構
從下往上依次為鏈路層
網絡層
傳輸層和應用層
Ethernet協議是鏈路層協議
使用的地址是MAC地址
MAC地址是Ethernet網卡在Ethernet中的硬件標志
網卡生產時將其存於網卡的EEPROM中
網卡的MAC地址各不相同
MAC地址可以唯一標志一塊網卡
在Ethernet上傳輸的每個報文都含有發送該報文的網卡的MAC地址
Ethernet根據Ethernet報文頭中的源MAC地址和目的MAC來識別報文的發送端和接收端
IP協議應用於網絡層
使用的地址為IP地址
使用IP協議進行通訊
每個IP報文頭中必須含有源IP和目的IP地址
用以標志該IP報文的發送端和接收端
在Ethernet上使用IP協議傳輸報文時
IP報文作為Ethernet報文的數據
IP地址對於Ethernet交換機或處理器是透明的
用戶可以根據實際網絡的需要為網卡配置一個或多個IP地址
MAC地址和IP地址之間並不存在一一對應的關系
MAC地址存儲在網卡的EEPROM中並且唯一確定
但網卡驅動在發送Ethernet報文時
並不從EEPROM中讀取MAC地址
而是在內存中來建立一塊緩存區
Ethernet報文從中讀取源MAC地址
而且
用戶可以通過操作系統修改實際發送的Ethernet報文中的源MAC地址
既然MAC地址可以修改
那麼MAC地址與IP地址的綁定也就失去了它原有的意義
破解方案
下圖是破解試驗的結構示意圖
其內部服務器和外部服務器都提供Web服務
防火牆中實現了MAC地址和IP地址的綁定
報文中的源MAC地址與
P地址對如果無法與防火牆中設置的MAC地址與
P地址對匹配
將無法通過防火牆
主機
和內部服務器都是內部網絡中的合法機器
主機
是為了做實驗而新加入的機器
安裝的操作系統是W
企業版
網卡是
Com的
試驗需要修改主機
中網卡的MAC和IP地址為被盜用設備的MAC和IP地址
首先
在控制面板中選擇
網絡和撥號連接
選中對應的網卡並點擊鼠標右鍵
選擇屬性
在屬性頁的
常規
頁中點擊
配置
按鈕
在配置屬性頁中選擇
高級
再在
屬性
欄中選擇
Network Address
在
值
欄中選中輸人框
然後在輸人框中輸人被盜用設備的MAC地址
MAC地址就修改成功了
然後再將IP地址配置成被盜用設備的IP地址
盜用內部客戶機IP地址
將主機
的MAC地址和IP地址分別修改為主機
的MAC地址和IP地址
主機
可以訪問外部服務器
能夠順利地通過防火牆
訪問權限與主機
沒有分別
而且
與此同時主機
也可以正常地訪問外部服務器
完全不受主機
的影響
無論是主機
還是防火牆都察覺不到主機
的存在
主機
如果訪問內部服務器
根本無需通過防火牆
更是暢通無阻了
盜用內部服務器IP地址
將主機
的MAC地址和U地址修改為內部服務器的MAC地址和IP地址
主機
也提供Web服務
為了使效果更明顯
主機
上提供的Web服務內容與內部服務器提供的內容不同
因為在實際的實驗中主機
與主機
連在同一個HUB上
主機
的訪問請求總是先被主機
響應
主機
期望訪問的是內部服務器
得到的卻總是主機
提供的內容
更一般地
主機
如果試圖訪問內部服務器
獲得的到底是主機
提供的內容還是內部服務器提供的內容具有隨機性
要看它的訪問請求首先被誰響應
在後面的分析中我們將進一步對此進行闡述
盜用服務器的MAC和IP危害可能更大
如果主機
提供的Web內容和內部服務器中的內容一樣
那麼主機
將無法識別它訪問的到底是哪個機器
如果Web內容中要求輸人賬號
密碼等信息
那麼這些信息對於主機
來說則是一覽無遺了
破解成功的原因 上面的實驗驗證了綁定MAC地址與IP地址的確存在很大的缺陷
無法有效地防止內部IP地址被盜用
接下來
將從理論上對該缺陷進行詳細的分析
缺陷存在的前提是網卡的混雜接收模式
所謂混雜接收模式是指網卡可以接收網絡上傳輸的所有報文
無論其目的MAC地址是否為該網卡的MAC地址
正是由於網卡支持混雜模式
才使網卡驅動程序支持MAC地址的修改成為可能
否則
就算修改了MAC地址
但是網卡根本無法接收相應地址的報文
該網卡就變得只能發送
無法接收
通信也就無法正常進行了
MAC地址可以被盜用的直接原因是網卡驅動程序發送Ethernet報文的實現機制
Ethernet報文中的源MAC地址是驅動程序負責填寫的
但驅動程序並不從網卡的EEPROM中讀取MAC
而是在內存中建立一個MAC地址緩存區
網卡初始化的時候將EEPROM中的內容讀入到該緩存區
如果將該緩存區中的內容修改為用戶設置的MAC地址
以後發出去的Ethernet報文的源地址就是修改後的MAC地址了
如果僅僅是修改MAC地址
地址盜用並不見得能夠得逞
Ethernet是基於廣播的
Ethernet網卡都能監聽到局域網中傳輸的所有報文
但是網卡只接收那些目的地址與自己的MAC地址相匹配的Ethernet報文
如果有兩台具有相同MAC地址的主機分別發出訪問請求
而這兩個訪問請求的響應報文對於這兩台主機都是匹配的
那麼這兩台主機就不只接收到自己需要的內容
而且還會接收到目的為另外一台同MAC主機的內容
按理說
兩台主機因為接收了多余的報文後
都應該無法正常工作
盜用馬上就會被察覺
盜用也就無法繼續了
但是
在實驗中地址被盜用之後
各台實驗設備都可以互不干擾的正常工作
這又是什麼原因呢？答案應該歸結於上層使用的協議
目前
網絡中最常用的協議是TCP/IP協議
網絡應用程序一般都是運行在TCP或者UDP之上
例如
實驗中Web服務器采用的HTTP協議就是基於TCP的
在TCP或者UDP中
標志通信雙方的不僅僅是IP地址
還包括端口號
在一般的應用中
用戶端的端口號並不是預先設置的
而是協議根據一定的規則生成的
具有隨機性
像上面利用IE來訪問Web服務器就是這樣
UDP或者TCP的端口號為
位二進制數
兩個
位的隨機數字相等的幾率非常小
恰好相等又談何容易？兩台主機雖然MAC地址和IP地址相同
但是應用端口號不同
接收到的多余數據由於在TCP/UDP層找不到匹配的端口號
被當成無用的數據簡單地丟棄了
而TCP/UDP層的處理對於用戶層來說是透明的
所以用戶可以
正確無誤
地正常使用相應的服務
而不受地址盜用的干擾
當然
某些應用程序的用戶端口號可能是用戶或者應用程序自己設置的
而不是交給協議來隨機的生成
那麼
結果又會如何呢？例如
在兩台MAC地址和IP地址都相同的主機上
啟動了兩個端口相同的應用程序
這兩個應用是不是就無法正常工作了呢？其實不盡然
如果下層使用的是UDP協議
兩個應用將互相干擾無法正常工作
如果使用的是TCP協議
結果就不一樣了
因為TCP是面向連接的
為了實現重發機制
保證數據的正確傳輸
TCP引入了報文序列號和接收窗口的概念
在上述的端口號匹配的報文中
只有那些序列號的偏差屬於接收窗口之內的報文才會被接收
否則
會被認為是過期報文而丟棄
TCP協議中的報文的序列號有
位
每個應用程序發送的第一個報文的序列號是嚴格按照隨機的原則產生的
以後每個報文的序列號依次加
窗口的大小有
位
也就是說窗口最大可以是
而序列號的范圍是
主機期望接收的TCP數據的序列號正好也處於對方的接收范圍之內的概率為
/
可謂小之又小
TCP的序列號本來是為了實現報文的正確傳輸
現在卻成了地址盜用的幫凶
解決MAC與IP地址綁定被破解的方法 解決MAC與IP地址綁定被破解的方法很多
主要以下幾種
交換機端口
MAC地址和IP地址三者綁定的方法
代理服務與防火牆相
From:http://tw.wingwit.com/Article/os/fwq/201311/29840.html
