POF協(xié)議解析器

儲蘇紅,劉 磊

(1.中國科學(xué)院聲學(xué)研究所國家網(wǎng)絡(luò)新媒體工程技術(shù)研究中心,北京 100190; 2.中國科學(xué)院大學(xué),北京 100049)

0 引 言

隨著信息技術(shù)的蓬勃發(fā)展，新型網(wǎng)絡(luò)業(yè)務(wù)與應(yīng)用層出不窮，其多元化、個性化的網(wǎng)絡(luò)需求給靜態(tài)僵化的傳統(tǒng)網(wǎng)絡(luò)帶來了新的挑戰(zhàn)。依靠端到端連接和盡力而為路由轉(zhuǎn)發(fā)的傳統(tǒng)網(wǎng)絡(luò)無法保障低延遲、高可靠通信[1-2]，另外傳統(tǒng)網(wǎng)絡(luò)依賴于硬件設(shè)備，不同廠商的設(shè)備難以統(tǒng)一部署管理，而且工作方式固定，難以根據(jù)業(yè)務(wù)需求自定義添加新功能，因此新型網(wǎng)絡(luò)的研發(fā)推廣勢在必行。軟件定義網(wǎng)絡(luò)(Software Defined Networking, SDN)[3-4]以其集中流管理、開放可編程、適應(yīng)性強的特點脫穎而出，通過在交換機與SDN控制器間定義統(tǒng)一編程接口，實現(xiàn)數(shù)據(jù)平面與控制平面的解耦，使得網(wǎng)絡(luò)具有強大的靈活性，可輕松實現(xiàn)網(wǎng)絡(luò)系統(tǒng)功能的修改、調(diào)整、拓展和提升，從而加快網(wǎng)絡(luò)業(yè)務(wù)部署的進程。

SDN呈現(xiàn)出快速發(fā)展的趨勢，也成為異構(gòu)網(wǎng)絡(luò)場景實施的關(guān)鍵推動因素，在數(shù)據(jù)中心、城域網(wǎng)、校園網(wǎng)等場景均已實現(xiàn)落地[5]。隨著SDN的推廣，其帶來的網(wǎng)絡(luò)安全問題日益彰顯。通過防火墻、入侵檢測系統(tǒng)可以監(jiān)測DoS攻擊、非法訪問等外部網(wǎng)絡(luò)攻擊和威脅[6]，但是對于交換機/控制器配置故障、轉(zhuǎn)發(fā)設(shè)備資源濫用、虛假流規(guī)則注入[7]、數(shù)據(jù)泄露等內(nèi)部安全威脅不能及時發(fā)現(xiàn)和跟蹤[8]。協(xié)議無感知轉(zhuǎn)發(fā)(Protocol Oblivious Forwarding, POF)[9-10]作為SDN的南向協(xié)議，是控制器和可編程交換機之間通信的橋梁[11]。POF消息中含有大量重要的控制、配置信息，獲取POF交換機硬件信息、設(shè)置交換機配置、進行POF控制器角色變換、下發(fā)流規(guī)則等行為均需通過POF協(xié)議實現(xiàn)。因此可通過解析POF協(xié)議實現(xiàn)對內(nèi)部安全威脅進行監(jiān)測和防范。但是目前并沒有針對POF協(xié)議的自動化在線解析工具，常用的通用數(shù)據(jù)包分析軟件(例如Wireshark)需要捕獲數(shù)據(jù)包后依賴專業(yè)分析人員進行分析[12]。

因此，本文基于網(wǎng)絡(luò)安全審計系統(tǒng)，設(shè)計并實現(xiàn)一種新的POF協(xié)議解析器。該協(xié)議解析器能夠在線對POF消息進行深度解析，實時監(jiān)測SDN網(wǎng)絡(luò)中的通信內(nèi)容，及時中斷非法操作保障網(wǎng)絡(luò)內(nèi)部安全。

1 網(wǎng)絡(luò)安全審計系統(tǒng)

