简介一份基于Python的网络入侵检测与防御系统完整源码专为毕业设计、课程设计及网络安全实践打造。系统支持实时流量捕获与分析、异常攻击检测、自动告警拦截和Web可视化监控可帮助在校生快速完成可演示的安全项目。资源共38个文件包含14个Python脚本Flask后端与Scapy抓包逻辑、9个pyc编译模块、4个HTML页面与3个JavaScript交互脚本另有CSS样式、JSON配置、Dockerfile与docker-compose.yml容器化部署文件以及requirements.txt和安装启动脚本压缩包仅92KB结构紧凑完整。技术栈覆盖Flask、Flask-SocketIO、Scapy、MongoDB与Docker Compose附带详细项目说明指南从环境安装、数据采集到功能演示均有清晰指引Web界面直观易用可实时查看流量统计、攻击日志与系统设置便于答辩展示和二次开发。已有172人学习浏览适合作为院校答辩或安全课设的完整实现也可在此基础上扩展自定义检测规则与防御策略。1. 基于Python的网络入侵检测与防御系统毕设能做什么一套闭环解决抓包、检测、阻断、展示毕业设计里选“基于Python的网络入侵检测与防御系统”本质上是拿一个可运行的安全系统同时覆盖“实时流量分析、攻击检测、自动防御、可视化监控”四个考核点。系统挂在局域网一台主机上网卡进入混杂模式抓取流量用Scapy解析数据包并按会话聚合成特征再用规则引擎或统计基线判断流量是否异常判定为攻击后自动调用iptables阻断攻击源IP同时把流量统计和告警推送到Web面板刷新。这套链路既有算法又有工程答辩时能演示的是“攻击触发→自动阻断→界面出现防御记录”的完整闭环。适合正在找毕设方向的学生、想补攻防实操经验的开发者以及需要内网小型监控工具的运维。2. 系统架构与模块划分实时流量分析、攻击检测、自动防御如何分层协作大部分同学拿到这类源码项目第一反应是直接跑main.py跑通了就开始改界面。这个顺序是错的。网络入侵检测系统最忌讳的就是“所有逻辑揉在一个文件里”后面你改一个阈值都要全局搜索答辩时被问“模块之间怎么通信”也答不上来。所以我建议先花半小时把架构吃透再动手改代码。2.1 为什么选PythonScapy、pandas和Flask的组合优势做入侵检测语言选型的关键在于“抓包能力”和“数据处理效率”。C/C加libpcap确实性能强但实现一套协议解析加规则引擎周期太长不适合一个毕业设计周期。Python生态里Scapy是事实上的抓包标准库一个sniff函数就能拿到原始数据包自带的协议解析器覆盖了以太网、IP、TCP、UDP、ICMP这些常见协议不需要自己手动解二进制头部。数据处理层用pandas做滑动窗口和分位数统计非常顺手。比如你要算“过去5秒内某个源IP发出的SYN包数量”一条groupby加rolling就能出结果这在C语言里要写几十行。可视化层用Flask加一个前端图表库Web面板的开发时间能压缩到两三天。还有个实际考量Python比较容易找到参考代码。网上开源的网络入侵检测项目八成以上是Python写的你遇到问题搜一下就是解决方案。用Python做这个方向意味着你把省下来的时间花在了检测算法调优和防御联动上而不是花在跟内存泄漏搏斗上。2.2 三层模块划分采集层、检测层、响应层的职责边界这套系统的核心设计原则是“分层且单向依赖”。采集层只负责把数据包从网卡拿回来不判断正常还是异常检测层只负责基于特征输出“是攻击”或“不是攻击”的结论不执行任何阻断动作响应层拿到检测结论后做防御动作和展示但不会反向去影响采集逻辑。层次核心职责输出物关键依赖采集层网卡抓包、协议解析、去重、分发原始数据包对象Scapy检测层会话聚合、特征提取、规则匹配告警事件含攻击类型、源IP、目标IPpandas 规则引擎响应层阻断、日志、可视化、通知iptables规则、告警记录、Web接口subprocess Flask为什么强调单向依赖因为一旦检测层直接调用iptables去封IP你的程序就变成了一锅粥规则误判时你不知道是检测逻辑错了还是阻断逻辑错了。分层之后每一层都可以单独喂数据测试。我在实际开发中就是这么干的先把检测层单独跑起来用pcap文件做离线回放确认告警准确率能接受了再把响应层接上。2.3 核心数据流一个数据包从网卡到可视化面板要走完的链路理解这套系统关键看一条数据包的生命周期。数据包从网卡到面板一共走六步。第一步采集层的sniff循环收到一个数据包立刻把它放进一个线程安全队列Queue里。这里注意采集层在入队之前对数据包做一次轻量级过滤比如只保留IP协议减少后面处理层的负担。第二步检测层的消费线程从Queue里取包按照五元组源IP、源端口、目标IP、目标端口、协议找到对应的会话记录把当前包的时间戳、长度、TCP标志位追加到这条会话里。第三步每到一个检测周期比如5秒检测层对最近一个窗口内的所有会话做特征计算输出一个特征向量包含包数量、平均包长、SYN包占比、端口数量等。第四步特征向量进入规则引擎与配置文件中定义的阈值逐一比较。命中任何一条规则就生成一个告警事件告警事件里写清楚攻击类型、源IP、目标IP、触发规则名称、当前特征值。第五步告警事件被推送到响应层。响应层的defender模块消费事件调用iptables添加DROP规则同时把事件写入告警日志文件。第六步Web服务从告警日志和内存中的流量统计摘取最近数据通过REST接口暴露出来前端图表定时拉取并刷新。这条链路里最容易出问题的位置在第二步和第五步的衔接采集入队快消费解析慢队列一旦积压就丢包。后面避坑章节会专门讲。2.4 工程目录建议与启动入口main.py和config.yaml怎么配合拿到一个号称“源码详细运行指南”的项目先打开目录看结构。这类毕设源码的典型目录组织是这样的nids_project/ ├── main.py # 启动入口初始化线程 ├── config.yaml # 网卡、阈值、白名单配置 ├── sniffer/ │ └── packet_sniffer.py # 采集层封装sniff ├── detector/ │ ├── feature_extractor.py # 会话聚合与特征计算 │ └── rule_engine.py # 检测规则与阈值判断 ├── defender/ │ ├── firewall.py # iptables封装 │ └── alert_logger.py # 告警落盘 ├── web/ │ ├── app.py # Flask应用 │ ├── templates/ │ └── static/ # 前端JS与图表库 └── logs/ ├── alerts.log # 告警记录 └── system.log # 运行日志main.py做的事不多但很关键读config.yaml启动sniffer线程启动detector消费线程启动defender线程启动Flask服务然后主线程进入简单的状态轮询防止程序退场。配置文件单独放的好处是你在答辩现场调整阈值只需要改yaml文件再重启不需要重新编译演示效果会很加分。config.yaml里最少要有四个配置块network网卡名称、detect窗口大小和阈值、defense白名单网段、web服务端口。后续章节介绍的具体参数都会落到这个文件里。3. 用Scapy实现实时流量分析与攻击检测从抓包到特征提取的完整链路这一章是系统的心脏。所谓实时流量分析本质就是把“网卡上流动的比特”变成“结构化的特征数字”然后基于数字做判断。我见过很多同学卡在第一步——抓包抓到了但不知道怎么组织特征。下面按顺序拆开讲。3.1 最小抓包程序sniff函数的关键参数与权限前提先写一个能跑的最小程序确认环境没问题再做复杂逻辑。from scapy.all import sniff, IP, TCP def packet_callback(pkt): 每个数据包到达时触发 if IP in pkt: proto pkt[IP].proto src pkt[IP].src dst pkt[IP].dst length len(pkt) print(f{src} - {dst} | proto{proto} | len{length}) # store0 表示不在内存保存原始包避免长时间运行导致内存暴涨 # count0 表示无限抓包直到手动中断 sniff(prnpacket_callback, count0, store0)逻辑说明sniff函数的prn参数指定每个包到达时的回调函数回调里解析IP层拿到源地址、目标地址和协议号。count0是持续抓包store0是不缓存原始数据包这两个参数在长时间运行时必须这样配。如果你在代码里省略store0默认会把所有数据包缓存在内存里跑几个小时内存占用就奔着几个G去了。运行权限这里有个踩坑点Linux下sniff必须用root运行普通用户没有权限把网卡设为混杂模式。Windows下先装Npcap驱动并且要以管理员身份打开命令行或IDE。装好之后用一条命令验证抓包能力python -c from scapy.all import sniff, IP; sniff(prnlambda p: p[IP].src if IP in p else None, count5)如果这条命令能打出5个IP地址说明环境就绪。如果卡住不动或报错优先检查驱动和管理员权限而不是检查代码。3.2 会话特征提取把零散数据包聚合成可计算的连接记录抓包只是开始检测逻辑需要的是“一段时间内的统计量”而不是单个数据包。比如检测端口扫描你需要知道“这个源IP在5秒内触达了多少个不同目标端口”检测SYN Flood你需要知道“这个源IP在5秒内发出了多少个SYN包”。这些统计量的基础是先完成会话聚合。from collections import defaultdict import time import threading session_table defaultdict(list) session_lock threading.Lock() def extract_features(pkt): 把数据包追加到对应的会话记录 if IP in pkt and TCP in pkt: key (pkt[IP].src, pkt[TCP].sport, pkt[IP].dst, pkt[TCP].dport) entry { ts: time.time(), length: len(pkt), flags: pkt[TCP].flags, } with session_lock: session_table[key].append(entry)逻辑说明用源IP、源端口、目标IP、目标端口组成的元组作为字典key每个连接对应一个列表列表里存放这个连接上的所有数据包摘要信息。flags字段保存TCP标志位后面判定SYN包时直接做位运算。这里必须加锁因为sniffer线程和检测线程会并发读写这张表不加锁程序跑到一半就会遇到字典在遍历时被修改的运行时错误。会话聚合之后检测层的思路就变得很直接每隔5秒遍历session_table里所有连接对每个连接计算一组统计特征。常见特征包括连接内包总数、平均包长、SYN包数量、目标端口多样性等。有了这些特征规则引擎才能工作。3.3 三类攻击检测规则SYN Flood、端口扫描、暴力破解的判定逻辑毕设里最常被要求覆盖的攻击类型是SYN Flood、端口扫描和暴力破解。这三个检测规则的逻辑都不复杂但细节有讲究。def detect_syn_flood(entries, window5, threshold80): 检测SYN Flood窗口期内SYN包数量超过阈值 now time.time() syn_count 0 for e in entries: # TCP SYN标志位是0x02用位与判断 if now - e[ts] window and (e[flags] 0x02): syn_count 1 return syn_count threshold逻辑说明window参数控制时间窗口threshold参数是阈值。判断SYN包的核心代码是e[flags] 0x02TCP SYN标志位对应的二进制是000010即十进制的2。这里有个经验SYN Flood有时候表现为单个源IP对同一个目标端口发大量SYN有时候表现为多个源IP对同一个目标IP发大量SYN前一种场景按源IP聚合后一种场景按目标IP聚合。config.yaml里可以加一个聚合维度配置项默认按源IP聚合。def detect_port_scan(src_ip, window5, port_threshold20): 检测端口扫描同一源IP在窗口期内触达不同端口数量超过阈值 now time.time() dst_ports set() with session_lock: for key, entries in session_table.items(): if key[0] ! src_ip: continue for e in entries: if now - e[ts] window: dst_ports.add(key[3]) # key[3]是目标端口 if len(dst_ports) port_threshold: return True return False逻辑说明遍历所有以该源IP开头的会话收集窗口期内的目标端口放入setset天然去重。如果目标端口数量超过20判定为端口扫描。这里端口阈值的设定很关键正常办公环境下内网主机访问的端口通常是个位数20是比较保守的值。暴力破解检测的思路稍微不同。暴力破解的核心特征是“短时间内发起大量连接尝试且每个连接交互的数据量极少”。所以判定条件是同一源IP对同一目标IP在窗口期内新建连接数超过阈值且每个连接的平均包长度小于某个值。这个规则能有效避开正常文件传输那种“连接数少但数据量大”的流量。3.4 检测阈值怎么定先统计基线再定阈值别拍脑袋阈值设定是这套系统里最需要“经验”也最容易“翻车”的地方。我见过很多同学把阈值随便写成100、1000结果要么是正常流量疯狂触发告警要么是攻击打完了系统还没反应。我一般会这样做把系统先以纯监听模式跑起来用tcpdump采集24小时真实流量保存为pcap文件。然后写一个离线分析脚本统计每个特征值的P50、P95、P99分位数。初始阈值取P99的1.5倍。比如监控发现正常时段内“每5秒SYN包数量”的P99是30那SYN Flood阈值就设为45。之后再通过攻击模拟测试来校准阈值太高就逐步下调直到能稳定捕获攻击。很多开源项目的配置文件里会直接给一组“默认阈值”但那组数字是针对作者的测试环境调的拿过来直接用通常会有问题。这也是为什么config.yaml要单独拆出来——你是要培训的人需要随时有权限调整这些参数。4. 自动防御与可视化监控落地从检测结果到iptables阻断和Web实时面板检测到攻击只是把问题“看出来了”毕设要高评价必须把“自动防御”和“可视化监控”两条链路打通。这一章讲清楚响应层怎么设计以及怎么用Flask快速做一个能实时刷新图表的监控面板。4.1 自动防御的响应链从检测到动作的延迟控制自动防御的逻辑其实是一条生产者消费者模型检测层是生产者产生告警事件响应层是消费者消费告警并执行阻断动作。这个模型的关键是“消费速度和告警频率要匹配”。我在实际实现里用Python标准库的queue.Queue作解耦。检测层命中规则后执行alert_queue.put(alert_event)响应层在独立线程里执行alert_queue.get()拿到事件后立刻调用iptables。Queue自带线程安全不需要额外加锁而且天然支持一个生产多个消费的扩展场景。延迟控制的细节经常被忽略defender模块执行iptables命令时用了subprocess这条命令本身是要花时间的。如果每次阻断都是串行等待攻击流量大的时候事件会积压。解决办法是把防火墙操作做成异步任务或者至少把超时时间设置得很短比如1秒即使单次阻断失败也记录下来继续处理下一条。4.2 调用iptables自动阻断攻击源IP阻断攻击源IP最直接、最通用的方式是调用系统iptables。以下是封装好的防火墙模块import subprocess import logging def block_ip(ip: str) - bool: 追加一条INPUT链DROP规则丢弃来自该IP的所有包 try: cmd [iptables, -A, INPUT, -s, ip, -j, DROP] subprocess.run(cmd, checkTrue, timeout3, capture_outputTrue) logging.info(fblocked {ip}) return True except subprocess.CalledProcessError as e: logging.error(fiptables rule failed for {ip}: {e.stderr.decode()}) return False def unblock_ip(ip: str) - bool: 删除对应的阻断规则用于临时封禁后的解封 try: cmd [iptables, -D, INPUT, -s, ip, -j, DROP] subprocess.run(cmd, checkTrue, timeout3, capture_outputTrue) return True except subprocess.CalledProcessError: return False逻辑说明block_ip向INPUT链末尾追加一条规则指定源IP为攻击IP目标是DROP丢弃。checkTrue保证命令失败时抛出异常capture_outputTrue用来捕获stderr便于排查。unblock_ip用-D参数删除同一条规则用来实现“临时封禁”策略封禁30分钟后自动解封避免把正常用户因为规则误判而长时间隔离。参数说明里有个容易被忽略的点iptables规则是有顺序的-A表示追加到链末尾。如果你的服务器本身已经有防火墙规则新追加的规则可能会被前面的ACCEPT规则抢先匹配导致DROP不生效。稳妥做法是改用-I参数插入到链最前面iptables -I INPUT 1 -s 攻击IP -j DROP这条命令把规则插入到链的第一行保证优先匹配。至于是用-A还是用-I取决于你的目标环境但我自己部署时优先用-I。4.3 用Flask Chart.js做实时可视化监控页可视化监控页面需要展示三样东西流量趋势图、攻击事件列表、当前阻断的IP清单。后端用Flask提供数据接口前端用Chart.js画图实现成本不高效果却能打。# web/app.py from flask import Flask, jsonify, render_template from collections import deque import time app Flask(__name__) # 每个元素是一个二元组(时间戳, 当前窗口流量字节数) traffic_history deque(maxlen60) app.route(/api/traffic) def traffic_api(): 前端轮询的流量数据接口返回最近60个时间点的数据 data [ {time: ts, bytes: count} for ts, count in traffic_history ] return jsonify(data) app.route(/) def index(): return render_template(index.html) if __name__ __main__: # 监听所有网卡方便局域网内演示访问 app.run(host0.0.0.0, port5000, debugFalse)逻辑说明Flask应用提供两个路由根路径返回页面/api/traffic返回流量历史数据。traffic_history用deque存储且maxlen60这意味着内存里最多保留60个采样点数据自动滚动丢弃不需要手动管理内存。前端页面每2秒fetch一次/api/traffic把返回的时间戳和字节数追加到Chart.js的数据集中。前端部分核心逻辑可以写在一个template里async function refreshChart() { const res await fetch(/api/traffic); const points await res.json(); chart.data.labels points.map(p p.time); chart.data.datasets[0].data points.map(p p.bytes); chart.update(); } setInterval(refreshChart, 2000);说明setInterval每2秒触发一次刷新函数从Flask接口拉取最新数据并更新图表。2秒的轮询间隔对毕设演示足够而且远比WebSocket实现简单。如果你需要更“实时”的效果再考虑换成WebSocket或SSE。4.4 告警日志设计让每一次防御动作都有据可查可视化面板展示的是“当前状态”但答辩时老师一定会问“你怎么证明你的系统真的防御过”这个问题只能靠告警日志来回答。每条告警记录应该包含这些字段触发时间、攻击类型、源IP、目标IP、目标端口、触发规则、当前特征值、阈值、阻断动作、处理耗时。这些信息足够支撑答辩时“挑一条告警说故事”的叙述。日志落盘格式用JSON行一行一条记录方便后续用pandas分析误报率。import json import time def write_alert(alert): record { time: time.strftime(%Y-%m-%d %H:%M:%S), type: alert.attack_type, src_ip: alert.src_ip, dst_ip: alert.dst_ip, rule: alert.rule_name, value: alert.current_value, threshold: alert.threshold, action: alert.action, } with open(logs/alerts.log, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)说明使用JSON行格式而不采用CSV是因为JSON能保存嵌套结构且不担心字段包含逗号导致解析错位。每条记录都固化了“当前值/阈值”这对数据答辩时你可以指着一条告警说当时这个源IP在5秒内发出了132个SYN包超过我们设定的80阈值所以被判定为攻击并被阻断。5. 常见问题与避坑指南从“能跑”到“能答辩”的五个关键坎我在这套系统的开发和教学上踩过不少坑。下面这五条基本覆盖了从搭环境到演示现场最常见的翻车场景每条按“现象→原因→解决”来说明希望你能绕开这些消耗时间的陷阱。5.1 Scapy抓包一直报错Windows下没装Npcap驱动现象代码没有问题但sniff一运行就报错提示socket权限不足或者直接抛OSError找不到网络设备。原因Windows系统默认的网络抓包能力不开放给用户层程序Scapy底层需要Npcap提供WinPcap兼容的抓包接口。你装好了Python和Scapy但没装Npcap这个驱动等于车有引擎没装轮胎。解决安装Npcap驱动安装时勾选“Install Npcap in WinPcap API-compatible Mode”这个选项确保Scapy能通过兼容接口访问网卡。安装完成后用管理员身份重新打开命令行或IDE再跑一次验证脚本。记住即使驱动装好了普通权限的终端还是会被拒绝管理员权限是硬前提。5.2 sniff阻塞主线程导致界面卡死现象程序启动后只看到抓包打印信息按任何键没反应Flask服务也连不上整个应用看起来像死机一样。原因sniff本身是一个阻塞式循环调用它的线程会一直被它占住。如果直接在main线程里调用sniff那后面的所有初始化代码都永远不会执行。解决把sniff放进单独守护线程运行。Python的标准库threading就够了不需要引入多进程。启动时先创建守护线程并启动sniff主线程继续初始化Web服务和检测模块。注意daemonTrue这个参数否则程序退出时守护线程会阻止进程结束。import threading def start_sniffer(): from scapy.all import sniff sniff(prnpacket_callback, count0, store0) threading.Thread(targetstart_sniffer, daemonTrue).start() # 主线程继续执行Web服务启动等逻辑5.3 SYN Flood规则误杀正常连接现象系统在没有攻击的时段频繁告警甚至把网关IP给封了导致整台监控主机自己断网需要手动登录服务器删iptables规则。原因阈值设太低正常业务高峰期的SYN包数量本来就高还有一个常见原因是聚合维度选择错误——把“所有源IP发往开放端口443的SYN包”统一聚合成一个会话而不是按“源IP五元组”做区分。解决先从审计模式开始调参不要一开始就开着自动阻断。config.yaml里加一个白名单段把内网核心网关和监控主机自身排除在外。同时把阈值从配置文件中读取方便在运行中调整而不是写在代码的硬编码里。# config.yaml示例 defense: trusted_nets: [192.168.1.0/24, 127.0.0.1/8] auto_block: true block_duration_seconds: 300 detect: syn_flood_threshold: 80 syn_flood_window: 5 port_scan_threshold: 20 brute_force_conn_threshold: 155.4 流量一大就开始丢包现象用hping3模拟攻击时系统偶尔能识别但更多时候漏检对比tcpdump抓到的原始包数量发现sniff回调处理的包数量少了一截。原因Python解释器一次处理一个包当数据包速率超过处理能力时内核缓冲区里的包会被丢弃。尤其是sniff回调里做了太多复杂操作比如实时计算、写日志、打印输出都会拖慢处理速度形成积压。解决采集层只做最轻量的工作——拿到包放进队列立刻返回。所有特征提取、规则匹配都放到独立的消费线程里。打印输出在生产时要关掉print是出了名的性能杀手。还可以调大sniff的缓冲区参数Scapy的sniff函数支持buffer参数控制内核缓冲我这里习惯设置为65536字节。from queue import Queue packet_queue Queue(maxsize10000) def packet_callback(pkt): 采集层回调只入队不做其他事 try: packet_queue.put(pkt, blockFalse) except queue.Full: pass # 队列满说明消费跟不上丢弃旧包比阻塞好并且把sniff的buffer调大sniff(prnpacket_callback, count0, store0, buffer65536)5.5 本机回环流量抓不到Sniffing on loopback现象本机用nmap扫描127.0.0.1触发攻击时系统无任何告警但扫描局域网内的其他主机却能正常检测到。原因默认sniff监听的网卡是首块活动网卡通常是物理网卡或无线网卡而本地回环流量走的是lo接口这个接口默认不进入混杂模式。解决在配置里显式指定监听接口。Linux上监听回环流量用ifacelo如果想监听所有接口可以用ifaceany但要注意使用any模式时数据包会出现重复抓取的问题需要在回调函数里做去重。# 监听所有接口Linux only sniff(prnpacket_callback, ifaceany, count0, store0)如果你的毕设演示环境是Windows需要注意Scapy在Windows上对回环接口的支持有限建议直接跑在虚拟机或Linux服务器上避免在回环问题上浪费太多时间。6. 进阶用nmap和hping3做攻击复现验证你的检测与防御真的有效毕设答辩前最值得做的一件事是问自己如果老师当场让我演示攻击检测我不出意外地让他们看到效果吗答案需要靠攻击复现来验证而不是靠口头描述。6.1 攻击模拟命令与验证步骤找一个干净的内网测试环境准备两台机器一台运行你的系统另一台作为攻击机。攻击机上安装nmap和hping3然后依次执行三类攻击验证。第一轮验证端口扫描检测。在攻击机执行nmap -sS -p 1-200 192.168.1.10观察系统端10秒内应在Web面板上看到一条“端口扫描”告警日志文件里出现记录iptables -L能查到你为攻击机IP添加的DROP规则。第二轮验证SYN Flood检测。在攻击机执行hping3 -S -p 80 --flood 192.168.1.10观察系统端CPU占用会明显上升检测线程应能在阈值窗口期内触发阻断。如果阻断规则生效攻击机的hping3会开始大量超时重传。第三轮验证暴力破解检测。在攻击机执行hydra -l admin -P password.txt ssh://192.168.1.10hydra会快速发起大量SSH连接尝试检测规则应能捕捉到“短时大量连接”的特征。6.2 性能与阈值调整的启发式验证过程中如果发现查漏不要急着改代码。先看告警日志里的“当前值/阈值”这对数据你会清楚地看到实际流量和阈值之间的差距这就是调参的依据。我个人的经验总结把阈值调整当作一次小型的A/B测试。每次只调一个参数用同样的攻击命令打一轮记录是否触发调整幅度控制在20%以内避免从一个极端跳到另一个极端。调参过程要留存记录写在项目的README或调参文档里答辩时主动讲“我根据测试结果如何调参”比被动回答“阈值为什么是80”更能加分。最开始做这个毕设时我犯过一个很蠢的错把公司内网网关IP写死了白名单觉得“网关肯定是可信的”结果内网一台中了伏特的机器伪装成网关MAC地址疯狂向内网发包我的规则愣是没识别出来。这件事让我明白所谓白名单必须有校验条件而不能只信IP地址。后来我在白名单判断里加了一条校验源MAC必须是网关的真实MAC才算可信。做网络防御系统永远不要相信单维度的信息。希望帮到你。本文还有配套的精品资源点击获取