2026-03-26 16:42:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文介绍了一种利用ELK（Elasticsearch、Logstash、Kibana）与大语言模型（LLM）Agent相结合的方法，来实现对Linux系统登录日志（wtmp/btmp）的智能监控和异常告警。传统的人工分析或简单脚本已无法应对日益复杂的攻击，因此该方案旨在构建一个自动化的采集-分析-告警-处置闭环。其核心是使用专门的工具（如Auditbeat）将二进制格式的登录日志解析为结构化数据并存储在Elasticsearch中。接着，利用Kibana设置基础阈值规则（如暴力破解、非常规时间登录等）筛选出可疑事件。随后，LLMAgent会自动获取这些告警并结合历史行为、资产信息等上下文进行深度推理分析，生成风险等级和处置建议。最后，系统可根据预设策略自动执行封禁IP、锁定账号等操作，从而有效提升登录安全的监控效率和响应速度。 综合评分： 85 文章分类： 安全建设,解决方案,威胁情报,应急响应,技术标准

cover_image

通过 ELK + LLM Agent 监控 wtmp / btmp，实现异常登录智能告警与处置

原创

RCS-TEAM安全团队 RCS-TEAM安全团队

RCS-TEAM

2025年11月19日 15:59 北京

wtmp / btmp 能看登录日志，但传统安全以及运维是靠“人 + 脚本”去盯它，已经跟不上现在的攻防强度了。把它们拉进 ELK，再加一层 LLM Agent，相当于从“到处翻日志”升级成“有个 7×24 在线的安全分析师＋自动化处置”。

为什么要盯紧 wtmp / btmp？

在 Linux 世界里，几乎所有和登录相关的“历史记录”都离不开这两个文件：

/var/log/wtmp：记录成功登录、注销、系统重启等历史事件

/var/log/btmp：记录失败登录事件（口令错误、非法用户、暴力破解等）

它们都是 utmp 二进制格式日志，系统命令 last / lastb 展示的内容，本质上就是从 wtmp/btmp 解析出来的。

在攻击链中，它们可以暴露出很多关键信息：

密码暴力破解/撞库：某 IP 短时间内大量失败登录

弱口令 + 提权：先失败若干次，再突然成功登录敏感账号

横向移动：某被攻陷主机开始用固定账号尝试登录多台服务器

异常时间登录：凌晨、节假日突然有敏感资产被登录

账号共享/滥用：一个账号短时间内在多地、多台机器频繁登录

传统做法往往是运维/安全人员手工去服务器上跑 last / lastb，或简单通过脚本发邮件告警，缺乏统一视图和智能分析。

本文的目标：把 wtmp / btmp 这类底层登录事件，通过 ELK + LLM Agent 串成一条完整的“采集 → 分析 → 告警 → 自动处置”链路，变成真正“有脑子”的登录安全监控系统。

总体架构设计：从 wtmp/btmp 到智能告警

整体可以拆成四层：

采集层（Beats / Elastic Agent）

使用 Auditbeat 或 Elastic Agent 的 system/login 数据集，专门读取 utmp/wtmp/btmp

将登录事件结构化为统一字段：user.name、event.outcome、source.ip、event.action 等

存储与可视化层（ELK）

Elasticsearch：存储所有登录事件

Kibana：提供查询、Dashboard、基础告警（阈值类）

智能分析层（LLM Agent）

定时或实时从 Elasticsearch 拉取“疑似异常”的登录事件

结合历史行为、地理位置、资产信息等上下文，用大模型进行推理生成自然语言分析报告和风险等级。

自动化处置层（Playbook / 脚本 / 安防系统）

LLM Agent 根据策略调用脚本或 SOAR 平台执行动作：封 IP、锁账号、通知值班、拉取更多证据等。

采集 wtmp / btmp：用系统登录数据集而不是直接读文件

1. 为什么不用 Filebeat 直接读 wtmp / btmp？

wtmp/btmp 是二进制格式，不是文本日志

Filebeat 默认的 file input 适合按行读取文本，直接去读会是一堆二进制乱码

即便通过 last / lastb 导出为文本再采集，也会遇到：

重复数据不好去重

需要自己写复杂解析规则（grok）

时间字段、用户名、IP 的提取容易出错

因此，更好的做法是使用专门的 system/login 数据集（Auditbeat 或 Elastic Agent 内置），它会直接解析 utmp 结构，生成标准化字段。

2. Auditbeat 采集示意配置（示例）

下面是一个简化的 auditbeat.yml 配置示例，专注于登录日志：

auditbeat.modules: – module: system datasets: – login # 核心：登录事件数据集，解析 wtmp/btmp period: 10s # 每 10 秒轮询一次 # 可选：显式指定 wtmp / btmp 及轮转文件 login.wtmp_file_pattern: /var/log/wtmp* login.btmp_file_pattern: /var/log/btmp* output.elasticsearch: hosts: [“http://10.0.0.149:9200”] username: “elastic” password: “你的密码” setup.kibana: host: “http://10.0.0.149:5601”

