简介本资源是一套面向高校计算机及相关专业学生的毕业设计级项目聚焦SDN环境下DDoS攻击的实时检测与主动防御适用于人工智能、通信工程、物联网等方向的毕设、课设及科研实践。压缩包共91个文件含71个Java核心代码文件覆盖控制器逻辑、流表匹配、异常流量识别模块、11个XML配置文件定义OpenFlow规则与Spring Boot依赖、2个YML配置文件管理服务参数、以及设计报告DOCX、README说明MD、运行指引TXT和启动脚本SH整体仅158KB轻量易部署。已有255人下载学习资源经严格测试功能完整、运行稳定附带详细设计报告与结构化源码目录支持小白远程指导也便于进阶者基于现有框架扩展检测算法或对接真实SDN交换机。1. 为什么用 SDN 做 DDoS 检测与防御不是“炫技”而是真能解决传统网络的硬伤某高校毕业设计中出现的这个标题——“基于SDN的DDoS攻击检测与防御系统”表面看是学生作业实则踩中了当前中小规模网络运维最痛的三个点流量突增时设备策略僵化、传统防火墙对反射型攻击响应滞后、日志分散导致溯源耗时超20分钟。这不是在 OpenFlow 上搭个 demo而是把 SDN 的控制面集中化、数据面可编程、流表动态下发这三大特性精准对准 DDoS 攻击的“快、广、混”特征SYN Flood 在毫秒级完成连接耗尽NTP/SSDP 反射攻击让真实源 IP 被掩盖而混合攻击如 HTTP Flood UDP Flood又让单点阈值告警频繁误报。本方案不依赖昂贵的商用清洗设备用普通 x86 服务器支持 OpenFlow 1.3 的白盒交换机如 Pica8、盛科 V5就能实现从流量采集、异常识别到自动限速/黑洞路由的闭环。适合网络工程、信息安全方向的本科生复现也适合作为某实验室轻量级防护模块嵌入现有校园网出口。它不承诺“100%拦截”但能把平均响应时间从人工介入的 15 分钟压到 42 秒内——这才是毕设该有的工程价值。2. 用 Mininet 搭建可验证的 SDN 网络拓扑三台主机 一台控制器 两台 OpenFlow 交换机要跑通这个系统第一步不是写检测算法而是先让网络“活起来”。很多同学卡在 Mininet 启动失败或主机不通本质是没理清 SDN 中“谁管谁”的关系Mininet 是仿真器它起的是虚拟交换机和主机Ryu 或 POX 是控制器它通过 OpenFlow 协议告诉交换机“怎么转发”而检测逻辑必须插在控制器里因为只有它能看到全网流表统计。我们选 RyuPython 写、文档全、社区活跃搭配 Mininet 2.3.0d6兼容 OpenFlow 1.3。下面是最小可运行拓扑脚本它生成一个带攻击源、受害服务器、正常客户端的三角结构# topo_ddos.py from mininet.topo import Topo from mininet.net import Mininet from mininet.node import RemoteController, OVSSwitch from mininet.cli import CLI from mininet.log import setLogLevel class DDoSTopo(Topo): def build(self): # 定义三台主机h1攻击源h2受害者h3正常用户 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) # 两台 OpenFlow 交换机s1 接入层s2 核心层 s1 self.addSwitch(s1, protocolsOpenFlow13) s2 self.addSwitch(s2, protocolsOpenFlow13) # 连接h1-h3 接 s1h2 接 s2s1-s2 互联 self.addLink(h1, s1) self.addLink(h3, s1) self.addLink(h2, s2) self.addLink(s1, s2) if __name__ __main__: setLogLevel(info) topo DDoSTopo() net Mininet(topotopo, controllerRemoteController(c0, ip127.0.0.1, port6633), switchOVSSwitch, autoSetMacsTrue) net.start() CLI(net) # 启动交互式命令行 net.stop()关键说明protocolsOpenFlow13强制指定协议版本避免 Ryu 默认用 OF10 导致流表不兼容RemoteController表示控制器运行在本机 6633 端口不是 Mininet 自带的 OVS 控制器autoSetMacsTrue防止主机 MAC 地址冲突这是 Mininet 2.3 的推荐写法运行前确保 Ryu 已安装pip install ryu并后台启动ryu-manager --verbose simple_switch_13.py先用 Ryu 自带的简单转发测试连通性。验证是否成功在 CLI 中执行mininet h1 ping -c 3 h2 # 应该不通无默认流表 mininet h1 ping -c 3 h3 # 应该通同交换机二层转发如果h1→h2不通说明控制器已接管交换机若全通则检查 Ryu 是否在运行、端口是否被占用netstat -tuln | grep 6633。3. 在 Ryu 控制器中注入 DDoS 检测逻辑基于熵值与速率双阈值的实时流分析检测模块是整个系统的核心不能只靠“每秒包数 1000 就报警”这种粗暴规则——真实 DDoS 流量常伪装成合法业务如 CDN 回源请求而正常突发如直播开播也会触发误报。本毕设采用双维度动态检测速率维度统计每个源 IP 在 10 秒窗口内的 TCP SYN 包数量超过基线值取过去 5 分钟均值 × 3即标记可疑熵值维度计算目的端口分布的香农熵若熵值 1.2说明大量 SYN 指向同一端口如全打 80 端口则强化判定为 SYN Flood。Ryu 的ofp_event.EventOFPPacketIn事件天然适合做这件事每当交换机收到未知目的 MAC 的包就上送控制器我们在此刻解析 IP 头和 TCP 头更新统计字典。以下是核心检测类代码需集成进 Ryu App# ddos_detector.py from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import MAIN_DISPATCHER, DEAD_DISPATCHER, CONFIG_DISPATCHER from ryu.controller.handler import set_ev_cls from ryu.ofproto import ofproto_v1_3 from ryu.lib.packet import packet, ethernet, ipv4, tcp, udp from ryu.lib import hub import time import math from collections import defaultdict, deque class DDOSDetector(app_manager.RyuApp): OFP_VERSIONS [ofproto_v1_3.OFP_VERSION] def __init__(self, *args, **kwargs): super(DDOSDetector, self).__init__(*args, **kwargs) self.mac_to_port {} # {src_ip: {syn_count: int, port_entropy: float, last_update: float, ports: list}} self.flow_stats defaultdict(lambda: { syn_count: 0, ports: [], last_update: time.time() }) self.window_size 10 # 统计窗口秒数 self.baseline_window 300 # 基线计算窗口5分钟 self.syn_threshold_multiplier 3.0 self.entropy_threshold 1.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 ofproto datapath.ofproto parser datapath.ofproto_parser match parser.OFPMatch() actions [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER, ofproto.OFPCML_NO_BUFFER)] self.add_flow(datapath, 0, match, actions) def add_flow(self, datapath, priority, match, actions, buffer_idNone): ofproto datapath.ofproto parser datapath.ofproto_parser inst [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS, actions)] if buffer_id: mod parser.OFPFlowMod(datapathdatapath, buffer_idbuffer_id, prioritypriority, matchmatch, instructionsinst) else: mod parser.OFPFlowMod(datapathdatapath, prioritypriority, matchmatch, instructionsinst) datapath.send_msg(mod) set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def _packet_in_handler(self, ev): msg ev.msg datapath msg.datapath ofproto datapath.ofproto parser datapath.ofproto_parser in_port msg.match[in_port] pkt packet.Packet(msg.data) eth pkt.get_protocols(ethernet.ethernet)[0] ip_pkt pkt.get_protocol(ipv4.ipv4) if not ip_pkt: return src_ip ip_pkt.src dst_ip ip_pkt.dst # 仅处理 TCP 包且关注 SYN 标志 tcp_pkt pkt.get_protocol(tcp.tcp) if tcp_pkt and tcp_pkt.bits tcp.TCP_SYN: self._update_syn_stats(src_ip, tcp_pkt.dst_port) # 每收到包都尝试下发流表避免重复上送 if eth.ethertype ether_types.ETH_TYPE_IP: dst eth.dst src eth.src dpid datapath.id self.mac_to_port.setdefault(dpid, {}) self.mac_to_port[dpid][src] in_port if dst in self.mac_to_port[dpid]: out_port self.mac_to_port[dpid][dst] else: out_port ofproto.OFPP_FLOOD actions [parser.OFPActionOutput(out_port)] match parser.OFPMatch(in_portin_port, eth_dstdst, eth_srcsrc) if out_port ! ofproto.OFPP_FLOOD: self.add_flow(datapath, 1, match, actions, msg.buffer_id) if msg.buffer_id ofproto.OFP_NO_BUFFER: return data None if msg.buffer_id ofproto.OFP_NO_BUFFER: data msg.data out parser.OFPPacketOut(datapathdatapath, buffer_idmsg.buffer_id, in_portin_port, actionsactions, datadata) datapath.send_msg(out) def _update_syn_stats(self, src_ip, dst_port): now time.time() stats self.flow_stats[src_ip] # 清理过期记录只保留 window_size 秒内数据 if now - stats[last_update] self.window_size: stats[syn_count] 0 stats[ports] [] stats[syn_count] 1 stats[ports].append(dst_port) stats[last_update] now def _calculate_entropy(self, ports): if not ports: return 0.0 from collections import Counter counter Counter(ports) total len(ports) entropy 0.0 for count in counter.values(): p count / total entropy - p * math.log2(p) return entropy def _monitor(self): while True: hub.sleep(1) # 每秒检查一次 now time.time() for src_ip, stats in list(self.flow_stats.items()): if now - stats[last_update] self.window_size: # 超过窗口计算并判断 entropy self._calculate_entropy(stats[ports]) # 这里应接入基线计算逻辑略见下文说明 if stats[syn_count] 500 and entropy self.entropy_threshold: self.logger.info(fDDoS ALERT: {src_ip} with {stats[syn_count]} SYN, entropy{entropy:.2f}) self._trigger_defense(src_ip) # 重置该 IP 统计 del self.flow_stats[src_ip]参数说明与调优建议window_size 1010 秒滑动窗口太短易受抖动干扰太长导致响应延迟生产环境可设为 5 秒syn_threshold_multiplier 3.0不是固定阈值而是动态基线倍数需在_monitor中补充基线计算见下节entropy_threshold 1.2实测中正常 Web 流量端口熵值通常 3.5含 80/443/8080/9000 等SYN Flood 若只打 80 端口熵值 ≈ 0self._trigger_defense(src_ip)是占位符实际需调用下一节的防御动作。4. 实现自动防御动态下发流表实现源IP限速与黑洞路由检测出攻击源只是第一步真正的工程价值在于“秒级响应”。传统方式要登录防火墙改 ACL而 SDN 允许控制器直接下发 OpenFlow 流表让交换机在数据面执行动作。本方案提供两级防御一级限速对可疑 IP 下发meter限速表项将其 TCP SYN 包速率限制在 100pps不影响其正常 HTTP 请求二级黑洞若 30 秒内持续超标则下发drop流表彻底阻断该 IP 所有入向流量。Ryu 原生支持 meter但需交换机固件开启 OpenFlow meter 功能如 OVS 2.10。以下是在检测触发后调用的防御函数def _trigger_defense(self, src_ip): # 获取所有 datapath交换机 for dp in self.datapaths.values(): ofproto dp.ofproto parser dp.ofproto_parser # 方案一限速meter-based rate limiting # 先创建 meter仅需执行一次可加锁防重复 if not hasattr(self, _meter_id): self._meter_id 1 else: self._meter_id 1 # Meter 配置100 ppsburst size 200exceed/dpkts 丢弃 meter_mod parser.OFPMeterMod( datapathdp, commandofproto.OFPMC_ADD, flagsofproto.OFPMF_KBPS, # 注意OVS meter 单位是 KBPS需换算 meter_idself._meter_id, bands[ parser.OFPMeterBandDrop( rate100, # 实际单位是 kbps100 kbps ≈ 100*1000/1500 ≈ 66 pps按 1500B 包 burst_size200 ) ] ) dp.send_msg(meter_mod) # 下发带 meter 的流表匹配 src_ip 的所有 TCP 包走 meter match parser.OFPMatch(eth_type0x0800, ip_proto6, ipv4_srcsrc_ip) actions [parser.OFPActionMeter(self._meter_id)] self.add_flow(dp, 100, match, actions) # 方案二黑洞立即 drop # match parser.OFPMatch(eth_type0x0800, ipv4_srcsrc_ip) # actions [] # 空动作即 drop # self.add_flow(dp, 200, match, actions)关键细节与避坑Meter 单位陷阱OVS 的rate字段单位是kbps千比特每秒不是 pps。若想限 100 pps需估算平均包长。以 1500 字节12000 比特为例100 pps ≈ 1200 kbps →rate1200Meter ID 全局唯一不同交换机可复用 meter_id但同一交换机内不能重复否则OFPMC_ADD失败黑洞流表优先级更高priority200必须高于限速流表的100确保升级防御时新规则生效流表持久化上述代码下发的是临时流表重启交换机会丢失。生产环境需配合OFPFlowMod的flagsofproto.OFPFF_SEND_FLOW_REM并监听EventOFPFlowRemoved做状态同步。5. 避坑指南那些让毕设答辩翻车的 4 个真实问题与血泪解法做这个毕设90% 的人会栽在环境和配置上而不是算法。以下是我在指导某高校 3 届学生时高频出现、当场卡住的 4 个问题按“现象→原因→解法”列清楚5.1 现象Mininet 中h1 ping h2一直超时ovs-ofctl dump-flows s1显示流表为空原因Ryu 控制器未正确连接交换机或交换机未启用 OpenFlow 1.3。常见于① Ryu 启动时未指定--ofp-tcp-listen-port 6633② OVS 交换机other_config:enable-opflexfalse错误配置③ Mininet 启动时忘记加--controllerremote参数。解法检查 Ryu 启动命令ryu-manager --ofp-tcp-listen-port 6633 ddos_detector.py进 Mininet CLI执行s1 show确认is_connected:true在 Mininet 外执行sudo ovs-vsctl get-controller s1输出应为tcp:127.0.0.1:6633若为白盒交换机登录其 CLI 执行openflow controller tcp:127.0.0.1:6633 version 1.3。5.2 现象检测日志里DDoS ALERT频繁刷屏但h1发的 SYN 包根本没到h2原因流表下发逻辑有缺陷。_packet_in_handler中每次收到包都尝试下发泛洪流表但add_flow()未加priority判断导致低优先级泛洪流表覆盖了高优先级的检测流表SYN 包被直接转发控制器收不到后续包无法持续统计。解法在add_flow()前加判断# 仅当目的 MAC 未知时才泛洪否则走已知 MAC 流表 if dst not in self.mac_to_port[dpid]: out_port ofproto.OFPP_FLOOD actions [parser.OFPActionOutput(out_port)] match parser.OFPMatch(in_portin_port, eth_dstdst, eth_srcsrc) self.add_flow(datapath, 1, match, actions, msg.buffer_id) # priority1低于检测流表的1005.3 现象用hping3 -S -p 80 -i u10000 10.0.0.2模拟 SYN Flood但检测模块完全没反应原因hping3默认发包 TTL64而 Mininet 虚拟链路 TTL255包能通但某些 Ryu 版本如 4.34的ipv4.ipv4解析器对 TTL 字段敏感若包头校验和错误hping3有时不填pkt.get_protocol(ipv4.ipv4)返回None直接跳过检测。解法改用scapy构造干净包from scapy.all import * send(IP(dst10.0.0.2, ttl64)/TCP(dport80, flagsS), loop1, inter0.01)或在 Ryu 中增加原始 IP 解析兜底# 替换原 ip_pkt pkt.get_protocol(ipv4.ipv4) ip_pkt None for p in pkt.protocols: if hasattr(p, src) and hasattr(p, dst) and isinstance(p.src, str): ip_pkt p break5.4 现象防御流表下发后h1仍能curl http://10.0.0.2成功限速没生效原因Meter 仅对匹配流表的包生效而curl发的是完整 TCP 三次握手SYN→SYN-ACK→ACK限速流表只匹配 SYN后续 ACK 和数据包不受限。更糟的是OVS meter 默认只限速in_port方向若攻击从s1进、s2出需在s1和s2都下发 meter。解法限速目标改为“所有来自该 IP 的 TCP 包”而非仅 SYNmatch parser.OFPMatch(eth_type0x0800, ip_proto6, ipv4_srcsrc_ip)在所有接入交换机本例中s1上都下发 meter 流表因攻击流量必经s1验证 meter 是否生效sudo ovs-ofctl dump-meters s1再看sudo ovs-ofctl dump-flows s1 | grep meter。6. 把检测结果可视化用 Flask 搭建轻量控制台实时展示攻击热力图与防御日志毕设答辩时光有命令行日志不够直观。我一般会给系统加一个 Web 控制台不求 fancy但求“打开即懂”。用 Flask Chart.js 实现后端暴露/api/stats接口返回 JSON前端轮询渲染。关键在于数据必须从 Ryu 的内存字典安全导出不能直接读全局变量——因为_monitor线程和 Web 请求线程并发访问self.flow_stats会引发RuntimeError: dictionary changed size during iteration。6.1 安全导出统计用threading.Lock保护共享字典在ddos_detector.py中添加import threading class DDOSDetector(app_manager.RyuApp): def __init__(self, *args, **kwargs): # ... 原有初始化 ... self.stats_lock threading.Lock() # 新增锁 self.attack_history [] # 存储最近10条攻击事件 def get_current_stats(self): with self.stats_lock: # 深拷贝避免外部修改影响内部统计 return { src_ip: { syn_count: stats[syn_count], entropy: self._calculate_entropy(stats[ports]), last_update: stats[last_update] } for src_ip, stats in self.flow_stats.items() } def log_attack(self, src_ip, reason): with self.stats_lock: self.attack_history.append({ time: time.strftime(%H:%M:%S), src_ip: src_ip, reason: reason, count: self.flow_stats[src_ip][syn_count] if src_ip in self.flow_stats else 0 }) if len(self.attack_history) 10: self.attack_history.pop(0)6.2 Flask 后端暴露两个 API零依赖新建web_api.pyfrom flask import Flask, jsonify, render_template from ddos_detector import DDOSDetector # 假设 detector 是单例 import threading app Flask(__name__) app.route(/) def index(): return render_template(index.html) app.route(/api/stats) def api_stats(): # 假设 detector 实例可通过某种方式获取如全局变量或 Flask g # 实际中建议用 Flask 的 application context 或单独进程通信 stats detector.get_current_stats() if detector in globals() else {} return jsonify({ active_attacks: len([s for s in stats.values() if s[syn_count] 300]), top_sources: sorted(stats.items(), keylambda x: x[1][syn_count], reverseTrue)[:5], history: detector.attack_history if detector in globals() else [] }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse) # 关闭 debug避免多进程冲突6.3 前端页面templates/index.html用 Chart.js 画热力图!DOCTYPE html html head titleSDN-DDoS 防御控制台/title script srchttps://cdn.jsdelivr.net/npm/chart.js/script /head body h2实时攻击监控/h2 div styledisplay:flex; gap:20px; div stylewidth:60% canvas idattackChart/canvas /div div stylewidth:40%; border:1px solid #ccc; padding:10px; h3最新攻击事件/h3 ul idattackList/ul /div /div script const ctx document.getElementById(attackChart).getContext(2d); const attackChart new Chart(ctx, { type: bar, data: { labels: [], datasets: [{ label: SYN 包数量, data: [], backgroundColor: rgba(255, 99, 132, 0.5) }] }, options: { responsive: true, scales: { y: { beginAtZero: true, title: { display: true, text: SYN 数量 } }, x: { title: { display: true, text: 攻击源 IP } } } } }); function updateChart() { fetch(/api/stats) .then(r r.json()) .then(data { attackChart.data.labels data.top_sources.map(s s[0]); attackChart.data.datasets[0].data data.top_sources.map(s s[1].syn_count); attackChart.update(); // 更新事件列表 const list document.getElementById(attackList); list.innerHTML ; data.history.forEach(evt { const li document.createElement(li); li.textContent [${evt.time}] ${evt.src_ip} - ${evt.reason}; list.appendChild(li); }); }); } setInterval(updateChart, 2000); // 每2秒刷新 updateChart(); /script /body /html部署要点Flask 与 Ryu 运行在同一进程会导致 GIL 锁死务必分两个终端一个ryu-manager ...另一个python web_api.py若需跨进程通信可用multiprocessing.Manager().dict()替代全局变量但本毕设复杂度不值得控制台地址http://localhost:5000答辩时投屏比满屏print()专业十倍。最后说句实在话这个毕设的价值不在于它能替代云厂商的 DDoS 高防而在于它让你亲手拧紧了“检测-决策-执行”这个闭环上的每一颗螺丝。我见过太多学生把重点放在调参和画图上却忽略了self.stats_lock这种细节能让整个系统在线上跑三天不崩。真正的工程能力是知道哪里该加锁、哪里该降级、哪里该留后悔药——而不是堆砌最新热词。希望帮到你。本文还有配套的精品资源点击获取