基于SDN的家用路由器安全审计工具

王宇， 李巍， 李舟军

(北京航空航天大学 计算机学院，北京 100083)

软件定义网络(software defined network,SDN)是一种新型架构，在这种网络架构中，路由器的控制功能被抽离出来. 而路由器通信所需要的各种协议(比如ARP(address resolution protocol)协议中MAC(media access control)地址的学习)，都在集中的控制器上进行完成，称之为SDN控制器.

这种新型架构重新定义了网络，也提高了网络中的通信效率，目前这种SDN控制器和路由器之间的交互采用的是OpenFlow协议.

安全审计的意义在于对目前的系统做出评价、对存在的威胁进行分析，最后进行对整个系统的安全性进行评估，在SDN架构中，这种分析的结果可以放在SDN控制器上集中展示，并且在SDN控制器上进行统一的控制.

在审计系统的标准上，在Zhang[1]运用到了CC国标. 而在审计系统的层级上，Ma[2]分析了多级服务器的审计系统的实现，主要致力于研究多级系统的审计，并且加入了审计智能分析的功能，但SDN的主要架构只有两层.

在审计技术中，有系统从用户的操作日志中进行分析，对用户的操作进行总结性的审核[3]，这项技术在轻量级的路由器审计上并不适用，因为路由器上并没有太大的内存提供给程序进行分析. 同时，在这个基础上，Lane等[4]也尝试从系统调用级别上进行操作的拦截，在内核上建立一个审计系统，但是在家用路由器上，没有这种权限.

在系统架构和部署方式上，目前在系统架构上，主要采用C/S[5]，服务器和客户端模式的比较多，在SDN架构下，控制器对应了C/S架构中的server，而在部署方式上，主要采用集中式的部署方式，例如Estrin等[6]实现的安全审计系统，实行了对于日志的统一处理，在此上面进行审计系统的实施，但这种方式的缺点并没有达到网络与审计架构的耦合.

在流量分析上，目前基于流量的分析研究有一种基于信息熵计算的分析方法. 比如在Song等[7]的工作中，就用信息熵检测了网路流量中的异常，并最终结合了大数据的分析方法. 同时，信息熵也可以用来研究具体协议的异常之处，比如在Chen[8]的工作当中，就将信息熵用来检测DNS的攻击.

在吕慧颖等[9]的工作中，提出了一种基于攻击模拟的网络安全风险分析方法，这对于审计系统来说应该是个新思路，即从一个攻击者的角度去模拟，然后提出分析方式，在审计中，也可以如此. 在李明等[10]的工作中，提出了一种基于AHP的网络化弹药攻击决策攻击方法，这些方法对审计工作有较大的启示，能够防御批量安全攻击事件的审计系统更强大.

在Scott-Hayward等[11]的工作中，对目前的SDN安全性进行了调查，并讨论了使用SDN框架导出的安全性增强和框架引入的安全挑战. 在Shin等[12]的工作中，提出了一种新型的基于SDN的攻击方式，在Kreutz等[13]的工作中，主要针对了SDN的可靠性和安全性进行了研究，并且提出了几种可能启用SDN漏洞的威胁载体.

在Han[14]的工作中，提出了一种基于SDN架构下，对SDN中的流量进行分析的攻击检测方式，采用了基于信息熵的检测方法，这种检测方法主要是针对SDN控制器的，并提出了之后的基于SDN的攻击检测主体，将从SDN的单个控制器转向SDN的一个子网.

本文在传统的C/S审计架构下，提出了一种将审计融合到网络环境中，运用SDN特殊架构的审计架构，运用家用路由器向SDN控制器发送的请求，进行流量分析审计. 基于上述架构，实现了对于流量中(IP,端口)的信息熵计算，并在最终的展示模块上，预留给了管理员控制和管理的接口，实现了管理和控制.

1 相关技术分析

1.1 网络嗅探

1.1.1 Libpcap实现框架

为了实现在轻量级的路由器上进行流量分析，本文将从底层的libpcap上进行抓包.

在libpcap中，抓包框架主要通过几个重要的模块实现，包括设备查询模块、设备读取模块、数据包过滤模块、数据包捕获模块、数据包处理模块.

