PPP協(xié)議及認(rèn)證分析

郭亮，郭海智，江榮旺，周密

（三亞學(xué)院，三亞 572000）

0 引言

點(diǎn)對(duì)點(diǎn)協(xié)議（Point to Point Protocol，PPP）及其衍生出來(lái)的PPPoE協(xié)議作為一種鏈路層傳輸協(xié)議，由于其功能簡(jiǎn)單并支持多種物理層和網(wǎng)絡(luò)層協(xié)議，使其在廣域網(wǎng)傳輸中應(yīng)用廣泛。由于當(dāng)前物理層信道傳輸質(zhì)量較以往有較大提升，該協(xié)議簡(jiǎn)化了HDLC協(xié)議中為保證可靠傳輸所使用的定時(shí)、重傳、序號(hào)、排序及流量控制等機(jī)制以提升傳輸效率。該協(xié)議支持同步和異步傳輸并可承載多種網(wǎng)絡(luò)層協(xié)議，支持認(rèn)證、IP地址動(dòng)態(tài)分配及管理、參數(shù)協(xié)商及多鏈路捆綁等功能。本文主要通過(guò)研究并分析PPP點(diǎn)對(duì)點(diǎn)協(xié)議工作過(guò)程和CHAP認(rèn)證原理，以清晰協(xié)議運(yùn)行過(guò)程，加深對(duì)該協(xié)議的理解。

1 協(xié)議分析

1.1 協(xié)議組成

PPP協(xié)議相關(guān)的RFC較多，主要內(nèi)容在RFC1661（The Point-to-Point Protocol(PPP)）[1]中有詳細(xì)描述，對(duì)于 CHAP認(rèn)證部分描述集中在 RFC1994（PPP Chal?lenge Handshake Authentication Protocol(CHAP)）[2]中 。PPP協(xié)議由實(shí)現(xiàn)封裝成幀和透明傳輸部分，實(shí)現(xiàn)鏈路層建立、配置、認(rèn)證和測(cè)試等功能的鏈路控制協(xié)議LCP（Link Control Protocol），以及為支持不同網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制協(xié)議NCP（Network Control Protocol）三個(gè)組成部分。協(xié)議總共包含了16個(gè)事件、10種狀態(tài)和13個(gè)動(dòng)作，標(biāo)準(zhǔn)詳細(xì)規(guī)定了特定狀態(tài)接收各類事件的狀態(tài)轉(zhuǎn)移過(guò)程。

1.2 工作過(guò)程

點(diǎn)到點(diǎn)鏈路的配置和維護(hù)過(guò)程中，經(jīng)歷了以下幾個(gè)階段：

（1）鏈路不可用階段，也稱為物理層不可用階段，鏈路需從這個(gè)階段開始并到這個(gè)階段結(jié)束。該階段在實(shí)際過(guò)程中停留時(shí)間短暫，當(dāng)外部事件指示物理層準(zhǔn)備就緒，如載波檢測(cè)到對(duì)端設(shè)備，則立即進(jìn)入到下一階段。

（2）鏈路建立階段，該階段通過(guò)交換LCP配置報(bào)文配置數(shù)據(jù)鏈路，交換的信息涉及鏈路層所需的參數(shù)，但不包括網(wǎng)絡(luò)層協(xié)議所需的參數(shù)，完成該階段后進(jìn)入網(wǎng)絡(luò)層協(xié)議階段或可選的認(rèn)證階段。

（3）認(rèn)證階段，默認(rèn)情況下鏈路兩端的設(shè)備通信前不進(jìn)行認(rèn)證，但可通過(guò)選用該階段并采用口令認(rèn)證協(xié)議（Password Authentication Protocol，PAP）或挑戰(zhàn)握手認(rèn) 證 協(xié) 議（Challenge Hand Authentication Protocol，CHAP）兩種認(rèn)證方式之一以保證連接的安全性。如果通過(guò)認(rèn)證，則進(jìn)入網(wǎng)絡(luò)層協(xié)議階段，否則進(jìn)入鏈路終止階段。

