简介这份资源是面向高校网络安全、SDN方向课程设计与期末大作业的完整源码包围绕基于软件定义网络的DDoS攻击检测与防御系统展开适合具备Java与网络编程基础的学生或开发者参考实践。压缩包共107个文件约605KB以71个Java源码为核心涵盖攻击检测、流量控制、主机与交换机管理等模块另含11个XML配置、2个YML文件、2个TXT说明及备份文件整体结构清晰便于按模块阅读与二次开发。资源已有183人学习下载热度适中。读者可从中获取一套可运行的SDN防御系统实现思路理解控制器如何采集流量、识别异常并动态调整策略同时参考JWT鉴权、代码生成、Linux工具类等辅助模块快速搭建实验环境并完成课程设计或大作业的落地与排错。1. 从一次课程作业答辩翻车说起SDN 环境下的 DDoS 检测到底难在哪很多同学做「基于 SDN 的 DDoS 攻击检测与防御系统」这个课程大作业时第一反应是去搜一份现成源码改改界面、跑个 demo 就交差。我见过太多这样的项目在答辩现场翻车控制器一接上 Mininet正常流量都跑不通更别说识别攻击了。问题不在于代码写得多烂而在于 SDN 这个架构本身把「控制平面」和「数据平面」拆开了DDoS 检测的切入点、采样方式、下发流表的时机跟传统网络完全不是一回事。这个标题拆开来看核心是三件事用 SDN 做网络底座用某种方法检测 DDoS 攻击检测到之后还要能防御通常是下发流表丢弃或限速。它适合两类人一是网络方向的研究生做课程设计或小论文原型二是刚接触 SDN 的工程师想找一个能跑通的端到端案例。难点集中在三个地方——流量特征怎么从 OpenFlow 交换机上低成本地采出来、检测算法放在控制器里还是独立进程、防御流表下发后怎么避免误伤正常业务。后面几章我会按「先跑通最小闭环再补检测精度最后做防御和验证」的顺序把每一步的命令、参数和踩过的坑讲清楚。2. 把 SDN 实验床搭起来Mininet Ryu 的最小可跑闭环2.1 为什么选 Ryu 而不是 OVS 自带控制器或 ONOS课程大作业的时间窗口通常只有两三周选控制器框架的第一原则是「改起来快、文档能搜到、依赖不恶心」。Ryu 是纯 Python 写的控制器逻辑就是一个继承app_manager.RyuApp的类装饰器一挂就能收 packet-in 和 flow stats改检测逻辑不用重新编译。ONOS 功能全但 Java 工程结构重起一个模块要写一堆 Maven 配置对只想验证检测算法的作业来说性价比太低。OVS 自带的ovs-testcontroller只能做最简单的二层转发拿不到细粒度统计。我一般会固定一套版本组合Ubuntu 20.04 Mininet 2.3.0 Ryu 4.34 Open vSwitch 2.13。这套组合在虚拟机里跑最稳Python 3.8 环境下 Ryu 的 eventlet 兼容性问题最少。装 Ryu 直接用 pip不要用 apt 里的老包# 建议在虚拟环境里装避免污染系统 Python python3 -m venv ryu-env source ryu-env/bin/activate pip install ryu4.34 eventlet0.30.2 # 验证安装 ryu-manager --versioneventlet的版本必须锁死Ryu 4.34 配 eventlet 0.31 以上会出现monkey_patch报错控制器起不来。这是血泪经验别问我是怎么知道的。2.2 用 Mininet 起一个带攻击源的拓扑检测系统要能验证拓扑里必须同时有正常流量源和攻击源。我常用的拓扑是 1 个交换机挂 4 台主机h1、h2 是正常客户端h3 是攻击源h4 是服务器。这样在控制器里能清楚看到不同 IP 的流量差异。# topo_ddos.py from mininet.topo import Topo from mininet.net import Mininet from mininet.node import RemoteController, OVSKernelSwitch from mininet.cli import CLI from mininet.log import setLogLevel class DDoSTopo(Topo): def build(self): # 单交换机四个主机方便观察流表 switch self.addSwitch(s1) h1 self.addHost(h1, ip10.0.0.1/24) h2 self.addHost(h2, ip10.0.0.2/24) h3 self.addHost(h3, ip10.0.0.3/24) # 攻击源 h4 self.addHost(h4, ip10.0.0.4/24) # 被攻击目标 for h in [h1, h2, h3, h4]: self.addLink(h, switch) if __name__ __main__: setLogLevel(info) topo DDoSTopo() # 指向本机 Ryu 控制器默认 6653 端口 net Mininet(topotopo, controllerRemoteController, switchOVSKernelSwitch) net.start() CLI(net) net.stop()启动顺序很关键先起 Ryu 控制器再起 Mininet。反过来的话交换机会连不上控制器流表全是默认的NORMAL检测逻辑根本收不到包。# 终端 1起控制器先用最简单的二层转发 app 验证连通 ryu-manager ryu.app.simple_switch_13 # 终端 2起拓扑 sudo python3 topo_ddos.py # 在 mininet 提示符下测试连通性 mininet pingallpingall全通说明控制平面和数据平面已经打通。如果出现大量 X先查sudo ovs-vsctl show看交换机有没有连上控制器再查 Ryu 终端有没有报Eventlet相关的异常。这一步跑不通后面所有检测都是空中楼阁。3. 检测模块怎么写从 OpenFlow 流统计到特征提取3.1 用 FlowStats 请求周期性采集流表统计DDoS 检测的本质是「在单位时间内某个维度的流量特征偏离了正常基线」。在 SDN 里最方便的数据源就是 OpenFlow 交换机的流表统计。Ryu 提供了OFPFlowStatsRequest控制器可以周期性向交换机要流统计拿到每个流的包数、字节数、持续时间。我一般设 2 秒一个采样周期。太短了交换机 CPU 扛不住太长了检测延迟高攻击都打完了才报警。采样逻辑放在一个独立的 RyuApp 里用hub.spawn起一个后台协程# monitor.py from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER, set_ev_cls from ryu.ofproto import ofproto_v1_3 from ryu.lib import hub class FlowMonitor(app_manager.RyuApp): OFP_VERSIONS [ofproto_v1_3.OFP_VERSION] def __init__(self, *args, **kwargs): super(FlowMonitor, self).__init__(*args, **kwargs) self.datapaths {} # 每 2 秒采样一次 self.monitor_thread hub.spawn(self._monitor) set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER) def switch_features_handler(self, ev): datapath ev.msg.datapath self.datapaths[datapath.id] datapath # 这里省略默认 table-miss 流表下发实际项目必须加 def _monitor(self): while True: for dp in self.datapaths.values(): self._request_stats(dp) hub.sleep(2) def _request_stats(self, datapath): ofproto datapath.ofproto parser datapath.ofproto_parser # 请求所有流的统计信息 req parser.OFPFlowStatsRequest(datapath) datapath.send_msg(req) set_ev_cls(ofp_event.EventOFPFlowStatsReply, MAIN_DISPATCHER) def flow_stats_reply_handler(self, ev): body ev.msg.body for stat in body: # 只关心有实际流量的流 if stat.packet_count 0: self.logger.info( src%s dst%s pkts%d bytes%d dur%d, stat.match.get(ipv4_src), stat.match.get(ipv4_dst), stat.packet_count, stat.byte_count, stat.duration_sec)OFPFlowStatsRequest不带 match 字段时返回所有流数据量大但信息全。如果交换机流表条目多可以加match只查特定网段。stat.duration_sec是流存在时间用它算包速率比单纯看包数更准。3.2 三个必须算的特征包速率、流表增速、源 IP 熵光有原始统计没用要转成能区分正常和攻击的特征。我踩过坑之后固定用三个特征计算方式正常范围攻击时表现包速率packet_count / duration_sec几十到几百 pps突增到几千以上流表增速新增流条目数 / 采样周期个位数每秒几十上百条源 IP 熵对源 IP 分布算香农熵较高分散骤降集中伪造源 IP 熵这个特征特别有用。正常流量源 IP 比较分散熵值高DDoS 攻击如果用固定几个源 IP 或者伪造大量相似 IP熵值会明显下降。计算熵的代码很短import math from collections import Counter def src_ip_entropy(ip_list): 输入一个采样周期内的源 IP 列表返回香农熵 if not ip_list: return 0.0 counter Counter(ip_list) total len(ip_list) entropy 0.0 for count in counter.values(): p count / total entropy - p * math.log2(p) return entropy这三个特征组合起来用最简单的阈值法就能跑出不错的检测率。课程作业阶段不建议一上来就上深度学习特征工程做扎实比模型花哨更重要。阈值可以先手动标定正常跑 5 分钟记录基线攻击跑 1 分钟看特征偏移取中间值。3.3 把检测逻辑挂到控制器主循环里检测模块和监控模块要解耦。我的做法是监控模块只负责采数据把每个周期的特征写到一个共享队列里检测模块从队列取数据判断是否超阈值。这样检测算法换掉不影响采集。# detector.py 核心判断逻辑 def is_attack(self, pkt_rate, flow_growth, entropy): # 三个条件满足两个就判定为攻击降低误报 votes 0 if pkt_rate self.pkt_rate_threshold: # 比如 2000 votes 1 if flow_growth self.flow_growth_threshold: # 比如 50 votes 1 if entropy self.entropy_threshold: # 比如 1.5 votes 1 return votes 2用投票机制而不是「与」逻辑是因为单一特征容易误判。比如正常的大文件传输包速率也高但流表增速和熵值正常投票就不会触发。阈值这三个数需要根据你的拓扑和流量规模调没有万能值。4. 防御动作怎么落地流表下发与限速的取舍4.1 检测到攻击后下发 drop 流表检测只是第一步防御才是这个作业的得分点。SDN 做防御最直接的方式就是下发一条高优先级流表把攻击源的包丢掉。Ryu 里下发流表的模板代码def block_source(self, datapath, src_ip): ofproto datapath.ofproto parser datapath.ofproto_parser # 匹配攻击源 IP优先级设高 match parser.OFPMatch(eth_type0x0800, ipv4_srcsrc_ip) # 空 actions 表示丢弃 inst [parser.OFPInstructionActions( ofproto.OFPIT_APPLY_ACTIONS, [])] mod parser.OFPFlowMod( datapathdatapath, priority100, # 高于默认流表的 0 matchmatch, instructionsinst, hard_timeout60) # 60 秒后自动过期避免永久误封 datapath.send_msg(mod)priority100必须高于 table-miss 流表的优先级否则不生效。hard_timeout60是后悔药——万一误判60 秒后自动解封不用手动清流表。这个参数在答辩时是加分项说明你考虑了误伤恢复。4.2 限速比直接 drop 更温和但实现更麻烦直接 drop 简单粗暴但如果是误判正常用户直接断网。更温和的做法是用 meter 做限速把攻击流量限到很低但不完全断。OpenFlow 1.3 支持 meter 表def rate_limit_source(self, datapath, src_ip, rate_kbps100): ofproto datapath.ofproto parser datapath.ofproto_parser # 先下发 meter bands [parser.OFPMeterBandDrop(raterate_kbps, burst_size10)] meter_mod parser.OFPMeterMod( datapathdatapath, commandofproto.OFPMC_ADD, flagsofproto.OFPMF_KBPS, meter_id1, bandsbands) datapath.send_msg(meter_mod) # 再下发引用 meter 的流表 match parser.OFPMatch(eth_type0x0800, ipv4_srcsrc_ip) inst [parser.OFPInstructionMeter(1), parser.OFPInstructionActions( ofproto.OFPIT_APPLY_ACTIONS, [])] mod parser.OFPFlowMod(datapathdatapath, priority100, matchmatch, instructionsinst, hard_timeout60) datapath.send_msg(mod)meter 的坑在于不是所有交换机都完整支持Mininet 里的 OVS 需要确认ovs-vsctl get bridge s1 datapath_type是system而不是netdevnetdev 模式下 meter 经常不生效。课程作业如果时间紧drop 方案足够拿分meter 作为进阶。4.3 防御动作要和检测周期对齐一个容易忽略的点检测是每 2 秒一次但攻击可能在这 2 秒内已经打了几万个包。所以防御流表下发要快检测模块一旦判定攻击立刻调用block_source不要等下一个周期。另外要维护一个已封禁 IP 集合避免对同一个 IP 重复下发流表流表条目爆炸会拖垮交换机。5. 避坑与排查那些让作业从 95 分掉到 60 分的细节5.1 现象pingall 全通但检测模块收不到任何流统计原因默认的simple_switch_13只处理 packet-in不下发带统计的流表或者流表的idle_timeout设得太短流还没被统计就过期了。解决确认 table-miss 流表下发了并且正常转发的流表idle_timeout至少 30 秒。可以在 Ryu 里打印datapath.id确认交换机注册成功。5.2 现象攻击流量跑起来包速率特征没变化原因Mininet 里用hping3打流量时如果目标端口没有服务监听交换机会回 ICMP 不可达实际转发的包很少。解决在 h4 上先起一个iperf -s或者python3 -m http.server 80让攻击有真实目标。另外确认攻击命令的-i参数别设太大hping3 -S --flood才是真正的洪水。5.3 现象防御流表下发后正常主机也断网了原因match 字段写太宽比如只匹配了eth_type没匹配ipv4_src把所有 IP 流量都丢了。解决match 一定要精确到攻击源 IP并且priority不要设得比正常转发流表还高到覆盖所有流量。下发前先打印 match 内容确认。5.4 现象Ryu 控制器跑十几分钟就内存暴涨原因flow_stats_reply_handler里把每个周期的统计都存进列表没清理或者日志级别设成 debug 疯狂写盘。解决统计只保留最近 N 个周期用collections.deque(maxlen30)日志级别设 info别用 debug 跑长时间测试。5.5 现象换一台机器跑同样的代码报 eventlet 版本错误原因Ryu 对 eventlet 版本极其敏感不同 Python 小版本下依赖解析结果不同。解决用requirements.txt锁死所有依赖版本pip freeze requirements.txt换机器先pip install -r requirements.txt。这个习惯能省掉大量「在我电脑上好好的」扯皮时间。6. 让检测率再上一个台阶滑动窗口与误报抑制的实战技巧前面几章跑通的是最小闭环能拿 80 分。想冲到 95 分以上差距在检测的稳定性和误报控制上。我最后一般会加两个东西滑动窗口平滑和告警抑制。滑动窗口解决的是单周期采样抖动问题。网络流量本身有突发性单看一个 2 秒周期可能误判。用最近 5 个周期的特征做加权平均攻击的持续性特征会更明显偶发突发会被平滑掉。实现上用一个deque(maxlen5)存历史特征每次判定用均值from collections import deque class SlidingWindowDetector: def __init__(self, window5): self.pkt_rates deque(maxlenwindow) self.flow_growths deque(maxlenwindow) self.entropies deque(maxlenwindow) def update(self, pkt_rate, flow_growth, entropy): self.pkt_rates.append(pkt_rate) self.flow_growths.append(flow_growth) self.entropies.append(entropy) def judge(self): if len(self.pkt_rates) 3: return False # 样本不足不判定 avg_rate sum(self.pkt_rates) / len(self.pkt_rates) avg_growth sum(self.flow_growths) / len(self.flow_growths) avg_entropy sum(self.entropies) / len(self.entropies) votes 0 if avg_rate 2000: votes 1 if avg_growth 50: votes 1 if avg_entropy 1.5: votes 1 return votes 2告警抑制解决的是「攻击持续期间反复告警和反复下发流表」的问题。维护一个blocked_ips字典记录 IP 和封禁时间60 秒内不重复处理。同时加一个冷却期攻击停止后不要立刻解封观察 30 秒确认流量恢复正常再放行。验证方法上我习惯用三组对照实验来证明系统有效纯正常流量跑 5 分钟记录误报数应该为 0纯攻击流量跑 1 分钟记录检测延迟应该小于 4 秒即两个采样周期混合流量跑 3 分钟记录检测率和误报率。这三组数据往答辩 PPT 一放比任何架构图都有说服力。最后一个习惯所有阈值参数不要硬编码在代码里抽到一个config.yaml或者常量文件顶部。答辩老师问「你这个阈值怎么定的」你能直接翻到那一行说「基于基线流量标定正常包速率均值 300取 6 倍余量设 2000」这比说「我试出来的」专业得多。这套东西从搭环境到调参认真做大概三到四天能跑出完整数据值得投入。希望帮到你。本文还有配套的精品资源点击获取