網(wǎng)絡(luò)安全審計系統(tǒng)是為了應(yīng)對日益嚴峻的網(wǎng)絡(luò)安全形勢而設(shè)計的能夠?qū)Ω咚倬W(wǎng)絡(luò)數(shù)據(jù)進行采集留存和分析檢索的系統(tǒng)[13-14]。通過旁路部署捕獲流經(jīng)交換機的流量，對采集的流量進行深度協(xié)議解析，并將解析結(jié)果進行存儲和展示，可實現(xiàn)實時監(jiān)控用戶網(wǎng)絡(luò)行為，及時發(fā)掘并阻止?jié)撛谕{[15]。網(wǎng)絡(luò)安全審計系統(tǒng)架構(gòu)由7個模塊構(gòu)成，分別是：采集模塊、數(shù)據(jù)包預(yù)處理模塊、數(shù)據(jù)包存儲模塊、協(xié)議識別模塊、協(xié)議解析模塊、日志管理模塊和展現(xiàn)模塊，如圖1所示。

圖1 網(wǎng)絡(luò)安全審計系統(tǒng)架構(gòu)

1)采集模塊。負責(zé)流量捕獲，基于DPDK(Data Plane Development Kit)[16-17]技術(shù)實現(xiàn)將網(wǎng)卡上收到的數(shù)據(jù)包以零拷貝的方式復(fù)制到用戶空間。

2)數(shù)據(jù)包預(yù)處理模塊。主要負責(zé)IP重組、TCP重組、流管理等操作，保證到達上層的數(shù)據(jù)包正確有序。

3)數(shù)據(jù)包存儲模塊。存儲捕獲的數(shù)據(jù)包，以供后續(xù)的取證分析。

4)協(xié)議識別模塊。由于應(yīng)用層協(xié)議眾多且協(xié)議格式不固定，因此在進行應(yīng)用層協(xié)議解析之前需要針對不同的協(xié)議進行區(qū)分。本模塊中采取協(xié)議號和端口號匹配方式[18]將報文分發(fā)到不同的解析模塊。

5)協(xié)議解析模塊。按照高層協(xié)議格式，對重組好的數(shù)據(jù)幀中的各個字段進行分析，識別出設(shè)備信息、登錄信息、操作命令等關(guān)鍵信息，將用戶關(guān)心的特定內(nèi)容提取出來，并按照一定的格式封裝成解析日志并發(fā)送至數(shù)據(jù)庫保存。

6)日志管理模塊。負責(zé)存儲和搜索解析日志，對協(xié)議解析模塊生成的日志按照一定的格式進行整合，并可根據(jù)展現(xiàn)模塊提供的關(guān)鍵字進行日志檢索來進行可視化顯示。

7)展現(xiàn)模塊。以圖形化的方式為用戶展示數(shù)據(jù)采集和分析的結(jié)果，可根據(jù)對應(yīng)的日志下載原始數(shù)據(jù)包進行取證分析，另外基于Web的用戶界面允許網(wǎng)絡(luò)管理員實時監(jiān)控網(wǎng)絡(luò)流量信息，可根據(jù)用戶需求進行采集分析的自定義配置。

2 POF協(xié)議分析

2.1 POF消息類型分析

POF是一種高度靈活和可編程的SDN轉(zhuǎn)發(fā)面技術(shù)，以{type, offset, length}[19-20]三元組定義字段，并定義了一套協(xié)議無關(guān)的指令集對數(shù)據(jù)包做處理[21-22]。POF控制器對POF交換機的配置和管理主要是通過POF消息實現(xiàn)的，POF消息主要包括對稱消息[23]、交換機配置消息、異步消息[24]、控制器命令消息、控制器角色消息[25]。下面對具體的消息類型和應(yīng)用場景進行介紹。

1)對稱消息。

HELLO消息：用于控制器和設(shè)備之間的握手。

ECHO消息：用于探測連接狀態(tài)、延遲和帶寬。

2)交換機配置消息。

FEATURE消息：用于控制器獲取交換機設(shè)備的硬件信息，如設(shè)備編號、端口等信息。

CONFIG消息：用于控制器配置和查詢交換機參數(shù)。

3)異步消息。

PACKET_IN消息：用于交換機將數(shù)據(jù)包上報給控制器。

