储苏红,刘 磊

(1.中国科学院声学研究所国家网络新媒体工程技术研究中心,北京 100190; 2.中国科学院大学,北京 100049)

0 引 言

随着信息技术的蓬勃发展，新型网络业务与应用层出不穷，其多元化、个性化的网络需求给静态僵化的传统网络带来了新的挑战。依靠端到端连接和尽力而为路由转发的传统网络无法保障低延迟、高可靠通信[1-2]，另外传统网络依赖于硬件设备，不同厂商的设备难以统一部署管理，而且工作方式固定，难以根据业务需求自定义添加新功能，因此新型网络的研发推广势在必行。软件定义网络(Software Defined Networking, SDN)[3-4]以其集中流管理、开放可编程、适应性强的特点脱颖而出，通过在交换机与SDN控制器间定义统一编程接口，实现数据平面与控制平面的解耦，使得网络具有强大的灵活性，可轻松实现网络系统功能的修改、调整、拓展和提升，从而加快网络业务部署的进程。

SDN呈现出快速发展的趋势，也成为异构网络场景实施的关键推动因素，在数据中心、城域网、校园网等场景均已实现落地[5]。随着SDN的推广，其带来的网络安全问题日益彰显。通过防火墙、入侵检测系统可以监测DoS攻击、非法访问等外部网络攻击和威胁[6]，但是对于交换机/控制器配置故障、转发设备资源滥用、虚假流规则注入[7]、数据泄露等内部安全威胁不能及时发现和跟踪[8]。协议无感知转发(Protocol Oblivious Forwarding, POF)[9-10]作为SDN的南向协议，是控制器和可编程交换机之间通信的桥梁[11]。POF消息中含有大量重要的控制、配置信息，获取POF交换机硬件信息、设置交换机配置、进行POF控制器角色变换、下发流规则等行为均需通过POF协议实现。因此可通过解析POF协议实现对内部安全威胁进行监测和防范。但是目前并没有针对POF协议的自动化在线解析工具，常用的通用数据包分析软件(例如Wireshark)需要捕获数据包后依赖专业分析人员进行分析[12]。

因此，本文基于网络安全审计系统，设计并实现一种新的POF协议解析器。该协议解析器能够在线对POF消息进行深度解析，实时监测SDN网络中的通信内容，及时中断非法操作保障网络内部安全。

1 网络安全审计系统

网络安全审计系统是为了应对日益严峻的网络安全形势而设计的能够对高速网络数据进行采集留存和分析检索的系统[13-14]。通过旁路部署捕获流经交换机的流量，对采集的流量进行深度协议解析，并将解析结果进行存储和展示，可实现实时监控用户网络行为，及时发掘并阻止潜在威胁[15]。网络安全审计系统架构由7个模块构成，分别是：采集模块、数据包预处理模块、数据包存储模块、协议识别模块、协议解析模块、日志管理模块和展现模块，如图1所示。

图1 网络安全审计系统架构

1)采集模块。负责流量捕获，基于DPDK(Data Plane Development Kit)[16-17]技术实现将网卡上收到的数据包以零拷贝的方式复制到用户空间。

2)数据包预处理模块。主要负责IP重组、TCP重组、流管理等操作，保证到达上层的数据包正确有序。

3)数据包存储模块。存储捕获的数据包，以供后续的取证分析。

4)协议识别模块。由于应用层协议众多且协议格式不固定，因此在进行应用层协议解析之前需要针对不同的协议进行区分。本模块中采取协议号和端口号匹配方式[18]将报文分发到不同的解析模块。

5)协议解析模块。按照高层协议格式，对重组好的数据帧中的各个字段进行分析，识别出设备信息、登录信息、操作命令等关键信息，将用户关心的特定内容提取出来，并按照一定的格式封装成解析日志并发送至数据库保存。

6)日志管理模块。负责存储和搜索解析日志，对协议解析模块生成的日志按照一定的格式进行整合，并可根据展现模块提供的关键字进行日志检索来进行可视化显示。

7)展现模块。以图形化的方式为用户展示数据采集和分析的结果，可根据对应的日志下载原始数据包进行取证分析，另外基于Web的用户界面允许网络管理员实时监控网络流量信息，可根据用户需求进行采集分析的自定义配置。

2 POF协议分析

2.1 POF消息类型分析

POF是一种高度灵活和可编程的SDN转发面技术，以{type, offset, length}[19-20]三元组定义字段，并定义了一套协议无关的指令集对数据包做处理[21-22]。POF控制器对POF交换机的配置和管理主要是通过POF消息实现的，POF消息主要包括对称消息[23]、交换机配置消息、异步消息[24]、控制器命令消息、控制器角色消息[25]。下面对具体的消息类型和应用场景进行介绍。

1)对称消息。

HELLO消息：用于控制器和设备之间的握手。

ECHO消息：用于探测连接状态、延迟和带宽。

2)交换机配置消息。

FEATURE消息：用于控制器获取交换机设备的硬件信息，如设备编号、端口等信息。

CONFIG消息：用于控制器配置和查询交换机参数。

3)异步消息。

PACKET_IN消息：用于交换机将数据包上报给控制器。

