6.3 监控与审计：日志和入侵检测

6.3 监控与审计：日志和入侵检测

本节摘要：日志体系是系统的记忆体，入侵检测是条件反射。本节讲三层感知体系（日志、指标、检测规则）的分工、日志完整性的攻防意义、检测规则的可测试性要求，以及一次"规则从发现到验证"的完整闭环——它把第 5 章的演练发现变成可复用的检测能力。

主线第三步：证据固定了、平台可信了，现在回到那条凌晨警报本身——它为什么响、该不该信、之后怎么做得更好。

从"假设安全"到"可验证的安全"

没有监控的系统处于"假设安全"状态：没消息就当没事。这套假设在两次现实冲击下破产：其一，停留时间——真实入侵从发生到被发现动辄以月计，没有感知就无从谈起响应；其二，归因需要——发现异常后要回答"什么时候开始的、做了什么"，没有记录就只能靠猜。

"可验证的安全"是另一套姿态：安全状态可以被证据陈述（哪些日志、什么规则、何时触发），防御措施可以被测试验证（下一节的紫队方法）。本节讲的监控与审计就是这套姿态的技术载体。

三层感知体系的分工

第一层：日志（记忆体）。 系统与服务的原始记录：谁登录了、什么进程启动了、哪个文件被访问了。它是事后分析的基础，也是 6.1 取证分析的主要食粮。工程要点三个：集中（日志留在本机，失守即被篡改，要送往独立的收集端）；完整（时间同步、覆盖关键事件类别）；保结构（机器可解析的格式，供规则消费）。

第二层：指标（生命体征）。 CPU、内存、流量、连接数的时序数据。异常往往先在指标上露头——凌晨三点的 outbound 流量尖峰、异常的进程数波动。指标的特长是"发现不对劲"，短板是"说不清是什么"。

第三层：检测规则（条件反射）。 对日志与指标的持续判定：什么样的模式值得警报。规则的来源有三：通用规则库（覆盖已知攻击模式的自定义规则语言写成，可跨平台部署）、厂商特征、以及自家演练沉淀（下一节的主角）。

# 第一层的日常功夫：知道日志在哪 会查会用
journalctl -u ssh --since "2026-08-30" --no-pager | tail -20
# 输出片段：
# Aug 30 23:41:02 lab sshd[1123]: Failed password for invalid user admin from 203.0.113.7
# Aug 30 23:41:05 lab sshd[1123]: Failed password for invalid user admin from 203.0.113.7
# 同一来源连续失败——这就是一条检测规则的原料

# 统计视角：失败登录的来源分布
journalctl -u ssh --since today | grep -c "Failed password"
​

日志完整性的攻防

一个必须讲透的点：日志是攻防双方都要抢的阵地。攻击者获得高权限后的常见动作之一就是清理痕迹——删日志、改时间戳。防御因此要有两层设计：外送（关键日志实时发往独立收集端，本机删了远端还在）；防篡改记录（对日志做链式哈希，类似 6.1 的证据链思路——每条记录附前条哈希，改动即断链）。

审计（在合规语境下）建立在这套完整性之上：定期核对"该有的记录都在、时间可对齐、未被发现改动"。1.3 节说的审计角色"结论可辩护性"，技术上就依赖这两层设计。

规则的可测试性：从发现到验证的闭环

好的检测规则和好的代码一样，必须有对应的测试。没有测试的规则是薛定谔的防御——你不知道它响不响，直到真攻击来了（或永远不来）。给一个完整闭环案例，它衔接第 5 章的演练：

背景：5.2 演练确认过一个风险——某服务允许匿名读取共享内容。整改关闭后，安全团队想把"这类行为"变成检测能力：万一配置回退或类似服务再出现，监控要能看见。

操作：把行为特征翻译成规则语言——目标服务端口上出现匿名会话且读取量超过阈值，持续若干分钟则警报。规则写好后主动构造测试：在测试环境复现一次该行为（匿名登录并批量读取），观察警报是否按时触发；再跑一次"阴性对照"（正常授权访问），确认不误报。

结果：规则在两分钟内触发，阴性对照安静。规则连同两份测试记录入库。

解读：这条规则从此是"可验证的防御"——它的有效性有证据、有日期、可复测。回看 6.2 的加固清单与 5.2 的整改建议，这条规则是它们的监测面延伸：加固解决"现在没有"，规则守护"不再出现"。

变式：同一方法适用于整类发现——弱口令发现转化为"认证失败率异常"规则、明文传输发现转化为"明文端口出现会话"规则、越权发现转化为"异常对象访问模式"规则。演练报告的每一条发现，都值得问一句"它能不能变成一条规则"。

⚠️ 误报是检测体系的慢性毒药：一条频繁误报的规则会让团队养成忽略警报的习惯，等于把真警报也一起埋掉。治理手段是给每条规则记账（触发次数、确认比例），连续低确认的规则要么修要么退役。

监控问答：建设中的三个疑问

问：日志该存多久？ 分层定策略：高频的操作类日志（每条认证、每条访问）量大价值密度低，常见保留三十到九十天；关键审计类日志（管理操作、权限变更）保留一年以上；涉及合规要求的场景按条款执行。原则是按事后追溯需求倒推——你最远需要回答"多久之前发生了什么"，答案就是保留下限。

问：规则从哪来，自研还是用现成的？ 先用现成的通用规则库铺底（覆盖面广、上手快），再逐步叠加自家演练沉淀的规则（针对性强、误报可控）。纯自研起步的团队容易陷入"三个月写不出十条规则"的泥潭；纯依赖现成规则的团队则永远缺自家环境的针对性。铺底加沉淀的组合，让两条路互相补台。

问：告警太多看不过来，先治哪头？ 先治误报大户（本节的记账治理），再调阈值（用 6.4 的对照数据校准），最后考虑分级响应（高危即时处理、中低危批量复盘）。顺序不能反——不清理误报就上分级，等于给噪声也分了级别，团队还是会习惯性忽略一切。

问：小团队没有专职值守怎么办？ 用"值守轮换加自动化预处理"的组合：告警先经自动化归类（按规则聚类、附上上下文），值守者每天两个固定时段集中处理，高危类走即时通知。关键设计是让告警找到人，而不是让人盯着告警——监控系统的成熟形态从来不是一块没人看的大屏，而是一条能在正确时间打扰正确的人的通道。

本节要点回顾

• 三套姿态的转变：从"假设安全"到"可验证的安全"，证据与测试是分界线；
• 三层分工：日志管记忆、指标管体征、规则管反射，各有长短；
• 日志是必争阵地：外送与链式哈希是完整性的两层设计；
• 规则必须有测试：主动构造触发加阴性对照，缺一不可；
• 发现转规则：演练报告的每条发现都值得问"能否变成规则"；
• 误报记账：低确认规则及时修退，保住警报的信用。