FLOW_REMOVED消息：用于交換機刪除表項后報告給控制器。

PORT_STATUS消息：用于在握手階段和端口狀態(tài)發(fā)生變化時，交換機向控制器上報其當(dāng)前狀態(tài)。

RESOURCE_REPORT消息：用于交換機將軟件資源配置信息上報給控制器，如支持的表數(shù)目、匹配域的總字節(jié)數(shù)等。

4)控制器命令消息。

PACKET_OUT消息：用于控制器發(fā)送數(shù)據(jù)包給交換機。

FLOW_MOD消息：用于流表操作，包括添加、刪除、修改流表項，由控制器下發(fā)給交換機，指導(dǎo)交換機對數(shù)據(jù)包的處理。

TABLE_MOD消息：由控制器發(fā)送給交換機，用于flow table的創(chuàng)建。

INSTRUCTION_BLOCK_MOD消息：用于創(chuàng)建、刪除或修改一個指令塊。

ASM_MOD消息：用于創(chuàng)建或修改一個指令塊。

5)控制器角色消息。

ROLE消息：交換機與多控制器連接時，控制器發(fā)送ROLE_REQUEST消息給交換機改變控制器角色，交換機回復(fù)ROLE_REPLY消息。

交換機與控制器通信時需要通過以上消息確定通信的POF版本并收集交換機的信息，具體的交互流程如圖2所示，分為3個階段：1)進行POF版本協(xié)商階段，交換機與控制器建立TCP連接后，控制器主動發(fā)送HELLO消息，交換機收到后應(yīng)答HELLO消息，在此過程中可以確定POF協(xié)議版本，當(dāng)控制器和交換機的協(xié)商版本不兼容時，便會報告出錯信息并斷開連接；2)進行交換機配置詢問階段，控制器向交換機發(fā)送FEATURES_REQUEST消息詢問交換機的硬件信息，交換機進行應(yīng)答，報告設(shè)備編號、端口數(shù)量、支持的最大表數(shù)目等信息；3)在交換機配置設(shè)置和資源上報階段，交換機應(yīng)答參數(shù)并上報交換機的資源配置信息、每個端口的狀態(tài)信息，當(dāng)流表中沒有匹配的流規(guī)則或者流規(guī)則是發(fā)往控制器的時候，交換機向控制器發(fā)送PACKET_IN消息，控制器下發(fā)PACKET_OUT指導(dǎo)交換機處理數(shù)據(jù)包[26]。

圖2 控制器與交換機交互流程

2.2 POF協(xié)議頭分析

不同類型的POF消息具有不同的數(shù)據(jù)結(jié)構(gòu)，字段實際內(nèi)容的偏移和長度值也不同。但都是以相同的消息頭開始，消息頭具有固定8 byte的長度，結(jié)構(gòu)如圖3所示，其中version表示POF版本號，本文中以2.1版本的POF消息進行解析；type是POF消息類型；length是POF消息總長度；xid表明事件ID，對于同一事件例如FEATURES_REQUEST和FEATURES_REPLY的事件ID相同[27]。解析從第1個字段按序進行，解析完固定結(jié)構(gòu)的消息頭后，再根據(jù)不同消息類型具有的特有數(shù)據(jù)結(jié)構(gòu)來解析字段[28-29]。

圖3 POF消息首部結(jié)構(gòu)

3 POF協(xié)議解析器設(shè)計

在交換機和控制器交互過程中傳遞了很多設(shè)備和配置信息，當(dāng)發(fā)生異常行為時可根據(jù)這些信息快速定位到網(wǎng)絡(luò)安全問題發(fā)生點，并且可以在事后進行溯源取證。本文基于網(wǎng)絡(luò)安全審計系統(tǒng)，針對2.1版本的POF協(xié)議設(shè)計并實現(xiàn)了協(xié)議解析器。該協(xié)議解析器能夠?qū)崿F(xiàn)對網(wǎng)絡(luò)鏈路上采集到的POF數(shù)據(jù)包進行深度解析并實時產(chǎn)生審計數(shù)據(jù)，以日志的形式發(fā)送至數(shù)據(jù)庫保存。POF協(xié)議解析器主要包含2個模塊：消息提取模塊和消息解析模塊。

