利用mininet模拟SDN架构并进行DDoS攻击与防御模拟（Ryu+mininet+sflow+postman）

1、知识概述

（1）软件定义网络：

（2）mininet：

Mininet是一个强大的网络仿真平台，通过这个平台，我们可以很方便的模拟真实环境中的网络操作与架构。特别是SDN，在真实网络中进行相关的网络实验有一定难度，自然需要一个仿真平台可以学习这种新型的网络架构，而Mininet就应运而生，承担了这个光荣而艰巨的使命。Mininet自带交换机（switchs）、主机（hosts）、控制器（controllers），同时，在mininet上可以安装OpenvSwitch、多种控制器（NOX\POX\RYU\Floodlight\OpenDaylight等），同时，Mininet可以运行在多种操作系统上（windows\linux\Mac OS）,具有很强的系统兼容性。

（3）ryu控制器：

ryu控制器是一款开源的SDN控制器，完全由Python语言实现，使用者可以用Python语言在控制器上实现自己的应用。而且Ryu目前支持所有版本的openflow协议。

（4）sflow：

sFlow是一款适用于高速交换网络中的监控软件，可以实时监测网络流量，sFlow需要交换机支持才能使用，而OpenvSwitch支持这个功能。sFlow监控工具由sFlow Agent和sFlow Collector两部分组成。Agent作为客户端，一般内嵌于网络转发设备（如交换机、路由器），通过获取本设备上的接口统计信息和数据信息，将信息封装成sFlow报文发送到指定的Collector。Collector作为远端服务器，负责对sFlow报文分析、汇总、生成流量报告。

2、实验配置过程（参考bolg：https://www.jianshu.com/p/870f7d7eba17）

（1）通过ryu-manager命令启动ryu控制器，并且打开ofctl_rest.py和simple_switch.py，作为交换机的转发规则，因为之后要用到restAPI，即控制器的北向接口（postamn连接使用），所以需要打开ofctl_rest.py。

（2）在miniedit中构建网络拓扑，并设置控制器为远程控制器，交换机DPID为0000000000000001，h1-h3主机的IP地址分别为10.0.0.1-10.0.0.3，最后设置全局模式，方便控制台进行操作。（关于使用miniedit构建网络拓扑图的详细步骤请参考博客我的前几篇blog）

设置网络拓扑完成后，在终端查看链路信息，是否成功建立拓扑：

（3）安装sFlow-RT，命令wget http://www.inmon.com/products/sFlow-RT/sflow-rt.tar.gz，然后解压到当前目录下，输入命令cd sflow-rt，然后启动：./start.sh，看到下列信息证明启动成功。其中 6343 是sFlow Collector 的默认端口，8008 则是 sFlow 的WebUI端口。（注意：执行sflow-rt需要先配置好jdk，否则会报Java不存在的错误，具体配置过程https://blog.csdn.net/asneverbefore/article/details/79098751。）

（4）配置sFlow Agent，我们需要在虚拟交换机配置sFlow Agent，这样sFlow Collector 才能收集到流量信息进行分析和呈现。键入以下指令部署sFlow Agent：

         上述命令的主要意思如下：

1）agent：监控s1-eth0 网卡产生的流量；s1-eth0是为s1创建的端口；

2）target：sFlow-RT的IP，默认端口6343；

3）bridge：需要开启sFlow的网桥；

4）sampling：采样率，表示每隔N个Packet就取样一次

5）polling：轮询时间，每隔N秒polling一次

（提示：如果有N个网桥，就需要执行N次部署 sFlowAgent 的指令，我们本次实验中只有一个网桥，所以执行一次就可以了。）

         查看已经配置的 sFlow Agent信息，通过命令：sudo ovs-vsctl list sflow

使用命令ip link，可以查看虚拟交换机端口与端口编号的映射，可以看见s1 交换机对应的编号是22：

         接下来，查看sFlow Agent 是否配置成功，我们可以通过其WebUI进行查看，在浏览器中输入网址localhost:8008/html/index.html，可以看见各项监控状态。

         3、模拟DDoS攻击过程