FLOW_REMOVED消息：用于交换机删除表项后报告给控制器。

PORT_STATUS消息：用于在握手阶段和端口状态发生变化时，交换机向控制器上报其当前状态。

RESOURCE_REPORT消息：用于交换机将软件资源配置信息上报给控制器，如支持的表数目、匹配域的总字节数等。

4)控制器命令消息。

PACKET_OUT消息：用于控制器发送数据包给交换机。

FLOW_MOD消息：用于流表操作，包括添加、删除、修改流表项，由控制器下发给交换机，指导交换机对数据包的处理。

TABLE_MOD消息：由控制器发送给交换机，用于flow table的创建。

INSTRUCTION_BLOCK_MOD消息：用于创建、删除或修改一个指令块。

ASM_MOD消息：用于创建或修改一个指令块。

5)控制器角色消息。

ROLE消息：交换机与多控制器连接时，控制器发送ROLE_REQUEST消息给交换机改变控制器角色，交换机回复ROLE_REPLY消息。

交换机与控制器通信时需要通过以上消息确定通信的POF版本并收集交换机的信息，具体的交互流程如图2所示，分为3个阶段：1)进行POF版本协商阶段，交换机与控制器建立TCP连接后，控制器主动发送HELLO消息，交换机收到后应答HELLO消息，在此过程中可以确定POF协议版本，当控制器和交换机的协商版本不兼容时，便会报告出错信息并断开连接；2)进行交换机配置询问阶段，控制器向交换机发送FEATURES_REQUEST消息询问交换机的硬件信息，交换机进行应答，报告设备编号、端口数量、支持的最大表数目等信息；3)在交换机配置设置和资源上报阶段，交换机应答参数并上报交换机的资源配置信息、每个端口的状态信息，当流表中没有匹配的流规则或者流规则是发往控制器的时候，交换机向控制器发送PACKET_IN消息，控制器下发PACKET_OUT指导交换机处理数据包[26]。

图2 控制器与交换机交互流程

2.2 POF协议头分析

不同类型的POF消息具有不同的数据结构，字段实际内容的偏移和长度值也不同。但都是以相同的消息头开始，消息头具有固定8 byte的长度，结构如图3所示，其中version表示POF版本号，本文中以2.1版本的POF消息进行解析；type是POF消息类型；length是POF消息总长度；xid表明事件ID，对于同一事件例如FEATURES_REQUEST和FEATURES_REPLY的事件ID相同[27]。解析从第1个字段按序进行，解析完固定结构的消息头后，再根据不同消息类型具有的特有数据结构来解析字段[28-29]。

图3 POF消息首部结构

3 POF协议解析器设计

在交换机和控制器交互过程中传递了很多设备和配置信息，当发生异常行为时可根据这些信息快速定位到网络安全问题发生点，并且可以在事后进行溯源取证。本文基于网络安全审计系统，针对2.1版本的POF协议设计并实现了协议解析器。该协议解析器能够实现对网络链路上采集到的POF数据包进行深度解析并实时产生审计数据，以日志的形式发送至数据库保存。POF协议解析器主要包含2个模块：消息提取模块和消息解析模块。

3.1 消息提取模块

通过网络安全审计系统的数据包预处理模块复原出POF数据包的有序载荷，再由协议识别模块通过POF协议号和端口6643将POF数据包发送到POF协议解析器进行协议解析。但是经过数据包预处理模块处理后的数据包只能保证是严格有序的，由于TCP/IP其基于流的传输方式，不能保证每个TCP数据包都是一个完整的应用层POF消息或只包含一个POF消息[30-31]。因此，POF协议解析器需要先对收到的POF载荷进行处理，提取出完整的POF消息后才能进行后续的协议解析流程。处理POF数据包得到完整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的主流程中，根据是否已经存在缓存对接收到的数据包分别进行处理(算法1第5～7行)。这是因为若对每个新来的数据包都加入缓存处理，将会浪费大量的缓存空间，而且数据包拷贝也会影响解析器的性能；对于不完整的POF消息，解析器又无法实现正确解析，则需要将数据包加入缓存，与其他数据包拼装组成一条完整的消息。针对这2种场景设计的对原始数据包直接处理和对缓存数据处理的流程如算法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中的数据包为例，说明以上数据包处理算法的执行过程。首先cache中无缓存数据，收到交互过程中的第1个数据包载荷后，判断数据包长度是否不小于8 byte。这是因为POF所有消息都包含相同8 byte结构的首部，因此最小的POF数据包载荷是8 byte，当收到的数据包长度小于8 byte时表明其是不完整的数据包，无法完成正确解析，只能直接加入缓存。图4中的第一个数据包长度是22 byte，满足上述条件，于是解析出POF消息头中的length字段，length字段的值是8，表明这条完整的POF消息应该具有的长度是8 byte，根据length长度提取出第1条完整的消息；继续将剩余的数据包长度与8比较，满足条件则解析出本应具有的长度。解析完第2条消息后，数据包1剩余长度为6 byte，是不完整的数据包，则加入缓存。当第2个数据包到来，缓存中存在数据，将此数据包加入缓存进行数据包拼接。将拼接后的数据包按照同样的逻辑解析出POF消息头中的length字段，从而根据消息长度判断消息边界，提取出完整的消息。

