基于OpenFlow的SDN状态防火墙

王 鹃，刘世辉，文 茹，洪 智 ，王 江 ，樊成阳 ，张浩喆

1.软件工程国家重点实验室，武汉 430072

2.空天信息安全与可信计算教育部重点实验室，武汉 430072

3.武汉大学 计算机学院，武汉 430072

4.清华大学 计算机科学与技术系，北京 100084

1 引言

伴随着以云计算、大数据为代表的新型业务的发展，传统网络难以满足其提出的灵活资源需求，主要是因为传统网络早已变得过于复杂且只能处于静态的运行模式。所以，亟需一种全新的网络架构来实现网络的灵活管理，由此SDN[1]应运而生。软件定义网络SDN（Software Defined Network）是由美国斯坦福大学Clean Slate研究组提出的一种新型网络创新架构，可通过软件编程的形式定义和控制网络，其本质特点是控制平面和数据平面的分离以及开放的可编程性，使得网络管理变得更加简单、灵活，被认为是网络领域的一场革命。

OpenFlow[2]是目前SDN的主流协议，其定义了SDN控制器和交换机之间的通信标准。通过网络控制平面和数据平面的分离实现网络的灵活控制，控制层利用OpenFlow协议向交换机下发相应指令，从而对整个网络实现集中控制。目前，基于OpenFlow的SDN设备已经在实际中得到了一定规模的部署。

然而，随着SDN的发展和应用，基于OpenFlow的SDN网络也面临着很多新的安全挑战[3-12]。其中一个重要的威胁是OpenFlow协议的无状态性使得在SDN网络中无法实现更细粒度的访问控制。目前SDN的防火墙应用模块并不完善，其功能只是简单进行包过滤，仅仅对网络流量中首个数据包进行安全处理，实现了简单的访问控制，但是这种简单的控制，对于整个网络的安全防护是远远不够的。

如果网络管理员想要实现基于状态的细粒度访问控制，例如外网不能与内网进行直接连接操作，但是内网可以请求获得外网的数据。对于现有的SDN控制器[13]的防火墙功能是无法满足以上功能要求的。此外，现有的架构中，SDN控制器是集中控制中心，无论是包过滤防火墙还是状态检测防火墙[14]均应被部署在控制器中。但是，当主机或者网络设备发送数据包时，除第一个数据包会被控制器检测外，只有当前流的第一个包会被控制器检测，对于其他数据包，控制器是无法直接进行决策的。如果把每个数据包都送给控制器进行检测，又会给控制器带来极大的性能开销。因此，如何实现有状态的细粒度访问控制是当前SDN网络面临的一个重要挑战。

针对这一问题，从SDN架构特点出发，通过在SDN交换机中增加状态表和状态转换表以及在控制器中添加状态表，设计并实现了一种基于OpenFlow的SDN状态检测防火墙系统。本文主要贡献有以下几点。

（1）SDN防火墙大多为传统的包过滤防火墙，缺少状态检测功能，而本文通过交换机和控制器协同工作的方式实现对全局网络通信状态的检测。这种设计方案相对高效且不违背SDN架构设计的宗旨和初衷，在保证控制器的集中化控制特性不受影响的基础下，在控制器和交换机之间使用较小的通信量实现了控制器对全局网络通信状态的获取和控制。

（2）实现了基于状态的数据流转发。现有OpenFlow流表是无状态的，因为无法完成对网络通信状态进行检测的功能，带来了很多安全威胁，如无法实现细粒度访问控制、防御DDos攻击困难等。本文对OpenFlow协议中定义的流表的基本结构进行了修改，添加了相关状态项，使得数据流转发不再与状态无关，完成了对状态表的维护与更新的功能。同时，管理员可以基于状态表定义规则，实现细粒度的访问控制。

（3）性能分析表明，相对于传统的基于包过滤的防火墙，本文提出的基于状态的防火墙综合性能更优。

2 相关工作及分析

目前，SDN防火墙方面的相关工作有：

Shin等人提出了一个OpenFlow安全应用开发框架FRESCO[7]，它是对NOX[15]控制器进行的二次开发，在对NOX内核进行安全加固的基础上，对外提供遗留网络安全系统的接口，保证平台的最大兼容性。FRESCO包含16个基本模块，每个基本模块都有5个接口：输入、输出、事件、参数和操作，其最大亮点为基本模块可以通过这5个接口组合成复杂的安全应用模块，实现许多通用网络安全平台和功能，从而替代防火墙、IDS和流量管理工具。