（4）網(wǎng)絡(luò)層協(xié)議階段，一旦PPP協(xié)議完成了前面幾個(gè)階段，每種網(wǎng)絡(luò)層協(xié)議會(huì)通過(guò)各自特定的網(wǎng)絡(luò)控制協(xié)議NCP進(jìn)行網(wǎng)絡(luò)層參數(shù)配置，如網(wǎng)絡(luò)層采用IP協(xié)議則使用IPCP協(xié)議實(shí)現(xiàn)IP地址分配等配置。在這個(gè)階段所需的一些配置參數(shù)協(xié)商完后就可以進(jìn)行網(wǎng)絡(luò)層通信。

（5）鏈路終止階段，PPP協(xié)議能在任何時(shí)候終止鏈路。當(dāng)載波丟失、認(rèn)證失敗和管理員人為關(guān)閉鏈路等情況下，使用LCP交換終止數(shù)據(jù)包，并通知網(wǎng)絡(luò)層和物理層采取合適行動(dòng)以應(yīng)對(duì)鏈路終止。

上述工作過(guò)程的鏈路狀態(tài)變遷如圖1所示：

圖1 PPP協(xié)議鏈路狀態(tài)變遷

2 實(shí)驗(yàn)仿真

2.1 拓?fù)浼芭渲?/h3>

本實(shí)驗(yàn)使用GNS3軟件仿真2臺(tái)各配置一塊NM-4T接口卡的Cisco C3640路由器[3]，利用Wireshark軟件進(jìn)行抓包分析，拓?fù)浣Y(jié)構(gòu)如圖2所示。為簡(jiǎn)化分析過(guò)程采用單向認(rèn)證方式，R1作為認(rèn)證方并在s0/0上配置采用CHAP認(rèn)證，R2作為被認(rèn)證放并在端口s0/1上配置對(duì)端認(rèn)證的用戶名和密碼，具體配置如下:

圖2 拓?fù)浣Y(jié)構(gòu)

認(rèn)證端R1配置為：

接入端R2配置為：

2.2 抓包分析

為減少抓取的數(shù)據(jù)包數(shù)量以清晰協(xié)議運(yùn)行原理方便后續(xù)分析，首先保證認(rèn)證成功，兩端ping測(cè)試通過(guò)，然后關(guān)閉R2的s0/1端口再開啟抓包過(guò)程，短暫停留后開啟s0/1端口，待認(rèn)證通過(guò)且協(xié)議up后發(fā)送1次ping包測(cè)試，再次短暫停留后結(jié)束抓包過(guò)程。圖3為按照上述步驟產(chǎn)生的抓包數(shù)據(jù)，為清晰分析對(duì)象過(guò)濾了其他流量信息。其結(jié)果清晰表明序號(hào)5、6、7為CHAP認(rèn)證三次握手過(guò)程，序號(hào)18、19為一次ping包測(cè)試數(shù)據(jù)的請(qǐng)求與響應(yīng)。

圖3 抓包數(shù)據(jù)

通過(guò)抓包分析并結(jié)合前述理論分析，可繪出PPP協(xié)議工作過(guò)程如圖4所示。

2.3 認(rèn)證分析

如前所述，PPP協(xié)議可選用兩種認(rèn)證方式。其中的PAP認(rèn)證采二次握手機(jī)制，用明文傳輸用戶名和密碼，很容易通過(guò)抓包可獲取，被認(rèn)證方容易被暴力破解，實(shí)際使用環(huán)境除PPPoE撥號(hào)使用該認(rèn)證方式外其余較少使用，下面詳述CHAP認(rèn)證原理。CHAP認(rèn)證采用三次握手機(jī)制完成認(rèn)證過(guò)程。在鏈路建立階段結(jié)束后，認(rèn)證方發(fā)出由本次認(rèn)證的序列號(hào)id，隨機(jī)值和路由器名字組合的挑戰(zhàn)口令給接入端，對(duì)端結(jié)合該挑戰(zhàn)口令部分信息及自身配置的認(rèn)證信息使用單向函數(shù)產(chǎn)生對(duì)應(yīng)的應(yīng)答信息，認(rèn)證方驗(yàn)證應(yīng)答后確認(rèn)連接成功或失敗。如果失敗則隨機(jī)等待一定時(shí)間后再次發(fā)起挑戰(zhàn)口令進(jìn)行認(rèn)證。實(shí)驗(yàn)仿真采用的Cisco路由器進(jìn)行CHAP認(rèn)證的基本原理如圖5所示，其三次握手的具體過(guò)程如下：

