王 軍，黃 皎，吳 穹，雷 鳴，盧 程

(河海大學(xué)，常州 213022)

1 引言

隨著網(wǎng)絡(luò)的普及和發(fā)展，越來越多的嵌入式設(shè)備具備了網(wǎng)絡(luò)通信的能力。信息在方便快捷傳輸?shù)耐瑫r(shí)，其通信的質(zhì)量和安全也面臨著挑戰(zhàn)。ARP(Address Resolution Protocol)［1］地址解析協(xié)議屬于TCP/IP協(xié)議族中網(wǎng)絡(luò)層協(xié)議，通過使用ARP協(xié)議能夠獲取局域網(wǎng)內(nèi)其他設(shè)備的IP地址和MAC地址的映射關(guān)系，從而使網(wǎng)絡(luò)設(shè)備之間能夠相互通信，所以在嵌入式網(wǎng)絡(luò)設(shè)備通信過程中，ARP協(xié)議扮演著十分重要的角色。但是ARP協(xié)議是無狀態(tài)協(xié)議，很容易受到惡意設(shè)備的攻擊和欺騙。通過ARP攻擊，攻擊方能夠阻塞網(wǎng)絡(luò)，竊取重要信息。所以尋求一種有效的抵御ARP攻擊的方法尤為重要。針對(duì)這一問題，從網(wǎng)絡(luò)化嵌入式設(shè)備出發(fā)，在原有的地址解析協(xié)議基礎(chǔ)上加以補(bǔ)充，提出了一種能有效抵御ARP攻擊的解決方案。

2 ARP攻擊問題描述

2.1 ARP—地址解析協(xié)議

ARP的功能分為兩部分:一部分在發(fā)送數(shù)據(jù)包時(shí)請(qǐng)求獲得目的方的物理地址;另一部分向請(qǐng)求物理地址的設(shè)備發(fā)送解析結(jié)果［2］。通過使用ARP協(xié)議，局域網(wǎng)內(nèi)的設(shè)備能夠獲得給定IP主機(jī)的MAC地址。MAC地址唯一的標(biāo)識(shí)每臺(tái)網(wǎng)絡(luò)設(shè)備，在局域網(wǎng)通信中，每個(gè)以太網(wǎng)幀的頭部都包含有接收方的MAC地址，因此用于獲取接收方MAC地址的ARP協(xié)議在網(wǎng)絡(luò)通信中至關(guān)重要。

2.2 ARP協(xié)議的安全缺陷

ARP協(xié)議的安全缺陷來源于協(xié)議自身設(shè)計(jì)上的不足。ARP協(xié)議工作在局域網(wǎng)中，早期的協(xié)議設(shè)計(jì)者認(rèn)為局域網(wǎng)是可信賴的，同時(shí)為了考慮傳輸效率，沒有加入安全機(jī)制。在通常情況下，每個(gè)設(shè)備的ARP緩存表中都保存有正確的IP地址和MAC地址的映射關(guān)系，設(shè)備間能夠正常通信。但是，當(dāng)網(wǎng)絡(luò)中的設(shè)備接收到其它設(shè)備發(fā)送的ARP回應(yīng)信息后，不論之前是否發(fā)送過ARP請(qǐng)求，它自身的ARP緩存表都會(huì)得到更新。在這種情況下，如果惡意設(shè)備B向設(shè)備A發(fā)送偽造的ARP回應(yīng)信息，設(shè)備A在接收到ARP回應(yīng)信息后，ARP緩存就會(huì)得到錯(cuò)誤的更新。

此外，當(dāng)向指定的IP設(shè)備發(fā)送ARP請(qǐng)求時(shí)，接收方在接收到ARP請(qǐng)求后，為了方便后期通信，也會(huì)更新ARP緩存。這種缺陷，同樣也會(huì)給惡意攻擊設(shè)備留下可乘之機(jī)。

2.3 ARP 中毒