Porras等人提出一种加固的控制平面操作系统FortNOX[16]。通过扩展开源的NOX操作系统的Send_OpenFlow_Command模块，增加策略冲突消解功能。来自不同应用的策略设定不同的安全等级，如来自安全应用（如防火墙、入侵检测、入侵防御）、可信应用等提供安全服务的应用策略具有最高优先级；控制层操作系统的本地应用策略具有中等优先级；其他提供业务的应用被分配最低优先级。扩展后的FT_Send_OpenFlow Command汇集所有应用策略，通过验证应用策略携带的数字签名，对策略进行源认证，检查是否存在策略冲突，并根据优先级决定策略冲突发生时的动作。

其中与所做的工作最相关的是由Sethi等人提出的模型检测控制器[17]，其提出了学习型交换机和一个简单状态防火墙的概念。该防火墙通过两个交换机协同工作，实现了阻止外网和内网主动通信的功能。但是该方案侧重于网络状态的描述，并没有给出有效的防火墙状态检测机制和系统。在此基础上，提出了一种基于OpenFlow的SDN状态检测防火墙。

3 基于OpenFlow的SDN状态检测防火墙系统

SDN状态检测防火墙系统旨在为SDN网络构建基于状态的细粒度访问控制机制。通过对开源SDN控制器Floodlight原有的包过滤防火墙进行功能扩展，在交换机中截获数据包并抽出与应用层状态有关的信息，将其中重要信息发送给控制器，并以此为依据决定数据的转发，从而实现基于状态的访问控制，同时具有较好的适应性、扩展性及较低的开销。

3.1 系统框架

为了实现状态防火墙的功能，同时满足控制器的集中控制，方便网络管理员统筹管理和操作，本文提出了如图1所示系统架构，其中包括以下5个模块。

（1）Key Extractor模块：交换机中包头信息提取模块，提取数据包头部中的关键信息。

（2）State Table-SW模块：状态表的建立和更新模块，该模块的功能为在交换机中建立连接状态表，同时将连接状态表同步更新到控制器中，而该状态表的更新由变换流表通过set_state指令控制。

（3）Shifted Flow模块：变换流表（Shifted Flow Table）建立和更新模块，控制器下发指令在交换机中建立变换流表，负责状态转换过程以及数据包转发操作。

图1 系统框架图

（4）Checking Legitimacy模块：合法性检测模块，负责判断到达交换机的数据包属于哪一次连接。

（5）State Table-C模块：控制器端的命令下发、状态表的同步模块，在控制器中建立连接状态表，并与交换机中的状态表保持同步，同时当收到交换机发送Packet_In消息时，该模块通过将包头信息、状态信息和连接状态表或者防火墙规则集进行对比，分配相应状态，同时下发变换流表到交换机中。

前4个模块是在交换机中添加相应的功能实现的，用于数据包匹配。State Table-C模块在控制器中实现，用于判断连接的合法性。State Table-C模块需要利用控制器提供的的核心服务（OpenFlow Core Service）与交换机通信，通过控制器内部提供的Firewall模块查询查询防火墙规则判断数据包是否合法。

3.2 系统关键技术

本系统涉及的关键技术主要包括：连接状态表的建立，变换流表管理以及状态表的更新管理。

3.2.1 连接状态表的建立

本系统定义了STATE_IN和OFP_STATE＿MOD两种消息结构完成控制器和交换机中连接状态表的同步操作。当交换机中的状态表发生状态更新时，其将会向控制器发送一个STATE_IN消息，通知控制器对相应状态记录进行更新；而当控制器中的状态表发生状态更新时，控制器会向交换机发送一个OFP_STATE＿MOD消息，命令交换机对相应状态记录进行更新。

针对本系统所要解决的实际问题，连接状态表由四元组组成（Match Field，State，Timeout，Packet_count），其中Match Field包括数据包的IP（源地址和目的地址，但是只针对连接状态，在匹配连接状态表时不进行区分）和协议类型（包括TCP/UDP，ICMP等等）；State表示连接状态；Timeout表示连接的超时时间；Packet_count表示通过的数据包数目。

3.2.2 变换流表管理

为了实现连接状态表的更新、维护以及管理，本系统对OpenFlow流表进行了相应的修改，添加了状态属性（State）以及下一状态属性（Next_State），并且重新定义了数据包和流表项匹配的过程。匹配的结果不仅依赖于数据包包头的信息，同时取决于数据包的状态。当匹配成功时，将会执行OFPIT_SET_STATE指令，该指令将变换流表中相应记录中的下一个状态值（Next_State）赋值给状态表中的状态属性值；同时按照ACTION指令处理该数据包；若匹配不成功则交换机将会向控制器发送包含数据包包头和状态信息的Packet_in消息，控制器返回Flow_mod消息作为回应，向交换机中添加流表。

