简介一套面向毕业设计的主机安全态势感知系统完整项目包适合网络空间安全、人工智能方向的本科生或研究生作为毕设参考与二次开发基础。系统围绕日志采集、特征工程、机器学习异常检测、实时监控与告警响应等核心模块展开覆盖从需求分析到功能实现的主要环节。压缩包共662个文件以619个JS前端脚本含ECharts可视化组件、15个Python后端/数据处理脚本、14个编译生成的pyc文件为主另有HTML页面、JSON配置、CSS样式、mmdb地理库及暴力破解、HTTP、SSH等分析模块整包约35.17MB。已有145人学习内容既包含可运行的代码骨架也结合ECharts实现了威胁情报地图便于读者快速理解态势感知的工作流程并针对自身课题扩展模型与功能。1. 主机安全态势感知系统毕设里的这个 zip拆出来到底在做什么主机安全态势感知系统听起来像企业级 SOC但对于毕业设计而言它的核心并不是算法有多深而是把「主机上有哪些正在发生的事」变成「能看、能查、能解释」的证据链。拿到这个 zip 之后你大概率面对的是这样一套东西主机侧有一个采集程序定时抓取进程、连接、账号登录、文件变更中间有一个管道把这些数据聚到一起存储层把结果归一化前端把统计结果和威胁事件画成 Tab 和大屏。整个标题的关键词落在「主机安全」和「态势感知」上前者框定了数据源后者框定了目标——不是做杀毒而是做可视化和关联分析。适合看这篇的人有两类一类是刚拿到这个项目、想在答辩前跑通并讲清楚的人另一类是实习生或初级安全工程师想从零搭一个可控、可演示的主机监控原型。下面所有内容都会围绕「怎么把这份 zip 变成一个能自圆其说的系统」来展开。先从架构说起因为绝大多数人解压之后的第一反应是找 README但真正的理解顺序应该是「数据从哪里来、到哪里去、凭什么说它是态势」。2. 从 agent 到可视化主机安全态势感知的模块分层与数据流选择把「主机安全态势感知」拆开看它由四个相对独立的层次组成。每一层都有可替换的开源实现而毕设的价值恰恰在于把层次之间的接口打通而不是重新发明轮子。2.1 四层结构采集、管道、存储与呈现第一层是数据采集。采集对象集中在五类主机痕迹上进程列表、网络连接、账号登录事件、文件与注册表变更、系统日志Windows 的事件日志或 Linux 的/var/log/secure。采集方式有轮询和事件驱动两种毕设项目里最常见的是定时轮询因为实现简单、效果直观而且答辩时容易演示「每隔 10 秒采集一次」这个动作。第二层是消息管道。它的作用不是传输大文件而是削峰填谷。当主机数量变多采集器和存储之间需要一层缓冲。常用的选择是 Redis List 或 Kafka。Redis 的优点是部署成本低适合单机演示Kafka 的好处是吞吐量大、支持多消费者但启动依赖 ZooKeeper或 KRaft 模式对毕设环境来说配置成本偏高。两者在数据流上承担的角色相同都是「写入侧解耦」。第三层是存储与分析。这一层决定了「态势」能做得多深。常见做法是 Elasticsearch 存全量事件MySQL/SQLite 存资产信息和告警结果Redis 存实时统计。ES 的价值在于全文检索和聚合统计比如查「过去 5 分钟内发起连接最多的源 IP」一条 agg 查询就能出结果关系型数据库则用于存主机清单、告警处置状态这类结构化程度高、更新频繁的数据。第四层是呈现。前端不一定要自己写很多毕设会用现成的可视化框架例如 ECharts、AntV G2或是直接用一个开源的大屏模板做二次开发。呈现层要回答三个问题当前一共有多少台主机在线、每台主机正在发生什么、这段时间内出现了哪些值得关注的威胁事件。这三件事对应的界面分别是「总览大屏」「主机详情页」「告警列表」。2.2 组件怎么选给毕业设计的匹配表层次常见组件毕设适用度说明采集端Python psutil、WMI、osquery高psutil 跨平台一门语言搞定进程、连接、CPU、内存、登录会话管道Redis List、Kafka、RabbitMQ高Redis 适合 1~5 台主机Kafka 用于展示高并发处理能力存储Elasticsearch MySQL高ES 存事件流水MySQL 存资产与告警状态前端ECharts Vue 3高大屏和列表页都能覆盖图表种类够用告警通知钉钉/邮件/飞书 webhook中加分项但不是必需演示时可以用前端告警面板替代选型的核心逻辑是「每一层都要能单机跑起来」。如果 ES 部署太重可以用 SQLite pandas 做分析效果会折扣但数据流链路依然完整。我一般建议课题组里的同学优先把链路打通再考虑引入 ES。否则第一次答辩时很容易出现前方可视化很漂亮、背后数据全是 mock 的情况——这会被评委一票否决。2.3 为什么说「态势感知」的核心是关联而不是告警很多毕设把「态势感知」做成了「告警列表」这其实错失了重点。单看「主机 A 有异常登录」只是一个事件「主机 A 异常登录成功后立即向主机 B 发起 445 端口扫描」才叫态势。前者是点后者是链。系统要能把这些点串成链就需要一个「关联字段」。最常见的是源 IP、目标 IP、账号名、主机 ID 四个字段的组合。这块是答辩时最有区分度的部分。与其堆一堆告警规则不如实现两条最有代表性的关联逻辑同一源 IP 在多个主机上登录失败同一主机在短时间内存在「登录成功 → 新建服务 → 外连」的路径。前者横向看扩散后者纵向看侵袭链。第二章的作用是帮你在心里搭好骨架现在进入实操——先把 zip 跑起来。3. 把 zip 跑起来解压、依赖与最小启动路径拿到「毕业设计 主机安全态势感知系统.zip」第一步是先确认里面是什么形态的交付物而不是直接双击运行。压缩包在传输过程中出现损坏、杀毒软件误删可执行文件、解压后路径含中文导致依赖加载失败这三个问题在毕设项目里反复出现。3.1 解压与目录结构先确认拿到的是什么形态建议不要用系统自带资源管理器右键解压而是用命令行工具这样遇到error read zip archive或 CRC 错误时能立刻看到详细信息。Windows 上常见的组合是 7-Zip 的7z命令Linux 上直接用unzip。# Windows 命令行7-Zip 安装目录 7z x 毕业设计 主机安全态势感知系统.zip -oD:/project/host_security -y # Linux 终端 unzip -q 毕业设计 主机安全态势感知系统.zip -d ~/host_security ll ~/host_security-o指定输出目录避免中文解压路径带来编码问题-y表示覆盖已有文件。解压后你通常会看到三类内容agent/主机采集端、server/后端服务与规则引擎、web/或dashboard/前端可视化。如果看到的是src/、doc/、sql/结构也正常说明作者按源码工程组织的。先不要急着运行先确认三件事有没有requirements.txt或pom.xml或package.json说明技术栈有没有config.ini或application.yml说明配置入口有没有README.md说明运行步骤。没有 README 时默认处理顺序是「先起存储、再起后端、再起采集端、最后开前端」。3.2 依赖清单与版本确认Python 技术栈的毕设项目最常见的问题是「代码是 3.7 写的你拿 3.11 跑某些依赖已经编译不了」。在安装依赖前先检查 Python 版本python --version pip --version pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple如果项目里没有requirements.txt但代码里import psutil、import pymysql、import requests那就手动补装这三个基础件。安装完成后用一段小代码验证采集端能够工作import psutil, json, time # 获取当前主机的基础状态作为采集端自检 proc_list [] for p in psutil.process_iter([pid, name, connections]): try: # 只保留建立了 TCP 连接的进程 if p.info[connections]: proc_list.append({ pid: p.info[pid], name: p.info[name], conns: len(p.info[connections]) }) except (psutil.NoSuchProcess, psutil.AccessDenied): pass print(json.dumps(proc_list[:5], ensure_asciiFalse, indent2))这段脚本的作用是确认 psutil 在当前操作系统上能正常遍历进程和连接。psutil.process_iter是迭代式获取进程信息比一次性process_iter()全量快attrs参数只提取需要的字段connections字段在 Windows 和 Linux 上都能拿到但需要管理员权限才能看到其他用户的进程连接信息这是正常的权限限制不是代码错误。3.3 最小启动顺序与验证命令一套典型的主机安全态势毕设系统启动顺序按依赖反向排先启动存储MySQL / Redis / Elasticsearch再启动后端服务和规则引擎然后启动 agent最后打开前端页面。以最常见的「Python 后端 Redis MySQL Vue 前端」组合为例# 1. 启动 MySQLWindows 服务或确认 3306 端口正在监听 netstat -ano | findstr :3306 # 2. 启动 RedisWindows 下用 redis-server.exe 或 WSL 中 service redis-server start redis-cli ping # 期望输出 PONG # 3. 初始化数据库项目里通常有 sql/init.sql mysql -uroot -p -e source D:/project/host_security/sql/init.sql; # 4. 启动后端 cd server python main.py --port 8080 # 5. 启动采集端另开一个终端 cd agent python agent.py --interval 10这里的--interval 10指采集周期是 10 秒一次。如果设计合理agent 每轮采集完会向后端/api/report推送一次 JSON 数据。验证方式是在后端日志里看到「received report from host-001」之类的记录或者在接口层自测curl -X POST http://127.0.0.1:8080/api/report \ -H Content-Type: application/json \ -d {\host_id\:\host-001\,\process_count\:128,\tcp_conns\:23}正常响应应返回{code: 0}或类似结构。如果这一步通了说明从采集到入库的链路已经走通接下来才是「感知能力」的实现与调优。4. 态势感知的「感知」在哪字段归一化、规则与调参数据能进系统只是完成了数字化还没完成安全化。要让系统具备「感知」能力需要做三件事统一数据字段、编写检测规则、调阈值防误报。这一步是整个项目的工作量重心也是答辩时评委最容易追问的部分。4.1 数据清洗把异构日志变成统一事件结构主机上的数据源格式五花八门进程列表是 pid/name/cpu/memory网络连接是 local/remote address/status登录日志在 Linux 是明文文本、在 Windows 是 Event ID。如果不做归一化后端的分析逻辑得针对每种格式各写一遍根本维护不住。统一的思路是定一张事件表字段名类型示例说明event_idstring20240601-001事件唯一编号host_idstringhost-001来自哪台主机event_typestringlogin/process/conn/file事件类型src_ipstring192.168.1.10来源 IPdst_ipstring192.168.1.20目标 IPaccountstringroot/admin涉及账号detailstring登录失败 3 次补充描述rawtext原始日志留作取证created_atdatetime2024-06-01 10:00:00发生时间归一化在 agent 端做一次后端就不再关心原始日志长什么样。判断 agent 归一化是否合格的标准很简单把采集到的数据全部导出来看能否只用 SQL 就完成「过去 5 分钟内登录失败最多的账号 Top 10」这类查询。如果答案是不能说明字段设计还不够干净。4.2 规则示例暴力破解与横向连接的检测有了统一事件结构检测逻辑就可以做成规则函数。下面是一个用 Python 实现的简单规则检测「同一源 IP 在 10 分钟内对 3 台以上主机登录失败超过 5 次」这个场景对应内网中的横向爆破尝试。import time from collections import defaultdict def detect_brute_force(events, window_sec600, threshold5, spread_min3): 暴力破解检测规则 events: 归一化后的登录事件列表 window_sec: 时间窗口默认 10 分钟 threshold: 同源 IP 登录失败次数阈值 spread_min: 涉及不同目标主机的最小数量 fail_map defaultdict(list) # 源IP - [主机ID, 时间戳] for ev in events: if ev[event_type] login and fail in ev[detail]: fail_map[ev[src_ip]].append((ev[host_id], ev[created_at])) alerts [] now time.time() for src_ip, records in fail_map.items(): # 只保留窗口内的记录并统计涉及多少台主机 in_window [r for r in records if now - r[1] window_sec] hosts set(r[0] for r in in_window) if len(in_window) threshold and len(hosts) spread_min: alerts.append({ alert_type: brute_force_spread, src_ip: src_ip, detail: f{len(in_window)} 次失败登录, 涉及 {len(hosts)} 台主机, hosts: list(hosts), ts: now }) return alerts逻辑说明代码先按src_ip对失败登录事件分组再用时间窗口过滤出当前有效事件统计窗口内涉及多少台不同主机。两个条件同时满足才告警——次数多且横向铺开。这里故意不设单主机内多次失败就告警因为单点爆破误报率太高可能是真人输入错密码横向扩散才是机器扫描的典型特征。参数上window_sec600用于对抗「低频慢速爆破」spread_min3的值取决于内网主机总数主机少就调小到 2。你可以把检测逻辑接入 WebSocket 推送或者定时扫最近 10 分钟的事件表。4.3 阈值参数怎么调从告警风暴到静默规则上线后第一个问题一定是误报。误报的来源通常不是检测逻辑写错而是参数跟环境不匹配。调试阈值时我习惯按三步走先把阈值调到「非常敏感」观察一天把产生的所有告警人工标记为「真攻击」和「假阳性」然后统计假阳性集中出现在哪些取值区间最后按「假阳性最多的事件类型」针对性加白名单或约束条件。最常见的白名单类型是「信任源 IP」和「运维窗口」。比如所在网络有一段是 DHCP 动态分配地址那么「IP 变化导致账号登录失败」就是正常现象需要把对应网段排除。再比如毕设演示环境里你本人会反复测试登录这时需要把演示机 IP 加进忽略名单否则大屏幕上会一直刷自己的操作记录。阈值参数建议放到配置文件里不要硬编码在规则函数中用 ini 或 yaml 管理[rule.brute_force] window_sec 600 threshold 5 spread_min 3 ignore_ips 127.0.0.1, 192.168.1.100调参的验证方法是回放把采集到的历史事件重新灌进规则引擎比较调整前后的告警数量与精确率如果一次调整能让告警量下降 50% 且没有漏掉已知攻击这组参数就可以固定下来。5. 答辩前要做的三件事攻击脚本、验证矩阵与人工研判演示到了这个阶段系统已经跑通规则已经能出告警。但答辩时的演示不能靠运气必须有一套「可重复、可预期、看得懂」的验证流程。这里分享我常用的三件事能把毕设的完成度拉高一个档位。第一件事是准备攻击模拟脚本。演示时如果只是打开大屏让评委看静态图表效果会大打折扣。更有效的做法是用脚本实时制造可控的安全事件。用 Python 在本地模拟一次密码爆破仅用于本机验证检测逻辑比引入真实攻击工具更安全可控import paramiko, time # 模拟爆破连续尝试 root 弱密码触发暴力破解规则 for i in range(8): try: client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(127.0.0.1, port22, usernameroot, passwordwrong_pwd, timeout3) except Exception: pass finally: client.close() time.sleep(1)这段脚本让系统在 8 秒内产生 8 次失败登录记录。配合第 4 章的规则如果threshold5已满足就会在告警列表里看到一条新告警大屏上的「今日告警」数字也会跳动。演示前跑一次确认从攻击开始到告警出现的延迟通常在 1~2 个采集周期内是可接受的。第二件事是做一张验证矩阵。把「输入事件 → 预期行为 → 系统实际表现」列成表贴在项目文档的首页PPT 里也可以放能让评委快速判断你理解系统好坏。常见验证矩阵示例验证场景操作预期系统行为主机上线启动 agent总览页主机数 1主机列表出现新记录暴力破解连续登录失败 5 次产生爆破告警详情含源 IP 与目标主机新进程创建安装一个 Nginx主机详情页出现 nginx 进程记录端口外连执行curl https://example.com网络连接表新增一条外连记录白名单过滤从白名单 IP 触发失败登录不产生告警第三件事是讲清「人工研判」的环节。很多毕设系统止步于告警答不出「告警之后怎么办」这是最容易丢分的点。你可以在告警列表里加一个「确认/误报」按钮点击后把结果写回数据库。这个功能在技术上极简单但能体现闭环思路。《主机安全痕迹排查与取证》类的热词检索量高说明大家对这个话题的关心在上涨。在系统里留一个「原始日志留存」功能例如保存最近 30 天的登录日志与连接日志答辩时顺手演示一次点击看原始 JSON 数据的过程能同时回应「事后取证」和「可解释性」两个问题。系统的终点不是告警而是让一个运维人员能在 5 分钟内回答出「这台主机发生了什么、我该不该处理、原始依据在哪里」——这三句话值得写进你的演示文案里。本文还有配套的精品资源点击获取 主机安全态势感知系统实战：从采集到可视化的毕设全解析
简介一套面向毕业设计的主机安全态势感知系统完整项目包适合网络空间安全、人工智能方向的本科生或研究生作为毕设参考与二次开发基础。系统围绕日志采集、特征工程、机器学习异常检测、实时监控与告警响应等核心模块展开覆盖从需求分析到功能实现的主要环节。压缩包共662个文件以619个JS前端脚本含ECharts可视化组件、15个Python后端/数据处理脚本、14个编译生成的pyc文件为主另有HTML页面、JSON配置、CSS样式、mmdb地理库及暴力破解、HTTP、SSH等分析模块整包约35.17MB。已有145人学习内容既包含可运行的代码骨架也结合ECharts实现了威胁情报地图便于读者快速理解态势感知的工作流程并针对自身课题扩展模型与功能。1. 主机安全态势感知系统毕设里的这个 zip拆出来到底在做什么主机安全态势感知系统听起来像企业级 SOC但对于毕业设计而言它的核心并不是算法有多深而是把「主机上有哪些正在发生的事」变成「能看、能查、能解释」的证据链。拿到这个 zip 之后你大概率面对的是这样一套东西主机侧有一个采集程序定时抓取进程、连接、账号登录、文件变更中间有一个管道把这些数据聚到一起存储层把结果归一化前端把统计结果和威胁事件画成 Tab 和大屏。整个标题的关键词落在「主机安全」和「态势感知」上前者框定了数据源后者框定了目标——不是做杀毒而是做可视化和关联分析。适合看这篇的人有两类一类是刚拿到这个项目、想在答辩前跑通并讲清楚的人另一类是实习生或初级安全工程师想从零搭一个可控、可演示的主机监控原型。下面所有内容都会围绕「怎么把这份 zip 变成一个能自圆其说的系统」来展开。先从架构说起因为绝大多数人解压之后的第一反应是找 README但真正的理解顺序应该是「数据从哪里来、到哪里去、凭什么说它是态势」。2. 从 agent 到可视化主机安全态势感知的模块分层与数据流选择把「主机安全态势感知」拆开看它由四个相对独立的层次组成。每一层都有可替换的开源实现而毕设的价值恰恰在于把层次之间的接口打通而不是重新发明轮子。2.1 四层结构采集、管道、存储与呈现第一层是数据采集。采集对象集中在五类主机痕迹上进程列表、网络连接、账号登录事件、文件与注册表变更、系统日志Windows 的事件日志或 Linux 的/var/log/secure。采集方式有轮询和事件驱动两种毕设项目里最常见的是定时轮询因为实现简单、效果直观而且答辩时容易演示「每隔 10 秒采集一次」这个动作。第二层是消息管道。它的作用不是传输大文件而是削峰填谷。当主机数量变多采集器和存储之间需要一层缓冲。常用的选择是 Redis List 或 Kafka。Redis 的优点是部署成本低适合单机演示Kafka 的好处是吞吐量大、支持多消费者但启动依赖 ZooKeeper或 KRaft 模式对毕设环境来说配置成本偏高。两者在数据流上承担的角色相同都是「写入侧解耦」。第三层是存储与分析。这一层决定了「态势」能做得多深。常见做法是 Elasticsearch 存全量事件MySQL/SQLite 存资产信息和告警结果Redis 存实时统计。ES 的价值在于全文检索和聚合统计比如查「过去 5 分钟内发起连接最多的源 IP」一条 agg 查询就能出结果关系型数据库则用于存主机清单、告警处置状态这类结构化程度高、更新频繁的数据。第四层是呈现。前端不一定要自己写很多毕设会用现成的可视化框架例如 ECharts、AntV G2或是直接用一个开源的大屏模板做二次开发。呈现层要回答三个问题当前一共有多少台主机在线、每台主机正在发生什么、这段时间内出现了哪些值得关注的威胁事件。这三件事对应的界面分别是「总览大屏」「主机详情页」「告警列表」。2.2 组件怎么选给毕业设计的匹配表层次常见组件毕设适用度说明采集端Python psutil、WMI、osquery高psutil 跨平台一门语言搞定进程、连接、CPU、内存、登录会话管道Redis List、Kafka、RabbitMQ高Redis 适合 1~5 台主机Kafka 用于展示高并发处理能力存储Elasticsearch MySQL高ES 存事件流水MySQL 存资产与告警状态前端ECharts Vue 3高大屏和列表页都能覆盖图表种类够用告警通知钉钉/邮件/飞书 webhook中加分项但不是必需演示时可以用前端告警面板替代选型的核心逻辑是「每一层都要能单机跑起来」。如果 ES 部署太重可以用 SQLite pandas 做分析效果会折扣但数据流链路依然完整。我一般建议课题组里的同学优先把链路打通再考虑引入 ES。否则第一次答辩时很容易出现前方可视化很漂亮、背后数据全是 mock 的情况——这会被评委一票否决。2.3 为什么说「态势感知」的核心是关联而不是告警很多毕设把「态势感知」做成了「告警列表」这其实错失了重点。单看「主机 A 有异常登录」只是一个事件「主机 A 异常登录成功后立即向主机 B 发起 445 端口扫描」才叫态势。前者是点后者是链。系统要能把这些点串成链就需要一个「关联字段」。最常见的是源 IP、目标 IP、账号名、主机 ID 四个字段的组合。这块是答辩时最有区分度的部分。与其堆一堆告警规则不如实现两条最有代表性的关联逻辑同一源 IP 在多个主机上登录失败同一主机在短时间内存在「登录成功 → 新建服务 → 外连」的路径。前者横向看扩散后者纵向看侵袭链。第二章的作用是帮你在心里搭好骨架现在进入实操——先把 zip 跑起来。3. 把 zip 跑起来解压、依赖与最小启动路径拿到「毕业设计 主机安全态势感知系统.zip」第一步是先确认里面是什么形态的交付物而不是直接双击运行。压缩包在传输过程中出现损坏、杀毒软件误删可执行文件、解压后路径含中文导致依赖加载失败这三个问题在毕设项目里反复出现。3.1 解压与目录结构先确认拿到的是什么形态建议不要用系统自带资源管理器右键解压而是用命令行工具这样遇到error read zip archive或 CRC 错误时能立刻看到详细信息。Windows 上常见的组合是 7-Zip 的7z命令Linux 上直接用unzip。# Windows 命令行7-Zip 安装目录 7z x 毕业设计 主机安全态势感知系统.zip -oD:/project/host_security -y # Linux 终端 unzip -q 毕业设计 主机安全态势感知系统.zip -d ~/host_security ll ~/host_security-o指定输出目录避免中文解压路径带来编码问题-y表示覆盖已有文件。解压后你通常会看到三类内容agent/主机采集端、server/后端服务与规则引擎、web/或dashboard/前端可视化。如果看到的是src/、doc/、sql/结构也正常说明作者按源码工程组织的。先不要急着运行先确认三件事有没有requirements.txt或pom.xml或package.json说明技术栈有没有config.ini或application.yml说明配置入口有没有README.md说明运行步骤。没有 README 时默认处理顺序是「先起存储、再起后端、再起采集端、最后开前端」。3.2 依赖清单与版本确认Python 技术栈的毕设项目最常见的问题是「代码是 3.7 写的你拿 3.11 跑某些依赖已经编译不了」。在安装依赖前先检查 Python 版本python --version pip --version pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple如果项目里没有requirements.txt但代码里import psutil、import pymysql、import requests那就手动补装这三个基础件。安装完成后用一段小代码验证采集端能够工作import psutil, json, time # 获取当前主机的基础状态作为采集端自检 proc_list [] for p in psutil.process_iter([pid, name, connections]): try: # 只保留建立了 TCP 连接的进程 if p.info[connections]: proc_list.append({ pid: p.info[pid], name: p.info[name], conns: len(p.info[connections]) }) except (psutil.NoSuchProcess, psutil.AccessDenied): pass print(json.dumps(proc_list[:5], ensure_asciiFalse, indent2))这段脚本的作用是确认 psutil 在当前操作系统上能正常遍历进程和连接。psutil.process_iter是迭代式获取进程信息比一次性process_iter()全量快attrs参数只提取需要的字段connections字段在 Windows 和 Linux 上都能拿到但需要管理员权限才能看到其他用户的进程连接信息这是正常的权限限制不是代码错误。3.3 最小启动顺序与验证命令一套典型的主机安全态势毕设系统启动顺序按依赖反向排先启动存储MySQL / Redis / Elasticsearch再启动后端服务和规则引擎然后启动 agent最后打开前端页面。以最常见的「Python 后端 Redis MySQL Vue 前端」组合为例# 1. 启动 MySQLWindows 服务或确认 3306 端口正在监听 netstat -ano | findstr :3306 # 2. 启动 RedisWindows 下用 redis-server.exe 或 WSL 中 service redis-server start redis-cli ping # 期望输出 PONG # 3. 初始化数据库项目里通常有 sql/init.sql mysql -uroot -p -e source D:/project/host_security/sql/init.sql; # 4. 启动后端 cd server python main.py --port 8080 # 5. 启动采集端另开一个终端 cd agent python agent.py --interval 10这里的--interval 10指采集周期是 10 秒一次。如果设计合理agent 每轮采集完会向后端/api/report推送一次 JSON 数据。验证方式是在后端日志里看到「received report from host-001」之类的记录或者在接口层自测curl -X POST http://127.0.0.1:8080/api/report \ -H Content-Type: application/json \ -d {\host_id\:\host-001\,\process_count\:128,\tcp_conns\:23}正常响应应返回{code: 0}或类似结构。如果这一步通了说明从采集到入库的链路已经走通接下来才是「感知能力」的实现与调优。4. 态势感知的「感知」在哪字段归一化、规则与调参数据能进系统只是完成了数字化还没完成安全化。要让系统具备「感知」能力需要做三件事统一数据字段、编写检测规则、调阈值防误报。这一步是整个项目的工作量重心也是答辩时评委最容易追问的部分。4.1 数据清洗把异构日志变成统一事件结构主机上的数据源格式五花八门进程列表是 pid/name/cpu/memory网络连接是 local/remote address/status登录日志在 Linux 是明文文本、在 Windows 是 Event ID。如果不做归一化后端的分析逻辑得针对每种格式各写一遍根本维护不住。统一的思路是定一张事件表字段名类型示例说明event_idstring20240601-001事件唯一编号host_idstringhost-001来自哪台主机event_typestringlogin/process/conn/file事件类型src_ipstring192.168.1.10来源 IPdst_ipstring192.168.1.20目标 IPaccountstringroot/admin涉及账号detailstring登录失败 3 次补充描述rawtext原始日志留作取证created_atdatetime2024-06-01 10:00:00发生时间归一化在 agent 端做一次后端就不再关心原始日志长什么样。判断 agent 归一化是否合格的标准很简单把采集到的数据全部导出来看能否只用 SQL 就完成「过去 5 分钟内登录失败最多的账号 Top 10」这类查询。如果答案是不能说明字段设计还不够干净。4.2 规则示例暴力破解与横向连接的检测有了统一事件结构检测逻辑就可以做成规则函数。下面是一个用 Python 实现的简单规则检测「同一源 IP 在 10 分钟内对 3 台以上主机登录失败超过 5 次」这个场景对应内网中的横向爆破尝试。import time from collections import defaultdict def detect_brute_force(events, window_sec600, threshold5, spread_min3): 暴力破解检测规则 events: 归一化后的登录事件列表 window_sec: 时间窗口默认 10 分钟 threshold: 同源 IP 登录失败次数阈值 spread_min: 涉及不同目标主机的最小数量 fail_map defaultdict(list) # 源IP - [主机ID, 时间戳] for ev in events: if ev[event_type] login and fail in ev[detail]: fail_map[ev[src_ip]].append((ev[host_id], ev[created_at])) alerts [] now time.time() for src_ip, records in fail_map.items(): # 只保留窗口内的记录并统计涉及多少台主机 in_window [r for r in records if now - r[1] window_sec] hosts set(r[0] for r in in_window) if len(in_window) threshold and len(hosts) spread_min: alerts.append({ alert_type: brute_force_spread, src_ip: src_ip, detail: f{len(in_window)} 次失败登录, 涉及 {len(hosts)} 台主机, hosts: list(hosts), ts: now }) return alerts逻辑说明代码先按src_ip对失败登录事件分组再用时间窗口过滤出当前有效事件统计窗口内涉及多少台不同主机。两个条件同时满足才告警——次数多且横向铺开。这里故意不设单主机内多次失败就告警因为单点爆破误报率太高可能是真人输入错密码横向扩散才是机器扫描的典型特征。参数上window_sec600用于对抗「低频慢速爆破」spread_min3的值取决于内网主机总数主机少就调小到 2。你可以把检测逻辑接入 WebSocket 推送或者定时扫最近 10 分钟的事件表。4.3 阈值参数怎么调从告警风暴到静默规则上线后第一个问题一定是误报。误报的来源通常不是检测逻辑写错而是参数跟环境不匹配。调试阈值时我习惯按三步走先把阈值调到「非常敏感」观察一天把产生的所有告警人工标记为「真攻击」和「假阳性」然后统计假阳性集中出现在哪些取值区间最后按「假阳性最多的事件类型」针对性加白名单或约束条件。最常见的白名单类型是「信任源 IP」和「运维窗口」。比如所在网络有一段是 DHCP 动态分配地址那么「IP 变化导致账号登录失败」就是正常现象需要把对应网段排除。再比如毕设演示环境里你本人会反复测试登录这时需要把演示机 IP 加进忽略名单否则大屏幕上会一直刷自己的操作记录。阈值参数建议放到配置文件里不要硬编码在规则函数中用 ini 或 yaml 管理[rule.brute_force] window_sec 600 threshold 5 spread_min 3 ignore_ips 127.0.0.1, 192.168.1.100调参的验证方法是回放把采集到的历史事件重新灌进规则引擎比较调整前后的告警数量与精确率如果一次调整能让告警量下降 50% 且没有漏掉已知攻击这组参数就可以固定下来。5. 答辩前要做的三件事攻击脚本、验证矩阵与人工研判演示到了这个阶段系统已经跑通规则已经能出告警。但答辩时的演示不能靠运气必须有一套「可重复、可预期、看得懂」的验证流程。这里分享我常用的三件事能把毕设的完成度拉高一个档位。第一件事是准备攻击模拟脚本。演示时如果只是打开大屏让评委看静态图表效果会大打折扣。更有效的做法是用脚本实时制造可控的安全事件。用 Python 在本地模拟一次密码爆破仅用于本机验证检测逻辑比引入真实攻击工具更安全可控import paramiko, time # 模拟爆破连续尝试 root 弱密码触发暴力破解规则 for i in range(8): try: client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(127.0.0.1, port22, usernameroot, passwordwrong_pwd, timeout3) except Exception: pass finally: client.close() time.sleep(1)这段脚本让系统在 8 秒内产生 8 次失败登录记录。配合第 4 章的规则如果threshold5已满足就会在告警列表里看到一条新告警大屏上的「今日告警」数字也会跳动。演示前跑一次确认从攻击开始到告警出现的延迟通常在 1~2 个采集周期内是可接受的。第二件事是做一张验证矩阵。把「输入事件 → 预期行为 → 系统实际表现」列成表贴在项目文档的首页PPT 里也可以放能让评委快速判断你理解系统好坏。常见验证矩阵示例验证场景操作预期系统行为主机上线启动 agent总览页主机数 1主机列表出现新记录暴力破解连续登录失败 5 次产生爆破告警详情含源 IP 与目标主机新进程创建安装一个 Nginx主机详情页出现 nginx 进程记录端口外连执行curl https://example.com网络连接表新增一条外连记录白名单过滤从白名单 IP 触发失败登录不产生告警第三件事是讲清「人工研判」的环节。很多毕设系统止步于告警答不出「告警之后怎么办」这是最容易丢分的点。你可以在告警列表里加一个「确认/误报」按钮点击后把结果写回数据库。这个功能在技术上极简单但能体现闭环思路。《主机安全痕迹排查与取证》类的热词检索量高说明大家对这个话题的关心在上涨。在系统里留一个「原始日志留存」功能例如保存最近 30 天的登录日志与连接日志答辩时顺手演示一次点击看原始 JSON 数据的过程能同时回应「事后取证」和「可解释性」两个问题。系统的终点不是告警而是让一个运维人员能在 5 分钟内回答出「这台主机发生了什么、我该不该处理、原始依据在哪里」——这三句话值得写进你的演示文案里。本文还有配套的精品资源点击获取