3.1 消息提取模塊

通過網(wǎng)絡(luò)安全審計系統(tǒng)的數(shù)據(jù)包預(yù)處理模塊復(fù)原出POF數(shù)據(jù)包的有序載荷，再由協(xié)議識別模塊通過POF協(xié)議號和端口6643將POF數(shù)據(jù)包發(fā)送到POF協(xié)議解析器進行協(xié)議解析。但是經(jīng)過數(shù)據(jù)包預(yù)處理模塊處理后的數(shù)據(jù)包只能保證是嚴格有序的，由于TCP/IP其基于流的傳輸方式，不能保證每個TCP數(shù)據(jù)包都是一個完整的應(yīng)用層POF消息或只包含一個POF消息[30-31]。因此，POF協(xié)議解析器需要先對收到的POF載荷進行處理，提取出完整的POF消息后才能進行后續(xù)的協(xié)議解析流程。處理POF數(shù)據(jù)包得到完整POF消息的主流程以偽代碼的形式展示，如算法1所示。

算法1POF Packets Process

1:start←payload

2:payload_len←len(payload)

3:whilepayload_len>0do

4:ifcache is NULLthen

5:process raw packets directly

6:else

7:process cache

8:endif

9:endwhile

算法1的主流程中，根據(jù)是否已經(jīng)存在緩存對接收到的數(shù)據(jù)包分別進行處理(算法1第5～7行)。這是因為若對每個新來的數(shù)據(jù)包都加入緩存處理，將會浪費大量的緩存空間，而且數(shù)據(jù)包拷貝也會影響解析器的性能；對于不完整的POF消息，解析器又無法實現(xiàn)正確解析，則需要將數(shù)據(jù)包加入緩存，與其他數(shù)據(jù)包拼裝組成一條完整的消息。針對這2種場景設(shè)計的對原始數(shù)據(jù)包直接處理和對緩存數(shù)據(jù)處理的流程如算法2和算法3所示。

算法2Raw POF Packets Process

1:ifpayload_len≥8then

2:msg_len←parser_pof_header(payload)

3:ifmsg_len≤payload_lenthen

4:process msg

5:payload←payload+msg_len

6:packet_len←packet_len-msg_len

7:else

8:cache←cache_add(payload, payload_len)

9:continue to receive packet

10:endif

11:else

12:cache←cache_add(payload, payload_len)

13:continue to receive packet

14:endif

算法3Cache Process

1:cache←cache_add(payload, payload_len)

2:payload_len←0

3:ifcache_len≥8then

4:msg_len←parser_pof_header(cache, length)

5:ifmsg_len≤cache_lenthen

6:process msg

7:cache_remove(cache, msg_len)

8:else

9:continue to receive packet

10:endif

11:else

12:continue to receive packet

13:endif

以圖4中的數(shù)據(jù)包為例，說明以上數(shù)據(jù)包處理算法的執(zhí)行過程。首先cache中無緩存數(shù)據(jù)，收到交互過程中的第1個數(shù)據(jù)包載荷后，判斷數(shù)據(jù)包長度是否不小于8 byte。這是因為POF所有消息都包含相同8 byte結(jié)構(gòu)的首部，因此最小的POF數(shù)據(jù)包載荷是8 byte，當(dāng)收到的數(shù)據(jù)包長度小于8 byte時表明其是不完整的數(shù)據(jù)包，無法完成正確解析，只能直接加入緩存。圖4中的第一個數(shù)據(jù)包長度是22 byte，滿足上述條件，于是解析出POF消息頭中的length字段，length字段的值是8，表明這條完整的POF消息應(yīng)該具有的長度是8 byte，根據(jù)length長度提取出第1條完整的消息；繼續(xù)將剩余的數(shù)據(jù)包長度與8比較，滿足條件則解析出本應(yīng)具有的長度。解析完第2條消息后，數(shù)據(jù)包1剩余長度為6 byte，是不完整的數(shù)據(jù)包，則加入緩存。當(dāng)?shù)?個數(shù)據(jù)包到來，緩存中存在數(shù)據(jù)，將此數(shù)據(jù)包加入緩存進行數(shù)據(jù)包拼接。將拼接后的數(shù)據(jù)包按照同樣的邏輯解析出POF消息頭中的length字段，從而根據(jù)消息長度判斷消息邊界，提取出完整的消息。

