熊熊亂說話

ARP反欺騙策略

創建時間︰2007-11-11
文章屬性︰原創
文章提交︰backspray (nimaozhi_at_163.com)

近來與Arp相關惡意軟體越來越猖獗，受害者的也不少，國內的各大殺毒廠商也紛紛推出Arp防火牆。但大部分防火牆虛有其表，原因下面會具體介紹。 這篇文章不是科普，主要是思路，更想起到拋磚引玉的作用。讓世界清靜一點。此外，末學接觸並熟悉Arp協議到寫出Arp欺騙和反欺騙的test code，前前後後也不過一個星期多一點的時間。經驗有限，疏漏之處，再所難免，各位見諒。
    Arp協議和Arp欺騙這裡就不做介紹了。網路這方面的文章比比皆是。
為了便於理解，下面構造一些名詞︰
假如局域網內，有通訊閘，發起欺騙的主機（以下簡稱欺騙主機），受騙主機
雙向欺騙︰欺騙主機使得通訊閘認為欺騙主機是受騙主機同時讓受騙主機認為欺騙主機是通訊閘；
單向欺騙通訊閘︰欺騙主機只使通訊閘認為欺騙主機是受騙主機；
單向欺騙目標主機︰欺騙主機只使受騙主機認為它是通訊閘；
    Arp除了能sniffer之外，現下比較流行的做法就是利用Arp進行HTTP掛馬的情況了。所以下面考慮的影響基本以這個角度的方面來衡量。
    由於環境不同，繼續往下分，一個機房被Arp欺騙的情，機房一般以伺服器為主，對外發的數據多以http應答包為主，此時單向欺騙目標主機的危害比較大。 另外一個普通的公司，家庭，及網吧之類的局域網環境，對外發的數據多以http請求為主，接收的數據多以http應答包為主，此時單向欺騙通訊閘危害比較 大。
    還有的就是和通訊閘有關了，通訊閘簡單的先分兩種︰
1、支援IP和mac綁定的；
2、不支援IP和mac綁定。
支援IP和mac綁定的通訊閘都好辦，所以這裡就不討論這種情況了，主要討論不支援IP和mac綁定的情況︰
下面舉的例子都是Arp雙向欺騙已經存在的情況，裝上Arp FW後FW將處理情況。
第一種情況──普通公司，家庭，及網吧之類局域網環境下，通訊閘不支援IP和mac綁定︰
先 說欺騙策略，說到這裡不得不提Arpspoof（以下簡稱as），最近流行這個工具，並且開源，好分析，也確實寫的不錯。我手頭拿到的3.1版本的源代 碼。若不修改as代碼，在當前情況下，並處在雙向欺騙時，只要把配置檔案稍微改改，就能夠實現利用ARP掛馬。但如果受騙主機綁定了正確通訊閘的mac， 就不靈了。但如果有人修改了as代碼，使其能支援gzip解碼，並且把本應發給受害主機的包，重組並解碼然後再發給受害主機。就又能欺騙了。
然後再回來看看現下國內的Arp FW。比較弱的，FW一進去，連正確的通訊閘mac都檢測不出來，需要手動填。好點的能自動檢測正確的通訊閘的mac。一般步驟是︰
1．    獲取當前通訊閘mac（如利用sendARP函數等等）；
2．    利用通訊閘IP發一個廣播包，獲取通訊閘的mac；
3．    抓包對比，如果第一步和第二步獲得通訊閘的mac相同，則認為通訊閘mac不是偽造的。如過第二步獲得兩個Arp reply，則把這兩個包與第一步的mac對比，相同的說明是偽造的。如果第二步只獲得一個Arp reply，以第二步獲得mac為準。
檢測到正確通訊閘mac後，就靜態的綁定通訊閘IP和mac，防止別人偽造通訊閘。
    基本上都這么搞，這個思路是有缺陷的。沒錯，是可以防的住現下的as。因為as發Arp欺騙包間隔是3s，如果不改源代碼的話。在這個的時間間隔下，這三 步是有能力獲得正確的通訊閘，但是如果把間隔設短，甚至沒有間隔發Arp欺騙包的話。現下國內市面上的Arp FW全都倒下。我測了兩款，這裡把測的結果說一下︰
    1、金山Arp FW，二話不說，倒下了。（as如果不設間隔的話能實現雙向欺騙）。
    2、360 Arp FW，倒下了，倒的挺愛的。它倒下的同時，如果你點擊重新獲取正確通訊閘，它等幾秒後，報告有Arp攻擊。我一看攻擊報告裡頭的惡意mac，結果惡意的mac恰恰是正確通訊閘發來的。（不設間隔的話能雙向欺騙）。
    瑞*的我沒測。因為我沒搞到它的註冊碼。向一個有可能有哥們要。結果被那哥們鄙視了，他的原話是“沒有哦垃圾瑞星我才不用那”（聊天記錄直接CTRL+V出來，連錯別字都我都沒改）。現下若評世界上哪一款殺軟的自身進程最多，瑞*應該能排第一吧。^_^
    雖然沒測，但結果應該是跑不掉的。因為Arp協議在那裡擺著。
    先說為什麼間隔3s的話，能檢測到正確通訊閘mac，在執行第二步時，在發廣播包之前必須先發一個Arp reply給通訊閘，告訴通訊閘自己正確的mac，然後通訊閘才能把它本身的mac發給受騙主機。這個過程必須在3s內完成。因此如果as的spoof不 設間隔的話。那麼通訊閘在接收了你的ip和mac之後。發起欺騙的主機馬上就去通訊閘那把它改回來。這樣受騙主機雖然發了廣播包，但是通訊閘根據mac， 會把它本身的mac發給欺騙主機而不是發給受騙主機，這樣受騙主機依然得不到正確通訊閘的mac。另外，哪怕受騙主機得到了正確的通訊閘mac，也只能保 證自己對外發包不受欺騙，但是收到的包還是會被欺騙的。當然FW可以和as玩拉鋸，二者都爭先恐後的去通訊閘那邊刷自己的mac。但是這樣導致是容易丟 包。
    其實這種狀況還是有一個相對的解決方案。就是徹底的改頭換面掉。同時改自己的IP和mac，不論FW用什麼添加ndis虛擬網卡，或者透過代碼直接就把當 前IP和mac替掉。獲得正確通訊閘mac才有保證，否則連正確通訊閘mac都拿不到。其它的就更不用說了（至於什麼手動填通訊閘mac之類的。就先不討 論了。知道通訊閘是什麼東西的用戶原沒有想像中的那麼多）。
    說這是一個相對的解決方案，是因為前提是局域網內得有富余的IP資源。另外它還有一些弊端。就是如果有些機器關機的話，而受害者替換了它的IP之後，以後將造成衝突。當然也是有解決方案了。比較多，這裡就先不討論了。
    因此，先要確定哪些IP是未被使用的，可以廣播Arp request 局域網各個IP的mac，如果有人應答的話說明這個IP被用，沒人應答的話，就是富余的IP了。
    只要把自己的IP和mac一改
    改了之後，迅速刷新通訊閘，獲得正確通訊閘的mac之後，可以詢問用戶是否改回來，改回來，因為無法避免丟包。網速也容易受影響。
    第二種關於機房Arp欺騙的情況這裡就不多說，參考上面文字。有幾點要說明的是，機房裡，外網IP和內網IP是映射的，同時改IP和mac是會導致斷網 的，有一定危險性。另外獲得正確通訊閘的mac後，IP和mac必須改回來。也就是說在機房這種情況下，丟包是免不了的。
         若您對本文有任何看法，歡迎給E我，backspray008@gmail.com