图4 POF数据包处理算法实例

以上这种数据包处理算法，根据是否存在缓存决定是直接处理数据包还是需要将数据包加入缓存进行数据包的拼接。在判断消息边界过程中，根据POF消息头的length字段获取这条完整POF消息的长度，根据此长度提取出完整消息；对于不完整的消息需要进行缓存与后续数据包进行拼接后再处理。这种方式避免将所有的数据包都加入缓存，有效减少缓存空间并提高数据包处理效率。

3.2 解析模块

经过消息提取模块得到完整的POF消息后便可进行POF消息的解析。解析流程如算法4所示，由于POF消息种类较多，其数据结构也各不相同，因此需要首先解析出是哪种类型的消息(算法4第3行)，然后针对特定的消息解析出用户感兴趣的内容，例如table id、port id等，并将其生成特定格式的日志，发送至数据库保存。日志分为会话日志和操作日志，会话日志用来表示一个POF会话的特征，日志内容包括IP、MAC、应用协议版本、用户名称、登录登出时间、请求包个数、响应包个数等信息；操作日志用来表示操作行为，包括操作命令、操作开始时间、操作结束时间等信息，其中关键内容及其描述如表1所示。在会话日志中，可根据服务端和客户端确定通信设备，当结束状态非0时表明非正常结束，根据相应的结束状态码判断异常结束原因，管理人员可根据记录的时间定位到异常行为的发生点进行异常检测。在操作日志中需要着重关注操作命令内容，因为它记录了资源配置、流表和指令块增删改、控制器角色更换等操作行为，这些操作与网络异常行为息息相关，例如当控制器的角色发生变化时，表明网络中可能出现中断、崩溃退出或重启等异常情况，安全分析人员可获取日志和原始数据包回溯分析当时网络状况。

表1 关键日志内容

算法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 实验结果

本文设计的POF协议解析器是在基于Linux平台开发的网络安全审计系统上实现的，实验测试环境如图5所示，Spirent测试仪SPT-C100通过交换机与网络安全审计系统相连。网络安全审计系统使用的操作系统为CentOS 7.6.1810 LTS，内核版本为3.10.0-957.el7.x86_64，CPU型号为Intel(R) Xeon(R) Silver 4116 CPU @ 2.10 GHz，内存大小为144 GB。Spirent测试仪作为流量产生器，回放提前抓取的控制器与交换机协商过程的POF数据包，交换机设置镜像功能，将Spirent发送的流量全部导入到安全审计系统，安全审计系统采集流量提交给POF解析模块进行解析，协议解析结果通过Web界面可视化进行展现，可将结果与Wireshark解析结果对比，验证POF协议解析模块能否正确实现解析。实验中针对2.1节所述的不同类型的POF消息都进行了解析结果对比，POF协议解析器均能实现正确解析。图6以FEATURES_REPLY消息为例进行说明，图6(a)为协议解析器的解析结果，包含版本、消息类型，交换机型号等信息，图6(b)为Wireshark解析结果，两者对比无误，说明此POF协议解析模块能够正确解析出用户感兴趣的字段并生成相对应的日志。

图5 测试环境

(a) 协议解析器解析结果

(b) Wireshark解析结果图6 POF协议解析结果

性能测试采用每秒并发连接数、吞吐和每秒包数这3个指标，实验数据包为对抓取的POF数据包进行改造后的数据包，只包含完整协商过程。在测试过程中使用2种方式，一种是只生成表示POF会话特征的会话日志，另一种是均生成会话日志和表示行为特征的操作日志。在测试吞吐过程中，调整数据包中PACKRT_IN和PACKET_OUT发送的次数，构造大流量高吞吐的场景。测试结果如图7所示，只生成会话日志时能达到62000的每秒并发连接数(CPS)、700 Mbps吞吐和每秒能处理74万个数据包；会话日志和操作日志均生成的时候也能达到30000的CPS、460 Mbps吞吐和每秒处理53万个数据包的性能。

(a) 每秒并发连接数

(b) 吞吐量

(c) 每秒包数图7 性能测试结果

从测试结果可以看出，POF协议解析过程中只生成会话日志时有更好的性能，能够解析更多的POF数据流；当2种日志均生成时，性能虽然降低，但能有更细粒度的解析结果。因此，可根据实际网络环境选择合适的方式。

5 结束语

为了监测和防范SDN网络中内部安全问题，本文基于网络安全审计系统设计并实现了POF协议解析器。该协议解析器能够在线对POF流量实现深度解析生成日志，并通过Web界面可视化展现。通过功能验证，POF协议解析器能够正确解析出POF版本、交换机设备信息、流表信息、端口信息、控制器角色等关键信息；经过性能测试，集成POF协议解析器的网络安全审计系统在满足不丢包情况下至少能达到的性能每秒连接数为30000，吞吐为460 Mbps，每秒处理数据包53万个，可以为SDN的安全审计工作提供有力支持，也能够为其他新型协议解析提供参考。