网络日志分析

在无 SIEM 平台的情况下，对设备级 syslog 日志进行分析并构建取证时间线。本技能涵盖来自 rsyslog/syslog-ng 收集器、设备控制台输出以及 SNMP trap 接收器的原始日志数据——所有分析均使用标准 Unix 工具（grep、awk、sort、sed）完成。

对于已部署 SIEM 平台的环境，请使用配套技能 siem-log-analysis，该技能提供相同的取证推理逻辑，但采用平台特定的查询语法。

参考 references/cli-reference.md 了解 rsyslog/syslog-ng 配置、设备 syslog 命令及日志解析的一行命令。

参考 references/syslog-patterns.md 获取厂商特定消息格式、RFC 5424 设施/严重性矩阵以及常见事件模式目录。

适用场景

• 无 SIEM 可用 —— 仅通过集中式收集器上的原始 syslog 文件或单个设备日志调查网络事件
• Syslog 基础设施审计 —— 验证 rsyslog 或 syslog-ng 是否正确接收、路由并保留所有目标网络设备的日志
• 多设备事件关联 —— 使用时间戳排序和模式匹配，从各设备或各设施的日志文件中构建统一时间线
• 异常情况调查 —— 在无统计查询引擎的情况下，识别日志量异常、新消息类型或认证失败聚集现象
• 事件后时间线重建 —— 在网络中断或安全事件发生后，从原始日志中重构时间顺序的证据链
• 日志留存合规性验证 —— 确认日志轮转策略和留存周期符合组织或监管要求

前提条件

• Syslog 收集器访问权限 —— 对 rsyslog/syslog-ng 服务器具有 SSH 或控制台访问权限，并具备日志目录（通常为 /var/log/ 或配置中定义的自定义路径）的读取权限
• 设备 CLI 访问权限 —— 具备网络设备的只读凭证，用于验证 syslog 转发配置及 NTP 同步状态
• Unix 工具可用性 —— 在 syslog 收集器上需具备 grep、awk、sort、sed、wc 和 date 工具（任何 Linux/BSD 系统均默认提供）
• NTP 一致性验证 —— 在进行多设备关联前，确认所有网络设备与 syslog 收集器的时间同步；时钟偏差将导致时间线失准
• 日志文件识别 —— 熟悉收集器上的日志文件路径、命名规范及轮转计划；rsyslog 和 syslog-ng 根据设施、严重性及源地址不同，日志路由方式也不同

操作流程

按以下六个步骤依次执行。该流程通过模式识别、关联分析、异常检测和时间顺序重构，从原始 syslog 证据中构建取证时间线。每一步产生的成果将作为后续步骤的输入。

步骤 1：日志收集评估

在分析日志内容前，先验证 syslog 基础设施是否完整且健康。缺失或配置错误的数据源会造成盲区，影响调查结论的有效性。

Syslog 服务器配置 —— 检查收集器配置以理解日志路由方式：