启用后，你会在 Elasticsearch 中得到类似这样的字段：

event.dataset: “login”

event.action: “user_login” / “user_logout”

event.outcome: “success” / “failure”

user.name: 登录用户名

source.ip: 远程 IP

host.name: 服务器名

event.start, event.end: 登录开始/结束时间

这些字段相当于是对 wtmp / btmp 的“结构化翻译”，非常适合后续做可视化和智能分析。

在 Kibana 中做基础异常登录告警

在把登录事件汇总到 ELK 之后，可以先利用 Kibana 构建一些基础规则，给 LLM Agent 提供“候选异常事件”。

1. 典型规则 1：暴力破解 / 高频失败登录

规则思路：

某个 IP 在 5 分钟内对某台主机、某个账号失败登录超过 N 次

在 Kibana 中可以用 KQL 过滤：

event.dataset : “login” and event.outcome : “failure”

然后在 Detection Rule 中按 source.ip 或 user.name 分组，设置阈值： “5 分钟内 >= 10 次失败” 即触发规则。

2. 典型规则 2：非常规时间的登录

规则思路：

在夜间（例如 00:00 – 06:00）出现敏感服务器的成功登录事件

KQL 示例：

event.dataset : “login” and event.outcome : “success” and host.name : “prod-db-*” and ( @timestamp >= “now-1d/d+0h” and @timestamp < “now-1d/d+6h” )

也可以利用 runtime field 或脚本字段提取小时，再基于 hour 字段筛选。

3. 典型规则 3：从未见过的地理位置登录

配合 GeoIP 解析，“同一账号”突然在完全不同的国家或城市出现：

event.dataset : “login” and event.outcome : “success” and user.name : “appadmin”

再通过 Elastic 的“基于前一日/前一周”分析“常见国家/城市”，将不在常见列表中的归为“异常来源”。

这些基础规则不一定需要 LLM，但它们产出的告警事件会被 LLM Agent 继续深挖： LLM 不是简单替代阈值规则，而是接收这些“可疑信号”，做更接近人类分析师的综合判断。

引入 LLM Agent：让异常登录分析“更像一个安全工程师”

1. LLM Agent 的角色定位

LLM Agent 在这个体系中的定位，可以理解为：

“一个 7×24 小时在线的高级安全分析师，专门盯登录事件和相关上下文。”

它的核心能力包括：

拉取上下文数据：

某告警涉及的账号、IP 在过去 24 小时 / 7 天的活动情况

该服务器的角色、重要性（生产/测试/办公）

当前时间点（是否节假日、是否工作时间）

历史上该账号常见的登录来源 IP/地理位置

自动归因 & 讲清楚“为什么是异常”

使用自然语言总结：攻击假设、风险评级、可能的攻击阶段

判断是否更像“误报”（例如：VPN 出口切换、运维人员临时操作）

给出行动建议甚至自动执行

提出建议：封禁 IP、锁定账号、通知负责人、拉取更多证据

在强策略下自动调用脚本/API 进行处置（例如写入防火墙、禁用账号）

2. LLM Agent 的工作流程

一个典型的 LLM Agent 流程可以设计为：

事件触发

ELK 规则触发告警，将告警事件写入一个专用索引或通过 Webhook 发给 Agent

Agent 拉取上下文

该账号过去 30 天的登录记录分布

该 IP 对其他主机的行为

同一服务器上同时发生的其他安全事件（sudo、SSH 配置更改等）

根据告警中的 user.name, source.ip, host.name 等字段

再次查询 Elasticsearch，拿到：

拼装成结构化“案件档案”

Agent 把这些数据整理为 JSON 或表格：时间线、来源地、资产等级、告警历史等

大模型推理

将“案件档案”+“安全策略/Playbook”作为 Prompt 输入 LLM

让大模型用“专家视角”进行推理：攻击阶段、风险等级、建议的行动步骤

形成结论 & 行动

风险评级（低、中、高、严重）

主要证据和判断逻辑

建议的处置步骤（可分自动执行与人工确认）

按预设格式生成结论：

将结论写回 ELK，或推送到 IM / 邮件 / 工单系统

如需要，调用 Ansible / SaltStack / 自研 API 执行自动操作

3. Prompt 模板示例（思路）

可以设计一个类似这样的 Prompt 模板（伪代码）：

你是一名资深安全分析师，负责判断 Linux 登录事件是否存在安全风险。

【登录事件】

触发时间：{{alert_time}}

服务器：{{host.name}}（重要性：{{asset_level}}）

用户：{{user.name}}

源 IP：{{source.ip}}（地理位置：{{geo.city}} / {{geo.country}}）

登录结果：{{event.outcome}} （失败/成功，附带失败次数、时间段）

【过去 24 小时该账号登录分布】 {{user_login_stats}}

【过去 24 小时该 IP 行为】 {{ip_behavior}}

【历史常见模式】

