测试dos攻击对openflow中flow_table溢出的影响

环境准备

环境

  • ubuntu16.04
  • mininet
  • pox
  • scapy

安装mininet

  • sudo apt-get update
  • sudo apt-get upgrade
  • git clone git://github.com/mininet/mininet
  • mininet/util/install.sh -a
    • 进入路径mininet/util
    • -a:安装mininet所有功能
  • 输入以下命令进行测试sudo mn --test pingall

安装pox

由于使用了mininet安装时添加了参数-a,所以在安装了mininet的同时,也安装了许多其他的软件,其中就包括了pox

使用pox

启动pox控制器

  • python pox.py -address=127.0.0.1 -port=6633 samples.pretty_log forwarding.l2_learning py
    • -address:设置控制器ip地址
    • -port:设置控制器端口
    • samples.pretty_log:pox的组件,美化控制台字体
    • forwarding.l2_learning:pox的组件,负责二层转发,可以让openflow交换机变成一个具有二层转发学习的交换机
    • py:进入python的交互式界面,可以继续对pox控制器进行控制器

使用mininet连接pox控制器

  • 新开一个命令行,输入sudo mn --custom topo.py --topo topo --controller=remote,ip=127.0.0.1,port=6633 --mac
    • 输入后,在启动pox的命令行,会看到提示有新的交换机connect

测试演示

0.topo

我们部署一台交换机s0,三台主机连接到该交换机

测试dos攻击对openflow中flow_table溢出的影响

1.修改交换机的流表数量为100,来模拟模拟交换机内存不足的情况

  • sudo ovs-vsctl add bridge s0 flow_tables 1=@nam1 -- --id=@nam1 create flow_table flow_limit=100:该命令会给交换机s0设置流表0上限为100条(一台交换机有多个流表)
  • sudo ovs-vsctl list bridge:查看交换机的设置情况
  • sudo ovs-ofctl dump-flows s0:查看交换机的流表
  • sudo ovs-vsctl list flow_table:查看流表的设置

2.使用scapy发送大量的流量(二层),促使控制器不断的install新的流表

  • 我们发送udp的数据包,只需要修改源端口,就会触发pox给交换机下方新的流表

测试dos攻击对openflow中flow_table溢出的影响

  • 将h2作为接收端,运行接收脚本,统计实际接收的数据包数量,和发送的数据包数量对比
    import socket

    address = ('10.0.0.2', 8080)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(address) i = 1
while True:
data, addr = s.recvfrom(2048)
print "i:", i, "received:", data, "from", addr
i = i + 1 s.close()
  • 将h1作为发送端,不断发送只有源端口修改的数据包
    from scapy.all import *

    for i in range(100, 1100):
print('now:', i)
pkt = Ether(src='00:00:00:00:00:01', dst='00:00:00:00:00:02')/IP(src='10.0.0.1', dst='10.0.0.2')/UDP(sport=i, dport=8080)/str(i)
sendp(pkt, iface='h1-eth0')

3.运行结果

测试dos攻击对openflow中flow_table溢出的影响

我们在设置流表上限最多为100条的情况下,可以看到在发送数据包个数大于100时,出现了数据包的丢包,同时在pox控制器端也出现了下发流表的报错

测试dos攻击对openflow中flow_table溢出的影响

由于pox模块forwarding.l2_learning下发的流表带有hard_time字段,当数据包超过100后,新的数据包到来后,被交换机上报到控制器,但是在控制器下发流表回交换机的环节,因为流表达到上限,而旧的流表还没有过期,导致了无法install新的流表,数据包没有办法被处理,进而出现了丢包

4.结论

在实际场景,交换机的流表数量远远大于100,出现流表溢出的情况的可能性较低,但是可以看出,如果能有办法达到这个临界值的话,是可以造成交换机正常工作的。

其实只是要说明这个以上结论,只要将流表上限设为1,那么pingall命令都将会无法ping通,就已经足够说明危害了,但是该思路存在进一步改进的地方,毕竟去发送这么大的流量去溢出流表,似乎有点大材小用了,应该尝试去试着用小流量就可以造成流表操作的异常,当然,这也就和题目的dos不相干了。并且该危害也只影响到了交换机,对控制器没有影响,也不够威力

改进的方向

  • 继续朝着dos的方向,利用交换机的reactive模式下,会将数据包完整的上发给控制器,而不仅仅只是header,通常控制链路(交换机与控制器之间的链路)会比数据链路的数据容量小,那么就存在了可能性去利用这一点来影响控制器,又或者控制器连接处理的能力有限,使一台交换机不断的进行请求访问,让控制器没有剩余的能力去处理其他正常交换机的请求,来影响控制器服务
  • 针对交换机对flow_table的操作,不同的交换机实现不同,有的模块可能使用硬件,有的使用软件,有的交换机匹配流表的操作是使用软件,并且基于hash表的方式实现,来达到O(1)的性能,但是hash表是存在hash碰撞的可能性,如果人为的去制造这个碰撞,使得所有流表都是一样的hash值,那么查找和添加流表的性能就会远远低于O(1),进而影响处理交换机处理数据包的性能
上一篇:Android5.0新特性之——控件移动动画(初级)


下一篇:CSS速查列表-1-(background)背景