圖4 POF數(shù)據(jù)包處理算法實例

以上這種數(shù)據(jù)包處理算法，根據(jù)是否存在緩存決定是直接處理數(shù)據(jù)包還是需要將數(shù)據(jù)包加入緩存進行數(shù)據(jù)包的拼接。在判斷消息邊界過程中，根據(jù)POF消息頭的length字段獲取這條完整POF消息的長度，根據(jù)此長度提取出完整消息；對于不完整的消息需要進行緩存與后續(xù)數(shù)據(jù)包進行拼接后再處理。這種方式避免將所有的數(shù)據(jù)包都加入緩存，有效減少緩存空間并提高數(shù)據(jù)包處理效率。

3.2 解析模塊

經(jīng)過消息提取模塊得到完整的POF消息后便可進行POF消息的解析。解析流程如算法4所示，由于POF消息種類較多，其數(shù)據(jù)結(jié)構(gòu)也各不相同，因此需要首先解析出是哪種類型的消息(算法4第3行)，然后針對特定的消息解析出用戶感興趣的內(nèi)容，例如table id、port id等，并將其生成特定格式的日志，發(fā)送至數(shù)據(jù)庫保存。日志分為會話日志和操作日志，會話日志用來表示一個POF會話的特征，日志內(nèi)容包括IP、MAC、應(yīng)用協(xié)議版本、用戶名稱、登錄登出時間、請求包個數(shù)、響應(yīng)包個數(shù)等信息；操作日志用來表示操作行為，包括操作命令、操作開始時間、操作結(jié)束時間等信息，其中關(guān)鍵內(nèi)容及其描述如表1所示。在會話日志中，可根據(jù)服務(wù)端和客戶端確定通信設(shè)備，當(dāng)結(jié)束狀態(tài)非0時表明非正常結(jié)束，根據(jù)相應(yīng)的結(jié)束狀態(tài)碼判斷異常結(jié)束原因，管理人員可根據(jù)記錄的時間定位到異常行為的發(fā)生點進行異常檢測。在操作日志中需要著重關(guān)注操作命令內(nèi)容，因為它記錄了資源配置、流表和指令塊增刪改、控制器角色更換等操作行為，這些操作與網(wǎng)絡(luò)異常行為息息相關(guān)，例如當(dāng)控制器的角色發(fā)生變化時，表明網(wǎng)絡(luò)中可能出現(xiàn)中斷、崩潰退出或重啟等異常情況，安全分析人員可獲取日志和原始數(shù)據(jù)包回溯分析當(dāng)時網(wǎng)絡(luò)狀況。

表1 關(guān)鍵日志內(nèi)容

算法4POF Message Parse

1:version←get_version(msg)

2:transaction ID←get_xid(msg)

3:type←get_type(msg)

4:switch(type)

5:caseFEATURES_REPLY:

6:get the client, username and login time of the flow

7:casePACKET_IN:

8:get the cookie, table id and port id

9:caseFLOW_REMOED or TABLE_MOD:

10:get the cookie and table id of flow

11:casePORT_STATUS_MESSAGE:

12:get the port id

13:caseINSTRUCTION_BLOCK_MOD or FLOW_MOD or ASM_MOD:

14:get the table id and msg command

15:caseROLE_REQUEST or ROLE_REPLY:

16:get the controller role

17:default:

18:break;

19:generate and send logs

4 實驗結(jié)果