設(shè)備在接收到網(wǎng)絡(luò)中的ARP請(qǐng)求或者ARP應(yīng)答后會(huì)更新本地的ARP緩存。利用這一規(guī)則，惡意設(shè)備可以發(fā)送包含有偽造IP地址和MAC地址映射關(guān)系的ARP請(qǐng)求或者ARP應(yīng)答，其他設(shè)備在接收到該請(qǐng)求或者應(yīng)答后，由于無法檢查地址的正確性，就會(huì)錯(cuò)誤的更新本地的ARP緩存。中毒的設(shè)備在利用錯(cuò)誤的緩存表項(xiàng)時(shí)，由于表項(xiàng)中的MAC地址不存在，就會(huì)造成信息無法送達(dá)接收方。

2.4 ARP 欺騙

惡意設(shè)備監(jiān)聽到局域網(wǎng)中設(shè)備A向設(shè)備B發(fā)送ARP請(qǐng)求后，向A連續(xù)多次發(fā)送ARP應(yīng)答信息或請(qǐng)求信息，在應(yīng)答或者請(qǐng)求信息中，攜帶有接收方B的IP地址和惡意設(shè)備的MAC地址。此時(shí)A利用惡意設(shè)備發(fā)送過來的偽造的IP地址和MAC地址映射進(jìn)行更新。此后，A向B發(fā)送信息時(shí)，信息將全部被惡意設(shè)備截獲。利用這種方法同樣也可以欺騙兩臺(tái)主機(jī)，使兩臺(tái)主機(jī)的流量都流經(jīng)惡意主機(jī)，這樣惡意主機(jī)就可以獲取這兩臺(tái)主機(jī)的通信內(nèi)容。APR攻擊是其他惡劣攻擊的組成部分，比如DoS攻擊，MITM攻擊。因此抵御ARP攻擊十分重要。

3 當(dāng)前的解決方案

文獻(xiàn)［3］提出的Arpwatch監(jiān)測(cè)軟件能夠監(jiān)測(cè)可疑的ARP信息。當(dāng)IP地址和MAC地址映射發(fā)生改變時(shí)，監(jiān)測(cè)軟件以電子郵件的形式發(fā)出警報(bào)。但是它依賴于網(wǎng)絡(luò)管理員能否準(zhǔn)確判別非惡意事件和ARP攻擊事件的能力，并且在發(fā)生攻擊時(shí)能否采取及時(shí)有效的措施。文獻(xiàn)［4］提出的Snort也能進(jìn)行ARP攻擊監(jiān)測(cè)，當(dāng)攻擊發(fā)生時(shí)能夠產(chǎn)生警報(bào)通知管理員。但是Snort有很高的誤報(bào)率。此外以上采用監(jiān)測(cè)軟件的方法適合運(yùn)行在計(jì)算機(jī)中，由于嵌入式設(shè)備的資源有限，難以運(yùn)行。RFC 2390［5］提出了向某個(gè)MAC地址發(fā)送“逆ARP”請(qǐng)求來避免MAC地址欺騙攻擊。根據(jù)響應(yīng)來判斷某個(gè)MAC地址是否被克隆。但是這種方法抵御攻擊的種類有限。文獻(xiàn)［6］提出在交換機(jī)中安裝OpenWrt，并且在局域網(wǎng)中增設(shè)服務(wù)器用于保存IP地址和MAC地址，通過修改交換機(jī)的固件，使原來廣播的ARP請(qǐng)求全部轉(zhuǎn)發(fā)到服務(wù)器中，通過服務(wù)器進(jìn)行應(yīng)答。這種方法的缺點(diǎn)在于增設(shè)了額外的服務(wù)器，增加了網(wǎng)絡(luò)成本。

以上方法可以分為兩類:一類通過運(yùn)行監(jiān)控軟件來監(jiān)測(cè)ARP攻擊，并由管理員作出決策，這種方式依賴于管理員的經(jīng)驗(yàn)而且不適合應(yīng)用于嵌入式設(shè)備中;另一種是在網(wǎng)絡(luò)中增設(shè)監(jiān)控硬件，缺點(diǎn)是增加了原有網(wǎng)絡(luò)的成本。由于嵌入式設(shè)備代碼透明，開發(fā)人員可以十分方便的對(duì)網(wǎng)絡(luò)協(xié)議部分進(jìn)行編寫和修改，利用此特點(diǎn)，提出了一種在原有的ARP協(xié)議基礎(chǔ)上進(jìn)行改進(jìn)的方法，通過改進(jìn)的協(xié)議來抵御ARP攻擊。