① 设备查询模块，其作用查询目前设备中可以用来嗅探的设备. ② 设备读取模块，其作用是读取上一步已经获得的设备名称，并打开，返回一个后续模块所需要的会话句柄. ③ 数据包过滤模块，生成嗅探器能够“读懂”的BPF代码，在生成在整个框架中，数据包过滤模块主要作用在后续的数据包获取模块上. ④ 数据包获取模块，网卡的数据包进行筛选和获取. ⑤ 数据包处理模块，数据包处理模块是整个框架灵活性最高的模块.

1.2 SDN架构及南向协议

SDN的确切定义目前最具代表性的是ONF组织提出的基于OpenFlow的架构. ONF认为SDN架构分为3个层面：应用层面、网络控制层面、网络架构层，其中网络架构层的通信受到网络控制层面的控制来进行通信，具体架构如图 1所示.

图1 基于OpenFlow的SDN网络架构Fig.1 SDN network architecture based on OpenFlow

目前主流的通信协议是Openflow协议，本文也将针对OpenFlow协议进行研究.

1.3 OpenFlow协议标准

1.3.1 OpenFlow协议

OpenFlow交换机与controller的连接建立和连接建立之后，OpenFlow交换机和controller都会进行通信，相应的通信是OpenFlow协议的主体，OpenFlow协议将消息类型划分了3种，根据消息的发出者来进行区分：controller-to-switch，由控制器controller发起，主要用来管理和获取Switch的状态；Asynchronous，由Switch发起，用来告知SDN控制器网络事件和Switch内部的配置变化；Symmetric，无需建立，主要是连接建立之前的Hello、Echo等.

连接建立的整个过程大致有3个阶段：①Hello通信阶段；②设备信息获取阶段；③通信阶段.

通信流程的具体流程如图2所示.

图2 OpenFlow交换机与控制器通信流程Fig.2 OpenFlow switch and controller communication process

2 SABIE系统需求分析与设计

2.1 SABIE系统需求分析

整个工具需要的功能设计主要包括对于流量信息的获取、对于流量信息的分析、对于流量分析结果的最终展示. 流量信息获取的要求是占用内存小，并且流量信息获取的主要数据为IP地址和端口号，满足最小的数据传输需求.

2.2 SABIE系统结构

2.2.1 系统部署结构

系统结构主要分为3个部分，即客户端和服务器和SDN控制器. 系统结构部署图如图3.

图3 系统结构部署图Fig.3 System structure deployment diagram

2.2.2 SABIE系统模块功能

系统功能模块图如图4.

图4 SABIE系统功能模块图Fig.4 SABIE system function module diagram

2.2.3 SABIE系统功能时序图

系统功能时序图描述了整个系统工作的流程，如图5所示.

图5 SABIE系统结构时序图Fig.5 SABIE system structure timing diagram

2.3 主要工作过程描述

系统的工作前提是路由器需要加入到SDN架构中，并且路由器是支持相应的协议的.

在服务器上，需要对客户端到来的信息进行收集，并通过数据包封包分析技术进行分析，获取到所需要的信息，并且在服务器上进行存储和管理，通过数据库技术来实现存储和管理，并读取数据库进行相关的计算，获得最终的审计结果.

在SDN控制器上，需要对最终的审计信息进行展示，这个展示需要运用到web服务器的实现，通过查看web内容，来判断是否会存在异常的情况. 在发现异常之后，又会给控制器一个接口，来改变目前系统的运行状态，管理者可以通过这种改变来定位目前系统中存在的潜在威胁.

3 SABIE系统功能实现

3.1 数据包获取模块

数据包获取模块通过直接调用libpcap函数进行设计和实现.

数据包获取模块主要分为以下步骤.

① 设备查询模块. 设备查询模块通过调用libpcap中的pcap_lookupdev函数进行实现.

② 设备读取模块.

③ 过滤器设置和应用模块. 这个模块主要是为了之后的结果更加简洁明了而设计的，过滤到那些无关紧要的数据包.

④ 数据包获取模块. 将截获到的数据包通过回调函数的方式，进一步的进行操作.

其中，过滤器设置主要分为两部分：首先通过过滤器进行物理的筛选，在客户端进行. 逻辑筛选的主要逻辑是在服务器上对所需要的信息进行裁剪，在服务器上，对于TCP(transfer control protocol)数据包，只需要IP地址、数据包长度等信息，并需要对整个数据包的数据内容进行逻辑筛选，筛选出服务器需要的信息，再通过socket进行传输，以达到整个系统的实现.

数据包信息传输的底层实现采用socket传输实现.

3.2 数据包信息分析处理模块