本文設(shè)計的POF協(xié)議解析器是在基于Linux平臺開發(fā)的網(wǎng)絡(luò)安全審計系統(tǒng)上實現(xiàn)的，實驗測試環(huán)境如圖5所示，Spirent測試儀SPT-C100通過交換機與網(wǎng)絡(luò)安全審計系統(tǒng)相連。網(wǎng)絡(luò)安全審計系統(tǒng)使用的操作系統(tǒng)為CentOS 7.6.1810 LTS，內(nèi)核版本為3.10.0-957.el7.x86_64，CPU型號為Intel(R) Xeon(R) Silver 4116 CPU @ 2.10 GHz，內(nèi)存大小為144 GB。Spirent測試儀作為流量產(chǎn)生器，回放提前抓取的控制器與交換機協(xié)商過程的POF數(shù)據(jù)包，交換機設(shè)置鏡像功能，將Spirent發(fā)送的流量全部導(dǎo)入到安全審計系統(tǒng)，安全審計系統(tǒng)采集流量提交給POF解析模塊進行解析，協(xié)議解析結(jié)果通過Web界面可視化進行展現(xiàn)，可將結(jié)果與Wireshark解析結(jié)果對比，驗證POF協(xié)議解析模塊能否正確實現(xiàn)解析。實驗中針對2.1節(jié)所述的不同類型的POF消息都進行了解析結(jié)果對比，POF協(xié)議解析器均能實現(xiàn)正確解析。圖6以FEATURES_REPLY消息為例進行說明，圖6(a)為協(xié)議解析器的解析結(jié)果，包含版本、消息類型，交換機型號等信息，圖6(b)為Wireshark解析結(jié)果，兩者對比無誤，說明此POF協(xié)議解析模塊能夠正確解析出用戶感興趣的字段并生成相對應(yīng)的日志。

圖5 測試環(huán)境

(a) 協(xié)議解析器解析結(jié)果

(b) Wireshark解析結(jié)果圖6 POF協(xié)議解析結(jié)果

性能測試采用每秒并發(fā)連接數(shù)、吞吐和每秒包數(shù)這3個指標，實驗數(shù)據(jù)包為對抓取的POF數(shù)據(jù)包進行改造后的數(shù)據(jù)包，只包含完整協(xié)商過程。在測試過程中使用2種方式，一種是只生成表示POF會話特征的會話日志，另一種是均生成會話日志和表示行為特征的操作日志。在測試吞吐過程中，調(diào)整數(shù)據(jù)包中PACKRT_IN和PACKET_OUT發(fā)送的次數(shù)，構(gòu)造大流量高吞吐的場景。測試結(jié)果如圖7所示，只生成會話日志時能達到62000的每秒并發(fā)連接數(shù)(CPS)、700 Mbps吞吐和每秒能處理74萬個數(shù)據(jù)包；會話日志和操作日志均生成的時候也能達到30000的CPS、460 Mbps吞吐和每秒處理53萬個數(shù)據(jù)包的性能。

(a) 每秒并發(fā)連接數(shù)

(b) 吞吐量

(c) 每秒包數(shù)圖7 性能測試結(jié)果

從測試結(jié)果可以看出，POF協(xié)議解析過程中只生成會話日志時有更好的性能，能夠解析更多的POF數(shù)據(jù)流；當(dāng)2種日志均生成時，性能雖然降低，但能有更細粒度的解析結(jié)果。因此，可根據(jù)實際網(wǎng)絡(luò)環(huán)境選擇合適的方式。

5 結(jié)束語

為了監(jiān)測和防范SDN網(wǎng)絡(luò)中內(nèi)部安全問題，本文基于網(wǎng)絡(luò)安全審計系統(tǒng)設(shè)計并實現(xiàn)了POF協(xié)議解析器。該協(xié)議解析器能夠在線對POF流量實現(xiàn)深度解析生成日志，并通過Web界面可視化展現(xiàn)。通過功能驗證，POF協(xié)議解析器能夠正確解析出POF版本、交換機設(shè)備信息、流表信息、端口信息、控制器角色等關(guān)鍵信息；經(jīng)過性能測試，集成POF協(xié)議解析器的網(wǎng)絡(luò)安全審計系統(tǒng)在滿足不丟包情況下至少能達到的性能每秒連接數(shù)為30000，吞吐為460 Mbps，每秒處理數(shù)據(jù)包53萬個，可以為SDN的安全審計工作提供有力支持，也能夠為其他新型協(xié)議解析提供參考。