4 ARP協(xié)議的改進(jìn)

原ARP緩存表項(xiàng)的更新完全依賴于接收到的ARP請(qǐng)求和回應(yīng)信息，不論接收到的信息正確與否，都將被用來直接更新本地的ARP緩存表。改進(jìn)方法，從處理ARP請(qǐng)求和回應(yīng)信息角度出發(fā)，借助于原有的ARP請(qǐng)求和回應(yīng)報(bào)文格式，重新設(shè)計(jì)了ARP請(qǐng)求和回應(yīng)規(guī)則。具體的規(guī)則如表1所示。下面對(duì)ARP請(qǐng)求和回應(yīng)規(guī)則進(jìn)行詳細(xì)闡述。

ARP緩存表的每個(gè)表項(xiàng)中設(shè)有3個(gè)元素:IP地址、MAC地址和生存時(shí)間。IP地址和MAC地址是一一對(duì)應(yīng)的關(guān)系，生存時(shí)間表示每個(gè)表項(xiàng)的生存時(shí)間，其中網(wǎng)關(guān)表項(xiàng)的生存時(shí)間設(shè)定為T，其他表項(xiàng)的生存時(shí)間設(shè)定為2T。由于每臺(tái)設(shè)備都在特定的局域網(wǎng)中，因此設(shè)備所在網(wǎng)絡(luò)網(wǎng)關(guān)的IP地址和MAC地址也就唯一確定，將設(shè)備所在網(wǎng)絡(luò)網(wǎng)關(guān)的IP地址和MAC地址寫入設(shè)備中，并作為信任地址，確保設(shè)備對(duì)網(wǎng)關(guān)的可靠綁定。

ARP緩存表中每一表項(xiàng)包含有生存時(shí)間，當(dāng)生存時(shí)間到期后，主動(dòng)發(fā)送ARP請(qǐng)求。當(dāng)設(shè)備中網(wǎng)關(guān)表項(xiàng)的生存時(shí)間到期后，所做的處理流程如圖1所示。首先向網(wǎng)關(guān)發(fā)送ARP請(qǐng)求，此時(shí)ARP請(qǐng)求以正常的廣播形式向外發(fā)送，網(wǎng)關(guān)收到請(qǐng)求后，發(fā)送回應(yīng)報(bào)文。發(fā)送設(shè)備在接收到ARP回應(yīng)信息后，利用已保存的網(wǎng)關(guān)IP地址和MAC地址，核對(duì)幀頭中源MAC地址以及報(bào)文中源MAC地址、源IP地址是否均為網(wǎng)關(guān)地址，若三個(gè)地址都正確，則將緩存中網(wǎng)關(guān)表項(xiàng)的生存時(shí)間更新為T;如果回應(yīng)的以太網(wǎng)幀中的源MAC地址和網(wǎng)關(guān)實(shí)際的MAC地址不符，說明有惡意設(shè)備克隆了網(wǎng)關(guān)的IP地址和MAC地址，如果ARP回應(yīng)幀中的源MAC地址和源IP地址不匹配，則說明有惡意設(shè)備試圖修改ARP表項(xiàng)，以上情況都不更新網(wǎng)關(guān)表項(xiàng)的生存時(shí)間，也不更新IP地址和MAC地址，繼續(xù)向網(wǎng)關(guān)發(fā)送ARP請(qǐng)求。

表1 改進(jìn)的ARP協(xié)議規(guī)則

圖1 網(wǎng)關(guān)表項(xiàng)生存時(shí)間到期后處理流程圖