（1）在miniedit中打开主机h1-h3的终端，可以在终端进行各项操作，例如：ping、traceroute等。打开之后，在h1中ping h3，h2中ping h3，这些操作为了查看sflow监测是否正常。可以看见，当h1、h2终端中ping h3时，sFlow Bytes明显升高，但是仍处于正常值，内存占用也明显升高。

         我们在h3中使用命令：python3 -m http.server 8000，开启一个http服务。然后再h2的终端中使用命令curl http://10.0.0.3:8000 ，对h3进行服务访问，可以看见获得了正常的服务连接。（注意：使用curl之前，必须确保系统中已经安装curl，否则使用命令：sudo apt-get install curl）

         （2）在mininet终端下，将h1作为攻击者向h3进行ping flood攻击，用来模拟DDoS攻击。在mininet终端下，输入命令h1 ping -f h3，-f的意思就是向h3 发起ping洪范攻击。可以看出当，命令执行后，监测的传输流量剧增，CPU占用和内存占用也大幅度增加。结束ping洪范后，系统给出了总的统计数据。

         4、DDoS攻击缓解

监测到流量异常之后，需要利用RYU控制器向OpenFlow交换机下发流表，抑制攻击流量。

几个基本概念

（1）什么是流表：

流表是交换机进行转发策略控制的核心数据结构。交换机芯片通过查找流表项来决策进入交换机网络的数据包执行适当的处理动作。可以理解为交换机收到数据包之后该做什么的一系列规则。

（2）下发流表：

下发一条流表好比一条指令，告诉交换机收到数据包之后该做什么。在本实验中，通过rest api接口（北向接口）连接postman插件，通过postman对流表进行各项操作。（postman官方下载地址：https://www.postman.com/downloads/，我上传的Linux版本postman：）

5、流表操作

（具体的流表操作api推荐这两个网址，一个是官方比较圈的操作，一个是bolg：https://ryu.readthedocs.io/en/latest/app/ofctl_rest.html#delete-all-flow-entries，https://blog.csdn.net/jmh1996/article/details/73303437）

（1）由于前面的DDoS采用的ping洪范攻击，因此我们需要下发流表，将攻击流down掉，因此利用postman添加流表。具体操作：首先进入postman，利用get操作可以获得已有的流表，所以url填http://localhost:8080/stats/flow/1，具体的各种api方式见上面的两个网址的介绍。点击send后，如果成功发送回返回200OK，并且在Body里面显示出流表。

         （2）下发流表，为了抑制攻击流，我们下发流表控制从交换机的端口1经过的流量，首先在postman中，url为http://localhost:8080/stats/flowentry/add，功能选择post方式，在Body中选择raw进行流表的编写。dpid代表交换机的号，priority表示优先级，优先级数字越大表示越优先处理，在match写入的in_port代表交换机输入端口为1的端口，在本实验中也就是h1连接交换机的端口，actions中为空，表示交换机对于h1的流量不作任何处理。编写完成后，点击send进行流表下发，如果发送成功会返回200OK。

         下图中，第一张图代表h1对h3进行泛洪攻击时sflow的监测流量，可以看出cpu和转发流量都是非常高的；第二张图是抑制数据流的流表下发之后，sflow的监测流量，可以看出不管是cpu还是流量都有巨大幅度的下降。

         （3）但是如果此时，从h1对h3进行http访问，会发现h1对h3正常进行的http访问也无法进行，因为流表是把从1口的流量都给down掉了，所以正常的访问也无法进行。

         因此我们需要对流表进一步改造，使其避免对正常的访问给逗我呢掉，首先，将刚才的流量进行删除，使用的url：http://localhost:8080/stats/flowentry/delete，功能post，流表项依然为刚才使用的，点击send后，返回值200OK证明删除完成。

         改造需要下发的流表，让OpenFlowSwitch 只Drop掉 ICMP的流量，不影响正常的HTTP服务。在之前的流表的基础之上，加上dl_type字段和nw_proto字段，其中，dl_type字段代表ip协议，其中2048的16进制0x0800代表ipv4协议，nw_proto代表:ip协议上搭载的协议类型，其中1代表icmp协议。改造完成的流表通过postman进行流表下发之后，再次进行测试，发现h1对h3的ping泛洪攻击失效，而h1对h3的正常的http访问是得到了正常的回应。