如何判断自己的Linux服务器是否已受到CVE-2025-6018/6019攻击？

发现系统异常，怀疑被入侵时，那种感觉就像半夜听到家里有异响，你无法确定是风还是贼。对于CVE-2025-6018和CVE-2025-6019这对组合漏洞，情况更是如此。它们利用的是系统里合法且看似无害的组件——PAM认证框架和udisks存储服务。攻击者得手后，可能不会留下传统木马那样明显的痕迹，而是像拿到了万能钥匙的管家，悄无声息地进出。判断是否已受攻击，考验的不是病毒扫描，而是对系统“行为异常”的洞察力。

从“症状”入手：寻找不合理的特权活动

攻击的最终目标是获取root权限。因此，最直接的线索就是去翻看那些记录了特权操作的日志。别只盯着/var/log/auth.log或/var/log/secure里的登录记录，那只是第一层。真正的关键在/var/log/syslog、journalctl的输出以及polkit的审计日志里。

你需要寻找的是，一个普通用户账户（尤其是最近通过SSH登录的账户）名下，却出现了本应需要root密码或管理员确认的udisks2相关操作。比如，在日志中搜索“org.freedesktop.udisks2”这个字符串。如果发现类似“用户alice成功调用了org.freedesktop.udisks2.modify-device（修改设备）而未触发认证”的记录，这就是一个极其强烈的红色警报。因为CVE-2025-6019的核心，正是利用libblockdev漏洞，通过udisks2接口绕过polkit认证，执行特权设备操作。

一个具体的排查命令

sudo journalctl _SYSTEMD_UNIT=polkit.service | grep -E "(org.freedesktop.udisks2|allow_active)" | tail -50

这条命令能帮你聚焦于polkit服务处理的、与udisks2或“allow_active”状态相关的最近事件。如果看到非root、非特权用户成功执行了相关操作，基本可以断定漏洞已被利用。

检查“犯罪现场”：PAM配置与进程内存

CVE-2025-6018为攻击开了第一道门，它让远程SSH用户错误地获得了本应属于本地控制台用户的“allow_active”状态。虽然直接修改/etc/pam.d/sshd等配置文件的可能性不大（动静太明显），但攻击者可能在漏洞利用的短暂窗口期，通过环境变量等方式影响了PAM模块的行为。

更隐蔽的检查，是查看SSH守护进程（sshd）及其子进程的内存或环境。这有点技术性，但你可以检查当前活跃的SSH会话进程的环境变量：

ps e -o pid,cmd -C sshd | grep -v "^.*sshd:.*@notty" | head -20

观察输出中是否有异常的环境变量设置，特别是与PAM或会话状态相关的。不过说实话，高手在利用后可能会清除痕迹，这招更像是在对方还没来得及打扫现场时才有用。

寻找“后门”：被篡改的信任关系与定时任务

攻击者一旦拿到root，通常不会只满足于一次性的访问。他们的目标是持久化。因此，检查重点应从“攻击过程”转移到“攻击结果”上。

1. SSH授权密钥（authorized_keys）：立刻检查/root/.ssh/authorized_keys以及所有具有SSH登录权限的用户目录下的同名文件。攻击者很可能在此添加了自己的公钥，这是最经典、最便捷的后门。
2. sudoers配置：运行sudo cat /etc/sudoers.d/*，查看是否有新增的、授予普通用户过高或不合理sudo权限的文件。
3. 系统服务与定时任务：检查是否有陌生的系统服务被创建（systemctl list-unit-files --type=service），或者查看/etc/cron.d/、/var/spool/cron/crontabs/目录下是否有可疑的定时任务。攻击者可能借此维持访问或执行后续指令。
4. 可疑进程与网络连接：使用netstat -tunlp或ss -tunlp查看异常的网络监听端口。结合top或ps auxf查看消耗资源异常或父进程可疑的进程。

主动验证：在测试环境重现攻击链

如果你管理的服务器集群中有一台疑似中招，而其他机器配置相同且尚未打补丁，那么在隔离的测试环境进行可控的漏洞验证，是最高效的判断方法。这不是让你去攻击生产服务器，而是在一个镜像环境里，使用公开的PoC概念验证代码（务必从如Qualys官方公告等可信来源获取），尝试复现攻击链。

如果能成功从一个普通SSH用户提升到root，并且产生的日志特征、polkit行为与你怀疑的那台生产服务器历史上的某些日志片段吻合，那么几乎可以坐实入侵判断。这相当于在实验室里匹配上了犯罪现场的指纹。

说到底，面对这类利用系统原生服务漏洞的高级攻击，事后检测总是被动的，且充满不确定性。日志可能被清理，文件时间戳可以被修改。最有力的“判断”，其实发生在漏洞披露的那一刻——立即评估自身风险，并抢在攻击者前面，把补丁打好，把配置调严。如果怀疑已经失陷，在保留必要证据（如内存镜像、原始日志）后，最彻底的做法往往是构建一个干净的基础镜像，从可信的备份中恢复数据。毕竟，在已被root掌控的系统里，你看到的“正常”，可能就是攻击者想让你看到的全部。