當(dāng)設(shè)備ARP緩存表中普通表項(xiàng)的生存時(shí)間到期后，例如A表項(xiàng)在2T的時(shí)間內(nèi)未得到更新，在2T時(shí)間到來時(shí)，將發(fā)送針對(duì)A的單播的ARP請(qǐng)求，如果接收到A的回應(yīng)請(qǐng)求，則更新ARP表項(xiàng)，否則將A的ARP表項(xiàng)刪除。流程如圖2所示。

圖2 普通表項(xiàng)生存時(shí)間到期后處理流程圖

通常情況下，如果網(wǎng)絡(luò)中廣播了ARP請(qǐng)求，當(dāng)發(fā)出請(qǐng)求的一方接收到該請(qǐng)求之后，其ARP緩存表項(xiàng)就會(huì)得到更新，其他設(shè)備即使接收到了ARP請(qǐng)求，也不會(huì)進(jìn)行任何操作。與上述更新ARP緩存表項(xiàng)的方法不同，修改的規(guī)則中，對(duì)ARP緩存更新的方法進(jìn)行了重新設(shè)計(jì)，具體方法如下:每個(gè)設(shè)備的ARP緩存表中都保存有生存時(shí)間為T的網(wǎng)關(guān)映射表項(xiàng)，假設(shè)A中網(wǎng)關(guān)表項(xiàng)生存時(shí)間T到期后，A向網(wǎng)關(guān)發(fā)送ARP請(qǐng)求，由于該請(qǐng)求是廣播形式，局域網(wǎng)中所有設(shè)備都可以接收到，其他設(shè)備在監(jiān)聽到該請(qǐng)求后，判斷該請(qǐng)求是否是向網(wǎng)關(guān)發(fā)送的ARP請(qǐng)求，如果是，則向A發(fā)送單播的ARP請(qǐng)求(封裝在以太網(wǎng)幀中的單播ARP請(qǐng)求報(bào)文格式如表2所示)。設(shè)備A在接收到請(qǐng)求后發(fā)送ARP回應(yīng)信息，其他設(shè)備在收到ARP回應(yīng)信息后更新本地緩存表中A對(duì)應(yīng)的ARP表項(xiàng)，并且生存時(shí)間更新為2T，如果沒有收到ARP回應(yīng)報(bào)文則不做任何處理。對(duì)于來自其它設(shè)備的ARP請(qǐng)求，該設(shè)備在接收到后同樣會(huì)進(jìn)行回應(yīng)，但不更新本地緩存。上述過程的流程如圖3所示。

表2 單播ARP請(qǐng)求報(bào)文

在ARP緩存表中，網(wǎng)關(guān)表項(xiàng)的生存時(shí)間為T，其他表項(xiàng)的生存時(shí)間為2T。在本規(guī)則的設(shè)計(jì)中，當(dāng)設(shè)備A中網(wǎng)關(guān)表項(xiàng)的生存時(shí)間T到期后，會(huì)以廣播形式發(fā)送針對(duì)網(wǎng)關(guān)的ARP請(qǐng)求，此時(shí)其他設(shè)備中A的緩存表項(xiàng)就會(huì)在T時(shí)間時(shí)得到更新，表項(xiàng)的生存時(shí)間更新為2T。實(shí)際上每個(gè)設(shè)備緩存表中每個(gè)表項(xiàng)在間隔T時(shí)間后都會(huì)得到更新，設(shè)置2T的生存時(shí)間實(shí)際上是考慮到設(shè)備在收到針對(duì)網(wǎng)關(guān)的ARP廣播請(qǐng)求后，從發(fā)送ARP單播請(qǐng)求到最后接收到ARP回應(yīng)信息要花費(fèi)一段時(shí)間，2T時(shí)間留有了充足的裕量。

圖3 ARP回應(yīng)信息處理流程圖

與通常情況下接收到任意的ARP請(qǐng)求立即更新緩存不同，在本設(shè)計(jì)中ARP緩存的更新全部依賴于每個(gè)設(shè)備向網(wǎng)關(guān)發(fā)送的ARP廣播請(qǐng)求，但是每個(gè)設(shè)備在接收到ARP請(qǐng)求后，同樣會(huì)發(fā)送回應(yīng)信息。

