8.1 检测：日志审计与入侵防御
8.1 检测：日志审计与入侵防御
本节摘要：本节搭建终局总攻的检测底座：日志的采集范围、集中化管道与留存策略，入侵检测的两条路线（特征匹配与异常基线）及其互补关系，告警分级与值班运营。前面七章的每一轮攻击都留下了痕迹，这一节回答"怎么让痕迹自动变成警報"。
看得见，才谈得上防
终局日蓝队复盘红队两周的全部动作，发现一个令人后怕的事实：几乎每一步都曾在日志里露过脸——登录失败聚集成峰、异常参数敲打接口、内网出现本该消失的协议流量——只是没人看、没人查、没人把点连成线。检测的本质不是发明魔法，是把已有的痕迹组织成可检索、可告警、可回溯的数据资产。日志因此是防御的第一基建：它既是实时告警的原料，也是事后取证与复盘的底档。
日志管道：从采集到运营
一条合格的日志管道分四段：采集（应用、系统、网络设备、数据库、认证服务的日志统一格式汇聚）、传输（加密信道集中投递，防篡改防丢弃）、存储（分层留存，热数据可秒查，冷数据按合规年限归档）、消费（告警规则、看板、检索）。范围上有条实用的红线：登录与授权、管理操作、外部输入的拒绝记录、出网连接，这四类日志缺任何一类，对应的攻击就等于在盲区里发生。
入侵防御系统在检测之上多了"自动阻断"动作，位置随之成为取舍：串接在线路中间能实时掐断，但误报即业务中断；旁路镜像观察则安全无感却只能告警。务实的选择是分层——边界处串接高置信规则（已知恶意特征），内网与业务层旁路观察加自动化处置（联动防火墙、吊销会话）。
靶场演示：把前七章的攻击写成规则
检测规则的原料就是本演习的红队路径，逐条回译：
-- 规则族：演习全科目对应的检测点（示例，阈值按业务标定） -- 口令回合：暴破（失败聚集）与喷洒（失败分散） CREATE ALERT brute_force AS SELECT src_ip, username, count(*) AS fails FROM auth_log WHERE result='fail' AND ts > now() - interval '10 minute' GROUP BY src_ip, username HAVING count(*) > 20; -- 侦察回合：账户枚举（单源高频"用户不存在"） -- 注入回合：参数命中注入指纹（引用 WAF 日志） -- 前端回合：CSP 违规报告聚积（输出欠账探测器） -- 内网回合：账号-主机配对突变（横向移动雪球信号） -- 误用回合：旧协议端口出现认证流量
# 告警分级与响应（配置语义示例） levels: P1: # 分钟级响应：疑似失陷——凭据已外带或异常登录成功 - auth_success_after_fail_chain - account_host_pair_anomaly P2: # 小时级响应：攻击进行中——暴破、扫描、注入尝试 - brute_force, injection_attempt, spray_pattern P3: # 日志级观察：低置信异常，进看板供值守巡检 - csp_violation, legacy_proto_seen
运营侧的铁律是告警必须有主、有分级、有闭环：每条 P1/P2 规则有明确值班人，处置动作写进剧本（下一节应急响应展开），误报反馈定期回收调阈值。告警洪水是检测体系最常见的死法——规则越加越多、没人敢删，最后全体静音。每月做一次规则健康度评审：触发量、误报率、平均处置时长，三条不达标的规则要么修要么废。
检测与运营
衡量检测底座的指标：关键日志覆盖率（四类红线日志接入比例）、告警平均确认时长、误报率、检出回验（演习注入的攻击有多少被规则命中——用紫队思路给检测体系打分）。终局日的靶场上，蓝队把红队两周的路径全部回放了一遍，规则命中了大半，剩下的几条静默路径变成了下一轮加固的排期——这就是检测体系该有的样子：不承诺完美，承诺持续变好。
日志体系的自检一句话：现在立刻查"上一次管理员账号异地登录"的完整记录，能在几分钟内拿到答案吗？拿不到，先补采集再谈检测。
从日志到证据：检索的实战姿势
检测底座建好后，蓝队的日常武器是检索。几个高频场景的标准姿势值得固化成团队的手册。场景一，"这个 IP 都干了什么"：以源地址为锚，按时间窗串联认证、访问、出网三类日志，重点看"失败之后有没有成功、成功之后去了哪"。场景二，"这个账号最近异常吗"：以账号为锚，比对设备与地理的历史基线，标注所有偏离点。场景三，"昨晚的告警是真事吗"：以告警事件为锚，向前回溯同指纹事件（同账号、同地址、同特征），向后追踪影响面。三个场景共用一个原则——单条日志不结论，成链才结论。
-- 场景一的锚点检索（示例）：串联一个来源的全部动作 SELECT ts, 'auth' AS kind, username, result, detail FROM auth_log WHERE src_ip = $1 AND ts > now() - interval '24 hour' UNION ALL SELECT ts, 'http', path, status, user_agent FROM http_log WHERE src_ip = $1 AND ts > now() - interval '24 hour' UNION ALL SELECT ts, 'egress', dst_host, bytes, rule FROM egress_log WHERE src_ip = $1 AND ts > now() - interval '24 hour' ORDER BY ts LIMIT 500; -- 输出即"一部微型攻击史"：侦察-尝试-命中-外带，一目了然
检索能力的组织化同样重要：把常用查询存成共享库（团队任何人都能一键跑标准动作），把"新告警的初步研判"固化成三步流程（看链、比基线、定级别），把每次事件检索补充进案例库。检测体系的最后一块拼图从来不是某个工具，而是让"会查的人"的经验变成"所有人都会查"的流程。
最后交代一个容量与成本的务实问题：日志体系的膨胀速度常被低估——全量采集跑一年，存储账单能让项目政治化。务实策略是分层留存：四类红线日志全量长期（它们是检测与取证的命根，贵也要留），高频业务日志热层短存（七天到一个月，够告警用即可），聚合指标替代原始明细长期保存（趋势分析用聚合足够）。容量规划按"红线日志不可裁、其余可谈"的原则先谈好，避免某天运维为了省钱一刀切掉认证日志——那等于把望远镜的镜片卸了卖钱。