该账号历史常见 IP / 归属地：{{user_normal_pattern}}

该服务器正常维护时间：{{maintenance_window}}

请根据以上信息判断：

这次登录行为是否存在较大安全风险？说明理由。

按“低/中/高/严重”给出风险等级。

如果你是 SOC 值班工程师，你会如何处置？请给出 3-5 条具体可执行建议。

列出你做出判断时使用的关键信息和逻辑链条。

这样得到的输出，既有可落地的行动建议，也可直接贴进 IM 群里给值班人员看。

一个完整的实战案例：从暴力破解到自动封禁

假设有这样一个场景：

凌晨 02:13，办公区的一台跳板机 jump-01 的 btmp 中，某国外 IP 203.0.113.10 在 5 分钟内对多个账号进行了 200 次失败登录尝试（包括 root、devops、oracle 等常用账号）。

02:17，同一个 IP 对生产数据库服务器 prod-db-01 也发起了多次 SSH 登录尝试。

对于 prod-db-01，过去一个月几乎只有内网堡垒机登录，GeoIP 从未出现过国外地址。

整个检测与处置链路如下：

Auditbeat / Agent 采集

btmp 中的失败登录被解析为 event.dataset: login, event.outcome: failure

采集至 Elasticsearch，包含 user.name, source.ip, host.name, event.start 等字段

ELK 阈值规则触发

一条规则：5 分钟内同一 IP 在同一主机上失败登录次数 > 50

一条规则：任何来自非白名单国家的 IP 尝试登录“生产级资产”

两条规则同时触发，生成告警文档写入 security-alerts 索引

LLM Agent 获取告警 & 拉取上下文

查询过去 24 小时 203.0.113.10 在所有主机上的行为

查询过去 30 天 prod-db-01 的登录来源分布

获取 CMDB 中 prod-db-01 的资产等级（核心业务数据库）

LLM 推理

风险等级：严重

攻击阶段：大概率是 SSH 暴力破解 + 资产探测

建议：

国外 IP

高频失败登录、扫描多账号

尝试访问核心生产数据库

时间为凌晨非维护窗口

模型综合判断：

得出结论：

立即阻断该 IP 到所有服务器的 SSH 访问

检查是否存在成功登录记录，拉取对方尝试的账号列表

核查 prod-db-01 上其他异常事件（sudo、关键配置变更）

将该事件记录到“外部暴力破解 IOC”库中

自动处置执行

将 203.0.113.10 加入 SSH 防火墙封禁列表

Agent 调用预先对接的防火墙 API / Ansible Playbook：

同时在告警群里推送一条带详细分析说明的消息，并创建工单。

这套流程的关键点在于：

ELK 做“眼睛”与“数据湖”。

LLM Agent 做“脑子”和“嘴”：分析 + 解释 + 给决策建议。

自动化脚本/平台做“手”：执行封禁、锁号等动作。

落地 ELK+LLM 登录监控时的几个注意事项

给 LLM 限定“角色”和“边界”

Prompt 中明确它是“安全分析师”，不要让它随意执行超出权限的动作

所有“自动执行”的动作，最好有阈值和白名单保护

控制告警噪音，减少“狼来了”问题

先用 ELK 做基础筛选，只把“高度可疑”的事件喂给 LLM

对同一 IP/账号短时间连续告警做聚合，避免刷屏

多维度数据融合更能体现 LLM 优势

CMDB（资产重要性、业务归属）

用户信息（运维/开发/外包）

VPN/防火墙日志（是否通过合法 VPN 入口）

其他安全告警（如 WAF、IDS、EDR）

不要只给它“登录日志”一维数据

可以结合：

保留人工验证环节

严重：自动 + 人工双通道

高：人工确认后执行

中/低：仅发送分析报告

对“自动封禁 IP / 锁账号”类动作，建议先推送到安全值班人员审批。

也可以按风险等级划分。

八、总结

wtmp / btmp 是 Linux 登录世界的“黑匣子”，记录着所有登录成败的历史。如果只靠零散脚本和人工排查，很容易被遗漏或无法形成整体视角。

借助 ELK，我们能把这些底层二进制日志转化为清晰可视化的结构化数据，加上地理位置、资产信息等维度，构建起完整的登录安全大盘。

将 LLM Agent 嵌入这套体系之后，它就不再只是“规则报警器”，而变成一个随时在线的“智能安全分析师”：

能看懂历史行为，

能解释“为什么可疑”，

能给出合理的处置建议，

甚至可以自动执行部分操作。

关

注

我

们

BEGINNING OF WINTER

往期好文

AI 驱动的SecOps：ELK 日志+大模型 Agent 如何重塑应急响应

AI颠覆网络安全：DeepSeek+ELK打造智能入侵检测新纪元！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：RCS-TEAM RCS-TEAM安全团队 RCS-TEAM安全团队《通过 ELK + LLM Agent 监控 wtmp / btmp，实现异常登录智能告警与处置》