• [rsyslog] —— 查看 /etc/rsyslog.conf 和 /etc/rsyslog.d/*.conf 中的输入模块（imudp、imtcp、imrelp）、设施/严重性路由规则及输出文件模板。确认 $ActionFileDefaultTemplate 包含源主机名，以便区分多设备日志。
• [syslog-ng] —— 查看 /etc/syslog-ng/syslog-ng.conf 中的源定义（网络监听器）、过滤链（设施、严重性、主机匹配）及目标路径。确保 keep-hostname(yes) 保留了原始设备主机名。

设备 syslog 验证 —— 在每个目标网络设备上，确认 syslog 转发已启用且指向正确的收集器：

• [Cisco] —— 执行 show logging 查看日志主机、陷阱级别和设施；使用 show logging history 查看最近缓冲区中的严重性计数
• [JunOS] —— 执行 show system syslog 查看配置的主机目标、设施过滤器及结构化数据启用状态
• [EOS] —— 执行 show logging 查看 syslog 服务器地址、日志级别及协议（UDP/TCP）

NTP 同步检查 —— 在每台设备上验证：

• [Cisco] —— show ntp status（主从等级、偏移量）
• [JunOS] —— show system ntp（对等状态、偏移量）
• [EOS] —— show ntp status（时钟状态、主从等级）

若设备 NTP 偏移超过 1 秒，需在关联分析前进行时间校正。

日志留存与轮转 —— 检查 logrotate 配置中的留存周期、压缩设置及文件大小限制。确认留存窗口覆盖调查时间段。缺失的轮转文件可能意味着证据缺失。

步骤 2：Syslog 模式识别

通过厂商特定格式知识，将原始 syslog 消息解析为结构化字段。模式识别可将非结构化文本转化为可关联的证据。

厂商消息格式：

• [Cisco] —— %FACILITY-SEVERITY-MNEMONIC: message。设施标识子系统（LINEPROTO、OSPF、SEC），严重性为 0–7（RFC 5424），助记符为事件标识符。
• [JunOS] —— hostname process[pid]: EVENT_ID: message。当启用结构化数据时，会附加 [tag value] 键值对。
• [EOS] —— hostname AgentName: %FACILITY-SEVERITY-message。Agent 名称标识子系统（Ebra、Bgp、Ospf）。

严重性分类 —— 提取严重性数字并映射至 RFC 5424 等级（0=紧急至 7=调试）。操作相关事件通常关注严重性 0–4（紧急至警告）。仅在低严重性信息缺乏上下文时，才考虑使用 5–7 级别。

消息频率基线 —— 统计每小时各设施的消息数量，建立正常流量基准：

awk '{print $1, $2, $3}' /var/log/network.log | sort | uniq -c | sort -rn

markdown

name: Network Log Analysis

version: 1.0.0

description: 通过时间戳分组生成频率表，显著偏离每小时均值的事件值得深入调查。

summary: 从日志中识别异常、关联事件、重建时间线并生成报告，用于网络故障排查与安全分析。

此操作生成按时间戳分组的频率统计表。若某时段的事件频率显著偏离每小时平均值，则表明存在值得关注的事件。

设施码到子系统映射 — 使用 references/syslog-patterns.md 将 syslog 设施码映射到网络子系统。本地设施 local0–local7 的分配因组织而异，需参考第 1 步中的 rsyslog 路由规则以确定其具体含义。

第三步：事件关联

通过共享属性将多个设备和日志文件中的事件进行关联，从孤立消息中构建完整的调查线索。

多设备时间线（使用 grep/awk/sort） — 将各设备的日志文件合并为一个按时间排序的流：

cat /var/log/rtr*.log /var/log/sw*.log | sort -k1,3 > /tmp/merged-timeline.log

若日志文件使用不同的时间格式，需在合并前先用 awk 进行标准化处理（详见第 5 步的时间戳标准化细节）。

时间聚类 — 在已知触发事件的时间窗口内识别相关事件。为提高精度，将时间戳转换为秒级纪元时间，并使用 awk 的数值比较筛选目标事件（参见 references/cli-reference.md 中的关联辅助命令）。

因果链检测 — 网络故障通常按协议依赖关系传播，具有可预测模式：接口震荡（LINK-3-UPDOWN）→ OSPF 邻居中断（OSPF-5-ADJCHG）→ BGP 路由撤回（BGP-5-ADJCHANGE）→ 流量切换至备用路径。通过提取每个阶段的事件并验证其时间顺序，可识别此类级联模式。

SNMP 陷阱关联 — 若采集器接收 SNMP 陷阱（通过 snmptrapd），应将陷阱 OID 与 syslog 事件进行关联。接口 linkDown 陷阱（OID 1.3.6.1.6.3.1.1.5.3）应与同一设备的 LINK-UPDOWN syslog 消息配对。不匹配可能表明日志缺失。

第四步：异常检测

将观测到的日志模式与基线进行对比，发现需要关注的偏差。所有检测均基于原始日志文件，使用 grep、awk 和 sort 实现。

基线偏差 — 对比当前日的事件数量与过去 7 天滚动平均值。若当前事件数超过平均值两倍，即为体积异常。按设施码统计可定位产生异常消息的子系统。

新或未知的消息类型 — 从调查时间段提取唯一标识符（mnemonic），并与基线文件对比：

grep -oP '%\S+-\d-\S+' /var/log/cisco.log | sort -u > /tmp/current.txt
comm -23 /tmp/current.txt /tmp/baseline-mnemonics.txt

出现在当前但不在基线中的标识符为首次出现事件，需进行分类。

认证失败聚集 — 提取认证相关消息，按源 IP 分组（参见 references/cli-reference.md 中的一行命令）。每小时失败次数超过 10 次的源 IP 值得调查，可能为暴力破解尝试。

非维护窗口内的配置变更 — 筛选配置变更消息（如 SYS-5-CONFIG_I、UI_COMMIT），检查其时间是否在批准的维护窗口之外。超出窗口的变更需追溯责任人、变更内容，并确认是否授权。

登录源 IP 异常 — 提取管理会话的源 IP 地址，与授权管理子网列表对比。位于已知范围外的 IP 表明可能存在未授权访问尝试。

第五步：时间线重构

整合第 1 至第 4 步收集的所有证据，构建一份明确的时间顺序事件序列。该时间线是取证日志分析的主要交付成果。

时间顺序组装 — 从多个日志源中提取相关事件，并合并为一个已排序的输出：

grep -h "PATTERN1\|PATTERN2\|PATTERN3" /var/log/*.log | sort -k1,3

使用 sort -s -k1,3（稳定排序）可保留相同时间戳事件的原始顺序。

支持 NTP 的时间戳标准化 — 若设备使用不同时区或时间格式，需在排序前将所有时间戳统一转换为 UTC 秒级纪元时间。使用 awk 结合 date 命令转换 RFC 3164 格式时间戳（参见 references/cli-reference.md 中的转换示例）。根据第 1 步获取的 NTP 偏移量，对已知时钟漂移设备的事件应用校正。对于 BSD/macOS 系统，请使用 date -jf 替代 date -d。

事件到影响的映射 — 对时间线中每个重要事件，标注其对用户可见的影响：

1. 识别事件（例如：OSPF-5-ADJCHG neighbor down）
2. 确定网络影响（冗余路径丢失）
3. 映射至用户症状（连接质量下降或故障切换延迟）

根因排序 — 从用户报告的症状开始，逆向遍历时间线，找到最早的因果事件。根因即为若被阻止则可防止所有后续影响的首个事件。用事件引用记录每一步的因果链条。

第六步：报告编写

将所有发现整理为结构化文档。以第 5 步生成的时间线为核心，为每条记录标注分类（根因、促成因素、症状、信息性）。总结第 4 步的异常发现，包含数量和严重程度评估。记录第 3 步的关联链条及支持证据。明确陈述根因判断及其置信度，并附上支撑证据链。另设“完整性”部分，列出限制结论的证据缺口。

阈值表

日志流量异常阈值

Syslog 严重性响应矩阵

关联置信度等级

决策树

调查切入点

收到调查触发信号
├── 已知时间窗口的故障报告？
│   ├── 是 → 从第 3 步（关联分析）开始，限定在该时间窗口内
│   │   └── 若关联分析事件不足，扩展至第 2 步（模式识别）
│   └── 否 → 从第 1 步（日志收集评估）开始
│
├── 监控中检测到异常（无日志详情）？
│   ├── 异常发生时间已知？ → 从第 4 步（异常检测）开始
│   │   └── 通过第 2 步模式分析进行确认
│   └── 时间未知？ → 执行完整流程 1–6 步
│
├── 事后复盘（事件已解决）？
│   └── 从第 1 步开始 → 完整流程以确保完整性
│       └── 重点在第 5 步（时间线）生成交付成果
│
└── 对 syslog 基础设施的合规审计？
    └── 仅执行第 1 和第 2 步（收集 + 模式验证）

异常分类

第 4 步中识别出异常
├── 量级异常（消息数量偏离）？
│   ├── 单一设备受影响？
│   │   ├── 设备重启或维护中 → 属于预期，需记录
│   │   └── 无维护记录 → 调查设备健康状态
│   └── 多个设备受影响？
│       ├── 共享上游链路事件？ → 在第 3 步中进行关联
│       └── 独立峰值？ → 分别调查每个设备
│
├── 出现新助记符或事件类型？
│   ├── 匹配已知固件升级模式？ → 属于预期
│   ├── 安全相关设施（SEC、AUTH）？ → 优先审查
│   └── 信息类设施？ → 若无害则加入基线
│
├── 认证异常？
│   ├── 单一源 IP，多个目标？ → 暴力扫描行为
│   ├── 多个源 IP，单一目标？ → 分布式攻击
│   └── 单一源 IP，单一目标？ → 凭据问题
│
└── 非窗口期配置变更？
    ├── 归因于已知管理员？ → 验证授权权限
    ├── 归因于未知用户？ → 视为安全事件
    └── 无法归因？ → 立即上报

报告模板

网络日志分析报告
==============================
报告编号：[唯一标识符]
调查触发来源：[故障报告 / 异常告警 / 合规审计]
调查时间窗口：[起始时间戳] — [结束时间戳]（UTC）
分析人员：[姓名/标识符]
日志来源：[采集器主机名，设备数量，日志文件路径]

摘要：
- 调查类型：[故障 / 安全 / 合规 / 异常]
- 根本原因置信度：[确认 / 可能 / 可疑]
- 涉及设备：[数量及主机名]
- 证据缺口：[列出任何缺失的日志源或时间间隙]

日志收集状态（第 1 步）：
- Syslog 采集器：[rsyslog / syslog-ng，配置路径]
- 正在转发的设备：[数量] / [总预期数量]
- NTP 同步状态：[同步数量] / [总数]，最大偏移：[毫秒]
- 保留覆盖范围：[可用天数] vs [所需天数]

事件时间线（第 5 步）：
| # | 时间戳（UTC） | 设备 | 设施-严重性 | 助记符/事件 | 消息摘要 | 分类 |
|---|-----------------|--------|-------------|----------------|-----------------|----------------|
| 1 | [时间] | [主机] | [fac-sev] | [助记符] | [摘要] | [根本原因 / 促成因素 / 症状] |

检测到的异常（第 4 步）：
| # | 类型 | 设备（群组） | 描述 | 严重性 |
|---|------|-----------|-------------|----------|

关联链路（第 3 步）：
- 链路 1: [事件 A] → [事件 B] → [事件 C]
  置信度：[确认 / 可能 / 可疑]

根本原因评估：
- 根本原因：[描述]
- 置信度：[等级及理由]
- 因果链：[首个事件 → ... → 用户影响]

证据完整性：
- 缺失项：[缺失设备、时间段、已轮转文件]
- 已应用的 NTP 修正：[列出所有偏移调整]

建议措施：
1. [立即行动 — 如修复 syslog 转发缺口、处理根本原因]
2. [短期措施 — 如添加缺失设备至采集器、优化轮转策略]
3. [长期改进 — 如优化 NTP 架构、增加日志冗余]

故障排查

采集器上缺少设备日志

现象： 设备已配置向 syslog 采集器转发日志，但采集器文件中仍无对应日志。

诊断： 验证设备上的 syslog 配置（参见步骤 1 命令）。检查网络路径——防火墙规则可能阻止设备与收集器之间的 UDP 514 或 TCP 514 通信。在收集器端，检查 rsyslog/syslog-ng 是否丢弃消息：rsyslogd 会将其输入错误记录到自身的 syslog 服务中。使用 ss -ulnp | grep 514 确认收集器是否在预期端口上监听。

解决方法： 修复转发路径（设备配置、网络 ACL、收集器监听器）。从设备生成一条测试消息并确认是否收到。在调查报告中记录数据缺失时间段。

时间戳格式不一致

症状： 合并的日志文件导致时间线无法排序，因为时间戳格式不同（RFC 3164 与 RFC 5424 以及设备特定格式）。

诊断： 检查每个源文件的前 10 行内容。RFC 3164 使用 Mmm dd HH:MM:SS 格式（无年份）；RFC 5424 使用带时区的 ISO 8601 格式。

解决方法： 为每种格式编写一个 awk 标准化脚本（参见步骤 5 和 references/cli-reference.md）。根据文件修改时间或 logrotate 命名规则，向 RFC 3164 时间戳补全年份。

日志轮转破坏证据

症状： 调查时间段超出当前可用日志文件的最早时间。

诊断： 检查 /etc/logrotate.d/ 中的保留策略和压缩设置。查找压缩归档文件（.gz、.bz2、.xz）。

解决方法： 使用 zgrep 或 zcat | grep 在压缩文件中搜索。若数据已永久丢失，应在报告中说明数据缺失情况，并指出哪些结论因证据缺失而受限。

日志量过大导致 grep 不切实际

症状： 数 GB 的日志文件使得交互式 grep 分析变得极慢，难以操作。

解决方法： 先通过基于日期的 grep 缩小范围至调查窗口，将结果重定向到工作文件，再对较小的提取文件进行详细分析。使用 LC_ALL=C grep 提升处理速度。对于多文件分析，可考虑使用 GNU parallel 加速处理。