3.2.1 数据分析模块

在整个系统中，审计服务器可以接收到来自于客户端的数据包信息，而服务器上需要对数据包信息进行分析，需要解决的是什么样的信息才是整个审计系统需要的.

在TCP报文中，可以获取到的信息主要有源端口、目的端口，对应的是具体的进程信息，这对之后的信息分析部分的设计会有帮助，主要通过IP地址和端口的序列进行信息的整合.

OpenFlow协议数据报文格式如图6所示.

图6 OpenFlow数据报文格式Fig.6 OpenFlow data packet format

对应结构体设计见表1.

表1 Struct OFHeaderTab.1 Struct OFHeader

其中，8位版本号指的是OpenFLow协议版本号，类型指的是OpenFlow协议中的具体协议号，消息长度指的是首部和后续载荷总共的长度，Transaction ID是一个内部的标识，用来将request和reply进行匹配而生成的一个字段.

关于类型中，具体指什么类型，如表2.

表2 OpenFlow协议Type具体含义对照表

Tab.2 OpenFlow protocol Type specific meaning comparison table

0Hello1Error2Echo Request3Echo Reply4Vendor5Features Request6Features Reply7Get Config Request8Get Config Reply9Set Config10Packet Input Notification11Flow Removed Notification12Port Status Notification13Packet Output14Flow Modification15Port Modification16Stats Request17Stats Reply18Barrier Request19Barrier Reply

重点是packet-in报文类型，即报文类型type字段为10的报文，这个报文产生的缘由是在OpenFlow交换机在自己内部的流表中找不到对应的流表项则会向SDN控制器发出packet-in请求，请求SDN中央控制器的指示. 目前的一些DDoS攻击，已经可以通过这种方式，进行针对SDN控制器的DDoS攻击了，所以在之后的审计信息计算过程中，会加入对这一个分支的具体检测.

在处理和计算模块当中，需要对流量的异常与否进行检测，这个检测的方法主要是通过计算信息熵来完成.

3.2.2 审计信息处理模块

具体算法流程如下.

假设目前设定的抓包间隔为T，固定的抓包个数为W.

① 在获取完W个数据包的信息之后，进入步骤②.

② 记(目的IP，目的端口)为一组数据对，以这个数据对为标准来区分所有数据，记数据对的个数为N，每一组数据对的出现次数为

μi， 1≤i≤N.

③ 通过μi和W计算出关于(目的IP，目的端口)的信息熵Hα为

(2)

④ 记每个packet-in包中(目的IP)出现的个数为N2，每一组(目的IP)次数为θi，1≤i≤N2，通过θi和W计算出关于(目的IP，packet-in消息)的信息熵Hβ为

(3)

Hα和Hβ的主要不同点在于，Hα反映了通过路由器的流量不规律性是否出现了变化，即它可能会存在DDoS攻击，而Hβ反映了这种变化的具体针对目标是针对网络中的主机还是针对的是SDN控制器本身.

信息熵计算完成后，将会运用数据库技术将相应的信息熵和时间段记录下来，将最终的结果交于SDN控制器，同时，信息熵的展示模块也将会在SDN控制器上进行，审计服务器端的工作就是获取和分析信息，并计算出SDN控制器所需要的结果.

3.3 审计信息展示和控制管理模块

3.3.1 审计信息展示模块

在得到了信息熵的结果之后，将会通过echarts等开源的项目对最终的审计结果进行展示，具体实现是在最终的web界面中展示目前最新的10个时间段的信息熵计算值，展示方式是通过在网页中调用echarts API，在echarts中输入目前的最新10个信息熵计算值，然后在进行显示，管理者可以从信息熵的变化中看出是否会存在异常.

3.3.2 控制管理模块

在控制管理模块中，通过数据库脚本对整个系统的运行进行配置，主要是包括数据库中计算信息熵的时间间隔和路由器上的抓包间隔时间的配置.

SDN控制器的南向协议中，有比如OpenFlow协议中的Set Config和ovsdb协议等功能可以实现SDN控制器对于OpenFlow交换机的配置管理，但是在配置的同时，还需要对OpenFlow交换机中的逻辑结构进行控制，虽然在OpenFlow协议中有配置，ovsdb协议可以对Openvswitch中的数据库进行管理，但是在对于OpenFlow交换机上的具体程序的控制是没有的. 基于这个情况，采用的是OpenFlow交换机主动地去询问SDN控制器目前的控制逻辑结构.