3.2.3 状态更新管理

本系统的另一个关键技术是状态的更新管理，即当一个数据包经过交换机时，交换机将会做哪些操作。

（1）状态查询，将数据包包头信息作为查询关键字（如源IP地址）对连接状态表进行查询，如果没有相关查询记录，则在状态表中添加该记录，并将其状态置为DEFAULT。

（2）变换流表实现状态转换，当数据包和状态连接表匹配成功后，将在数据包包头中添加状态信息；该状态信息也会作为匹配项和表换流表进行匹配，如果匹配成功，则将包头中的下一状态信息写回连接状态表，对状态表进行更新，同时根据流表中ACTION表项对数据包进行处理操作。

（3）状态更新，包含添加、删除和修改，一般会通过OFPIT_SET_STATE指令完成状态更新，有些情况下会使用State_mod。

4 系统实现流程

4.1 具体流程

在网络中，大部分数据传输是基于面向连接的TCP协议，并且一旦控制了连接建立的过程，就认为整个通信过程是可信的。在本系统中，TCP的数据包处理流程较为典型，且具有代表性，因此本文将以TCP数据包状态检测流程为重点进行设计和实现。

TCP数据包状态检测模块的主要工作是创建一个TCP连接状态表。具体流程如图2所示：

（1）当数据包到达交换机后，交换机的关键信息提取模块启动，并和交换机中的状态表（state table）进行匹配操作。

（2）如果没有匹配成功，则在状态表中添加该记录，将状态置为DEFAULT，并通知控制器进行相应的状态表更新转向（4）。

（3）如果匹配成功，则将状态信息写入数据包包头。

（4）与交换机中的变换流表进行匹配，如果匹配失败，没有找到对应流表信息，那么则判断该数据包是否为SYN数据包。

（5）如果为SYN数据包，说明为新连接的建立，则与控制器中防火墙模块的规则集进行匹配，匹配成功后，向交换机中发送Flow_mod消息，在变换流表中，添加记录，动作为forward，分配下一个状态标志，交换机收到后，立即执行SET_STATE操作，即更新连接状态表（包括控制器中的连接状态表（State Table-C，和交换机中的连接状态表（State Table-SW），两者通过State_mod实现同步），进行合法性检测后，转发该数据包。

（6）如果不是SYN 数据包，说明可能是原有连接的一部分，不需要规则匹配，直接查询控制器连接状态表，如果存在，则下发Flow_mod消息，向交换机中变换流表添加记录，动作为forward，并分配下一个状态标志；交换机收到后，立即执行SET_STATE操作，即更新连接状态表（包括控制器中的连接状态表（State Table-C，和交换机中的连接状态表（State Table-SW），两者通过State_mod实现同步），进行合法性检测后，转发该数据包。

（7）如果数据包可与交换机中状态表（state Table-SW）和变换流表（Shifted Flow Table）都匹配，则数据包包头信息不发给控制器，直接由交换机处理。

图2 数据包处理流程图

在建立TCP连接三次握手过程中，第一个SYN数据包会和控制器中的防火墙规则进行匹配，保证该连接不违反防火墙规则。如果违反防火墙规则，那么状态表中不会有该连接的记录；否则，可以根据状态表和交换流表处理后面的数据包。这就保证了TCP通信不会违反防火墙规则。对于UDP数据包的处理过程与之类似，因为状态表中会保留一个虚拟的UDP连接。由此流程可以得出，在通信过程中大部分数据可以绕过复杂的规则库匹配过程，而有状态检查取而代之，这是一个简洁高效的处理过程，从而提高了防火墙的性能。

这里，将每一次Client和Server之间连接的三次握手过程，作为一个“实体”的生成过程。这只是一个临时过程，连接成功，则防火墙生成一个完整实体；连接失败，则释放本次连接占用的资源。对于这类实体的状态（记录连接的状态，如：双方连接序号、已确认数据、半连接状态等信息），是随着通信的进行而不断更新的。实体状态分为两类——确认状态和临时状态。收到数据时，实体先进入临时状态，收到接收端确认信息后再将临时状态修正为确认状态，这样可以避免实体状态与通信双方不同步的问题，其中系统状态转换如图3所示。S0、S1和S2是临时状态分别代表三次握手中的发送SYN数据包、接收SYN+ACK数据包和发送ACK数据包三个状态。S3是确认态，表示连接已经建立成功。S4是终止状态，防火墙释放连接占用的资源。

