線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:5437
推到 Plurk!
推到 Facebook!

網路監聽技術概覽

 
conundrum
尊榮會員


發表:893
回覆:1272
積分:643
註冊:2004-01-06

發送簡訊給我
#1 引用回覆 回覆 發表時間:2005-10-03 09:55:08 IP:218.175.xxx.xxx 未訂閱
 
網路監聽技術概覽    內容: 
http://219.237.67.103/hawk/bbs/topic.php?forumid=6&topicid=1095345798    一些基本概念 
例子 
實現網路監聽的工具 
網路監聽的具體實現 
網路監聽的防範方法 
檢測網路監聽的手段 
安全的交換機? 
Arp 理論的實踐 
Arp 方式監聽的防範 
Arp 方式監聽的檢測 
結束語 
參考資料 
關於作者     更多內容:     所有文章 
教學         宮一鳴 (yiming@security.zz.ha.cn) 
中國電信網路安全小組核心成員 
2002 年 4 月     網路監聽,在網路安全上一直是一個比較敏感的話題,作為一種發展比較成熟的技術,監聽在協助網路管理員監測網路傳輸資料,排除網路故障等方面具有不可替代的作用,因而一直倍受網路管理員的青睞。然而,在另一方面網路監聽也給乙太網安全帶來了極大的隱患,許多的網路入侵往往都伴隨著乙太網內網路監聽行為,從而造成口令失竊,敏感資料被截獲等等連鎖性安全事件。 
網路監聽在安全領域引起人們普遍注意是在94年開始的,在那一年2月間,相繼發生了幾次大的安全事件,一個不知名的人在眾多的主機和骨幹網路設備上安裝了網路監聽軟體,利用它對美國骨幹互聯網和軍方網竊取了超過100,000個有效的用戶名和口令。上述事件可能是互聯網上最早期的大規模的網路監聽事件了,它使早期網路監聽從"地下"走向了公開,並迅速的在大眾中普及開來。     關於網路監聽常常會有一些有意思的問題,如:"我現在有連在網上的電腦了,我也有了竊聽的軟體了,那麼我能不能竊聽到微軟(或者美國國防部,新浪網等等)的密碼?     又如:我是公司的局域網管理員,我知道hub很不安全,使用hub這種網路結構將公司的計算計互連起來,會使網路監聽變得非常容易,那麼我們就換掉hub,使用交換機,不就能解決口令失竊這種安全問題了麼?     這是兩個很有意思的問題,我們在這裏先不做回答,相信讀者看完全文後會有自己正確的答案。     一些基本概念: 
首先,我們知道,一台接在乙太網內的電腦為了和其他主機進行通訊,在硬體上是需要網卡,在軟體上是需要網卡驅動程式的。而每塊網卡在出廠時都有一個唯一的不與世界上任何一塊網卡重複的硬體位址,稱為mac位址。同時,當網路中兩台主機在實現tcp/ip通訊時,網卡還必須綁定一個唯一的ip位址。下面用一個常見的unix命令ifconfig來看一看作者本人的一台正常工作的機器的網卡:     [yiming@server/root]# ifconfig -a 
hme0: flags=863 mtu 1500 
inet 192.168.1.35 netmask ffffffe0 
ether 8:0:20:c8:fe:15         從這個命令的輸出中我們可以看到上面講到的這些概念,如第二行的192.168.1.35是ip 位址,第三行的8:0:20:c8:fe:15是mac地址。請注意第一行的BROADCAST,MULTICAST,這是什麼意思?一般而言,網卡有幾種接收資料幀的狀態,如unicast,broadcast,multicast,promiscuous等,unicast是指網卡在工作時接收目的地址是本機硬體位址的資料幀。Broadcast是指接收所有類型為廣播報文的資料幀。Multicast是指接收特定的組播報文。Promiscuous則是通常說的混雜模式,是指對報文中的目的硬體位址不加任何檢查,全部接收的工作模式。對照這幾個概念,看看上面的命令輸出,我們可以看到,正常的網卡應該只是接收發往自身的資料報文,廣播和組播報文,請大家記住這個概念。     對網路使用者來說,流覽網頁,收發郵件等都是很平常,很簡便的工作,其實在後臺這些工作是依靠tcp/ip協議族實現的,大家知道有兩個主要的網路體系:OSI參考模型和TCP/IP參考模型,OSI模型即為通常說的7層協議,它由下向上分別為物理層、資料連結層、網路層、傳輸層、會話層、表示層、應用層,而tcp/ip模型中去掉了會話層和表示層後,由剩下的5層構成了互聯網的基礎,在網路的後臺默默的工作著。     下面我們不妨從tcp/ip模型的角度來看資料包在局域網內發送的過程:當資料由應用層自上而下的傳遞時,在網路層形成ip資料報,再向下到達資料連結層,由資料連結層將ip資料報分割為資料幀,增加乙太網包頭,再向下一層發送。需要注意的是,乙太網的包頭中包含著本機和目標設備的mac位址,也即,鏈路層的資料幀發送時,是依靠48bits的乙太網位址而非ip位址來確認的,乙太網的網卡設備驅動程式不會關心ip資料報中的目的ip位址,它所需要的僅僅是mac位址。     目標ip的mac位址又是如何獲得的呢?發端主機會向乙太網上的每個主機發送一份包含目的地的ip位址的乙太網資料幀(稱為arp資料包),並期望目的主機回復,從而得到目的主機對應的mac位址,並將這個mac位址存入自己的一個arp緩存內。     當局域網內的主機都通過HUB等方式連接時,一般都稱為共用式的連接,這種共用式的連接有一個很明顯的特點:就是HUB會將接收到的所有資料向HUB上的每個埠轉發,也就是說當主機根據mac位址進行資料包發送時,儘管發送端主機告知了目標主機的位址,但這並不意味著在一個網路內的其他主機聽不到發送端和接收端之間的通訊,只是在正常狀況下其他主機會忽略這些通訊報文而已!如果這些主機不願意忽略這些報文,網卡被設置為promiscuous狀態的話,那麼,對於這台主機的網路介面而言,任何在這個局域網內傳輸的資訊都是可以被聽到的。     例子: 
我們不妨舉一個例子來看看:我們現在有A,B兩台主機,通過hub相連在一個乙太網內,現在A機上的一個用戶想要訪問B機提供的WWW服務,那麼當A機上的用戶在流覽器中鍵入B的ip地址,得到B機提供的web服務時,從7層結構的角度上來看都發生了什麼呢?     1:首先,當A上的用戶在流覽器中鍵入B機的位址,發出流覽請求後,A機的應用層得到請求,要求訪問IP位址為B的主機,     2:應用層於是將請求發送到7層結構中的下一層傳輸層,由傳輸層實現利用tcp對ip建立連接。     3:傳輸層將資料報交到下一層網路層,由網路層來選路     4:由於A,B兩機在一個共用網路中,IP路由選擇很簡單:IP資料報直接由源主機發送到目的主機。     5:由於A,B兩機在一個共用網路中,所以A機必須將32bit的IP位址轉換為48bit的乙太網位址,請注意這一工作是由arp來完成的。     6:鏈路層的arp通過工作在物理層的hub向乙太網上的每個主機發送一份包含目的地的ip位址的乙太網資料幀,在這份請求報文中申明:誰是B機IP地址的擁有者,請將你的硬體位址告訴我。     7:在同一個乙太網中的每台機器都會"接收"(請注意這一點!)到這個報文,但正常狀態下除了B機外其他主機應該會忽略這個報文,而B機網卡驅動程式識別出是在尋找自己的ip位址,於是回送一個arp應答,告知自己的ip位址和mac地址。     8:A機的網卡驅動程式接收到了B機的資料幀,知道了B機的mac位址,於是以後的資料利用這個已知的MAC位址作為目的地址進行發送。同在一個局域網內的主機雖然也能"看"到這個資料幀,但是都保持靜默,不會接收這個不屬於它的資料幀。     上面是一種正常的情況,如果網卡被設置為為混雜模式(promiscuous),那麼第8步就會發生變化,這台主機將會默不作聲的聽到乙太網內傳輸的所有資訊,也就是說:竊聽也就因此實現了!這會給局域網安全帶來極大的安全問題,一台系統一旦被入侵並進入網路監聽狀態,那麼無論是本機還是局域網內的各種傳輸資料都會面臨被竊聽的巨大可能性。     實現網路監聽的工具: 
上面我們看到,一切的關鍵就在於網卡被設置為混雜模式的狀態,這種工作複雜嗎?不幸的是,這種工作並不複雜,目前有太多的工具可以做到這一點。     自網路監聽這一技術誕生以來,產生了大量的可工作在各種平臺上相關軟硬體工具,其中有商用的,也有free的。在google上用sniffer tools作為關鍵字,可以找到非常多。     作者在這裏列舉一些作者喜歡的軟體,供有興趣的讀者參考使用。     Windows平臺下的:     Windump 
Windump是最經典的unix平臺上的tcpdump的window移植版,和tcpdump幾乎完全相容,採用命令行方式運行,對用慣tcpdump的人來講會非常順手。目前版本是3.5.2,可運行在Windows 95/98/ME/Windows NT/2000/XP平臺上     Iris 
Eeye公司的一款付費軟體,有試用期,完全圖形化介面,可以很方便的定制各種截獲控制語句,對截獲資料包進行分析,還原等。對管理員來講很容易上手,入門級和高級管理員都可以從這個工具上得到自己想要得東西。運行在Windows 95/98/ME/Windows NT/2000/XP平臺上     unix平臺下的:     tcpdump 
不多說,最經典的工具,被大量的*nix系統採用,無需多言。     ngrep 
和tcpdump類似,但與tcpdump最大的不同之處在于,借助於這個工具,管理員可以很方便的把截獲目標定制在用戶名,口令等感興趣的關鍵字上。     snort 
目前很紅火的免費的ids系統,除了用作ids以外,被用來sniffer也非常不錯,可以借助工具或是依靠自身能力完全還原被截獲的資料。     Dsniff 
作者設計的出發點是用這個東西進行網路滲透測試,包括一套小巧好用的小工具,主要目標放在口令,用戶訪問資源等敏感資料上,非常有特色,工具包中的arpspoof,macof等工具可以令人滿意的捕獲交換機環境下的主機敏感資料。     Ettercap 
和dsniff在某些方面有相似之處,也可以很方便的工作在交換機環境下 
提示:國內用戶訪問這個站點需要使用代理伺服器。     Sniffit 
被廣泛使用的網路監聽軟體,截獲重點在用戶的輸出。     網路監聽的具體實現: 
在系統管理員看來,網路監聽的主要用途是進行資料包分析,通過網路監聽軟體,管理員可以觀測分析即時經由的資料包,從而快速的進行網路故障定位。     我們可以舉個例子: server是郵件伺服器,下面帶了很多的client用戶,郵件伺服器收發郵件工作正常,但下面的client用戶總是抱怨發郵件時連接到郵件伺服器後要等待很久的時間才能開始發送工作,問題出在哪里呢?     在server上使用tcpdump對來自其中的一個client的資料包進行捕獲分析,看看結果如何?     server#tcpdump host client 
tcpdump: listening on hme0 
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) win 64240  (DF) 
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack 1087965816 win 10136  (DF) 
19:04:30.040960 client.1065 > server.smtp: . ack 1 win 64240  (DF)         client連接伺服器的25埠,三次握手正常,沒有問題,我們再往下看     19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760  (DF) 
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760  (DF) 
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760  (DF) 
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF) 
19:04:56.070108 server.smtp > client.1065: P 1:109(108) ack 1 win 10136  (DF)         這裏有問題了,我們看到server端試圖連接client的113認證埠,然而client端並不會去回應它,server端從19點04分30秒到19點04分56秒嘗試3次,費時26秒後,才放棄認證嘗試,主動reset了client端的113埠,開始push後面的資料,而正是在這個過程中所花費的時間,使用戶發送郵件時產生了漫長的等待。     問題找到了,下面的工作就好辦了,通過修改伺服器端的軟體配置,使它不再進行113埠的認證,看看這個問題解決了麼?不用問client用戶,再抓包如下:     server# tcpdump host client 
tcpdump: listening on hme0 
19:06:45.775516 client.1066 > server.smtp: S 1119047365:1119047365(0) win 64240  (DF) 
19:06:45.775546 server.smtp > client.1066: S 116566929:116566929(0) ack 1119047366 win 10136  (DF) 
19:06:45.775776 client.1066 > server.smtp: . ack 1 win 64240  (DF) 
19:06:45.789316 server.smtp > client.1066: P 1:109(108) ack 1 win 10136  (DF) 
19:06:45.796767 client.1066 > server.smtp: P 1:11(10) ack 109 win 64132  (DF)         我們看到,server不再進行113埠的認證嘗試,直接push資料,問題應該解決,到client試驗,果然延遲現象消失!     由這個試驗,我們可以看到,網路監聽手段,對網路的系統管理員是非常有價值的。     然而,對入侵者呢?與管理員感興趣的是對資料包進行分析不同,入侵者,感興趣的是資料包的內容,尤其是帳號,口令等敏感內容。     我們模仿入侵者在主機上跑一個上面提到的sniffit軟體,監聽本機發出去的所有telnet資料,如下:     server#./sniffit -A . -p 23 -s server         同時,我們模仿一個用戶yiming登錄一台client機器,     server@yiming#telnet client 
Trying 192.168.1.1... 
Connected to 192.168.1.1 
Escape character is '^]'.     login: yiming 
Password: 
Sun Microsystems Inc. SunOS 5.7 Generic October 1998 
$ ls 
bak lost+found project wangguan 
libcap nms snmp wglist 
$ pwd 
/yiming 
$         我們看到這個用戶telnet到client機器,輸入帳號口令,執行了ls,pwd命令,     此時看看sniffit的記錄檔記錄了什麼,     server# more server.32780-client.23 
........... ..!.."..'.......h.7....#..$....VT100....'.........yiming..Power^man!..ls ..pwd..         我們看到了帳號yiming,密碼Power^man!,還有登錄後操作的命令。請注意一點,yiming這個用戶儘管設置了非常複雜的密碼,但對網路監聽而言,是沒有絲毫意義的。     其實除了截獲telnet密碼這樣的功能外,專用的網路監聽軟體從密碼到郵件,流覽的網頁等內容,無所不包,但由於本文不是介紹網路監聽軟體用途的,因此這裏不詳細?述各種監聽軟體的使用方法,有興趣的讀者可以參照各個軟體的readme等檔,很簡單。     網路監聽的防範方法: 
上面我們介紹了可以用來進行網路監聽的軟體,那麼對這種不受歡迎的行為,有沒有一些防範手段呢?     上面我們知道,sniffer是發生在乙太網內的,那麼,很明顯,首先就要確保乙太網的整體安全性,因為sniffer行為要想發生,一個最重要的前提條件就是乙太網內部的一台有漏洞的主機被攻破,只有利用被攻破的主機,才能進行sniffer,去收集乙太網內敏感的資料資訊。     其次,採用加密手段也是一個很好的辦法,因為如果sniffer抓取到的資料都是以密文傳輸的,那對入侵者即使抓取到了傳輸的資料資訊,意義也是不大的-比如作為telnet,ftp等安全替代產品目前採用ssh2還是安全的。這是目前相對而言使用較多的手段之一,在實際應用中往往是指替換掉不安全的採用明文傳輸資料的服務,如在server端用ssh,openssh等替換unix系統自帶的telnet,ftp,rsh,在client端使用securecrt,sshtransfer替代telnet,ftp等。     除了加密外,使用交換機目前也是一個應用比較多的方式,不同於工作在第一層的hub,交換機是工作在二層,也就是說資料連結層的,以CISCO的交換機為例,交換機在工作時維護著一張ARP的資料庫,在這個庫中記錄著交換機每個埠綁定的MAC位址,當有資料報發送到交換機上時,交換機會將資料報的目的MAC位址與自己維護的資料庫內的埠對照,然後將資料報發送到"相應的"埠上,注意,不同於HUB的報文廣播方式,交換機轉發的報文是一一對應的。對二層設備而言,僅有兩種情況會發送廣播報文,一是資料報的目的MAC位址不在交換機維護的資料庫中,此時報文向所有埠轉發,二是報文本身就是廣播報文。由此,我們可以看到,這在很大程度上解決了網路監聽的困擾。但是有一點要注意,隨著dsniff,ettercap等軟體的出現,交換機的安全性已經面臨著嚴峻的考驗!我們將在後面對這種技術進行介紹。     此外,對安全性要求比較高的公司可以考慮kerberos,kerberos是一種為網路通信提供可信第三方服務的面向開放系統的認證機制,它提供了一種強加密機制使client端和server即使在非安全的網路連接環境中也能確認彼此的身份,而且在雙方通過身份認證後,後續的所有通訊也是被加密的。在實現中也即建立可信的第三方伺服器保留與之通訊的系統的密鑰資料庫,僅kerberos和與之通訊的系統本身擁有私鑰(private key),然後通過private key以及認證時創建的session key來實現可信的網路通訊連接。     檢測網路監聽的手段 
對發生在局域網的其他主機上的監聽,一直以來,都缺乏很好的檢測方法。這是由於產生網路監聽行為的主機在工作時總是不做聲的收集資料包,幾乎不會主動發出任何資訊。但目前網上已經有了一些解決這個問題的思路和產品:     1:反應時間 
向懷疑有網路監聽行為的網路發送大量垃圾資料包,根據各個主機回應的情況進行判斷,正常的系統回應的時間應該沒有太明顯的變化,而處於混雜模式的系統由於對大量的垃圾資訊照單全收,所以很有可能回應時間會發生較大的變化。     2:觀測dns 
許多的網路監聽軟體都會嘗試進行位址反向解析,在懷疑有網路監聽發生時可以在dns系統上觀測有沒有明顯增多的解析請求。     3:利用ping模式進行監測 
上面我們說過:當一台主機進入混雜模式時,乙太網的網卡會將所有不屬於他的資料照單全收。按照這個思路,我們就可以這樣來操作:假設我們懷疑的主機的硬體位址是00:30:6E:00:9B:B9,它的ip位址是192.168.1.1,那麼我們現在偽造出這樣的一種icmp資料包:硬體位址是不與局域網內任何一台主機相同的00:30:6E:00:9B:9B,目的地址是192.168.1.1不變,我們可以設想一下這種資料包在局域網內傳輸會發生什麼現象:任何正常的主機會檢查這個資料包,比較資料包的硬體位址,和自己的不同,於是不會理會這個資料包,而處於網路監聽模式的主機呢?由於它的網卡現在是在混雜模式的,所以它不會去對比這個資料包的硬體位址,而是將這個資料包直接傳到上層,上層檢查資料包的ip位址,符合自己的ip,於是會對對這個ping的包做出回應。這樣,一台處於網路監聽模式的主機就被發現了。     這種方法,在10pht這個駭客組織的antisniff產品中有很好的體現。可參見:http://www.securitysoftwaretech.com/antisniff/download.html     4:利用arp資料包進行監測 
除了使用ping進行監測外,目前比較成熟的有利用arp方式進行監測的。這種模式是上述ping方式的一種變體,它使用arp資料包替代了上述的icmp資料包。向局域網內的主機發送非廣播方式的arp包,如果局域網內的某個主機回應了這個arp請求,那 麼我們就可以判斷它很可能就是處於網路監聽模式了,這是目前相對而言比較好的監測模式。     這種方式,在neped和PromiScan這兩個產品中有所體現。可分別參見:http://www.securityfriday.com/ToolDownload/PromiScan/promiscan_doc.html" target=_blank>http://www.apostols.org/、http://www.securityfriday.com/ToolDownload/PromiScan/promiscan_doc.html     值得注意的是,現在互聯網上流傳著一些基於上面這兩種技術的腳本和程式,它們宣稱自己能準確捕捉到局域網內所有進行網路監聽的主機,目前來講,這種說法基本上是不可靠的,因為上述技術在實現中,除了要考慮網卡的硬體過濾外,還需要考慮到不同作業系統可能產生的軟體過濾。因為雖然理論上網卡處於混雜模式的系統應該接收所有的資料包,但實際上不同的作業系統甚至相同的作業系統的不同版本在tcp/ip的實現上都有自己的一些特點,有可能不會接收這些理論上應該接收的資料包。     除了上述幾種方式外,還有一些其他的方式,如:檢測hub燈,但相比局限性就更大了,只能作為上述模式的補充。     相對而言,對發生在本機的網路監聽,是可以利用一些工具軟體來發現的,比較簡單,這裏我們不介紹,有興趣的讀者可以參考cert等網站。     安全的交換機? 
文章到這裏結束了嗎?沒有,我們還漏掉了一個很重要的監聽手段-交換環境下面的網路聽,這是個很有必要談及的話題,筆者作為網路管理員參加了許多的工程決策,吃驚的發現許多的公司都還停留在交換機是局域網安全的徹底解決之道的概念上。     應該認識到這個概念是個傳說,是的,在以前,的確是這樣的,但隨著上面介紹的dsniff等軟體的誕生,所謂交換機的安全已經成為一個傳說了。     本文前面的部分介紹了交換機工作的原理,不同於HUB的共用式報文方式,交換機轉發的報文是一一對應的,由此看來,交換環境下再採用傳統的共用式局域網下網路監聽是不可行了,由於報文是一一對應轉發的,普通的網路監聽軟體此時無法監聽到交換環境下其他主機任何有價值的資料。     交換機是安全的?     不,還有一些別的方法,比如利用arp,本文一開始就提到了局域網內主機資料包的傳送完成不是依靠ip位址,而是依靠arp找出ip地址對應的mac位址實現的。而我們知道arp協議是不可靠和無連接的,通常即使主機沒有發出arp請求,也會接受發給它的arp回應,並將回應的mac和ip對應關係放入自己的arp緩存中。     那麼如果能利用這個特性,在這個環節中做些文章,還是可以截獲資料包的。     Arp理論的實踐 
作者這裏推薦一個不錯的上述理論產物,dsniff,這個套裝軟體中包括了filesnarf、 mailsnarf、msgsnarf、urlsnarf、dnsspoof、macof 等諸多很有特色的元件,可以捕獲網路中的各種敏感資料,但這些不是今天感興趣的主題,我們只看其中一個元件,arpspoof,這個元件就是上述arp理論的一個實踐,它的工作原理是這樣的:發起arpspoof的主機向目標主機發送偽造的arp應答包,騙取目標系統更新arp表,將目標系統的閘道的mac位址修改為發起arpspoof的主機mac位址,使資料包都經由發起arpspoof的主機,這樣即使系統連接在交換機上,也不會影響對資料包的攫取,由此就輕鬆的通過交換機實現了網路監聽。     舉例如下: 
主機a和b連接在交換機的同一個vlan上, 
A機的ip地址:192.168.1.37 
B機的ip地址:192.168.1.35,mac地址為:08-00-20-c8-fe-15 
閘道的ip地址:192.168.1.33,mac地址為:00-90-6d-f2-24-00     首先在a機上看看a機的arp表     C:\ >arp -a 
Interface: 192.168.1.37 
Internet Address Physical Address Type 
192.168.1.33 00-90-6d-f2-24-00 dynamic         我們看到a機中保留著閘道的ip地址192.168.1.33和對應的mac位址00-90-6d-f2-24-00     我們在B機上執行arpspoof,將目標指向a機,宣稱自己為閘道,如下:     HOSTB# arpspoof -t 192.168.1.37 192.168.1.33 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15 
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15         可以看到b機持續向a發送arp回應包,宣稱閘道192.168.1.33的mac地址是自己!此時,我們在a機上看看arp表的內容,     C:\>arp -a 
Interface: 192.168.1.37 
Internet Address Physical Address Type 
192.168.1.33 08-00-20-c8-fe-15 dynamic         哈!a機的arp表已經改變了,閘道的mac位址被更新為了 b機的mac位址,這樣,當有資料包發送時,a機理所當然的會發到它arp表中閘道對應的mac位址08-00-20-c8-fe-15,然而這個地方的b機正在等待著,悄然無聲的冒充閘道收發著a機的資料包。     有一點要說明的是,為了讓a機能正常使用網路,b機還必須打開資料轉發,     linux中可以使用     sysctl -w net.ipv4.ip_forward = 1         bsd系統可以使用     sysctl -w net.inet.ip.forwarding =1         solaris系統可以使用     ndd -set /dev/ip ip_forwarding 1         除了這樣打開內核的支援外,也可以選用外部的fragrouter等轉發軟體,如此,就能確保a機正常工作了。     此外,ettercap的作者指出,內核為2.4.x的linux系統在arp實現中,考慮到了arp欺騙,不會接受未經請求的arp回應,因此直接向這種系統發送arp reply也是無效的,不過,有意思的是雖然它不會接受未經請求的arp reply,但是只要接收到arp的request,它就會更新自己的arp緩存,;),如此就好辦了,發送一個偽造的arp request即可!不過,作者在自己實驗時沒有發現這個問題,作者內核為2.4.7的系統接受了直接的arp reply,並更新了自己的arp表。     如果一切配置正常的話,被重定向的a機是不會有什麼明顯的感覺的,網路照常是通暢的,只是在後臺資料都繞了一個小圈子,不是直接到閘道,而是先經由b機,再由b機轉發到閘道,因為資料包都經過了b機,那麼在b機上起一個網路監聽軟體,a機的所有資料必然會被監聽到。交換環境下的監聽由此實現!     除此之外,dsniff還提供了macof等淹沒交換機arp表等進行監聽的模式,這裏就不介紹了,有興趣的讀者可以自己查閱相關資料。     Arp方式監聽的防範 
對付採用arp方式的監聽也是個比較棘手的問題,有幾個不是非常理想的對策。     首先還是上面提到的加密,盡可能的讓局域網內的傳輸的資料都是秘文的,這個可能相對最理想的防範方法,但實施起來可能有一點困難。有一點要注意,ssh1是不安全的,我們提到的dsniff和ettercap都可以對ssh1實施中間人的監聽。     另外,還可以考慮指定靜態arp,如大多數unix系統支援arp讀取指定的ip和mac位址對應檔,首先編輯內容為ip和mac位址對照的檔,然後使用命令:arp -f /path/to/ipandmacmapfile讀取檔,這樣就指定了靜態的arp位址,即使接收到arp reply,也不會更新自己的arp緩存,從而使arpspoof喪失作用。windows系統沒有-f這個參數,但有-s參數,用命令行指定ip和mac地址對照關係,如arp -s 192.168.1.33 00-90-6d-f2-24-00,可惜除了xp外,其他的版本的window平臺即使這樣做,當接收到偽造的arp reply後,依然會更新自己的arp緩存,用新的mac位址替換掉老的mac位址,所以無法對抗arpspoof。而且採用靜態arp有一個缺憾,就是如果網路很大的話,工作量會非常的大。     Arp方式監聽的檢測 
首先是借助檢測ip位址和mac位址對應的工具,如arpwatch,安裝了arpwatch的系統在發生mac位址變化時會在系統的日誌檔中看到如下提示     Apr 21 23:05:00 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15) 
Apr 21 23:05:02 192.168.1.35 arpwatch: flip flop 192.168.1.33 8:0:20:c8:fe:15 (0:90:6d:f2:24:0) 
Apr 21 23:05:03 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15)         從提示中可以看出arpwatch檢測到了閘道mac位址發生了改變。     其次借助於一些入侵檢測系統,如snort,亦可以起到的一定的檢測作用。在snort的配置檔中打開arpspoof的preprocessor開關並進行配置即可。     作者本人試驗發現,如果採用本地解析時,觀測局域網本地的dns伺服器的反解是一個好的辦法,因為發起arpspoof的主機會不間斷的嘗試正反解析冒充的閘道ip,發送數量非常多的重複解析資料包,當懷疑有arpspoof時很容易被發現,如下:     nameserver# tcpdump -n -s 0 port 53 
tcpdump: listening on hme0 
23:19:22.489417 192.168.1.35.41797 > 192.168.1.68.53: 32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF) 
23:19:22.490467 192.168.1.35.41798 > 192.168.1.68.53: 32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF)         結束語: 
上面我們介紹了網路監聽技術的幾個主要方面,包括網路監聽的主要技術細節,具體實現,檢測方法等。此外還介紹了一種非傳統的監聽方式,通過本文,希望讀者能對網路監聽產生一些認識。     參考資料     Richard stevens: 《TCP/IP Illustrated, Volume 1: The Protocols》 
Dsniff網站:http://www.monkey.org/~dugsong/dsniff/ 
Attacks Against SSH 1 And SSL的討論:http://slashdot.org/articles/00/12/18/0759236.shtml 
ettercap網站:http://ettercap.sourceforge.net/
台灣災難都是事後算帳 無人飛行載具(Unmanned Aerial Vehicle,UAV)為什麼沒大量應用於救災行列
系統時間:2024-04-30 11:23:19
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!