AI SSH 运维助手 V13.13.8：用 eBPF 实现秒级入侵检测与自动取证

2026-11-12 12:57 0 阅读

为什么传统监控守不住服务器安全

大多数运维人员都有过这样的经历：服务器被植入挖矿脚本，往往不是安全工具第一时间报警，而是 CPU 占用率飙升触发监控告警，甚至是客户投诉服务变慢后才发现。当你通过 top 命令排查时，挖矿进程可能已经运行了数小时，定时任务里藏好了持久化脚本，authorized_keys 文件中也多出了陌生的公钥。

传统的监控方案（如 Prometheus 配合 Alertmanager）主要解决的是“资源异常”问题。但资源异常通常是攻击发生后的下游症状，而非上游原因。真正需要关注的是那些具有攻击特征的行为指纹：

Web 进程何时开始执行 Shell 命令？
curl 或 wget 何时从外部下载文件并立即执行？
凌晨时段是否有大量 SSH 登录失败记录？

针对这些痛点，AI SSH 运维智能体更新至 V13.13.8 版本，核心变化是引入了一套完整的安全值班体系。这套体系不再依赖简单的指标阈值，而是基于行为基线进行告警，并通过真机攻击演练验证了其有效性。

四层安全防护体系架构

新版本的安全能力由四个层级构成，每一层对应不同的技术底座和检测目标：

层级	核心能力	技术实现
内核层	检测 Web-to-Shell、反弹 Shell、下载执行链、异常进程突发	eBPF (bpftrace 常驻)
系统层	SSH 撞库、账号后门、公钥注入、持久化变更	日志增量解析 + 基线 Diff
文件层	WebShell 上传、关键系统文件篡改	Manifest 基线快照
决策层	告警自动取证，生成事件分析报告	证据包 + LLM 分析

这一架构的核心原则是将告警对象从“指标越阈值”转变为“行为偏离基线”。例如，CPU 占用率达到 90% 可能是正常业务高峰，但 Nginx 进程拉起 Bash 则极大概率是攻击行为。

内核层：eBPF 监控的实践与陷阱

为何选择 eBPF

传统的进程监控方案存在明显短板：ps 轮询存在时间窗口，容易漏掉短命进程；auditd 配置复杂且日志难以实时解析；传统 HIDS 代理资源占用较高。eBPF 技术允许在内核态挂载 tracepoint，确保事件捕获无遗漏，同时具备以下优势：

无需修改内核：只需安装 bpftrace 包，不加载内核模块。
零依赖部署：Rocky 9 及内核 5.x 以上版本自带 BTF（BPF Type Format），无需安装 kernel-devel 头文件，脚本即可直接运行。
极低开销：实测常驻状态下 CPU 占用率为 0.0%，对生产环境几乎无感知。

开发中的关键技术细节

在实现“下载工具拉取脚本并执行”的检测逻辑时，曾遇到一个典型的语义陷阱。直觉上，开发者可能会在 sys_enter_execve 探针中匹配 comm == "curl"。然而，这是错误的。在 execve 进入点，comm 字段保留的是调用者的旧程序名（例如 Bash），因此永远无法匹配到 curl 启动的瞬间。

正确的实现方式是双探针配合：

登记阶段：使用 sched:sched_process_exec 探针。此时 exec 已完成，comm 已更新为新程序名。若检测到 curl、wget 或 nc，将其 PID 存入映射表。
捕获阶段：使用 syscalls:sys_enter_execve 探针。检查当前进程的父进程 PID 是否在登记表中。若在，则判定为可疑的下载执行链。

此外，在使用 count() 聚合地图输出时，必须显式转换为 (uint64) 类型，否则 printf 会因格式说明符不支持而报错。该错误仅输出至 stderr，进程不会退出，导致输出静默为空。若不检查 stderr，极易误判脚本正常运行。

实际检测效果

在真机演练中，模拟伪造 comm=curl 的进程拉起脚本并授权，系统成功捕获以下事件：

[ebpf] 可疑下载执行链：curl->/usr/bin/chmod
[ebpf] 可疑 web->shell 调用：nginx->/bin/sh

通过事件级聚合、常驻单实例运行以及每窗口限流 20 条的策略，有效防止了告警风暴，实现了从内核捕获到告警推送的秒级响应。

系统层：零依赖的登录审计

系统层监控不依赖复杂代理，仅通过对 /var/log/secure（CentOS/Rocky）或 /var/log/auth.log（Ubuntu）进行增量解析，并结合关键文件基线比对来实现。

检测策略遵循“克制”原则：对于正常业务中可能波动的信号（如 SSH 登录失败），采用计数加去抖机制，仅在超过阈值（如 20 次/窗口）时告警；而对于正常情况下绝不应发生的变更（如 authorized_keys 文件 MD5 值改变、新增 uid=0 账户、crontab 内容变更），则采取“出现即告警”策略。

这种设计旨在控制误报率。安全产品的生命力在于可信度，频繁的误报会导致用户关闭通知，从而真正错过危险信号。

文件层：WebShell 秒级发现

针对 Web 主机，系统自动从 Nginx 配置中提取站点根目录，利用 find 和 md5sum 建立文件完整性快照。每轮扫描对比三类变更：新增、删除、修改。

在演练中，向站点目录投放伪装成缓存文件的 WebShell，系统在下一轮扫描（30 秒内）即发出告警：

[fim] 文件完整性告警（1 项）：新增: /usr/share/nginx/html/.wp_cache.php

为应对正常发版带来的误报，系统提供一键重置基线功能，避免反复骚扰运维人员。

决策层：AI 自动取证与分析

传统监控止步于告警，而响应的成本往往在于后续的人工取证：登录服务器、翻阅日志、检查网络连接、查找落盘文件，整个过程耗时较长。

V13.13.8 引入了自动取证机制。当安全类告警触发后，Agent 会在目标主机执行一组固定的只读证据采集命令，包括：

当前登录会话
TCP 连接状态
高 CPU 占用进程
/tmp 目录下近 30 分钟的新建文件
计划任务列表
认证日志尾部
UID 为 0 的账户列表

采集到的证据包被发送至 LLM（大语言模型），生成结构化的事件分析报告。报告包含事件定性、风险等级、关键证据、攻击路径推断及建议处置命令。

安全边界设计：取证过程不使用主 Agent 的工具循环，也不允许 LLM 直接执行命令。这是因为如果攻击者控制了日志数据，并将其喂给拥有 SSH 权限的自主 Agent，可能导致提示词注入攻击。因此，取证必须是固定命令清单加上 LLM 的纯分析，确保取证过程本身不可被操纵。若 LLM 不可用，系统降级为仅输出证据包原文，保证链路始终有产出。