应交叉验证模块信息并检查内核符号、登录日志和auditd规则有效性：比对/proc/modules与lsmod，查/lib/modules下非标模块；用cat /proc/kallsyms | grep -v ‘ t ‘ | grep -e ‘(sys_|do_|entry_)’找异常重定向；核查auth.log中accepted与authorized_keys时间戳一致性；auditd需用-f exe=而非-f path=，且必须用aureport验证事件上报；journalctl须配合/var/log/auth.log或secure使用，优先用_comm=sshd。
怎么快速确认系统是否已被植入 rootkit
直接用 chkrootkit 或 rkhunter 扫描，但它们只能发现已知签名——真正隐蔽的内核模块级 rootkit 很可能漏掉。更可靠的做法是交叉验证：比对 /proc/modules 输出和 lsmod 结果是否一致，检查 /lib/modules/$(uname -r)/kernel/ 下有没有非标准模块文件。
常见错误现象：lsmod 显示某个模块，但 find /lib/modules -name "*.ko" | xargs ls -l 找不到对应文件；或者 cat /proc/kallsyms | head -20 里有可疑符号名（如 hide_process、fake_netdev）。
- 优先运行
sudo cat /proc/kallsyms | grep -v ' t ' | grep -E '(sys_|do_|entry_)'看是否有异常函数地址被重定向 - 不要只信
rkhunter --checkall的“OK”结果，它默认跳过内核模块校验，需手动加--enable sysctl和--enable kernel_modules - 若系统启用了 Secure Boot，
insmod加载未签名模块会失败，但攻击者可能已绕过或禁用它——检查mokutil --sb-state
auth.log 里哪些登录行为必须立刻人工核查
不是所有失败登录都危险，重点盯住那些“成功绕过常规限制”的痕迹。比如 sshd 日志中出现 Accepted publickey 但对应用户主目录下 ~/.ssh/authorized_keys 文件时间戳早于上次安全审计日期，就极可能被篡改。
使用场景：日常巡检时用 grep "Accepted" /var/log/auth.log | tail -50 快速拉取最新成功登录，再逐条反查来源 IP 是否在白名单内。
- 特别注意
invalid user后紧跟着Accepted的记录——说明攻击者爆破到了一个真实存在的用户名+密码组合 -
session opened for user root by (uid=0)出现在非运维时段，且没有对应sudo日志，大概率是直接 SSH 登录或 su 提权后残留 - 同一 IP 在 1 分钟内触发多次
PAM 2.0认证成功（查看journalctl -u sshd | grep -E "PAM.*success"），可能是利用 PAM 模块漏洞绕过双因素
auditd 规则写错会导致日志爆炸或完全失效
auditd 不像 syslog 那样宽容，规则语法错一个字符（比如漏掉 -F 或多打空格），整个规则就会静默失效。最常踩的坑是想监控敏感命令执行，却只写了 -a always,exit -S execve -F path=/usr/bin/wget，结果什么都没捕获到——因为 execve 系统调用的路径参数实际是 argv[0]，而 wget 常被软链接调用或通过绝对路径执行。
性能影响：开启 -a always,exit -S execve 全局监控，单机每秒超 200 次命令执行时，auditd 进程 CPU 占用可飙到 40%+，磁盘 I/O 也会明显升高。
- 正确做法是用
-F exe=/usr/bin/wget替代-F path=，它匹配的是解释器真实路径，不受软链影响 - 避免用
-w监控整个/etc，应拆成具体文件：如-w /etc/passwd -p wa -k identity，否则每次ls /etc都会打点 - 规则生效后务必运行
sudo aureport -m -ts today | head -10验证是否真有事件上报，别只看auditctl -l列出的规则
用 journalctl 查历史登录会漏掉关键信息
journalctl -u sshd 默认只显示 systemd-journald 收到的日志，而 OpenSSH 在 UsePrivilegeSeparation yes（默认开启）时，子进程日志可能不经过 journald，尤其当连接被暴力破解中断、或认证方式为键盘交互式时。
兼容性影响：centos 7 默认用 rsyslog 转发 auth 日志，但 systemd-journal-gatewayd 在某些内核版本下无法解析二进制日志头，导致 journalctl --since "2024-01-01" -u sshd 返回空。
- 必须同时查
/var/log/auth.log（debian/ubuntu）或/var/log/secure（RHEL/CentOS），不能只依赖 journalctl -
journalctl _COMM=sshd比-u sshd更准，因为后者只匹配 unit 名，前者匹配实际进程名，能捕获非 systemd 启动的 sshd 实例 - 如果系统禁用了 persistent journal（
Storage=volatile），重启后所有日志丢失——检查ls /var/log/journal/是否为空目录
日志分析最难的从来不是工具用法，而是搞清一条记录背后到底发生了什么系统调用、哪个进程写的、有没有被重定向或伪造。别急着写告警规则，先花十分钟手工追一条可疑登录的完整调用链：从 auth.log 时间戳 → 对应的 audit log ID → 查 aureport -f -i -x sshd --start recent → 再反查该进程打开的文件描述符。这步省了，后面所有自动化都只是安慰剂。