圖4 PPP協(xié)議原理

圖5 CHAP認(rèn)證過(guò)程

（1）認(rèn)證方發(fā)送01標(biāo)識(shí)符表示挑戰(zhàn)，以及標(biāo)識(shí)本次驗(yàn)證的序號(hào)id，隨機(jī)值，和認(rèn)證方用戶名，其中id和隨機(jī)值保存在認(rèn)證方以備后續(xù)驗(yàn)證使用。

（2）被認(rèn)證方接收后，把id、random及通過(guò)認(rèn)證方用戶名找到的密碼信息經(jīng)單向md5哈希計(jì)算得到的值和表示應(yīng)答的02標(biāo)識(shí)符以及本次驗(yàn)證id和自身用戶名組合成應(yīng)答包回送。

（3）認(rèn)證方收到應(yīng)答后，利用id找到原來(lái)存儲(chǔ)的隨機(jī)值以及id標(biāo)識(shí)符，和應(yīng)答用戶存儲(chǔ)的密碼通過(guò)md5哈希計(jì)算得到的值與收到的值進(jìn)行比較，判斷是否相同從而驗(yàn)證是否通過(guò)認(rèn)證，進(jìn)而給出認(rèn)證成功的03標(biāo)識(shí)符或認(rèn)證失敗的04標(biāo)識(shí)符作為回應(yīng)。

2.4 認(rèn)證算法代碼驗(yàn)證

分析了CHAP認(rèn)證原理后，下面結(jié)合單向認(rèn)證實(shí)驗(yàn)所抓取的數(shù)據(jù)包采用Python代碼進(jìn)行驗(yàn)證。具體代碼如下，函數(shù)chap_md5verify在認(rèn)證方收到被認(rèn)證方的應(yīng)答后調(diào)用，從接收消息中抽取標(biāo)識(shí)符id，自身配置所保存的密碼及發(fā)送挑戰(zhàn)的隨機(jī)值計(jì)算出hash值，然后與接收的hash值進(jìn)行比較，相同則輸出“access granted”提示認(rèn)證通過(guò)，否則輸出“Access denied”表明認(rèn)證不通過(guò)。下面代碼驗(yàn)證所使用的數(shù)據(jù)從上述抓包數(shù)據(jù)中得出，并驗(yàn)證通過(guò)認(rèn)證。

從標(biāo)準(zhǔn)化和通用性考慮，其他系統(tǒng)為對(duì)接Cisco設(shè)備，其CHAP認(rèn)證也必須遵循相關(guān)RFC標(biāo)準(zhǔn)，但RFC標(biāo)準(zhǔn)中并未給出hash計(jì)算所用參數(shù)的具體裝配步驟，上述代碼明確了該過(guò)程。同時(shí)，通過(guò)分析Linux平臺(tái)上PPP協(xié)議實(shí)現(xiàn)的相關(guān)代碼[4]，與其CHAP認(rèn)證實(shí)現(xiàn)部分做對(duì)比與上述代碼原理一致，進(jìn)而再次驗(yàn)證了代碼正確性。

3 結(jié)語(yǔ)

本文通過(guò)實(shí)驗(yàn)仿真及抓包對(duì)PPP協(xié)議運(yùn)行過(guò)程進(jìn)行了比較全面的分析，結(jié)合代碼驗(yàn)證更加清晰了對(duì)CHAP認(rèn)證原理及細(xì)節(jié)的理解，提高了理論聯(lián)系實(shí)際的能力，對(duì)其他網(wǎng)絡(luò)協(xié)議的研究和學(xué)習(xí)有一定的參考價(jià)值。另外，通過(guò)分析和實(shí)驗(yàn)發(fā)現(xiàn)，CHAP和PAP認(rèn)證模式在認(rèn)證通過(guò)后不再隨機(jī)持續(xù)驗(yàn)證，例如修改了被認(rèn)證方的用戶名和口令，如果沒(méi)有重新使能端口則配置規(guī)則不起作用，鏈路依然保持通暢，該類問(wèn)題為后續(xù)改進(jìn)并提升協(xié)議安全性研究方面提供了方向。