第一章：安全日志基础
大家好，我是老张。在安全这个行当摸爬滚打了十几年，今天咱们来聊聊安全日志审计的入门课——日志基础。说实话，很多人觉得日志就是些枯燥的文本记录，没什么好看的。但我告诉你，真正的高手，能从日志里读出整个系统的「心电图」。
1.1 日志的定义与重要性
日志是什么？说白了，就是系统、网络设备、应用程序在运行过程中产生的「流水账」。它记录了「谁、在什么时间、从哪来、干了什么事、结果如何」。
我经常跟团队里的新人说：日志是安全事件的「第一现场」。没有日志，安全分析就是盲人摸象。
日志的核心价值：
- 溯源取证：出事后，日志是唯一的「黑匣子」
- 实时告警：异常行为能第一时间被发现
- 合规审计：等保、ISO27001 都要求日志留存
- 性能优化：从日志里能看出系统的瓶颈在哪
我记得有一次，客户说服务器被黑了，但找不到入口。我翻了一个月的登录日志，发现有个账号总是在凌晨3点登录，而且登录IP来自境外。顺着这条线，我们找到了一个被暴力破解的弱口令账号。你看，这就是日志的价值。
⚠️ 避坑指南：我曾经见过一个团队，日志只保留7天。结果出了安全事件，需要回溯15天前的记录，直接傻眼了。我建议：核心系统的日志至少保留180天，合规要求严格的行业（如金融、医疗）建议保留1年以上。
1.2 常见日志类型
日志分很多种，咱们按来源来分，主要有三大类：
1.2.1 系统日志
系统日志是操作系统自己产生的。Windows 有事件查看器，Linux 有 /var/log/ 目录。
常见的系统日志包括：
- 登录日志：谁登录了、什么时候、成功还是失败
- 系统事件：服务启动/停止、系统重启、驱动加载
- 安全审计：权限变更、策略修改、账号创建/删除
举个例子，Linux 下查看登录失败的记录：
# 查看 SSH 登录失败的记录
grep "Failed password" /var/log/auth.log
# 输出示例
Mar 15 03:22:11 webserver sshd[12345]: Failed password for root from 192.168.1.100 port 54321 ssh2嗯，这里要注意：系统日志里，登录失败次数突然暴增，基本就是暴力破解的征兆。我处理过很多次这种情况，发现后第一时间封禁源IP，然后排查是否有账号被攻破。
1.2.2 网络日志
网络设备（防火墙、路由器、交换机）产生的日志。这类日志对安全分析特别重要，因为网络是攻击者的必经之路。
| 设备类型 | 常见日志内容 | 安全价值 |
|---|---|---|
| 防火墙 | 连接建立/断开、策略命中、NAT转换 | 发现异常流量、端口扫描 |
| 入侵检测系统 | 攻击特征匹配、异常协议检测 | 实时发现攻击行为 |
| VPN网关 | 用户认证、隧道建立/断开 | 追踪远程访问行为 |
| DNS服务器 | 域名解析请求、响应 | 发现DNS隧道、恶意域名通信 |
我个人习惯，每天上班第一件事就是扫一眼防火墙的拒绝日志。如果某个IP被拒绝的次数突然飙升，那大概率是有人在搞事情。
1.2.3 应用日志
应用日志是业务系统自己产生的。Web服务器、数据库、中间件，都有自己的日志。
常见的应用日志场景：
- Web访问日志：记录每个HTTP请求的URL、状态码、User-Agent
- 数据库查询日志：记录SQL语句的执行情况
- 业务操作日志：用户下单、支付、修改密码等关键操作
你想想看，如果有人在你的网站上尝试SQL注入，Web日志里会留下什么？
# 典型的SQL注入尝试日志
192.168.1.100 - - [15/Mar/2024:03:22:11 +0800] "GET /product?id=1' OR '1'='1 HTTP/1.1" 500 234 "-" "Mozilla/5.0"看到那个 id=1' OR '1'='1 了吗？这就是典型的注入测试。我在项目中遇到过很多次，只要在日志里看到这种模式，基本可以断定有人在试探你的应用安全。
1.3 日志格式标准
日志格式不统一，是安全分析最大的痛点之一。好在业界有一些标准格式，咱们来认识一下。
1.3.1 Syslog 格式
Syslog 是最古老的日志协议，也是目前最通用的。它定义了日志的传输方式和基本格式。
标准的 Syslog 格式长这样：
<PRI>Timestamp Hostname AppName[PID]: Message举个例子：
<13>Mar 15 03:22:11 webserver sshd[12345]: Failed password for root from 192.168.1.100这里 <13> 是优先级，13 表示「认证系统的错误消息」。嗯，这个数字是有讲究的，它由设施代码和严重级别组合而成。
💡 小技巧：Syslog 的严重级别从 0（紧急）到 7（调试）。我建议你在日志收集时，至少保留 0-4 级别（紧急到警告）的日志。调试级别的日志太啰嗦，除非排查问题，否则别开。
1.3.2 JSON 格式
JSON 格式是现在最流行的结构化日志格式。它最大的好处是——机器可读性强，解析起来特别方便。
{
"timestamp": "2024-03-15T03:22:11.123Z",
"hostname": "webserver",
"appname": "sshd",
"pid": 12345,
"severity": "ERROR",
"message": "Failed password for root",
"src_ip": "192.168.1.100",
"dst_port": 22,
"auth_method": "password"
}你看，JSON 格式把每个字段都标得清清楚楚。我特别喜欢用 JSON 格式的日志，因为写分析脚本时，直接 json.loads() 就能解析，省去了正则匹配的麻烦。
1.3.3 CEF 格式
CEF（Common Event Format）是 ArcSight 公司定义的格式，现在被很多安全设备和 SIEM 系统采用。
CEF 格式长这样：
CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension实际例子：
CEF:0|Check Point|Firewall-1|R80.10|100|Connection Denied|5|src=192.168.1.100 dst=10.0.0.1 dpt=443说实话，CEF 格式看着有点复杂，但它把安全事件的关键信息都封装进去了。扩展字段（Extension）里可以放任意键值对，灵活性很高。
| 格式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Syslog | 通用性强、兼容性好 | 格式不统一、解析困难 | 传统设备、网络设备 |
| JSON | 结构化、易解析、可扩展 | 体积较大 | 现代应用、云原生环境 |
| CEF | 标准化程度高、安全事件专用 | 学习成本高 | SIEM系统、安全设备 |
我的建议：如果你的环境允许，尽量统一使用 JSON 格式。实在不行，至少保证所有日志都包含「时间、来源、事件类型、结果」这四个核心字段。这是做安全分析的最低要求。
好了，第一章的内容就到这里。日志是安全分析的基础，就像盖房子要打地基一样。下一章咱们聊聊日志收集的那些事儿——怎么把分散在各处的日志集中起来，怎么保证日志不丢、不乱、不被篡改。
记住一句话：没有日志，安全就是空谈。