2. 日志源与收集架构：常见日志源与集中式收集方案

日志安全审计这件事，第一步不是选工具，而是搞清楚——你的日志到底从哪来？

我见过不少团队，一上来就搭ELK，结果发现网络设备的日志格式五花八门，应用日志又缺字段。最后审计的时候，连谁在什么时间干了什么都对不上。说白了，日志源没理清楚，后面全是坑。

2.1 常见日志源：三类核心来源

我个人习惯把日志源分成三大类：服务器、应用、网络设备。每一类的特点、格式、安全关注点都不一样。

2.1.1 服务器日志

服务器日志是最基础的。Linux的/var/log/目录下，藏着系统运行的所有秘密。

• 系统日志（syslog）：记录内核、服务、认证信息。比如用户登录失败、sudo提权操作。
• 安全日志（auth.log / secure）：重点关注。SSH登录、sudo执行、用户切换都在这里。
• 审计日志（audit.log）：Linux auditd产生的，能记录文件访问、系统调用。我在项目中用它抓过内部人员删库的痕迹。

2.1.2 应用日志

应用日志是安全审计的重灾区。为什么？因为应用层最贴近业务，攻击者最喜欢在这里动手脚。

• Web服务器日志：Nginx、Apache的access log和error log。SQL注入、XSS攻击、路径遍历，全都能在这里找到线索。
• 业务应用日志：比如Java应用的log4j、Python的logging模块。记录用户操作、交易流水、权限变更。
• 数据库日志：MySQL的general log、slow query log，PostgreSQL的pg_log。谁执行了DROP TABLE？什么时候执行的？一查便知。

你想想看，如果应用日志里没有记录用户ID、操作时间、源IP、操作结果这四个字段，那审计基本就是废的。我建议每个应用日志至少包含这四要素。

2.1.3 网络设备日志

网络设备日志，说白了就是防火墙、路由器、交换机的“黑匣子”。

• 防火墙日志：记录允许/拒绝的连接。谁从外网访问了内网？哪个端口被扫描了？
• VPN日志：谁在什么时间建立了VPN连接？从哪个IP拨入的？
• IDS/IPS日志：检测到的攻击事件。比如CVE-2021-44228的利用尝试。

2.2 集中式日志收集架构

日志源分散在各处，总不能一台一台去翻吧？集中式收集是必然选择。目前主流的两套方案：ELK和Splunk。

2.2.1 ELK（Elasticsearch + Logstash + Kibana）

ELK是开源界的明星。我用了快十年，从1.x版本一路跟到8.x。它的核心逻辑很简单：

• Logstash：负责采集、解析、过滤日志。支持多种输入源（filebeat、syslog、TCP/UDP）。
• Elasticsearch：存储和索引日志。支持全文检索、聚合分析。
• Kibana：可视化展示。画图表、建仪表盘、做告警。

下面是我画的一个典型ELK架构图，你可以看看数据是怎么流转的：

ELK的配置其实不复杂。下面是一个Logstash的简单配置示例，用来解析Nginx日志：

input {
  beats {
    port => 5044
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
  geoip {
    source => "clientip"
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "nginx-logs-%{+YYYY.MM.dd}"
  }
}

2.2.2 Splunk

Splunk是商业方案，贵，但确实好用。它的核心优势在于：

• 数据接入简单：支持几乎所有格式，自动解析字段。
• 搜索语言强大：SPL（Search Processing Language）可以快速做复杂分析。
• 内置安全分析：有现成的安全仪表盘和告警规则。

下面是一个Splunk搜索示例，用来查找过去24小时内失败的SSH登录：

index=linux_secure sourcetype=secure
"Failed password" OR "authentication failure"
| stats count by src_ip, user
| where count > 10
| sort - count

我个人觉得，Splunk适合预算充足、对易用性要求高的团队。ELK则适合技术能力强、愿意折腾的团队。没有绝对的好坏，看你的场景。

2.3 收集架构的安全考量

日志收集架构本身也要防篡改。我总结了几条核心原则：

安全维度	要求	实现方式
传输加密	日志在传输过程中不能被窃听或篡改	TLS/mTLS加密通道
身份认证	只有合法的日志源才能发送日志	证书认证、API Token
完整性校验	日志到达后未被修改	哈希链、数字签名
访问控制	只有授权人员能查看/修改日志	RBAC、审计日志
冗余备份	单点故障不影响日志可用性	多节点集群、异地备份

好了，关于日志源和收集架构，就聊这么多。记住一句话：日志源是基础，收集架构是骨架，安全是灵魂。三者缺一不可。

---