基于嗅探技術(shù)的內(nèi)部網(wǎng)絡(luò)安全研究
摘 要: 網(wǎng)絡(luò)邊界處的防火墻系統(tǒng)可以有效防御一些來自外網(wǎng)的攻擊,在入侵檢測系統(tǒng)的實時保護下,理論上可以保障內(nèi)網(wǎng)安全無憂。然而,內(nèi)部網(wǎng)絡(luò)的非法操作更隱蔽、更有威脅。針對這種情況,通過嗅探技術(shù)對內(nèi)網(wǎng)進行實時的流量監(jiān)控和數(shù)據(jù)包分析,較好地加強和保障了內(nèi)網(wǎng)的安全。
關(guān)鍵詞: 嗅探技術(shù);流量監(jiān)控;數(shù)據(jù)包分析
由于TCP/IP協(xié)議族本身存在許多安全漏洞,使復(fù)雜的網(wǎng)絡(luò)安全難以保障。網(wǎng)絡(luò)安全一般來說分為網(wǎng)絡(luò)外部安全和網(wǎng)絡(luò)內(nèi)部安全兩方面,這兩方面出現(xiàn)的安全問題的比例約為3:7,顯然,最普遍的安全威脅主要來自內(nèi)部。內(nèi)網(wǎng)由大量的終端組成,內(nèi)網(wǎng)任何一部分的安全問題,都可能導(dǎo)致整個內(nèi)部網(wǎng)絡(luò)的癱瘓。內(nèi)網(wǎng)的安全通常依靠主機防護系統(tǒng)、入侵檢測系統(tǒng)(IDS)及漏洞掃描技術(shù)等來保證[1]。針對使用入侵檢測系統(tǒng)的內(nèi)網(wǎng),由于網(wǎng)絡(luò)傳輸速率的大大加快,使IDS的負(fù)擔(dān)加重,造成了IDS的高虛警率,且IDS在應(yīng)對對自身的攻擊時,對其他傳輸?shù)臋z測也會被抑制。因此本文通過嗅探技術(shù)加強對內(nèi)網(wǎng)的實時監(jiān)控管理,一定程度上加強了內(nèi)網(wǎng)安全。
1 嗅探技術(shù)及Omni peek
網(wǎng)絡(luò)嗅探是指利用計算機的網(wǎng)絡(luò)接口截獲目的地為其他計算機的數(shù)據(jù)報文的一種手段。網(wǎng)絡(luò)嗅探技術(shù)不主動向網(wǎng)絡(luò)發(fā)送數(shù)據(jù)包,而是監(jiān)聽、提取和解析網(wǎng)絡(luò)中正在傳輸?shù)臄?shù)據(jù)包。網(wǎng)絡(luò)嗅探技術(shù)是一把雙刃劍,其正當(dāng)用途主要是分析網(wǎng)絡(luò)的流量及性能,以便找出網(wǎng)絡(luò)中潛在的問題,但不可用于竊取私密信息[2]。如果某時段一個網(wǎng)段運行不暢,造成信息包的發(fā)送比較慢,丟包現(xiàn)象嚴(yán)重,而網(wǎng)絡(luò)管理員又不知道問題所在,此時就可以用嗅探軟件作出較準(zhǔn)確的判斷。
Omni peek是出自WildPackets的著名抓包軟件,其功能與Sniffer Pro有相似之處,是一款網(wǎng)管和應(yīng)用故障診斷分析軟件。針對復(fù)雜的網(wǎng)絡(luò)環(huán)境,執(zhí)行管理、監(jiān)控、分析、除錯及最佳化的工作。Omni peek軟件v6.02提供更好的圖形用戶界面,不管是在有線網(wǎng)絡(luò)還是在無線網(wǎng)絡(luò)中,它都能夠給予網(wǎng)絡(luò)管理人員實時的網(wǎng)絡(luò)監(jiān)視、數(shù)據(jù)包捕獲以及故障診斷分析能力。
2 實時網(wǎng)絡(luò)監(jiān)控
2.1 協(xié)議分析
在共享網(wǎng)絡(luò)環(huán)境下,即由集線器組成的局域網(wǎng)環(huán)境,只需將網(wǎng)卡設(shè)置成混雜模式,即可監(jiān)聽到所有經(jīng)過該網(wǎng)卡的數(shù)據(jù)包。而在交換網(wǎng)絡(luò)環(huán)境,設(shè)置網(wǎng)卡接收模式就不可行了。因此,在一個交換式的局域網(wǎng)中,在其任一臺主機上安裝網(wǎng)絡(luò)嗅探工具,無論其嗅探功能如何強大,也無能為力。這時,它只能嗅探到從本機進出的數(shù)據(jù)包。而若把嗅探工具安裝在代理服務(wù)器上便可解決這一問題。對內(nèi)網(wǎng)的實時監(jiān)控,不是為了實時記錄網(wǎng)絡(luò)狀態(tài),而是為了發(fā)現(xiàn)異常和攻擊。本文分析了一些常見的內(nèi)網(wǎng)安全問題(正常的數(shù)據(jù)包就不再此闡釋),通過運行Omni peek,捕獲數(shù)據(jù)包,經(jīng)查看發(fā)現(xiàn)內(nèi)網(wǎng)主機192.168.0.136的數(shù)據(jù)包可疑,剛開機不久便向IP地址為24.89.201.200發(fā)送大量數(shù)據(jù)包,且這臺主機發(fā)出的所有數(shù)據(jù)包協(xié)議都基于HTTP,如圖1所示。
通過查看某個捕獲的數(shù)據(jù)包的源碼,解碼后如表1所示。
由于HTTP是基于請求/響應(yīng)范式的,信息交換過程分為4個部分:建立連接、發(fā)送請求、發(fā)送響應(yīng)、關(guān)閉連接。但捕獲到的內(nèi)網(wǎng)IP為192.168.0.136的主機所發(fā)出的數(shù)據(jù)包卻很可疑,ACK確認(rèn)的數(shù)量值全為0。圖2是通過Omni peek軟件對TCP的解析,發(fā)現(xiàn)所有數(shù)據(jù)包均是SYN包,而SYN包是主機要發(fā)起TCP連接時發(fā)出的數(shù)據(jù)包,也就是這臺內(nèi)網(wǎng)主機不斷地向外網(wǎng)中的某主機建立HTTP連接,但沒有得到任何回應(yīng),既未收到ACK確認(rèn)包,也沒有FIN釋放連接[3]。
在30 s內(nèi),內(nèi)網(wǎng)主機192.168.0.136從網(wǎng)絡(luò)收到的數(shù)據(jù)包數(shù)只有5個,但其向外網(wǎng)發(fā)出的數(shù)據(jù)包卻有904個,如圖3所示。
這時用Omni peek節(jié)點分析功能,查看192.168.0.136節(jié)點的詳細(xì)資料統(tǒng)計,如圖4所示,發(fā)現(xiàn)HTTP協(xié)議占了整個通信協(xié)議的99.386%。
通過對上述情況的分析,可以推測192.168.0.136所收到的5個包是來自別的節(jié)點的DNS包(從圖3可以看出總共有3個節(jié)點與它通信,并且圖4的協(xié)議中DNS數(shù)據(jù)包占了0.614%)。
當(dāng)單獨查看IP地址為192.168.0.136與24.89.201.200的主機通信協(xié)議時,則100%都是HTTP協(xié)議,如圖5所示。它與IP地址為24.89.201.200的主機通信全是基于HTTP的,但沒有收到一個回包。這對HTTP來說顯然是不正常的,HTTP是基于TCP、是有連接的,不會只發(fā)不收。因此判斷該主機可能是感染了病毒,是造成TCP SYN泛洪(Flood)攻擊所需的“肉雞”。
然而對于被攻擊主機來說,由于SYN泛洪攻擊所使用的IP地址并不是真實的地址,而是代理服務(wù)器的公共IP地址,所以被攻擊者最多只能追蹤到內(nèi)網(wǎng)代理服務(wù)器的IP地址為210.40.20.76(假設(shè)未使用二級以上代理),而要確定攻擊終端很難,黑客通常利用這種攻擊的隱蔽性肆意破壞。所以,內(nèi)網(wǎng)管理員應(yīng)該立即確定這臺內(nèi)網(wǎng)主機,對其進行下線處理,再進行掃描殺毒,以免造成不可避免的損失。
2.2 流量監(jiān)控
一般進行流量監(jiān)控時,首先要關(guān)注那些流量最大的終端節(jié)點。某一時段,丟包現(xiàn)象嚴(yán)重,網(wǎng)絡(luò)性能下降,通過Omni peek軟件分析發(fā)現(xiàn)網(wǎng)絡(luò)阻塞,如圖6所示。
經(jīng)查看發(fā)現(xiàn),內(nèi)網(wǎng)IP為192.168.0.162的主機流量最大,且比例一直在持續(xù)增加,這是造成網(wǎng)絡(luò)阻塞的重要原因。本文先分析網(wǎng)絡(luò)流量的流向[4],通過Omni peek的peer map捕獲發(fā)現(xiàn),確定192.168.0.162向外網(wǎng)很多終端發(fā)送大量的數(shù)據(jù)包,如圖7所示。再對數(shù)據(jù)包的傳輸協(xié)議進行查看,發(fā)現(xiàn)均為基于UDP的數(shù)據(jù)包。UDP是一個無連接、不可靠和缺乏安全性的傳輸層協(xié)議。通過對內(nèi)網(wǎng)IP為192.168.0.162的主機進行單點分析,其在短時間內(nèi)向257外網(wǎng)終端發(fā)出了7 863個數(shù)據(jù)包,其中UDP數(shù)據(jù)包占了91.4%,如圖8所示。
主機向外網(wǎng)發(fā)出大量UDP數(shù)據(jù)包,雖然UDP數(shù)據(jù)包不像TCP建立連接需“3次握手”,可以被人利用SYN消耗一方資源,但如果利用大量UDP包沖擊服務(wù)器,可能會造成UDP FLOOD攻擊,也會使網(wǎng)絡(luò)癱瘓。一般出現(xiàn)下面兩種可能:(1)“肉雞”終端不斷向外網(wǎng)發(fā)送大量無意義的UDP數(shù)據(jù)包,利用UDP協(xié)議漏洞,在兩臺主機的網(wǎng)段之間產(chǎn)生大量沒有實際意義的UDP數(shù)據(jù)流。這些數(shù)據(jù)流將占盡服務(wù)器的網(wǎng)絡(luò)帶寬資源,從而導(dǎo)致系統(tǒng)無法正常提供服務(wù)功能,造成DoS攻擊[5]。(2)某種P2P下載軟件的共享功能從圖8得知,它收到了2 642個數(shù)據(jù)包。有關(guān)調(diào)查表明,P2P業(yè)務(wù)不斷增加,造成了網(wǎng)絡(luò)帶寬的巨大消耗,引起網(wǎng)絡(luò)擁塞,降低其他業(yè)務(wù)的性能。經(jīng)查找證實,該內(nèi)網(wǎng)終端確實在使用P2P軟件Emule。在這種情況下,應(yīng)對該終端進行限速處理,恢復(fù)網(wǎng)絡(luò)通暢。
2.3 防止內(nèi)網(wǎng)ARP欺騙攻擊
在局域網(wǎng)中,最常見的攻擊是ARP欺騙攻擊。由于ARP使主機不會驗證包的來源是否合理,使得一臺主機在從未收到ARP請求包時,也可以發(fā)送ARP應(yīng)答包。一旦某臺主機收到ARP應(yīng)答包,即使它從未向發(fā)送此應(yīng)答包的主機發(fā)送過ARP請求包,仍會對本地的ARP緩存進行更新,將應(yīng)答包中的IP和MAC地址存儲在ARP緩存中,所以很多人利用這種缺陷,通過發(fā)送偽造的ARP應(yīng)答包給發(fā)出請求的主機,從而改變它們之間的數(shù)據(jù)傳輸過程[6]。造成這種情況主要是因為ARP的基礎(chǔ)就是信任局域網(wǎng)內(nèi)所有的人,這樣就很容易實現(xiàn)在以太網(wǎng)上的ARP欺騙。被ARP攻擊的主要現(xiàn)象有:局域網(wǎng)內(nèi)頻繁性區(qū)域掉線,網(wǎng)速時快時慢,同時能夠在網(wǎng)絡(luò)中產(chǎn)生大量的ARP數(shù)據(jù)包通信量使網(wǎng)絡(luò)阻塞。
某時段,發(fā)現(xiàn)捕獲的數(shù)據(jù)包不顯示目的IP地址及源IP地址,查看其數(shù)據(jù)包協(xié)議為ARP的應(yīng)答包,如圖9所示,分析證實必然是某臺主機發(fā)送ARP欺騙數(shù)據(jù)包。
在MS-DOS環(huán)境下使用arp–a命令來查看ARP緩存,正常情況下,每一個內(nèi)網(wǎng)IP都有唯一的MAC地址與之對應(yīng)。某主機竄改MAC地址(人為或是病毒)(如圖10所示),主機192.168.0.105偽造代理服務(wù)器192.168.0.1的MAC地址。
同時Omni peek軟件的ARP數(shù)據(jù)包分析功能也發(fā)現(xiàn)異樣,如圖11所示,幅度較大的部分是ARP Response包的頻率值,從圖得知這個時段內(nèi)有大量的ARP應(yīng)答包,應(yīng)答包數(shù)量大大超過請求包,經(jīng)分析得知,圖中大部分的應(yīng)答包是192.168.0.105的終端發(fā)出的,以達(dá)到欺騙的目的。
內(nèi)網(wǎng)管理員可以通過Omni peek軟件第一時間察覺到ARP攻擊,立即對惡意主機進行下線處理。
在基于代理服務(wù)器的環(huán)境下,通過網(wǎng)絡(luò)嗅探軟件Omni peek可以很方便地對內(nèi)網(wǎng)進行實時監(jiān)控管理。本文對常見的內(nèi)網(wǎng)安全問題進行了分析和闡述,特別是第一種,由于內(nèi)網(wǎng)主機本身沒有真實IP地址,通過代理服務(wù)器的公共IP地址隱藏終端來攻擊外網(wǎng)主機,而被攻擊者又很難確定這臺沒有真實IP地址的終端。從被攻擊者的角度,如何確定沒有固定IP地址的終端,即非真實IP地址網(wǎng)絡(luò)終端定位方法的有待進一步的研究。
參考文獻(xiàn)
[1] 楊云江.計算機網(wǎng)絡(luò)管理技術(shù)[M].第2版,北京:清華大學(xué)出版社,2009.
[2] 蔡林.網(wǎng)絡(luò)嗅探技術(shù)在信息安全中的應(yīng)用[J].計算機時代,2008(6):16-18.
[3] RICHARD S W.TCP/IP illustrated volume 1[M].北京:機械工業(yè)出版社,2002.
[4] DABIR A, MATRAWY A. Bottleneck analysis of traftic monitoring using wireshark[C]. 4th International Conference on Innovations in Information Technology, 2007, IEEE Innovations′07, 2007:158-162.
[5] OADEER M A. Network traffic analysis and intrusion detection using packet sniffer[C]. 2010 Second International Conference on Communication Software and Networks, 2010:313-317.
[6] 孫謙,黃家林,傅軍.基于協(xié)議分析的ARP欺騙病毒源自動定位[J].現(xiàn)代計算機,2008,289:136-139.