控制管理模块是保证了SDN控制器能够和OpenFlow交换机进行通信的一个模块，这也体现了整个系统架构的灵活性. 这部分的具体实现是通过更改数据库中event的时间间隔和抓包参数配置进行管理，管理者在发现目前的流量中存在异常后，可以通过更改数据库中的event时间间隔更改信息熵计算时间差，通过抓包参数配置来更改抓包间隔和个数，来实现最后的管理模块.

4 系统测试

4.1 实验环境

路由器：NETGEAR4300，系统版本：OpenWrt Chaos Calmer 15.05，安装Openvswitch[2.3.90].

服务器：Ubuntu17.04，安装mysql[5.7.18].

SDN控制器：与服务器位于同一台机器，安装opendaylight，apache，php.

4.2 功能测试

功能测试中将测试每个模块的功能实现，下面将分模块进行测试.

由于路由器上部署程序将涉及到嵌入式设备的编译，需要搭建交叉编译环境，技术实现难度太大，将采用监听路由器输出端口的方式进行测试.

首先是在路由器上，对端口的监听进行配置.

监听端口配置完毕后，进入服务器，打开监听模块，运行. 在监听PC上运行，分别运行catchpacket和checkchange程序：进入opendaylight，运行控制器，在控制器的node下可以看到OpenFlow交换机，目前的配置是每隔10 min抓取一次数据包，所以等待大约2 h，就可以获得10次信息熵的计算值.

如图7，查看web界面：可以看到，管理员已经可以查看目前的网络状态的信息熵计算.

图7 查看web界面Fig.7 View web

通过控制功能测试，通过改写脚本envent.sql中的两个时间，如图8，改为10 s.

图8 修改脚本Fig.8 Modify script

在数据库中查看HaInformation表的计算结果，发现现在的计算结果间隔为10 s，还需要进行的测试是，信息熵的计算能否真正地反应出网络流量中的异常. 这个测试主要分为两个小实验：用Nmap(the network mapper)进行端口扫描；查看信息熵计算结果. 结果如图9～11所示.

在Nmap扫描实验中，前9个正常网络数据都在2～4波动，而第10个数据是Nmap扫描时间段的信息熵值，Nmap对每个端口进行扫描时候，会截到大量端口不一样的包表现在信息熵上，是信息熵的突然增大，如图9.

图9 Nmap扫描结果Fig.9 Nmap scan results

图10 LOIC-DDoS攻击结果Fig.10 LOIC-DDoS attack results

图11 程序消耗的字节数Fig.11 The number of bytes consumed by the program

在LOIC-DDoS攻击实验中，前5个数据是正常网络数据. 而在LOIC软件中进行DDoS攻击，截获的数据包的目的端口几乎一样，只有源端口在不停变化. 表现在信息熵上，是信息熵从第6组数据信息熵开始迅速变小，7、8、9、10组数据由于只能截到一样的(目的IP，目的端口)，所以计算值为0.

这两个小实验说明信息熵的计算在表现异常上很明显.

4.3 性能测试

性能测试主要分为两方面，所占带宽和程序运行所占内存.

所占带宽分析：在程序中，每个报文所截取的字节是14+20+20=54 B，在客户端没有对TCP和IP的报文分支进行分析，所以选择了最长的TCP报文头部，加上ethernet和IP报文头部，总共是54 B.

在数据库中，查询在运行阶段所有到来的报文的总报文数和总长度如表3，可以得到总共长度，计算总报文数×54，得到程序消耗字节数.

表3 程序消耗字节分析Tab.3 Program consumption byte analysis

可以看出，程序所占带宽的比例不大. 内存查看，通过ps指令分析，可以查看到程序运行的内存在8 MB左右.

目前Openwrt嵌入式设备的内存大约在16 MB，所以程序理论上是可以运作的.

5 结 论

从传统C/S架构出发，提出了一种基于SDN架构的审计系统设计思路. 在这个架构下，保证了路由器的正常运行，审计系统的正常工作，达到了审计路由器中是否存在DDoS攻击的目的，并且在SDN控制器上加入了可以控制和展示的模块，使得整个系统可以完整地运行. 并且整个系统对于路由器内存的使用仅有8 MB，所用网络负载2.67%，达到了轻量级的目的. 未来的工作主要有：①研究基于SDN中Flow的检测和分析方法;②研究基于OpenFlow协议的控制模块.