测试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，三台主机连接到该交换机

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给交换机下方新的流表

• 将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.运行结果

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

由于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），进而影响处理交换机处理数据包的性能