日志监测与流量分析在攻击识别上的差异

攻击流量监控并不等于盯着某一个数字看。一次异常可能先表现为网络连接数量增加，随后才在应用日志中出现大量失败请求；也可能请求本身返回正常，但数据包的来源、协议和方向已经明显偏离业务习惯。因此，日志监测与流量分析应被看作两种互补的识别方法，而不是互相替代的工具。

一、两种方法分别观察什么

日志监测看“请求做了什么”

日志通常由Web服务器、应用程序、身份认证组件或数据库产生。以Nginx访问日志为例，其中可能包含客户端地址、请求时间、URI、HTTP状态码、响应大小和User-Agent。通过日志分析，可以发现短时间内大量登录失败、同一账户从异常地址切换、管理路径被连续探测，以及某个接口的错误率突然上升。

它的优势是接近业务语义：管理员能知道访问了哪个路径、使用了什么账户、最终返回了什么结果。缺点是依赖应用是否正确记录。如果请求在到达应用前就被防火墙丢弃，或者攻击者制造大量半连接，应用日志可能几乎没有记录。

流量分析看“连接如何发生”

网络流量分析关注源地址、目的地址、端口、协议、连接持续时间、数据包方向和负载特征。它可以观察到连接建立失败、端口扫描、异常DNS请求、加密连接数量突增等现象，即使无法解密HTTPS内容，也能利用连接元数据识别偏离基线的行为。

流量分析覆盖网络层和传输层，适合发现尚未进入应用的攻击。但它通常不知道用户具体提交了哪个表单，也难以单独判断一次请求是否符合业务规则。加密、地址转换、代理和内容分发网络还可能降低识别精度。

二、攻击识别上的关键差异

例如，攻击者对登录接口进行低速口令尝试时，每次请求可能都返回正常的HTTP响应，流量曲线并不突出，但日志中的账户、地址和失败比例会形成清晰线索。相反，端口扫描可能在应用日志中没有留下有效请求，却能在网络侧表现为一个来源访问多个端口。

三、如何组合建立攻击流量监控

不要先追求复杂平台，先把时间、字段和关联规则固定下来。以下步骤适合多数拥有Web服务或内部网络的环境：

1. 划定采集边界。至少同时保留一类应用访问日志和一类网络连接数据，记录采集位置、时区、保留期限及是否经过代理或地址转换。
2. 建立分时段基线。分别统计工作日、夜间、发布窗口和批处理期间的请求量、状态码、连接数及常见来源。基线应按接口或服务拆分，不能只看整台主机的平均值。
3. 设置分层条件。单一指标只触发观察；当异常来源、失败比例、连接速率或目标端口同时变化时，再提高事件等级，避免把正常发布或备份任务误判为攻击。
4. 关联两类证据。用时间戳、源地址、目标服务和请求标识对齐记录。流量侧先发现异常时，检查应用日志是否存在对应请求；日志侧出现异常时，再确认是否伴随连接激增或横向访问。
5. 保留原始证据并处置。先保存相关日志、流量摘要和时间范围，再按影响选择限速、阻断单个来源、要求验证码、隔离主机或升级网络防护。处置规则要记录解除条件，避免临时封禁影响正常用户。

四、怎样选择侧重点

如果主要担心账户接管、接口滥用或越权操作，应优先完善应用日志，确保记录请求结果、账户标识、认证状态和关联编号，同时避免记录明文密码、完整令牌等敏感内容。

如果主要担心扫描、异常外联、协议攻击或内部横向移动，应优先建设入侵检测和网络连接观测能力，关注服务之间不常见的通信、短时间内的多端口访问，以及出站连接目的地突然改变。

对于规模较大的事件，流量侧通常更早反映攻击范围，日志侧更适合判断哪些功能和账户真正受到影响。事件响应时，前者帮助确认“攻击从哪里来、影响多大”，后者帮助回答“攻击者做了什么、是否成功”。

常见问题

1. 只做日志监测够不够？

不够。被网络设备提前丢弃的流量、端口扫描和部分连接攻击可能不会进入应用日志。

2. 流量异常就一定代表攻击吗？

不一定。发布、备份、爬虫、直播或突发活动都可能改变流量，应结合业务日程、状态码、来源分布和持续时间判断。

3. HTTPS会让流量分析失效吗？

不会，但分析重点会转向连接次数、时序、大小、方向和目标信息；若需查看请求内容，应在合法合规且具备相应密钥或终端采集条件时进行。

4. 告警应先看哪个指标？

建议先看异常是否同时影响请求量、失败率、连接行为和业务结果，再决定优先级，不要仅凭流量峰值下结论。

综合来看，日志监测负责解释业务行为，流量分析负责呈现网络行为。把两者按统一时间线关联，才能让攻击流量监控从“发现波动”进一步发展为“确认攻击、评估影响并指导处置”。