沂樾如果把TryHackMe的SOC学习路径刷到Section 8，很多人会突然有一种“前面学的东西要开始拼起来了”的感觉。前面几章更多在教分析告警、读日志、梳理事件时间线，到了Web安全监控这一节，你面对的不再是单个孤立告警，而是海量访问流量里怎么找出那些“看起来正常，实际有问题”的请求。这个模块的核心并不是让你变成Web漏洞利用专家，而是训练你从防御者视角看Web流量：日志里哪些字段是关键线索，哪些攻击特征会暴露在access log里，以及一条告警出现后如何快速判断它到底要不要升级处置。这篇内容我就按自己刷题后回到监控岗位的体会，把Web安全监控要盯的东西、日志指纹怎么读、规则怎么落地、误报怎么降，完整盘一遍。
1. 先搞清楚一件事：SOC里的Web安全监控到底在盯什么
1.1 为什么平台上的任务和真实值班的视角完全不同
在TryHackMe这类平台上做实验，题目通常已经告诉你“某个攻击者的IP是什么”“哪条请求有问题”，你的任务是找到证据并分析影响。真实SOC值班完全不是这样。值班时，绝大部分流量都是正常的用户访问、API调用、定时任务，真正恶意的东西可能只藏在几百万条日志里的三四条请求中，而且恶意请求往往伪装成正常请求。
这就带来一个根本差别：平台任务练的是“已知异常后的取证分析”，真实监控练的是“未知噪声里的异常发现”。Section 8这个模块比较好的地方在于，它不会只让你看单条恶意请求就结束，而是逼着你去理解Web应用正常行为长什么样。我的建议是，做实验时不要只满足于答对题目，可以把每道题背后的流量都导出来看一遍，思考“如果我是当天值班的人，在没有任何提示的情况下，我会从哪里注意到这条流量”。这个习惯比刷完所有题目更重要。
1.2 监控的落脚点不是“拦截攻击”，而是“看见异常”
Web安全监控很容易被误解成“部署一个WAF就完事了”。实际上，SOC里Web安全监控的目标对象是一组非常宽泛的行为，包括扫描探测、身份冒用、篡改尝试、数据批量抽离、WebShell通信等。单靠某一种安全设备很难覆盖全部，你真正需要的是不同日志源互相印证。
我在实际监控中会把Web类告警分成三类来看：
- 已有明确签名命中的攻击流量，例如WAF拦截记录、IDS检测到SQL注入特征；
- 没有签名但行为可疑的流量，比如某个IP短时间内高频遍历大量路径、大量404后又出现200；
- 业务逻辑层面的异常，比如单个账号在非工作时段高频调用订单接口、下载接口单次响应体积异常巨大。
第一类依赖规则，第二类依赖聚合分析，第三类依赖你对正常基线的理解。Section 8的训练重点其实落在第二类和第三类上，因为第一类工具已经帮你做了。很多人做题时觉得“这也不难啊”，是因为日志已经被刻意筛选过，一旦回到生产环境，你需要自己决定日志接入范围、需要定义什么叫“异常波动”，这才是监控真正难的地方。
1.3 不同Web资产要有不同的监控重点
不是所有Web资产都值得用同一套监控规则。我在实际工作中会把资产至少分成三类：
| 资产类型 | 重点监控信号 | 最容易出现的误报源 |
|---|---|---|
| 对外门户站点 | 状态码突变、非工作时段访问高峰、路径爬取、异常响应体积 | 搜索引擎爬虫、第三方监测 |
| API接口服务 | 参数注入、调用频率突增、批量枚举、越权尝试 | 正常业务联调、定时任务 |
| 后台管理系统 | 登录失败率突增、来源IP聚集、UA偏离基线 | 办公网出口聚合IP、运维跳板 |
这里最容易被忽视的是API监控。传统Web监控更多关注页面请求，但如今大部分业务流量都是API调用。API日志的字段比页面访问日志更干净，通常包含调用方AppID、接口路径、请求体大小、响应时间等，非常适合做行为基线。比如一个普通查询接口平时单次响应体只有几十KB，如果某天某个调用方开始频繁请求并且响应体冲到几十MB，那不管有没有攻击特征命中，都应该触发告警。这类“数据抽离”行为往往不携带任何恶意Payload，纯靠签名规则根本发现不了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Web访问日志里的攻击指纹该怎么读
2.1 一条日志十几个字段，真正办案要用哪几个
Web访问日志是Web安全监控里最基础也最直接的日志源。NGINX、Apache默认日志格式不一样，但归一化之后关键字段基本一致。如果只靠看原始日志，很多新手会被满屏字符串淹没，实际办