文章总结： 本文介绍了一种利用ELK（Elasticsearch、Logstash、Kibana）与大语言模型（LLM）Agent相结合的方法，来实现对Linux系统登录日志（wtmp/btmp）的智能监控和异常告警。传统的人工分析或简单脚本已无法应对日益复杂的攻击，因此该方案旨在构建一个自动化的采集-分析-告警-处置闭环。其核心是使用专门的工具（如Auditbeat）将二进制格式的登录日志解析为结构化数据并存储在Elasticsearch中。接着，利用Kibana设置基础阈值规则（如暴力破解、非常规时间登录等）筛选出可疑事件。随后，LLMAgent会自动获取这些告警并结合历史行为、资产信息等上下文进行深度推理分析，生成风险等级和处置建议。最后，系统可根据预设策略自动执行封禁IP、锁定账号等操作，从而有效提升登录安全的监控效率和响应速度。
综合评分： 85
文章分类： 安全建设,解决方案,威胁情报,应急响应,技术标准
通过 ELK + LLM Agent 监控 wtmp / btmp，实现异常登录智能告警与处置
原创
RCS-TEAM安全团队
RCS-TEAM安全团队
RCS-TEAM
2025年11月19日 15:59
北京
wtmp / btmp 能看登录日志，但传统安全以及运维是靠“人 + 脚本”去盯它，已经跟不上现在的攻防强度了。把它们拉进 ELK，再加一层 LLM Agent，相当于从“到处翻日志”升级成“有个 7×24 在线的安全分析师＋自动化处置”。
01
为什么要盯紧 wtmp / btmp？
在 Linux 世界里，几乎所有和登录相关的“历史记录”都离不开这两个文件：
/var/log/wtmp：记录成功登录、注销、系统重启等历史事件
/var/log/btmp：记录失败登录事件（口令错误、非法用户、暴力破解等）
它们都是 utmp 二进制格式日志，系统命令 last / lastb 展示的内容，本质上就是从 wtmp/btmp 解析出来的。
在攻击链中，它们可以暴露出很多关键信息：
密码暴力破解/撞库：某 IP 短时间内大量失败登录
弱口令 + 提权：先失败若干次，再突然成功登录敏感账号
横向移动：某被攻陷主机开始用固定账号尝试登录多台服务器
异常时间登录：凌晨、节假日突然有敏感资产被登录
账号共享/滥用：一个账号短时间内在多地、多台机器频繁登录
传统做法往往是运维/安全人员手工去服务器上跑 last / lastb，或简单通过脚本发邮件告警，缺乏统一视图和智能分析。
本文的目标： 把 wtmp / btmp 这类底层登录事件，通过 ELK + LLM Agent 串成一条完整的“采集 → 分析 → 告警 → 自动处置”链路，变成真正“有脑子”的登录安全监控系统。
02
总体架构设计：从 wtmp/btmp 到智能告警
整体可以拆成四层：
01
采集层（Beats / Elastic Agent）
使用 Auditbeat 或 Elastic Agent 的 system/login 数据集，专门读取 utmp/wtmp/btmp
02
将登录事件结构化为统一字段：user.name、event.outcome、source.ip、event.action 等
存储与可视化层（ELK）
03
Elasticsearch：存储所有登录事件
Kibana：提供查询、Dashboard、基础告警（阈值类）
智能分析层（LLM Agent）
定时或实时从 Elasticsearch 拉取“疑似异常”的登录事件
结合历史行为、地理位置、资产信息等上下文，用大模型进行推理生成自然语言分析报告和风险等级。
04
自动化处置层（Playbook / 脚本 / 安防系统）
LLM Agent 根据策略调用脚本或 SOAR 平台执行动作：封 IP、锁账号、通知值班、拉取更多证据等。
03
采集 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 的“结构化翻译”，非常适合后续做可视化和智能分析。
04
在 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 不是简单替代阈值规则，而是接收这些“可疑信号”，做更接近人类分析师的综合判断。
05
引入 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 群里给值班人员看。
06
一个完整的实战案例：从暴力破解到自动封禁
假设有这样一个场景：
凌晨 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 做“脑子”和“嘴”：分析 + 解释 + 给决策建议。
自动化脚本/平台 做“手”：执行封禁、锁号等动作。
07
落地 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，实现异常登录智能告警与处置》