简介面向网络安全方向学习者与Java后端开发者的Spring Boot集成SDN的DDoS攻击检测与防御系统项目包。项目基于Spring Boot与MyBatisPlus构建业务与数据层借助JWT实现无状态身份认证并利用SDN控制器集中监控网络流量通过OpenFlow协议动态下发流表以隔离异常攻击源适合用于毕业设计、课程实践或安全方向入门参考。压缩包共88个文件以Java源码为主71个用于业务模块与SDN控制器逻辑实现XML配置与YAML应用配置负责依赖管理和环境参数Shell启动脚本便于快速部署TXT与Markdown文档提供说明整体仅59KB结构轻量清晰。目前已有252人学习下载。通过该项目可掌握SDN控制器改造、异常流量识别与流表下发策略的落地实现同时理解Spring Boot项目分层、MyBatisPlus数据库操作和JWT认证流程并可直接借鉴其检测与防御联动设计。1. SDN场景下DDoS检测为什么绕不开控制器传统网络里做DDoS检测通常要依赖流量镜像、NetFlow或者交换机上的ACL日志部署成本高而且每台设备只能看到自己端口上的流量。SDN把控制平面集中到控制器之后交换机上的流表统计、端口计数、匹配命中等数据天然汇聚在一个点上。基于SDN的DDoS攻击检测与防御核心价值在于控制器本身就具备全网视图SpringBoot在这套系统里要解决的不是“怎么抓到流量”而是怎么把控制器的统计能力转成检测规则再把检测结果转成可执行的防御动作。整个过程可以拆成三条链路数据采集、异常判定、流表下发。理解这三条链路比纠结具体用哪个控制器更关键。这套系统适合两类人一类是用Java技术栈做网络安全方向课题的开发者想找一个能把SDN和业务代码串起来的落地方式另一类是在虚拟化或实验网络里需要快速做到“检测到异常后自动封禁”的运维工程师。想跑通这套代号前提是已经有一个暴露了REST接口的SDN控制器常见的如Floodlight、ONOS或者OpenDaylight后面都以Floodlight为例说明因为它的REST接口足够简单和SpringBoot对接不需要额外鉴权。2. 流量采集从OpenFlow端口统计到SpringBoot指标仓库2.1 控制器选型为什么优先用Floodlight的REST接口SDN控制器里能被SpringBoot直接消费的流量统计来源有三种Floodlight的/wm/statistics系列接口、ONOS的/onos/v1/statistics接口、OpenDaylight的RESTCONF接口。差异主要在鉴权方式和JSON结构上Floodlight默认不鉴权返回结构简单ONOS需要BasicAuth适合对安全要求更高的环境OpenDaylight的RESTCONF路径能同时处理XML和JSON但学习成本高。做本地实验或课题演示时优先选择Floodlight能省掉不少对接时间。控制器REST接口风格鉴权与SpringBoot对接难度Floodlight/wm/statistics/switch/all/port/json无低ONOS/onos/v1/statistics/...BasicAuth中OpenDaylight/restconf/operational/...BasicAuth高Ryu/stats/port/...无中但需额外起web服务选择接口时还应该注意端口统计的口径。Floodlight的port/json返回的是交换机端口的累计值包含receivePackets、receiveBytes、transmitPackets等字段这是检测速率的最原始数据。要得到每秒速率必须要在两次采集之间做差值计算这也是SpringBoot调度层要做的事。2.2 用RestTemplate拉取端口统计并转换为指标对象SpringBoot项目中拉取控制器统计最直接的方式是RestTemplate不需要引入额外的SDK。这里有一个容易踩的坑Floodlight返回的JSON里portNumber字段在不同版本里可能是数字也可能是字符串解析时不能直接asInt()要先判断节点类型。Service public class FlowStatsCollector { private final RestTemplate restTemplate new RestTemplate(); public ListPortMetric collect(String controllerBase, int port, long samplePeriodMs) { String url http:// controllerBase : port /wm/statistics/switch/all/port/json; JsonNode root restTemplate.getForObject(url, JsonNode.class); ListPortMetric metrics new ArrayList(); if (root null || !root.isArray()) { return metrics; } for (JsonNode sw : root) { String switchId sw.path(switch).asText(); // Floodlight返回的统计数组可能缺失不能直接遍历 JsonNode stats sw.path(statistics); for (JsonNode st : stats) { PortMetric m new PortMetric(); m.setSwitchId(switchId); // portNumber在不同版本中类型不一致用isNumber做兜底 m.setPortNumber(st.path(portNumber).isNumber() ? st.path(portNumber).asInt() : 0); m.setReceivePackets(st.path(receivePackets).asLong()); m.setReceiveBytes(st.path(receiveBytes).asLong()); m.setTransmitPackets(st.path(transmitPackets).asLong()); m.setCollectTime(System.currentTimeMillis()); m.setSamplePeriodMs(samplePeriodMs); metrics.add(m); } } return metrics; } }path()方法在节点不存在时返回MissingNode不会抛异常适合解析SDN控制器这种字段结构不稳定的响应。setSamplePeriodMs要和后面的定时调度周期保持一致因为在检测阶段计算PPS时要用这个值做分母如果调度周期和传入值不一致算出来的速率会偏差很大。2.3 采样周期怎么选500ms、1s还是5s采样周期直接影响检测灵敏度和误报率。周期越短对突发流量越敏感但控制器REST接口的调用压力也会增大Floodlight在周期小于500ms时可能因为线程阻塞而拖垮转发线程。以下是实际项目中常用的参数参考采样周期适用场景风险500ms高灵敏度实验单交换机容易把正常突发误判为攻击1s中小型虚拟网络默认推荐平衡性能和灵敏度5s低频率慢速攻击跨交换机封禁动作可能延迟5秒以上在SpringBoot里我一般用Scheduled注解启动定时采集fixedDelayString配置成${ddos.detection.sample-period}方便通过application.yml动态调整。注意fixedDelay和fixedRate的差异这里必须用fixedDelay否则上一次HTTP请求还没返回下一次又开始了。ddos: controller: base-url: 127.0.0.1 port: 8080 detection: sample-period: 1000 slot-ms: 1000 slot-num: 10采集到指标后不需要把原始数据全量入库。检测引擎只关心最近几十秒的速率我一般把PortMetric按switchId:portNumber作为key存到ConcurrentHashMap里同时保留前一轮的累计值。历史数据要归档的话再异步写入InfluxDB或Prometheus不要在采集线程里同步写库。3. 检测引擎基于滑动窗口与阈值的DDoS判定3.1 为什么不能用瞬时速率做判断检测DDoS攻击最容易犯的错是拿“当前一秒的PPS”和“固定阈值”做比较。正常业务流量本身就存在突发电商秒杀、批量任务回帖都会造成瞬间速率翻倍。如果把阈值设低误报率会高得没法用设高了真正的小流量攻击反而漏掉。常见的做法是引入滑动窗口把最近N个时间片的速率聚合成一个窗口值再和阈值比较。这样既能消除毛刺又能保证攻击持续几秒后一定能被感知。窗口的选择有个经验法则检测SYN Flood时窗口不要超过10秒否则攻击者在窗口内变化源IP会让检测结果失真。3.2 滑动窗口计数器的实现实现滑动窗口不需要引入复杂框架一个环形数组加上时间戳取模即可。关键点在于每次写入新槽位时要判断当前时间是否已经跨到了新的窗口周期如果跨了窗口需要把落后的槽位清零避免旧数据混入当前窗口。public class SlidingWindowCounter { private final long slotMs; private final int slotNum; private final long[] buckets; private long currentSlotKey; public SlidingWindowCounter(long slotMs, int slotNum) { this.slotMs slotMs; this.slotNum slotNum; this.buckets new long[slotNum]; } public synchronized long add(long nowMs, long value) { long slotKey nowMs / slotMs; int idx (int) (slotKey % slotNum); if (slotKey ! currentSlotKey) { if (slotKey - currentSlotKey slotNum) { // 跳过了整个窗口直接全部清零 Arrays.fill(buckets, 0L); } else { // 只清理中间跨过的槽位避免重复累加 long start currentSlotKey 1; for (long s start; s slotKey; s) { buckets[(int) (s % slotNum)] 0L; } } currentSlotKey slotKey; } buckets[idx] value; long sum 0L; for (long v : buckets) { sum v; } return sum; } }synchronized在这里是必须的虽然会牺牲一点并发性能但检测引擎处理的是秒级粒度的统计值每秒钟只有几次写入锁竞争几乎可以忽略。slotKey - currentSlotKey slotNum这个判断处理的是系统暂停超过一个完整窗口的情况比如SpringBoot服务GC停顿或者控制器响应超时如果不做这个判断那旧窗口的数据会被误算进当前窗口。3.3 攻击判定逻辑窗口求和与动态阈值有了滑动窗口计数器检测逻辑就清晰了对于每个switchId:portNumber把当前PPS写入窗口取窗口求和如果窗口总和超过了thresholdPps * slotNum就产生一条告警。这里有个更合理的做法是计算窗口平均值再和阈值比较但窗口求和的效果和平均值是等价的只是数值口径不同。public class DdosDetector { private final MapString, SlidingWindowCounter counters new ConcurrentHashMap(); private final long thresholdPps; private final long slotMs; private final int slotNum; public DdosDetector(long thresholdPps, long slotMs, int slotNum) { this.thresholdPps thresholdPps; this.slotMs slotMs; this.slotNum slotNum; } public AttackEvent detect(ListPortMetric metrics) { long now System.currentTimeMillis(); for (PortMetric m : metrics) { String key m.getSwitchId() - m.getPortNumber(); SlidingWindowCounter counter counters.computeIfAbsent( key, k - new SlidingWindowCounter(slotMs, slotNum)); long pps m.getReceivePackets() * 1000L / Math.max(1L, m.getSamplePeriodMs()); long windowTotal counter.add(now, pps); long avgPps windowTotal / slotNum; if (avgPps thresholdPps) { return new AttackEvent(key, m.getPortNumber(), pps, avgPps, thresholdPps, now); } } return null; } }thresholdPps不能拍脑袋定我一般的做法是先在没有攻击的平时流量下运行几个小时记录各个端口的PPS数据取90分位数再乘2或乘3作为初始阈值。如果链路是千兆口理论极限大约是1488000 PPS但实际业务跑到50万PPS已经算高流量阈值可以设置在20万到30万之间再根据误报情况上下调整。检测到攻击后不要立即下发防御规则这是很多人会犯的错。单次告警可能是突刺应该连续两个采样周期都触发相同告警才确认攻击。确认后的告警事件里应该带出switchId、portNumber、avgPps、thresholdPps和时间戳这组字段就是后面防御模块的输入。4. 防御执行用SpringBoot下发OpenFlow流表阻断攻击4.1 告警到防御的链路检测引擎产出AttackEvent后防御模块要做的第一件事不是下发drop规则而是查冷却表。同一个交换机端口在短时间内可能被重复告警如果每次告警都下发流表交换机的流表空间马上会被塞满。我这里维护一个ConcurrentHashMapkey是switchId:portNumbervalue是最后封禁时间封禁后5分钟内不重复下发相同规则。防御动作根据攻击类型分三种丢弃、重定向、限速。对于确认的SYN Flood或UDP Flood直接丢弃是最有效的对于可疑但是业务不能中断的流量优先把流量重定向到清洗端口。在Floodlight里最常见的下发方式是调用staticflowentrypusher接口。防御动作实现方式适用场景丢弃目标端口流量静态流表actiondrop确认攻击业务可中断重定向到清洗节点静态流表output到指定端口需要保留业务但先清洗端口限速Meter或Group表疑似攻击业务不可中断4.2 用Java代码下发Drop流表SpringBoot调用Floodlight的staticflowentrypusher非常简单一个POST请求就能完成。这里要注意priority参数的设置OpenFlow默认转发的优先级通常是32768要想让drop规则优先生效必须设置成大于默认优先级的数值。Service public class FlowRuleEnforcer { private final RestTemplate restTemplate new RestTemplate(); public void blockPort(String controllerBase, int controllerPort, String switchId, int portNumber) { String ruleName block-port- portNumber - System.currentTimeMillis(); MapString, Object flow new HashMap(); flow.put(switch, switchId); flow.put(name, ruleName); flow.put(priority, 50000); flow.put(ingress-port, String.valueOf(portNumber)); flow.put(active, true); flow.put(actions, drop); String url http:// controllerBase : controllerPort /wm/staticflowentrypusher/json; String resp restTemplate.postForObject(url, flow, String.class); log.info(下发封禁流表: {}, 响应: {}, ruleName, resp); } }ingress-port匹配的是流量进入交换机的物理端口对DDoS检测场景来说比较有效。如果攻击源集中在个别IP也可以把匹配字段换成ipv4-src格式需要写成1.2.3.4/32。activetrue表示规则立即生效。Floodlight的staticflowentrypusher设计上每次只能下发或修改一条流表批量封禁时要循环调用。4.3 用curl验证规则下发是否成功在本地调试时我习惯先用curl直接测试控制器接口确认参数没问题后再改Java代码。这样能省去不少排查时间也能快速验证控制器的接口行为是否符合预期。curl -X POST http://127.0.0.1:8080/wm/staticflowentrypusher/json \ -H Content-Type: application/json \ -d { switch: 00:00:00:00:00:00:00:01, name: block-test-1, priority: 50000, ingress-port: 3, active: true, actions: drop }命令执行后返回的一般包含Result和status字段如果返回里带true说明Floodlight已经把规则写入交换机。注意不同版本的Floodlight对JSON字段要求略有差异ingress-port有些版本接受字符串有些接受数字实际调试时两个都试一下。删除封禁规则用DELETE请求地址是/wm/staticflowentrypusher/json/{name}要保证name唯一否则删除时可能误删其他规则。4.4 自动防御时机的选择与恢复机制防御规则不能永久生效。攻击结束后流表还留在交换机上会导致业务无法恢复。所以下发规则时要带hard-timeout参数比如300秒到了时间自动过期。这也是为什么在SpringBoot里要对规则做持久化记录的原因否则交换机上的规则到期后SpringBoot内存里还保留着已经封禁的key后续告警会被冷却表拦下来形成“假封禁”。一个稳妥的做法是把攻击告警和封禁记录写入一张表字段包括switchId、portNumber、ruleName、beginTime、endTime、status。SpringBoot定时任务每30秒检查一次发现statusBLOCKED且当前时间超过endTime时主动调用控制器的删除接口清理规则再把状态改成EXPIRED。这比完全依赖交换机的硬超时更可靠因为控制器和交换机之间的链路偶尔会中断导致删除命令丢失。5. 回归验证、误报排查与阈值自调整技巧5.1 用Mininet造一个最小验证环境整个链路跑通之后验证不能只靠看日志。我在实验环境里习惯用Mininet创建一个single拓扑再接一个Floodlight控制器然后用hping3往目标主机发起SYN报文模拟异常流量。注意这只是实验网里的合法测试生产环境不要用这套流程。sudo mn --topo single,5 --controller remote,ip127.0.0.1,port6633拓扑起来后先在主机h1上执行ping h2确认基本连通性然后观察Floodlight的端口统计中各个端口PPS。此时阈值可以临时调低到1000 PPS便于快速触发告警。sudo hping3 --flood -S -p 80 10.0.0.2如果检测模块正常SpringBoot日志里应该出现AttackEvent接着下发流表的日志也会出现。验证流表是否真正进入交换机可以直接查Floodlight的流表列表接口curl -s http://127.0.0.1:8080/wm/staticflowentrypusher/list \ | python3 -m json.tool返回结果里能看到刚下发的规则名称、优先级和动作。如果交换机实现了OpenFlow统计还可以通过/wm/core/switch/{switch}/flow/json查看每条规则的匹配计数确认drop规则是否真的命中了流量。5.2 误报排查先看时间戳再看差值误报率是这套系统能否真正投入使用的关键。排查误报时我首先看采样时间和检测时间是否对得上SpringBoot的定时任务如果因为HTTP请求超时发生堆积会导致PortMetric里的collectTime不准窗口计算出来的PPS比实际高出一个量级。其次是检查差值计算逻辑。Floodlight返回的是累计值如果两次采集之间控制器重启了累计值会归零计算出的速率会变成负数。在采集层必须做判断当本次值小于上次值时跳过本轮差值计算而不是直接取绝对值。最后一个常用的调优手段是动态阈值。固定阈值在不同时间段表现差异很大我一般在SpringBoot里加一个ThresholdService每5分钟从近一小时的PPS数据中计算95分位把thresholdPps更新为p95 * 2。这个更新过程通过Scheduled执行阈值变化不需要重启服务。这样一套流程下来系统才能真正做到从检测到防御的闭环而不是一台只会发告警的定时任务。本文还有配套的精品资源点击获取 SDN环境下基于SpringBoot的DDoS检测与自动防御实践
简介面向网络安全方向学习者与Java后端开发者的Spring Boot集成SDN的DDoS攻击检测与防御系统项目包。项目基于Spring Boot与MyBatisPlus构建业务与数据层借助JWT实现无状态身份认证并利用SDN控制器集中监控网络流量通过OpenFlow协议动态下发流表以隔离异常攻击源适合用于毕业设计、课程实践或安全方向入门参考。压缩包共88个文件以Java源码为主71个用于业务模块与SDN控制器逻辑实现XML配置与YAML应用配置负责依赖管理和环境参数Shell启动脚本便于快速部署TXT与Markdown文档提供说明整体仅59KB结构轻量清晰。目前已有252人学习下载。通过该项目可掌握SDN控制器改造、异常流量识别与流表下发策略的落地实现同时理解Spring Boot项目分层、MyBatisPlus数据库操作和JWT认证流程并可直接借鉴其检测与防御联动设计。1. SDN场景下DDoS检测为什么绕不开控制器传统网络里做DDoS检测通常要依赖流量镜像、NetFlow或者交换机上的ACL日志部署成本高而且每台设备只能看到自己端口上的流量。SDN把控制平面集中到控制器之后交换机上的流表统计、端口计数、匹配命中等数据天然汇聚在一个点上。基于SDN的DDoS攻击检测与防御核心价值在于控制器本身就具备全网视图SpringBoot在这套系统里要解决的不是“怎么抓到流量”而是怎么把控制器的统计能力转成检测规则再把检测结果转成可执行的防御动作。整个过程可以拆成三条链路数据采集、异常判定、流表下发。理解这三条链路比纠结具体用哪个控制器更关键。这套系统适合两类人一类是用Java技术栈做网络安全方向课题的开发者想找一个能把SDN和业务代码串起来的落地方式另一类是在虚拟化或实验网络里需要快速做到“检测到异常后自动封禁”的运维工程师。想跑通这套代号前提是已经有一个暴露了REST接口的SDN控制器常见的如Floodlight、ONOS或者OpenDaylight后面都以Floodlight为例说明因为它的REST接口足够简单和SpringBoot对接不需要额外鉴权。2. 流量采集从OpenFlow端口统计到SpringBoot指标仓库2.1 控制器选型为什么优先用Floodlight的REST接口SDN控制器里能被SpringBoot直接消费的流量统计来源有三种Floodlight的/wm/statistics系列接口、ONOS的/onos/v1/statistics接口、OpenDaylight的RESTCONF接口。差异主要在鉴权方式和JSON结构上Floodlight默认不鉴权返回结构简单ONOS需要BasicAuth适合对安全要求更高的环境OpenDaylight的RESTCONF路径能同时处理XML和JSON但学习成本高。做本地实验或课题演示时优先选择Floodlight能省掉不少对接时间。控制器REST接口风格鉴权与SpringBoot对接难度Floodlight/wm/statistics/switch/all/port/json无低ONOS/onos/v1/statistics/...BasicAuth中OpenDaylight/restconf/operational/...BasicAuth高Ryu/stats/port/...无中但需额外起web服务选择接口时还应该注意端口统计的口径。Floodlight的port/json返回的是交换机端口的累计值包含receivePackets、receiveBytes、transmitPackets等字段这是检测速率的最原始数据。要得到每秒速率必须要在两次采集之间做差值计算这也是SpringBoot调度层要做的事。2.2 用RestTemplate拉取端口统计并转换为指标对象SpringBoot项目中拉取控制器统计最直接的方式是RestTemplate不需要引入额外的SDK。这里有一个容易踩的坑Floodlight返回的JSON里portNumber字段在不同版本里可能是数字也可能是字符串解析时不能直接asInt()要先判断节点类型。Service public class FlowStatsCollector { private final RestTemplate restTemplate new RestTemplate(); public ListPortMetric collect(String controllerBase, int port, long samplePeriodMs) { String url http:// controllerBase : port /wm/statistics/switch/all/port/json; JsonNode root restTemplate.getForObject(url, JsonNode.class); ListPortMetric metrics new ArrayList(); if (root null || !root.isArray()) { return metrics; } for (JsonNode sw : root) { String switchId sw.path(switch).asText(); // Floodlight返回的统计数组可能缺失不能直接遍历 JsonNode stats sw.path(statistics); for (JsonNode st : stats) { PortMetric m new PortMetric(); m.setSwitchId(switchId); // portNumber在不同版本中类型不一致用isNumber做兜底 m.setPortNumber(st.path(portNumber).isNumber() ? st.path(portNumber).asInt() : 0); m.setReceivePackets(st.path(receivePackets).asLong()); m.setReceiveBytes(st.path(receiveBytes).asLong()); m.setTransmitPackets(st.path(transmitPackets).asLong()); m.setCollectTime(System.currentTimeMillis()); m.setSamplePeriodMs(samplePeriodMs); metrics.add(m); } } return metrics; } }path()方法在节点不存在时返回MissingNode不会抛异常适合解析SDN控制器这种字段结构不稳定的响应。setSamplePeriodMs要和后面的定时调度周期保持一致因为在检测阶段计算PPS时要用这个值做分母如果调度周期和传入值不一致算出来的速率会偏差很大。2.3 采样周期怎么选500ms、1s还是5s采样周期直接影响检测灵敏度和误报率。周期越短对突发流量越敏感但控制器REST接口的调用压力也会增大Floodlight在周期小于500ms时可能因为线程阻塞而拖垮转发线程。以下是实际项目中常用的参数参考采样周期适用场景风险500ms高灵敏度实验单交换机容易把正常突发误判为攻击1s中小型虚拟网络默认推荐平衡性能和灵敏度5s低频率慢速攻击跨交换机封禁动作可能延迟5秒以上在SpringBoot里我一般用Scheduled注解启动定时采集fixedDelayString配置成${ddos.detection.sample-period}方便通过application.yml动态调整。注意fixedDelay和fixedRate的差异这里必须用fixedDelay否则上一次HTTP请求还没返回下一次又开始了。ddos: controller: base-url: 127.0.0.1 port: 8080 detection: sample-period: 1000 slot-ms: 1000 slot-num: 10采集到指标后不需要把原始数据全量入库。检测引擎只关心最近几十秒的速率我一般把PortMetric按switchId:portNumber作为key存到ConcurrentHashMap里同时保留前一轮的累计值。历史数据要归档的话再异步写入InfluxDB或Prometheus不要在采集线程里同步写库。3. 检测引擎基于滑动窗口与阈值的DDoS判定3.1 为什么不能用瞬时速率做判断检测DDoS攻击最容易犯的错是拿“当前一秒的PPS”和“固定阈值”做比较。正常业务流量本身就存在突发电商秒杀、批量任务回帖都会造成瞬间速率翻倍。如果把阈值设低误报率会高得没法用设高了真正的小流量攻击反而漏掉。常见的做法是引入滑动窗口把最近N个时间片的速率聚合成一个窗口值再和阈值比较。这样既能消除毛刺又能保证攻击持续几秒后一定能被感知。窗口的选择有个经验法则检测SYN Flood时窗口不要超过10秒否则攻击者在窗口内变化源IP会让检测结果失真。3.2 滑动窗口计数器的实现实现滑动窗口不需要引入复杂框架一个环形数组加上时间戳取模即可。关键点在于每次写入新槽位时要判断当前时间是否已经跨到了新的窗口周期如果跨了窗口需要把落后的槽位清零避免旧数据混入当前窗口。public class SlidingWindowCounter { private final long slotMs; private final int slotNum; private final long[] buckets; private long currentSlotKey; public SlidingWindowCounter(long slotMs, int slotNum) { this.slotMs slotMs; this.slotNum slotNum; this.buckets new long[slotNum]; } public synchronized long add(long nowMs, long value) { long slotKey nowMs / slotMs; int idx (int) (slotKey % slotNum); if (slotKey ! currentSlotKey) { if (slotKey - currentSlotKey slotNum) { // 跳过了整个窗口直接全部清零 Arrays.fill(buckets, 0L); } else { // 只清理中间跨过的槽位避免重复累加 long start currentSlotKey 1; for (long s start; s slotKey; s) { buckets[(int) (s % slotNum)] 0L; } } currentSlotKey slotKey; } buckets[idx] value; long sum 0L; for (long v : buckets) { sum v; } return sum; } }synchronized在这里是必须的虽然会牺牲一点并发性能但检测引擎处理的是秒级粒度的统计值每秒钟只有几次写入锁竞争几乎可以忽略。slotKey - currentSlotKey slotNum这个判断处理的是系统暂停超过一个完整窗口的情况比如SpringBoot服务GC停顿或者控制器响应超时如果不做这个判断那旧窗口的数据会被误算进当前窗口。3.3 攻击判定逻辑窗口求和与动态阈值有了滑动窗口计数器检测逻辑就清晰了对于每个switchId:portNumber把当前PPS写入窗口取窗口求和如果窗口总和超过了thresholdPps * slotNum就产生一条告警。这里有个更合理的做法是计算窗口平均值再和阈值比较但窗口求和的效果和平均值是等价的只是数值口径不同。public class DdosDetector { private final MapString, SlidingWindowCounter counters new ConcurrentHashMap(); private final long thresholdPps; private final long slotMs; private final int slotNum; public DdosDetector(long thresholdPps, long slotMs, int slotNum) { this.thresholdPps thresholdPps; this.slotMs slotMs; this.slotNum slotNum; } public AttackEvent detect(ListPortMetric metrics) { long now System.currentTimeMillis(); for (PortMetric m : metrics) { String key m.getSwitchId() - m.getPortNumber(); SlidingWindowCounter counter counters.computeIfAbsent( key, k - new SlidingWindowCounter(slotMs, slotNum)); long pps m.getReceivePackets() * 1000L / Math.max(1L, m.getSamplePeriodMs()); long windowTotal counter.add(now, pps); long avgPps windowTotal / slotNum; if (avgPps thresholdPps) { return new AttackEvent(key, m.getPortNumber(), pps, avgPps, thresholdPps, now); } } return null; } }thresholdPps不能拍脑袋定我一般的做法是先在没有攻击的平时流量下运行几个小时记录各个端口的PPS数据取90分位数再乘2或乘3作为初始阈值。如果链路是千兆口理论极限大约是1488000 PPS但实际业务跑到50万PPS已经算高流量阈值可以设置在20万到30万之间再根据误报情况上下调整。检测到攻击后不要立即下发防御规则这是很多人会犯的错。单次告警可能是突刺应该连续两个采样周期都触发相同告警才确认攻击。确认后的告警事件里应该带出switchId、portNumber、avgPps、thresholdPps和时间戳这组字段就是后面防御模块的输入。4. 防御执行用SpringBoot下发OpenFlow流表阻断攻击4.1 告警到防御的链路检测引擎产出AttackEvent后防御模块要做的第一件事不是下发drop规则而是查冷却表。同一个交换机端口在短时间内可能被重复告警如果每次告警都下发流表交换机的流表空间马上会被塞满。我这里维护一个ConcurrentHashMapkey是switchId:portNumbervalue是最后封禁时间封禁后5分钟内不重复下发相同规则。防御动作根据攻击类型分三种丢弃、重定向、限速。对于确认的SYN Flood或UDP Flood直接丢弃是最有效的对于可疑但是业务不能中断的流量优先把流量重定向到清洗端口。在Floodlight里最常见的下发方式是调用staticflowentrypusher接口。防御动作实现方式适用场景丢弃目标端口流量静态流表actiondrop确认攻击业务可中断重定向到清洗节点静态流表output到指定端口需要保留业务但先清洗端口限速Meter或Group表疑似攻击业务不可中断4.2 用Java代码下发Drop流表SpringBoot调用Floodlight的staticflowentrypusher非常简单一个POST请求就能完成。这里要注意priority参数的设置OpenFlow默认转发的优先级通常是32768要想让drop规则优先生效必须设置成大于默认优先级的数值。Service public class FlowRuleEnforcer { private final RestTemplate restTemplate new RestTemplate(); public void blockPort(String controllerBase, int controllerPort, String switchId, int portNumber) { String ruleName block-port- portNumber - System.currentTimeMillis(); MapString, Object flow new HashMap(); flow.put(switch, switchId); flow.put(name, ruleName); flow.put(priority, 50000); flow.put(ingress-port, String.valueOf(portNumber)); flow.put(active, true); flow.put(actions, drop); String url http:// controllerBase : controllerPort /wm/staticflowentrypusher/json; String resp restTemplate.postForObject(url, flow, String.class); log.info(下发封禁流表: {}, 响应: {}, ruleName, resp); } }ingress-port匹配的是流量进入交换机的物理端口对DDoS检测场景来说比较有效。如果攻击源集中在个别IP也可以把匹配字段换成ipv4-src格式需要写成1.2.3.4/32。activetrue表示规则立即生效。Floodlight的staticflowentrypusher设计上每次只能下发或修改一条流表批量封禁时要循环调用。4.3 用curl验证规则下发是否成功在本地调试时我习惯先用curl直接测试控制器接口确认参数没问题后再改Java代码。这样能省去不少排查时间也能快速验证控制器的接口行为是否符合预期。curl -X POST http://127.0.0.1:8080/wm/staticflowentrypusher/json \ -H Content-Type: application/json \ -d { switch: 00:00:00:00:00:00:00:01, name: block-test-1, priority: 50000, ingress-port: 3, active: true, actions: drop }命令执行后返回的一般包含Result和status字段如果返回里带true说明Floodlight已经把规则写入交换机。注意不同版本的Floodlight对JSON字段要求略有差异ingress-port有些版本接受字符串有些接受数字实际调试时两个都试一下。删除封禁规则用DELETE请求地址是/wm/staticflowentrypusher/json/{name}要保证name唯一否则删除时可能误删其他规则。4.4 自动防御时机的选择与恢复机制防御规则不能永久生效。攻击结束后流表还留在交换机上会导致业务无法恢复。所以下发规则时要带hard-timeout参数比如300秒到了时间自动过期。这也是为什么在SpringBoot里要对规则做持久化记录的原因否则交换机上的规则到期后SpringBoot内存里还保留着已经封禁的key后续告警会被冷却表拦下来形成“假封禁”。一个稳妥的做法是把攻击告警和封禁记录写入一张表字段包括switchId、portNumber、ruleName、beginTime、endTime、status。SpringBoot定时任务每30秒检查一次发现statusBLOCKED且当前时间超过endTime时主动调用控制器的删除接口清理规则再把状态改成EXPIRED。这比完全依赖交换机的硬超时更可靠因为控制器和交换机之间的链路偶尔会中断导致删除命令丢失。5. 回归验证、误报排查与阈值自调整技巧5.1 用Mininet造一个最小验证环境整个链路跑通之后验证不能只靠看日志。我在实验环境里习惯用Mininet创建一个single拓扑再接一个Floodlight控制器然后用hping3往目标主机发起SYN报文模拟异常流量。注意这只是实验网里的合法测试生产环境不要用这套流程。sudo mn --topo single,5 --controller remote,ip127.0.0.1,port6633拓扑起来后先在主机h1上执行ping h2确认基本连通性然后观察Floodlight的端口统计中各个端口PPS。此时阈值可以临时调低到1000 PPS便于快速触发告警。sudo hping3 --flood -S -p 80 10.0.0.2如果检测模块正常SpringBoot日志里应该出现AttackEvent接着下发流表的日志也会出现。验证流表是否真正进入交换机可以直接查Floodlight的流表列表接口curl -s http://127.0.0.1:8080/wm/staticflowentrypusher/list \ | python3 -m json.tool返回结果里能看到刚下发的规则名称、优先级和动作。如果交换机实现了OpenFlow统计还可以通过/wm/core/switch/{switch}/flow/json查看每条规则的匹配计数确认drop规则是否真的命中了流量。5.2 误报排查先看时间戳再看差值误报率是这套系统能否真正投入使用的关键。排查误报时我首先看采样时间和检测时间是否对得上SpringBoot的定时任务如果因为HTTP请求超时发生堆积会导致PortMetric里的collectTime不准窗口计算出来的PPS比实际高出一个量级。其次是检查差值计算逻辑。Floodlight返回的是累计值如果两次采集之间控制器重启了累计值会归零计算出的速率会变成负数。在采集层必须做判断当本次值小于上次值时跳过本轮差值计算而不是直接取绝对值。最后一个常用的调优手段是动态阈值。固定阈值在不同时间段表现差异很大我一般在SpringBoot里加一个ThresholdService每5分钟从近一小时的PPS数据中计算95分位把thresholdPps更新为p95 * 2。这个更新过程通过Scheduled执行阈值变化不需要重启服务。这样一套流程下来系统才能真正做到从检测到防御的闭环而不是一台只会发告警的定时任务。本文还有配套的精品资源点击获取