2. dmesg 命令详解：从启动日志看透硬件级安全威胁

dmesg 这命令，说白了就是内核的“日记本”。系统从按下电源键到登录界面出现，内核干了什么、发现了什么硬件、报了什么错，全记在里面。我干了这么多年安全排查，每次遇到不明原因的宕机、硬件异常、甚至疑似后门，第一件事就是翻 dmesg。

你想想看，如果攻击者往你的服务器上插了个恶意的 USB 设备，或者 BIOS 被篡改过，这些痕迹大概率会出现在 dmesg 里。今天我们就把它彻底讲透。

2.1 dmesg 的基本用法

直接敲 dmesg，你会看到满屏的日志。但别慌，我们一条条来拆解。

# 查看所有内核日志
dmesg

# 实时监控新产生的日志（类似 tail -f）
dmesg -w

# 清空日志缓冲区（谨慎使用）
dmesg -c

# 显示人类可读的时间戳
dmesg -T

# 限制输出行数
dmesg -n 3   # 只显示级别 3（KERN_ERR）及以上的日志

我个人习惯，排查问题时先用 dmesg -T | tail -100 看最近 100 条。为什么？因为很多硬件故障是在系统运行一段时间后才触发的，只看启动阶段容易漏掉。

2.2 过滤内核消息：从海量日志中精准定位

裸跑 dmesg 输出可能有几千行。怎么快速找到关键信息？我教你几招。

2.2.1 按日志级别过滤

内核日志有 8 个级别，从紧急到调试。我们最关心的是 KERN_ERR（3）和 KERN_CRIT（2）。

# 只看错误和严重错误
dmesg -l err,crit

# 只看某个级别以上的日志
dmesg -l 3   # 显示级别 3 及以上的日志

2.2.2 按关键词过滤

用 grep 配合 dmesg 是最常见的操作。我排查硬件安全时，这几个关键词是必搜的：

# 搜索 USB 相关
dmesg | grep -i usb

# 搜索硬盘/存储相关
dmesg | grep -iE 'sd[a-z]|nvme|ata'

# 搜索错误
dmesg | grep -i error

# 搜索固件/BIOS 相关
dmesg | grep -i 'firmware|bios|uefi'

# 搜索可疑设备
dmesg | grep -i 'unknown|unrecognized|failed'

2.3 时间戳解读：把内核时间翻译成人话

dmesg 默认的时间戳是从系统启动开始算的秒数。比如 [ 12.345678] 表示系统启动后 12.345678 秒。这玩意儿看着费劲，得换算。

# 查看系统启动时间
who -b

# 或者用 uptime 看运行时间
uptime -s

举个例子：系统启动时间是 2024-01-15 09:00:00，dmesg 里有一条 [ 3600.123456] 的错误。那实际发生时间就是 09:00:00 + 3600 秒 = 10:00:00 左右。

我建议，排查时直接用 dmesg -T 转成人类时间。但要注意，-T 依赖系统时钟，如果系统时间被篡改过，那转换出来的时间也是错的。遇到这种情况，我会用 dmesg 原始时间戳配合 uptime -s 手动推算。

# 直接看人类时间
dmesg -T | tail -20

# 输出示例
[Mon Jan 15 10:00:00 2024] usb 1-1: new high-speed USB device number 2 using xhci_hcd

2.4 实战排查：硬件级安全威胁

好了，理论讲完，咱们上实战。下面是我总结的几种常见硬件安全威胁，以及如何在 dmesg 里找到它们。

2.4.1 恶意 USB 设备（BadUSB、Rubber Ducky）

攻击者把伪装成键盘的恶意设备插到你的服务器上，模拟按键执行命令。dmesg 里会留下什么？

# 正常 USB 键盘插入
[ 1234.567890] usb 1-1: new low-speed USB device number 5 using xhci_hcd
[ 1234.573456] input: USB Keyboard as /devices/pci0000:00/.../input/input5

# 可疑的 BadUSB 设备（注意设备描述和 VID/PID）
[ 1234.567890] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[ 1234.573456] input: HID 1234:5678 as /devices/pci0000:00/.../input/input5
[ 1234.580123] hid-generic 0003:1234:5678.0002: input,hidraw1: USB HID v1.10 Keyboard [HID 1234:5678] on usb-0000:00:14.0-1/input0

关键点： 正常的键盘厂商 VID/PID 是公开的（比如 Logitech 是 046d），如果看到一个不认识的 VID/PID，或者设备描述里写着 HID 1234:5678 这种通用描述，就要警惕了。

2.4.2 DMA 攻击（通过 Thunderbolt/PCIe 设备）

攻击者通过 Thunderbolt 或 PCIe 接口直接访问物理内存，绕过操作系统保护。dmesg 里会有这些特征：

# 可疑的 PCIe 设备热插拔
[ 5678.901234] pci 0000:04:00.0: [8086:15d9] type 00 class 0x0c0330
[ 5678.902345] pci 0000:04:00.0: DMAR: [DMA Write] Request device [04:00.0] fault addr 0x12345000
[ 5678.903456] DMAR: DRHD: handling fault status reg 3

关键点： 看到 DMAR、DMA fault、DRHD 这些关键词，说明有设备在尝试 DMA 操作。如果系统没有 Thunderbolt 设备，却出现了这些日志，那基本可以断定有人在搞鬼。

2.4.3 固件/BIOS 篡改

攻击者修改了 BIOS 或 UEFI 固件，植入持久化后门。dmesg 里可能出现的异常：

# 正常的 ACPI 表加载
[    0.123456] ACPI: RSDP 0x00000000BFFF0000 000024 (v02 ALASKA)
[    0.123789] ACPI: XSDT 0x00000000BFFF00A0 0000AC (v01 ALASKA A M I)

# 异常的 ACPI 表（注意签名和 OEM ID）
[    0.123456] ACPI: RSDP 0x00000000BFFF0000 000024 (v02 ??????)
[    0.123789] ACPI: XSDT 0x00000000BFFF00A0 0000AC (v01 ?????? ??????)

关键点： 正常的 ACPI 表会有明确的 OEM ID（比如 ALASKA、AMI、Phoenix）。如果看到 ?????? 或者奇怪的字符串，说明固件可能被改过。

2.4.4 硬件 Keylogger（硬件键盘记录器）

攻击者在键盘和电脑之间串入一个硬件记录器。dmesg 里会多出一个 HID 设备：

# 正常情况：只有一个键盘
[ 1234.567890] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

# 异常情况：出现两个键盘设备
[ 1234.567890] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
[ 1234.573456] input: HID 1234:5678 as /devices/pci0000:00/.../input/input5

关键点： 系统里不应该有两个键盘设备。如果发现多了一个，而且 VID/PID 不熟悉，那大概率是硬件 Keylogger。

2.5 知识体系总览

下面这张图，是我梳理的 dmesg 排查硬件安全威胁的完整流程。你可以把它当作一个检查清单。

2.6 建立你的 dmesg 基线

说了这么多，其实最有效的办法是：在系统刚装好、确认安全的时候，保存一份 dmesg 快照。以后每次排查，拿当前日志和基线对比，差异一目了然。

# 保存基线
dmesg -T > /var/log/dmesg.baseline.$(date +%Y%m%d)

# 对比差异
diff /var/log/dmesg.baseline.20240115 <(dmesg -T)

嗯，dmesg 这块内容其实很深，但掌握了今天讲的这些，你已经能应对 90% 的硬件安全排查场景了。记住：日志不会说谎，除非你读不懂它。