图3 系统TCP状态转换图

4.2 具体问题分析

包过滤防火墙可以允许或阻止内网和外网的通信。但是无法满足这种要求：允许内网向外网发送连接请求，外网无法向内网发送连接请求。这样可以更好地保护内网，防止攻击者嗅探、扫描等。这里用基于上述SDN状态检测防火墙，举例如何解决这个问题（这里为了完全展示各个模块的功能，在连接状态表和变换流表中均不包含相关的记录信息）。由内网h1（192.168.0.1）可以主动与外网h2（202.114.1.1）建立连接，而外网的h2不能主动与内网发起连接。首先，在防火墙中定义规则如表1所示。

表1 状态防火墙规则定义

当h1发送连接请求时，SYN包到达交换机后，交换机中的关键信息提取模块启动提取其包头信息，并和交换机中的连接状态表进行匹配操作，显然此时交换机中没有相关记录，那么在状态表中添加相关记录，如表2所示。

表2 State Table-SW记录

同时，将状态信息写入SYN数据包的包头，并与交换流表进行匹配。在变换流表中没有找到相关记录，则将关键信息发送到控制器，控制器判断其为SYN请求包后，将其与防火墙规则进行匹配，并得到允许连接结果，则控制器便会向交换机发送Flow_mod消息，在变换流表中添加新记录，如表3所示。

表3 Shifed Flow Table记录

此后，交换机需要对数据包包头进行合法性检测，检测通过后通过SET_STATE操作将状态表（State Table-SW）相关记录的STATE值被置为交换流表中Next_state的值，并将信息同步至控制器的状态表（State Table-C）。

通过以上操作，外网主机h2成功接收到h1发送的连接请求，并返回一个SYN+ACK数据包。当该数据包到达交换机后，成功匹配到状态表中相关记录，将状态值SEND_SYN写入数据包包头中后，与交换流表进行匹配操作，显然匹配失败（变换流表中，没有STATE域为SEND_SYN项）。再次将数据包包头信息发送至控制器，并与控制器的状态表（State Table-C）成功匹配后，控制器便向交换机发送Flow_mod消息，从而在变换流表中添加新记录，如表4所示，并将Next_State的值写入交换机状态表中，同步到控制器中。

表4 更新后变换流表

进行合法性检测后，数据包被发到了内网h1主机，内网h1即回复一个ACK的数据包，与以上步骤相同，变换流表的更新，和状态表更新如表5、表6所示。

表5 变换流表更新

表6 状态表更新

同时，当控制器状态表的STATE的值为ESTABLISHED时，则立即向交换机中变换流表中添加以下流表信息，如表7所示。

表7 连接建立后变换流表状态

当连接建立后，内网h1可以和h2进行正常通信而不会遭到阻断。一旦交换机接收到相关连接中有RST或者FIN标志的信息，控制器会便删掉状态表（包括State Table-SW和State Table-C）中的连接记录，同时删除变换流表中的相关项。

反过来，当外网h2向内网h1发送连接请求后，连接请求的SYN包包头同样会被送到控制器，根据防火墙规则，h2到h1的包不允许通过，因此，该SYN包会被Drop，连接无法建立。

管理员可以根据需要灵活制定防火墙策略。例如，允许外网的某一个主机对内网的主机发起连接，禁止内网主机对外网发起连接但仍可以对外网提供服务等。利用SDN状态防火墙，管理员可以实现更加细粒度的访问控制。在包过滤防火墙中要实现这样的功能，管理员可能会配置以下防火墙规则，见表8。

表8 包过滤防火墙规则

表面上看，从h1发送的连接建立请求可以通过防火墙到达h2，从h2发送的连接建立请求却不能到达h1。实际上当存在这样的防火墙规则时，会发现主机h1和h2是无法完成TCP通信的。因为TCP通信是双向的，防火墙规则拒绝了h2返回的SYN+ACK数据包，连接无法建立。如果将表8中的第二条防火墙规则改为ALLOW，h2就可以向h1发送建立连接的请求了，但是这显然不符合要求。包过滤防火墙在处理这样的问题是矛盾的，因为它将一次连接的多个数据包隔离开考虑，没有考虑到数据包的状态。这样的访问控制是简单而粗糙的，管理员无法实现更加细粒度的访问控制，例如本例。

