简介：面向毕业设计与课程设计的网络入侵检测与防御项目，以Python为基底，整合实时流量分析、攻击检测、自动防御与可视化监控，适合网络安全方向学生快速搭建课设原型，也可作为毕设演示系统二次开发。资源共38个文件，以14个Python源码文件为核心，辅以9个编译后的pyc、4个HTML页面、3个JavaScript脚本及CSS、JSON、Dockerfile等配置，压缩包整体约92KB，目录分明，代码内附注释，便于定位与修改。系统基于Flask与Flask-SocketIO构建Web服务，利用Scapy捕获解析网络数据包，内置检测规则与告警响应机制，可对恶意流量实施拦截；前端采用Bootstrap与Chart.js，以图表形式展示流量趋势、攻击统计与系统状态。容器化方面提供Docker Compose编排文件，配合install脚本与requirements依赖清单，能够快速完成环境部署。随包另附详细项目说明指南，包含模块设计与运行说明，帮助理解整体架构。目前已有172人学习下载，适合需要完整参考实现并追求可读性的本科毕设与课程设计场景。
1. 基于Python的网络入侵检测与防御系统：毕设场景下它到底能干什么
毕业设计撞上“网络入侵检测”这个题目，很多人上来就想堆机器学习模型，可真到演示节点才发现，连实时流量都没地方抓、告警不知道往哪展示。这个Python项目换了一条务实的路线：用Scapy实时捕获网卡流量，规则引擎解析五元组和TCP特征，识别端口扫描、SYN Flood、ICMP Flood这类常见攻击，命中后自动执行封禁，再通过Web仪表盘把流量趋势和攻击事件实时亮出来。做毕设、课程设计可以直接跟着运行指南把服务跑起来；想搭IDS/IPS原型的从业者，规则库、防御模块和MongoDB存储结构都是现成的改造点，不用从零拼。
2. 核心架构与模块职责：Flask、Scapy、SocketIO、MongoDB各自扮演什么角色
2.1 整体架构：三层面怎么分工
这个项目没有把抓包、检测、展示揉在同一个文件里，而是拆成三层，各跑各的线程，靠队列和事件把链路串起来。抓包层由Scapy负责，它绑定网卡做实时流量捕获，抓到包后只做最简单的字段提取就丢进内存队列；检测层是一个规则引擎，消费队列里的数据包，做协议解析和攻击判定；展示层是Flask应用，通过Flask-SocketIO把告警实时推到浏览器。数据层用MongoDB存攻击日志、封禁列表和系统配置，Docker则负责把整套环境打包交付，省去每台机器手动配Python环境的重复劳动。
把一条数据包走完的链路写出来，对后面理解踩坑很有帮助：网卡收到一个SYN包，Scapy回调提取源IP、目的IP、源端口、目的端口和TCP标志位，写入packet_queue；后台detector线程从队列取包，更新滑动窗口统计，判断是否超过阈值；一旦命中SYN_FLOOD规则，防御模块封禁源IP并写告警记录；同时SocketIO把告警事件推给前端Chart.js，页面上的流量曲线和告警表格同步刷新。链路里最容易被忽视的是抓包与检测必须解耦，否则高流量下Scapy回调被数据库写操作卡住，抓包本身就会丢包。
Flask在这里的角色是“应用外壳”，不管抓包细节，只负责路由、模板渲染和静态资源。modules目录下按职责拆了sniffer和detector模块，routes.py负责API和页面路由，templates和static分别是Jinja2模板与前端资源。这种拆法对毕设答辩很友好，评委问“模块之间怎么解耦”，直接指出队列和SocketIO事件这两条边界就行，比一锅粥的脚本清晰得多。
2.2 源码结构解读：哪些文件是你要改的
收到压缩包后先别急着跑，把目录结构过一遍，搞清楚每个文件的作用，后面改规则、加页面才不会找半天。典型结构如下：
| 路径 | 职责 | 你需要关注的改动点 |
|---|---|---|
| app.py | Flask应用入口，启动Web服务和抓包线程 | 端口、host、是否启动抓包 |
| app/init.py | 应用工厂，注册路由与数据库连接 | MongoDB连接串、模块注册 |
| modules/sniffer.py | Scapy抓包与队列写入 | iface网卡名、抓包过滤表达式 |
| modules/detector.py | 规则引擎与攻击判定 | 阈值、时间窗口、规则逻辑 |
| modules/defense.py | 封禁、解封与黑名单管理 | 封禁时长、iptables命令 |
| routes.py | 页面路由和API接口 | /api/alerts之类接口的返回字段 |
| templates/ | Jinja2页面模板 | 仪表盘布局 |
| static/ | Chart.js、Bootstrap等前端资源 | 图表刷新频率、告警颜色 |
| docker/ | Dockerfile与docker-compose.yml | 端口映射、卷挂载 |
| install.sh / install.py | 依赖安装与初始化 | Python版本、pip源 |
| requirements.txt | Python依赖清单 | 版本锁定 |
app.py是整个系统的心脏，初始化Flask应用、绑定SocketIO、启动抓包子线程。核心代码大概是这个骨架：
from flask import Flask from flask_socketio import SocketIO from modules.sniffer import start_sniffer from modules.detector import DetectionEngine from routes import register_routes app = Flask(__name__) socketio = SocketIO(app, cors_allowed_origins="*", async_mode="threading") detector = DetectionEngine() register_routes(app, detector, socketio) if __name__ == "__main__": start_sniffer(detector, iface="eth0") socketio.run(app, host="0.0.0.0", port=5000, debug=False)这里有几个参数值得展开。host设成0.0.0.0，是为了让Docker容器或局域网里其他机器能通过IP访问仪表盘；如果只在本机调试，改成127.0.0.1也行。debug=True在我们这种带抓包线程的场景里要慎开，因为Flask的reloader会重启进程，把抓包子线程也带着重启，容易出现端口占用或重复抓包。async_mode="threading"指的是SocketIO用线程模式跑，不依赖eventlet和gevent，兼容性最好，代价是并发性能一般，对毕设仪表盘完全够用。
start_sniffer(detector, iface="eth0")这一行是在Web服务启动前拉起抓包线程，注意它是非阻塞的，内部用daemon线程跑Scapy的sniff循环，所以不会挡在socketio.run前面。iface名字在不同操作系统上差异很大，Linux常叫eth0或ens33，Windows常见WLAN或以太网，macOS是en0，写死之前先跑一遍Scapy的list_interfaces确认。
2.3 容器化部署结构：Docker Compose 编排与两个注意点
压缩包里带了docker-compose.yml和Dockerfile，说明项目作者考虑到不同机器跑Python环境容易翻车，直接容器化交付。Compose文件大致长这样：
version: "3.8" services: app: build: . ports: - "5000:5000" depends_on: - mongo environment: MONGO_URI: mongodb://mongo:27017/ids_db volumes: - ./logs:/app/logs mongo: image: mongo:6.0 volumes: - mongo_data:/data/db volumes: mongo_data:这里面第一个坑是端口映射跟抓包的关系。app容器做端口映射后虽然外部能访问5000，但容器内Scapy监听的是容器自己的虚拟网卡，抓不到宿主机物理网卡的真实流量。我一般会用两种解法：一是把app服务改成network_mode: host，host模式下容器直接用宿主网络栈，但这时ports配置要删掉，访问直接用宿主机IP加5000；二是让抓包模块支持通过参数关闭抓包，把抓包进程单独跑在宿主机上，容器只跑Web和检测。两种方式各有取舍，具体看你的演示场景。
第二个坑是depends_on只是控制启动顺序，不代表MongoDB已经完全就绪。容器启动的瞬间MongoDB可能在初始化过程中，Flask应用连库会报错。常见做法是在install.py或app启动代码里加一个重试逻辑，或者用healthcheck检查mongo的健康状态再启动app，不然第一次docker-compose up偶尔会看到MongoDB连接超时。
提示：容器部署时，抓包权限和网络栈隔离是两件最容易出问题的事，建议先在宿主机上把整套系统跑通，再套容器，这样排错时能把环境因素和代码因素分开。
2.4 选型理由：为什么是 Scapy、MongoDB 而不是别的方案
选型不是拍脑袋，这个技术栈明显是为“教学可演示、开发速度快、改起来直观”服务的。抓包层面，Python生态里最常用的是Scapy和dpkt。Scapy不仅能解析，还能构造和发送数据包，调试攻击脚本和验证防御效果时不用换另一套工具链，这是它最大的优势。dpkt解析性能更好但只有解析没有构造，想模拟SYN Flood还要额外找发包库。Suricata和Snort性能、规则库都强，但要先学一套规则语法和配置体系，对课程设计来说学习成本偏高。下面是面向毕设场景的对比：
| 方案 | 性能 | 上手成本 | 发包能力 | 适合场景 |
|---|---|---|---|---|
| Scapy | 一般 | 低 | 支持 | 教学、原型验证、快速开发 |
| dpkt | 较好 | 中 | 不支持 | 纯解析类工具 |
| Suricata | 高 | 高 | 不支持 | 生产级入侵检测 |
| Snort | 高 | 高 | 不支持 | 生产级入侵检测 |
存储层选MongoDB而不是MySQL，是因为攻击日志和流量统计都是半结构化数据，字段随时可能扩展，比如今天要加一个user_agent字段，用MySQL就得改表结构，MongoDB直接往文档里塞就行了。另外黑名单、检测规则这些配置以JSON文档形式存，跟Python的字典结构天然匹配，不用做ORM映射。对毕设项目，答辩时解释“为什么文档型数据库更适合日志类数据”本身就是个加分项。
3. 实时流量分析与攻击检测：抓包参数、规则定义与检测链路
3.1 抓包入口：sniff参数到底怎么调
Scapy的sniff是系统流量分析的入口，几乎所有实时数据都从这函数出来。很多人第一次跑起来发现“啥都抓不到”或者“一抓就卡死”，基本都是参数没吃透。先看一段最核心的抓包代码：
from scapy.all import sniff, IP, TCP, UDP, ICMP, list_interfaces iface = "eth0" # Windows上先跑 list_interfaces() 确认实际网卡名 print(list_interfaces()) def handle_packet(pkt): if IP in pkt: src = pkt[IP].src dst = pkt[IP].dst proto = pkt[IP].proto size = len(pkt) print(f"[capture] {src} -> {dst} proto={proto} size={size}") sniff(iface=iface, prn=handle_packet, store=False, count=0, timeout=60)参数逐个说清楚：iface指定监听的网卡，写错就抓不到，所以前面先打印list_interfaces把所有可用网卡列出来；prn是每抓到一包就会被调用的回调函数，这是数据处理的主入口；store=False很关键，sniff默认会把所有包缓存在内存里，长时间抓包内存会持续上涨，关掉存储只做实时处理才能跑长任务；count=0表示不限数量一直抓；timeout=60是分段停止，配合循环可以做定时任务。注意抓包需要root权限，Linux下要用sudo运行，Windows下要装Npcap驱动。
回调函数里我通常只做最轻量的字段提取，不做数据库写入，不做复杂运算。原因很简单：sniff的回调是同步执行的，如果回调里耗时太长，后面的包就要排队，高流量下直接丢包，而且CPU会被拖满。这个“回调里只干轻活”的原则，后续小节会用队列来落实。
3.2 规则定义：从抓包到攻击事件
有了原始包，下一步是从协议字段里提取特征，跟规则库比对。规则引擎的核心是五元组加TCP标志位：源IP、目的IP、源端口、目的端口、协议，再加上包大小和时间戳，这八个字段足以识别出绝大多数常见攻击。项目里预置的规则大致是这么一张表：
| 规则名 | 特征条件 | 判定动作 |
|---|---|---|
| 端口扫描 | 同一源IP在60秒内访问超过20个不同目的端口且均为SYN包 | 告警并封禁源IP |
| SYN Flood | 同一源IP在60秒内SYN包数量超过30 | 告警并封禁源IP |
| ICMP Flood | 同一源IP在60秒内ICMP包数量超过100 | 告警并限制速率 |
| Ping of Death | ICMP包长度异常或分片偏移异常 | 告警并丢弃 |
规则引擎的代码实现可以写得很简洁，核心就是一个滑动窗口计数器：
import time from scapy.all import IP, TCP THRESHOLD = 30 WINDOW = 60 stats = {} def detect_attack(pkt): if IP in pkt and TCP in pkt: flags = pkt[TCP].flags if flags & 0x02: # SYN标志位 now = time.time() src = pkt[IP].src stats.setdefault(src, []).append(now) stats[src] = [t for t in stats[src] if now - t < WINDOW] if len(stats[src]) > THRESHOLD: return "SYN_FLOOD", src return None参数说明都写在这里：THRESHOLD=30表示一个源IP在WINDOW=60秒内SYN包累计超过30次就判定为攻击。这里不是简单累加，而是用列表存储每个包的时间戳，然后过滤掉窗口之外的老记录，这样计数器就能滑动，不会因为“两小时前发过攻击”这种历史数据一直触发告警。flags & 0x02是位运算，检查TCP头部SYN标志位是否为1，比直接比较flags == 0x02更严谨，因为SYN包可能同时带其他标志位。
阈值怎么定，这是整个系统里最玄学的部分。30这个数字在Demo环境里很灵敏，几行扫描脚本就能触发；但如果你在自己电脑上开着浏览器访问外网，正常连接产生的SYN可能也会到几十次，容易误报。我一般会把检测分成两步：先用低阈值做“可疑标记”，再要求连续多个窗口都命中才判定攻击，这个思路在后面进阶章节会细说。
3.3 检测链路与队列解耦：别在回调里做重活
流量分析和攻击检测两个阶段要分开跑，靠queue连接。抓包线程只负责把包放队列，检测线程负责消费和判定，这样两边速度不一致时不会互相拖累。工程上的标准做法：
import queue import threading packet_queue = queue.Queue(maxsize=2000) alert_queue = queue.Queue() def on_packet(pkt): try: packet_queue.put_nowait(pkt) except queue.Full: pass # 队列满了就丢，优先保证抓包线程不被阻塞 def detection_worker(): while True: pkt = packet_queue.get() event = detect_attack(pkt) if event: alert_queue.put(event) threading.Thread(target=detection_worker, daemon=True).start()put_nowait配合queue.Full的处理是防止队列无限积压的兜底策略，当检测速度跟不上抓包速度时，新的包会被丢弃而不是撑爆内存，这在实时监控里是“丢新不丢旧”的取舍。detection_worker放在daemon线程里，主程序退出它跟着结束，不会残留僵尸线程。alert_queue是给下一阶段防御模块用的，检测模块只负责“发现问题”并把事件交给队列，不直接执行封禁，保持模块间单向依赖。
队列解耦之后有一个附带的好处：流量统计和告警展示可以各自消费数据。前端需要每秒刷新一次统计数字，直接读stats字典就行；告警推送只消费alert_queue。四层链路各干各的，定位问题的时候也能很快判断是抓包死了还是检测逻辑写错了。另外一个实用技巧是给sniff加BPF过滤表达式，比如只关心TCP流量就写sniff(iface=iface, filter="tcp", ...)，能显著降低无效包的数量，让CPU省下来干活。
4. 自动防御与告警响应：拦截机制、黑名单策略与可视化监控
4.1 自动防御：从命中到封禁的完整动作
检测到攻击只是第一步，这个项目的亮点是“自动防御”，也就是命中规则后立刻执行拦截策略。项目里最直接的做法是通过iptables封禁来源IP，模块里用一个ban_ip函数封装整条命令：
import subprocess import time from pymongo import MongoClient client = MongoClient("mongodb://localhost:27017") db = client.ids_db BAN_DURATION = 300 # 封禁时长，单位秒 def save_alert(event): db.alert_logs.insert_one({ "time": int(time.time()), "type": event[0], "src": event[1], "action": "ban" }) def ban_ip(ip, duration=BAN_DURATION): if is_whitelisted(ip): return False db.blacklist.insert_one({ "ip": ip, "created_at": int(time.time()), "expire_at": int(time.time()) + duration }) cmd = ["iptables", "-I", "INPUT", "-s", ip, "-j", "DROP"] result = subprocess.run(cmd, capture_output=True, text=True) return result.returncode == 0逻辑说明：先查白名单，命中的IP直接放行，避免把自己或学校网关封掉；然后写MongoDB黑名单，记录封禁时间和过期时间，为后面的自动解封留依据；最后用subprocess调用iptables添加拒绝规则。-I INPUT表示插入到INPUT链最前面，优先匹配；-s指定源IP；-j DROP直接丢包，比REJECT更省资源，也不给对方明确反馈。save_alert把攻击事件落到alert_logs集合，这是MongoDB在项目里的主要数据来源。
这里有个权限前提：执行iptables需要root权限。如果你用sudo python app.py启动整套系统，subprocess调用iptables时是继承sudo身份的；如果用普通用户启动，这里会报权限不足，需要在defense.py里做一次权限检测并给出明确提示。Docker容器里跑iptables还需要容器具备NET_ADMIN能力，否则同样失败。
4.2 黑名单策略与自动解封：别把自己封出局
封禁IP做到一半就不管了，演示久了会发现黑名单越积越长，内网里大家全被封掉。项目里的解封逻辑是这样做的：后台开一个定时任务，每30秒扫描一次blacklist集合，检查过期记录，调用iptables删除对应规则：
def sweep_expired_rules(): now = int(time.time()) expired = db.blacklist.find({"expire_at": {"$lt": now}}) for doc in expired: ip = doc["ip"] subprocess.run(["iptables", "-D", "INPUT", "-s", ip, "-j", "DROP"]) db.blacklist.delete_one({"_id": doc["_id"]}) threading.Timer(30, sweep_expired_rules).start()delete_one用_id定位删除，避免删错记录；-D参数跟-I对应，表示删除指定规则。之所以做成30秒扫一次而不是每次封禁时顺带检查，是为了避免频繁遍历iptables规则列表，毕竟iptables -L在规则多的时候也不算快。封禁时长BAN_DURATION默认300秒，也就是5分钟，这个值对演示刚好：攻击脚本跑完去Web面板截图，5分钟后恢复连通，不影响后续测试。
防御策略上还应该预留白名单机制，项目里黑名单与白名单通常是两个集合，白名单优先级高于黑名单。判断顺序一定要是“先白名单后黑名单”，我在实际调试时有过一次血泪教训：把自己电脑的IP写进黑名单规则后，SSH直接断了，只能去机房手动清规则。从那之后我强制要求所有封禁动作前必须过一遍白名单。
4.3 实时监控与告警推送：SocketIO怎么把事件推给浏览器
防御动作做完，可视化监听是这套系统最出效果的部分。后端通过routes.py暴露统计接口，同时用SocketIO把新告警实时推给前端。后端接口大致提供了以下数据：
| 接口 | 返回内容 | 前端用途 |
|---|---|---|
| /api/stats | 总包数、告警数、封禁IP数、当前速率 | 仪表盘顶部数字卡片 |
| /api/alerts | 最新告警列表 | 告警表格初始渲染 |
| /api/blacklist | 当前黑名单及过期时间 | 黑名单管理页面 |
| /api/rules | 规则列表与阈值配置 | 系统设置页面 |
前端JavaScript监听告警事件，插到表格顶部并刷新图表：
var socket = io(); socket.on('alert_event', function(data) { $('#alert-table').prepend( '<tr><td>' + data.time + '</td><td>' + data.type + '</td><td>' + data.src + '</td><td>已封禁</td></tr>' ); updateChart(data.time, data.type); }); function updateChart(time, type) { if (typeof attackChart !== 'undefined') { attackChart.data.labels.push(time); attackChart.data.datasets[0].data.push(1); attackChart.update(); } }SocketIO事件的数据结构由后端决定，通常包含time、type、src三个字段，分别对应攻击时间、攻击类型、来源IP。prepend把最新告警插到表格第一行，比append更像实时监控的交互习惯。Chart.js的attackChart实例在页面初始化时创建，updateChart每次推送都往里追加一个点，形成攻击频率的时间序列。
后端推送的逻辑其实很薄：检测线程命中规则后，defense模块把事件写入alert_queue，然后由推送线程通过socketio.emit('alert_event', event)广播给所有前端页面。这里顺带解释为什么选Flask-SocketIO而不是前端轮询API：轮询每秒请求一次接口，流量大、延迟高，而且浏览器要一直维持HTTP请求；SocketIO建立长连接后服务端主动往客户端推，浏览器页面打开就能收到实时告警，演示体验明显更流畅。
5. 避坑与常见问题：从环境搭建到跑通的五条踩坑记录
这套系统看着不复杂，但真从头搭一遍，容易踩的坑比想象中多。下面五条都是我在实际跑项目时真实触发过的问题，每条按“现象、原因、解决”写清楚，遇到类似情况可以直接对着排。
5.1 抓包环境起不来或收不到包
现象：启动后直接抛OSError: Permission denied，连list_interfaces都能正常输出，一到sniff就崩；或者程序跑起来但一行流量都打不出来，回调函数从不执行。
原因：两类情况混在一起。一是抓包权限不对，Scapy要开原始套接字，普通用户没这个权限；二是监听的网卡选错了，Windows上常见的是WLAN或以太网，代码里写死eth0自然抓不到，另外sniff里的filter="tcp"这类BPF表达式也会把UDP、ICMP都过滤掉，造成“什么都没发生”的假象。
解决：Linux、macOS下用sudo python app.py启动，Windows下先装Npcap，装的时候勾选WinPcap API兼容模式。网卡名不要靠猜，在代码开头跑一次scapy.all.list_interfaces()，对照系统网络设置里的名字再填。测试阶段先把filter参数去掉，用手机往电脑发消息验证有数据进来，再逐步加过滤，这样能快速确认抓包链路是通的。
5.2 MongoDB连接超时与启动顺序问题
现象：Flask启动后报pymongo.errors.ServerSelectionTimeoutError: No servers found yet，Web服务起来了但所有依赖数据库的接口都在报错。
原因：Mongo服务没启动，或者连接串写错。本地开发时mongod没跑起来，后端代码直接连localhost:27017自然连不上；容器部署时depends_on只是控制启动顺序，MongoDB容器在初始化完成之前，Flask就开始连库了。
解决：本地先命令行跑mongod --dbpath验证数据库能独立启动，再用mongosh连接确认没问题后再启动Python应用。容器环境给mongo服务加healthcheck，或者在应用启动代码里做三次重试、每次间隔两秒。连接串注意区分环境：容器内部用mongodb://mongo:27017，宿主机直连用mongodb://localhost:27017，别混着填。
5.3 Docker容器里iptables防御失效
现象：Web面板显示“已封禁”，来源IP进了黑名单，但攻击流量还在源源不断进来，防御形同虚设。
原因：Docker容器内的iptables跟宿主机网络栈是隔离的，容器里执行iptables -I INPUT封的是容器自己的INPUT链，宿主机物理网卡收到的流量根本不经过这条链。另外有的defense模块只往数据库写了黑名单，没校验iptables命令是否真的执行成功，前端看到“已封禁”其实是误报。
解决：容器部署时把app服务设置成network_mode: host，让容器共享宿主机网络栈，封禁规则才能作用到真实流量；或者把封禁逻辑从容器里挪出来，改成宿主机上的独立进程执行。defense模块里必须检查subprocess.run的返回码，非零就记录错误日志并回滚前端状态，数据库里有没有记录不能当作封禁成功的依据。
5.4 CPU飙到100%与页面卡死
现象：系统运行一段时间后CPU占用接近100%，Web页面刷新极慢，抓包结果也出现明显延迟。
原因：Scapy的回调函数里干了重活，比如在回调里直接写MongoDB或者做复杂规则计算，导致抓包线程被阻塞；sniff没有设置store=False，所有包都被缓存在内存里，越积越多；stats字典里滑动窗口的过期数据没清理，内存和计算量都在涨。
解决：回调里只做字段提取和入队，把检测逻辑交给detection_worker线程；sniff显式传store=False；统计字典每次写入时顺手把窗口之外的时间戳删掉。如果流量确实很大，给sniff加BPF过滤表达式，只保留TCP或指定协议，减少无效包。
5.5 前端SocketIO始终连不上
现象：页面能打开，但浏览器控制台一直报WebSocket连接失败，实时图表完全不更新，只有手动刷新才能看到新数据。
原因：Flask-SocketIO的async_mode没显式指定，机器上装了eventlet就优先用eventlet，没装就退回threading，两套异步行为不一致；如果前面还挂了网关或负载均衡，网关没开启WebSocket协议升级，长连接建立不起来。
解决：创建SocketIO时强制指定async_mode="threading"，去掉对eventlet和gevent的隐式依赖；本地演示直接访问5000端口，不套额外网关层，能少一层变量。确认后端代码里用了socketio.emit而不是普通request上下文里的写法，后者在实际部署时也常导致推送失效。
6. 进阶验证：用Scapy模拟攻击流量，校准检测灵敏度
6.1 自己给自己发攻击包，验证系统是否真能命中
系统跑通之后，最需要证明的是“它真的能检测到攻击”，而不是界面上一直显示零告警。安全起见，只在自己实验网段里测试，别拿公网IP练手。用Scapy写一个最小的SYN Flood模拟器：
from scapy.all import IP, TCP, send target_ip = "192.168.1.100" # 换成你跑检测系统的机器 for i in range(50): pkt = IP(dst=target_ip)/TCP(flags="S", sport=10000+i, dport=80) send(pkt, verbose=False)这段脚本发起50个源端口递增的SYN包，模拟一次小规模握手洪泛。跑完去Web面板看告警日志，正常应该看到SYN_FLOOD事件，来源IP是执行脚本的机器，状态为已封禁。端口扫描的验证同理，把目的端口改成1到100连续扫一遍，触发端口扫描规则。如果发完包面板没反应，优先怀疑检测线程没有消费队列，或者规则阈值太高，先用小数量发包确认抓包链路是通的，再逐步加大数量。
6.2 灵敏度校准：把阈值从“乱封”调到“可用”
我最早把SYN阈值设成10，结果开个浏览器、刷个网页，后台就封了一片IP，连自己路由器都封进去，页面直接打不开。后来改了思路：用滑动窗口连续两次命中才触发封禁，第一次命中只记可疑，不执行动作。也就是把“一次超标”升级为“持续超标”，误报率立刻降下来。
参数上我最终用的是：窗口60秒、单窗口SYN阈值30、连续命中2次、封禁300秒、白名单包含网关和本机IP。这套值在单机演示和课程设计场景下很省心。如果你要在更真实的网络里跑，把阈值拉高到50到80，连续命中次数保持2到3次。从那以后我每次改规则都会先跑一遍仿真流量再放行，确认检测逻辑确实命中、封禁确实生效，然后才放心做后续测试，希望帮到你。
本文还有配套的精品资源，点击获取
