从 dmesg 日志发现恶意软件的实用方法
一、快速定位思路
dmesg > /var/log/dmesg-$(date +%F).log 或使用 journalctl -k -b all 导出内核日志。实时监控可用 dmesg -w；按严重级别筛选可用 dmesg -l err,crit,alert,emerg。注意普通用户可能权限不足，需 root 或加入 adm 组/配置 /dev/kmsg 权限。二、重点排查信号与示例命令
| 可疑信号 | 典型日志关键词/示例 | 排查要点 |
|---|---|---|
| 未授权内核模块加载或签名校验失败 | “module xxx: signature verification failed”；“insmod: ERROR: could not insert ‘xxx’: Invalid module format” | 立即核对 /proc/modules、lsmod 输出，定位模块文件（如 /lib/modules/**/*.ko），用 modinfo 查看签名与来源，必要时隔离并卸载。 |
| LSM/SELinux/AppArmor 拒绝 | “SELinux: avc: denied { read/write } … comm=“xxx” path=…”；“AppArmor: DENIED { write } …” | 结合进程名与路径判断是否异常访问；若为合法进程策略过严，调整策略；若为可疑进程，视为潜在提权/持久化迹象。 |
| 异常设备接入或驱动异常 | “usb 1-1: new high-speed USB device … error -110”；“device descriptor read/64, error -110” | 排查未知 USB/存储设备；结合 lsusb -v、udev 规则与物理端口检查，防止 BadUSB/嗅探器。 |
| 文件系统与磁盘异常 | “EXT4-fs (sda1): error …”；“I/O error …” | 检查 `dmesg -T |
| 内存错误与 OOM Killer | “EDAC MC#: CE memory read error …”（可纠正错误频发需警惕）；“Out of memory: Killed process 1234 (xxx)” | 内存错误频发可能指向硬件问题或被利用的内存破坏；OOM 结合 pmap -x <pid>、smem 与业务基线判断是否异常占用。 |
| 异常重启/崩溃线索 | “Kernel panic …”；“BUG: unable to handle page fault …” | 保存完整 dmesg 与 journalctl -k -b -1 回溯；结合 kdump/vmcore 分析，排查内核漏洞利用或不稳定内核模块。 |
| 以上信号与示例命令可快速筛出高风险线索，并指导后续取证与处置。 |
三、高效排查命令清单
dmesg -w -T（按时间显示并持续输出）。dmesg -l err,crit,alert,emerg -T | less。dmesg -T | egrep -i "module|signature|selinux|apparmor|usb|i/o|error|fail|panic|oom|edac|ext4-fs" | less。journalctl -k -b all > kernel_all_$(date +%F).log；查看上次启动 journalctl -k -b -1 -e。grep -i "invalid user\|failed password" /var/log/auth.log；与 dmesg 时间线对齐分析暴力尝试与内核日志的因果关系。四、误报甄别与进一步取证
lsmod、modinfo <module>、find /lib/modules -name <module>.ko 定位文件；结合进程树 pstree -aps <pid>、网络连接 ss -tulpen | grep <pid> 与文件完整性校验（如 sha256sum）取证；必要时在离线环境做静态分析。modprobe -r <module>），回滚最近内核/驱动更新；修复策略（SELinux/AppArmor）、更新签名与补丁；完善持久化与审计（开启并审计 auditd，集中收集 journalctl -k 与系统日志到 SIEM/IDS 做关联告警）。