5 實(shí)驗(yàn)測(cè)試

為了測(cè)試上述方案抵御ARP攻擊的能力，將兩個(gè)EasyArm8962開發(fā)板和一臺(tái)主機(jī)接入局域網(wǎng)中。在開發(fā)板上將上述方案實(shí)現(xiàn)，并通過串口將ARP緩存表中的表項(xiàng)實(shí)時(shí)顯示在上位機(jī)中。接入局域網(wǎng)的主機(jī)上運(yùn)行有ARP攻擊軟件WinArpAttacker，用來對(duì)兩個(gè)開發(fā)板進(jìn)行ARP攻擊。通過觀察開發(fā)板發(fā)送到上位機(jī)中的ARP緩存表項(xiàng)來對(duì)該方案進(jìn)行測(cè)試。

試驗(yàn)中，將兩個(gè)開發(fā)板分別編號(hào)為設(shè)備A，設(shè)備B。A 的IP 地址為10.4.100.154，MAC 地址為00－14－97－F0－07－73;B 的 IP地址為 10.4.100.155，MAC地址為00－24－81－38－9B－08。網(wǎng)關(guān)的 IP地址為10.4.100.254，MAC 地址為00－1A －A9－15－FD－42。

WinArpAttacker中的Send功能能夠發(fā)送內(nèi)容任意的ARP請(qǐng)求和回應(yīng)報(bào)文。利用該功能分別不間斷的發(fā)送冒充來自網(wǎng)關(guān)和其他主機(jī)的ARP請(qǐng)求和回應(yīng)報(bào)文，發(fā)送不存在的IP和MAC地址映射表項(xiàng)，通過觀察上位機(jī)接收到的ARP緩存表項(xiàng)，未發(fā)現(xiàn)有異常的表項(xiàng)出現(xiàn)。實(shí)驗(yàn)結(jié)果如圖4、圖5所示。

圖4 設(shè)備A中的ARP緩存

6 結(jié) 束 語

針對(duì)嵌入式網(wǎng)絡(luò)設(shè)備易于遭受攻擊的問題，從嵌入式設(shè)備的角度考慮，利用其代碼透明易于修改的特點(diǎn)，在原有的ARP協(xié)議基礎(chǔ)上，設(shè)計(jì)出了適用于網(wǎng)絡(luò)化嵌入式設(shè)備的改進(jìn)版本的ARP協(xié)議。通過實(shí)驗(yàn)驗(yàn)證，具有一定的抵御ARP攻擊的能力，為網(wǎng)絡(luò)化嵌入式設(shè)備抵御ARP攻擊提供了一種可行的方案。

圖5 設(shè)備B中的ARP緩存

［1］David C.Plummer.Ethernet Address Resolution Protocol［DB/OL］.SanDeigo，Calif:IETE，1982［June17，012］.http://www.rfc － editor.org/pdfrfc/rfc826.txt.pdf.

［2］蘭少華，楊余旺，呂建永.TCP/IP網(wǎng)絡(luò)與協(xié)議［M］.北京:清華大學(xué)出版社，2006.

［3］L. N. R. Group.Arpwatch，the ethernetmonitor program;for keeping track of ethernet/ip address pairings［J/OL］.2001［June 17，2012］.ftp://ftp.ee.lbl.gov/arpwatch.tar.gz.

［4］Martin Roesch.The Snort:The open source network intrusion detection system［DB/OL］.1998［July 20，2012］.http://www.snort.org.

［5］T.Bradley.Inverse address resolution protocol［DB/OL］.SanDeigo，Calif:IETE，1998［July20，2012］.http://www.rfc － editor.org/pdfrfc/rfc2390.txt.pdf.

［6］Ortega A P，Marcos X E，Chiang L D，Abad C L.Preventing ARP cache poisoning attacks:A proof of concept using OpenWrt［A］.In:Network Operations and Management Symposium［C］.2009:29－31.