状态检测防火墙可以在允许内网主机和外网正常通信的情况下，阻止外网向内网发送连接请求。因此，外网的SYN数据包都会被防火墙拒绝，可以非常容易地防御SYN洪泛攻击。

5 系统测试与性能分析

5.1 访问控制功能测试

本系统部署在Floodlight和Open vSwitch中，测试环境配置如表9所示。

本次测试使用如图4所示的网络拓扑结构，其中包括3台交换机（S1、S2、S3）和4台主机（VM1、VM2、VM3、VM4）。

表9 测试环境

图4 网络拓扑

设置VM1的IP地址为192.168.0.1，设定VM3的IP地址为202.114.1.1。在Floodlight防火墙模块中添加如表10规则。

表10 防火墙规则

在防火墙规则的基础上通过在交换机中添加连接状态表、包含数据包状态信息的变换流表以及在控制器中同步更新连接状态表，实现细粒度的基于OpenFlow的SDN状态防火墙。在建立连接时根据防火墙规则以及状态表允许符合规则的连接通过，并按照不同状态情况记录在状态表中，进一步在生成相应的变换流表项，一旦连接建立成功后，后续的数据包只要符合状态表，就可以通过。

在测试中分别进行VM1向VM3发起TCP连接以及VM3向VM1发起TCP连接操作，实现了VM1可以访问VM3的同时使得外网不受信任主机不能访问主机VM1。从而为整个SDN网络提供了更加细粒度的访问控制，使得访问授权与数据包状态信息相关，也使得内外网连接更加安全。

5.2 系统性能分析

5.2.1 数据包传输延时

基于Open vSwitch和虚拟VM构建了测试网络拓扑，如图4所示。在SDN架构下，基于包过滤和基于状态检测两种防火墙传输延迟对比情况如图5所示。

图5 传输延时测试

可以得出随着数据量的增加，状态检测防火墙的传输延迟逐渐低于包过滤防火墙。

测试结果显示随着数据量的增加，状态检测防火墙的传输延迟逐渐低于包过滤防火墙。在SDN架构下，基于状态检测的防火墙比基于包过滤的防火墙的传输延时要短，数据量越大，优势越明显。起始时，由于交换机中的状态流表尚未建立，数据包需要发送给控制器中的防火墙模块进行比对，因此状态防火墙性能和包过滤防火墙并无太大差别。但随着数据量的增加，在交换机中建立状态流表后，后续的流量检测可以基于交换机中的流表规则进行，而无需再发送给控制器进行复杂的规则库匹配。因此，数据量越大，本文中设计的状态防火墙性能反而相比Floodlight中包含的包过滤防火墙性能更高些。因为Floodlight中包含的包过滤防火墙所有过滤规则都在控制端，未在交换机中建立过滤策略。

5.2.2 TCP建立连接速度

同时，在SDN架构下，进行了基于包过滤的和基于状态检测的防火墙建立连接的速度对比。分别以建立100～900次TCP连接所花费的总时间来对比两个防火墙性能，具体测试情况如图6所示。

图6 TCP建立连接速度测试

由图6可知，在建立连接时的速度上总体基于状态检测的防火墙要比基于包过滤的防火墙要慢一点，这是因为基于状态的防火墙在连接建立初期需要进行状态建立与同步等各种操作。当连接次数较少时，由于每次连接的时间是毫秒级，因此差别不明显。连接次数越多，整体上状态防火墙速度要慢些。在个别点测试的结果是相同的，这主要是由于网速不太稳定，并且二者速度差别不显著造成的。

在SDN架构下，通过对比两种防火墙的数据包延迟和建立连接的速度可以得出，基于状态检测的防火墙系统延时更短，不过在建立连接时速度稍慢，但综合而言，建立连接的时间在整个数据传输中所占比例较少。因此综上所述，基于状态的防火墙系统总体性能上要优于比基于包过滤的防火墙系统。

6 结束语

针对目前SDN防火墙难以实现基于状态的细粒度访问控制问题，本文设计和实现了一种基于OpenFlow的SDN状态检测的防火墙系统，提出了对于OpenFlow流表和协议修改与设计方法，以及连接状态表与变换流表的关键技术及实现流程。在Floodlight开源控制器和Open vSwitch开源交换机环境下实现了该系统。通过对OpenFlow流表结构与协议的修改以及在交换机中添加状态检测模块，使得系统可检测数据包的状态，从而使网络管理员可以通过定义规则实现基于状态的细粒度的访问控制功能。最后，对系统进行了功能和性能评估，结果表明系统可以实现现有SDN防火墙不具有的状态检测功能，并且具有较低的开销。