传统监控部署中最繁琐的部分 #

部署监控工具时，最费工夫的并不是初始设置，而是“逐设备注册工作”。

无论是Zabbix还是其他SIEM，每次将新设备加入监控，都需要“主机注册→模板选择→解析器配置→测试→正式部署”。10台设备就是2-3人日，100台设备就是20-30人日。而且每当设备增减时，这项工作都要重复一遍。

BASTION彻底省去了这整个步骤。

整体机制概览 #

以下5个步骤全部自动运行。

换言之，设备开始发送syslog后最快15分钟，监控报告就会送达Slack。

步骤1：rsyslog自动生成目录 #

BASTION的rsyslog会根据接收到的syslog的主机名，为每个发送主机自动创建目录。

/var/log/remote/
  Hostname-A/2026/04/Security-Auditing.log
  Hostname-B/2026/04/sshd.log
  Hostname-C/2026/04/filterlog.log
  ...

新设备开始发送syslog时，无需任何配置变更，目录就会自动出现。这是一切自动化的起点。

步骤2：自动检测新主机 #

检测脚本每天运行一次，将目录列表与此前的列表进行比对。

这里的关键思路是一个反直觉的做法：不是管理“要监控什么”，而是管理“要排除什么”。已有的服务器和网络设备（那些已经在summarize.sh中单独解析处理的设备）被列入排除列表，其余的一律视为“新客户端”。

# Exclusion list (hostname patterns for servers/NW equipment)
EXCLUDE_HOSTS="existing-server1|existing-server2|existing-fw|..."

# Subtract exclusion list from /var/log/remote/ host list
# → Remaining items are new clients

系统会根据检测结果通知Slack。

步骤3：LLM自动分类 #

这是核心部分。检测到新主机时，会从该主机的日志文件中提取样本（前5个文件×最后20行），发送给LLM进行分类。

分类对象 #

分类分为以下9个类别。

向LLM发送分类请求 #

请求直接发送给GPUStack（本地LLM服务器）的OpenAI兼容API。提示词中包含主机名、日志文件列表和日志样本，并指示以JSON格式返回分类结果。

# Classification request (overview)
curl -s -X POST "${GPUSTACK_URL}/v1/chat/completions" \
  -H "Authorization: Bearer ${API_KEY}" \
  -d '{
    "model": "qwen2.5-14b-instruct",
    "messages": [{
      "role": "system",
      "content": "You are a device classifier. Classify this host..."
    }, {
      "role": "user",  
      "content": "Hostname: XXX\nLog files: ...\nSample: ..."
    }],
    "temperature": 0.1
  }'

# → Response example
{
  "category": "win_client",
  "confidence": "high",
  "os_detail": "Windows 10/11 desktop",
  "reasoning": "Security-Auditing logs with LogonType 2..."
}

从LLM响应中提取JSON部分，并注册到设备注册表中。

步骤4：基于模板的监控 #

设备注册表 #

分类结果会累积到一个JSON文件（设备注册表）中。

{
  "devices": [
    {
      "hostname": "CLIENT-001",
      "category": "win_client",
      "template": "win_client.sh",
      "confidence": "high",
      "os_detail": "Windows 10/11 desktop",
      "active": true
    },
    ...
  ],
  "exclude_hosts": ["existing-server1", "existing-fw", ...],
  "last_scan": "2026-04-21T06:00:00+09:00"
}

监控模板 #

为每个类别都准备了模板脚本。每个模板提供两个函数。

# templates/win_client.sh

# Summary output (called from summarize.sh)
template_summarize_win_client() {
    # Count authentication anomalies, PowerShell, USB, account changes
}

# Detailed analysis (called from analyze-detail.sh)
template_detail_win_client() {
    # Per-endpoint failed logon details, privileged logon details, LOLBin detection...
}

在现有summarize.sh（定期分析脚本）的末尾，添加了一段读取设备注册表并动态调用模板的代码。

# Appended to end of summarize.sh
jq -r '.devices[] | select(.active==true) | ...' device-registry.json \
| while read HOST CATEGORY TEMPLATE; do
    source "templates/${TEMPLATE}"
    template_summarize_${CATEGORY} "$HOST" ...
done

现有的硬编码部分保持不变，只是追加的部分增加了新功能。

步骤5：完全自动化的结果 #

首次扫描自动检测到14台Windows客户端。LLM读取了每个终端的日志样本，判断出“Security-Auditing日志中包含登录事件→Windows客户端”。系统自动应用了win_client模板，认证异常、PowerShell执行、USB连接、账户变更这4个类别的监控立即开始。

LLM分类准确率 #

14台设备中，13台被正确分类，confidence为high。有1台被分类为“win_server”，confidence同样为high，但实际上是Windows客户端。据推测，这是由于主机名中包含了暗示服务器的字样所致。

由于win_client和win_server使用相同的监控模板，实际上并无影响。不过，如果类别准确性变得重要，我们也在考虑增加一个手动修正功能，可在设备注册表中手动纠正category字段。

与现有监控的共存 #

BASTION原本就在summarize.sh中为防火墙、认证基础设施、负载均衡器、交换机和Web服务器硬编码了分析流程。自动分类的对象是排除这些现有设备之后剩余的设备。

我们不会冒险破坏已经正常运作的部分。今后，现有的硬编码部分或许也可以转换为模板并整合进来，但目前存在“两层结构”：“现有设备=硬编码”与“新设备=模板自动应用”。

今后的扩展 #

目前模板只有win_client和generic（unknown用）两种，但随着每一次客户部署，模板数量都会不断增加。

随着模板库的不断扩充，仅靠“接入syslog”就能覆盖的设备范围也会不断扩大，这将成为持续积累的直接竞争优势。

总结 #

BASTION的自动设备分类，将rsyslog自动生成目录→主机检测→LLM日志分类→模板自动应用→开始监控这一整套流程完全自动化。只需配置syslog的发送目标，设备类型判定、监控规则选择、设备变更管理便都会自动完成。

这是一种从结构上消除了传统监控部署中最大瓶颈——“逐设备注册与配置”——的机制。无论是10台还是100台设备，人工工作量都保持不变（只需配置一行syslog发送目标）。“设备在无人察觉的情况下被排除在监控之外”这类问题，从结构上就不可能再发生。