云服务器权限被篡改如何修复?

上个月，一个做在线教育的创业团队找到我，他们的技术负责人小林在电话里急得快哭了。事情是这样的，他们公司的云服务器突然所有人都登录不上了，包括用最高权限的root账号也提示认证失败。更麻烦的是，他们的自动备份脚本也因为这个权限问题没能按时运行，将近两天的新用户数据悬在半空，取不出来也写不进去。我问小林最近有没有人动过服务器的配置，他说前几天有个运维同事离职，交接的时候可能有些账号权限没处理干净。我说你先别急，这种情况我见过不少，权限被篡改虽然听起来吓人，但只要按步骤来，基本都能找回来。

云服务器权限被篡改，说白了就是有人或者某个程序，把系统里原本设定好的访问规则给改了。改的方式有很多种，可能是有人直接用root权限执行了修改用户ID的命令，把你的管理员账号降成了普通用户，也可能是某个漏洞被利用后，攻击者在系统里新建了一个高权限账号，然后把原来的管理员账号锁掉，还有可能是配置文件被篡改，比如认证模块的关键文件被人动了手脚，导致所有用户都无法通过验证。不管是哪种情况，最终表现都差不多，你进不去系统了，或者进去之后发现很多命令执行不了，权限不够。

遇到这种情况，第一件事不是慌，而是先判断一下问题到底出在哪个层面。是小林遇到的那种所有账号都登录不了，还是说有些账号能登录但是权限变低了，又或者是某些特定的操作比如修改文件、重启服务被提示权限不足。不同的表现指向不同的问题根源，修复的方法也不一样。

我让小林的团队先做一件事，不要反复尝试登录失败的账号，因为有些安全机制会在多次失败后自动封锁IP。正确的做法是通过云服务商提供的管理控制台，也就是那个网页后台，找到“管理终端”或者“VNC登录”的功能。这个方式的好处是，它绕过操作系统本身的登录认证，直接给你一个类似插了显示器键盘鼠标的物理访问界面。不管你系统里的用户权限被改得多乱，只要云主机还跑着，你就能从这个后门进去。

小林按照我说的，用管理终端成功连上了服务器。进去之后第一眼看到的就是一堆报错，提示找不到某些命令的执行路径。他试着输入几个基本命令，发现大部分都能用，但用sudo提权的时候提示用户不在sudoers文件里。这就说明问题了，root账号本身应该没被禁用，但是当前登录的这个普通用户被剥夺了执行管理员命令的权限。

接下来就是正式的修复过程，分几个步骤详细说。

第一步是确认当前系统的身份状态。在管理终端里，用能登录的那个账号进去之后，先看看当前用户是谁，再看看系统里还有哪些用户。查看用户列表的文件，这个文件记录了系统里所有账号的基本信息。一般来说，正常的系统里会有一个用户ID为零的账号，那就是最高权限的管理员账号。如果你发现原来的root账号的用户ID被改成了非零的数字，或者原本应该存在的一些系统账号丢失了，那就是被篡改过的。还有一种情况是出现了陌生的用户，尤其是用户ID也是零的，那就意味着有人新建了一个和你平起平坐的账号，甚至把你原来的账号踢掉了。

第二步是进入单用户模式或者救援模式来修复权限。这个听起来有点技术味，但实际操作并不复杂。在管理终端里重启云服务器，在启动过程中按特定的键进入引导菜单，然后选择带有救援模式或者单用户模式的内核启动。在这个模式下，系统只会加载最基本的内核和文件系统，不会启动那些乱七八糟的服务，也不会执行任何用户自定义的脚本。这时候你就是系统里唯一的王，可以大胆地去修改那些被篡改的配置文件。

具体要改哪些文件，我一个个说清楚。第一个是用户账户文件，这个文件里每一行对应一个用户，冒号分隔的几个字段里，第三个数字就是用户ID。你把应该拥有管理员权限的那个账号的第三个数字改成零，这样它就重新获得了最高权限。有时候攻击者不仅改了ID，还把用户的家目录或者登录Shell也改了，所以顺便检查一下这些字段是否正常。第二个是密码文件，但这个文件现在很多系统已经不直接存密码了，而是用影子文件来管理。如果你发现能登录但是密码不对，可以用命令强制重置密码。第三个是权限委派文件，这个文件定义了哪些用户可以用sudo命令提权。如果这个文件被清空或者被改坏了，那就算是root账号也可能无法正常使用sudo。你需要在里面加上一行，意思就是允许管理员组的所有成员执行任何命令。第四个是认证模块的配置文件目录，如果攻击者动了里面的PAM模块配置，可能会导致所有登录方式都被拒绝。检查一下这些文件是否被修改过，拿不准的话可以从同版本的健康系统里复制一份过来。

小林按照这个步骤检查下来，发现问题出在两个方面。一个是那个离职的运维同事，在离职前执行了一个脚本，脚本里有一条命令把除了他自己之外的几乎所有用户都从管理员组里移除了。另一个问题是，那个同事不知道什么时候修改了sudoers文件，加了一行限制，导致只有特定时间才能执行管理员命令。这两个问题叠加在一起，就造成了所有人都无法正常管理服务器的局面。

第三步是修复完成后的验证。把前面说的那些文件都改好之后，重启系统，正常登录试试。先用改回权限的那个管理员账号登录，然后用命令确认一下当前用户的ID是否为零。再试试执行几个只有管理员才能做的操作，比如查看系统日志、修改网络配置，看看会不会被提示权限不足。另外还要用其他普通用户的账号登录，确认他们没有意外获得管理员权限，这是防止修复过程中矫枉过正，把不该给权限的人也提上去了。

第四步是排查权限被篡改的根本原因。这一步很多人会跳过，觉得系统已经能用了就算完事了。但其实不查清楚漏洞在哪里，同样的攻击很快会再来。你需要翻看系统的认证日志和安全日志，看看在权限被篡改的时间点前后，有哪些人登录过，登录的IP来自哪里，执行了哪些命令。如果发现登录IP是一个你不认识的地址，那可能是密码泄露或者存在弱口令。如果登录IP是你们公司自己的出口IP，那就要查查是哪个内部人员操作的，是不是存在误操作或者恶意行为。还有一种情况是没有发现任何异常登录记录，那就要考虑是不是某个应用漏洞被利用了，攻击者通过WebShell或者SQL注入拿到了权限，然后从内部修改了配置。这种情况下，光修复权限是不够的，还得把应用层的漏洞堵上。

我记得去年帮一个做游戏的公司处理过类似的问题。他们的云服务器权限被篡改，原因是他们在服务器上跑了一个第三方提供的管理面板，这个面板有一个内置的后门账号，账号密码被写死在代码里。攻击者扫描到了这个面板的开放端口，用默认密码登录进去，然后通过面板的操作界面直接修改了系统用户权限。那一次修复起来更麻烦，因为攻击者不仅改了权限，还删掉了系统的关键日志文件，让你查不出是谁干的。最后我们的方案是，把业务数据迁移出来，彻底销毁那台云主机，重新创建一台干净的系统，然后换了一个开源的、有社区维护的管理面板。

修复完权限之后，还有几件事一定要做，不然就是给下一次入侵留后门。首先是把所有用户的密码都强制重置一遍，尤其是那些拥有管理员权限的账号。不要只是改密码，还要检查每个账号的SSH公钥，看有没有被添加陌生的公钥，有的话删掉。其次是检查定时任务，看有没有设置周期执行的反弹Shell或者其他可疑的命令。然后是检查开机启动项，确保没有恶意脚本在系统启动时自动运行。最后是审查对外开放的服务端口，把那些不需要的端口关掉，比如远程管理端口如果不是必须对公网开放，就改成只允许公司办公网络的IP访问。

我还想特别提一下关于云平台提供的“操作审计”功能。大部分云服务商都有这个功能，它会记录下谁在什么时候对云服务器做了哪些操作，包括重启、改配置、登录终端等等。如果你在修复过程中发现系统里的日志被删了，可以去云平台的审计日志里找线索，那里的日志是存在云服务商那边的，攻击者删不掉。这个功能平时可能不太注意，但真出事了它就是破案的关键。

说回小林的案例，他们最终用了大概三个小时把所有权限问题修复好，业务恢复正常。但让我印象深刻的是，他们之后做了一系列改变。他们把服务器的权限管理从原来几个人共用一个root账号，改成了每个人独立的账号，并且只给每个人最低需要的权限，谁要执行管理员操作必须通过一个专门的审批流程。他们还把云平台的操作审计日志接入了公司的告警系统，一旦有敏感操作就实时通知所有人。小林跟我说，那次事故之后，他养成了一个习惯，每周都会登录服务器看一眼关键配置文件的最后修改时间，确认没有意外的改动。

写到这儿，我想总结一下云服务器权限被篡改后的修复要点。第一，不要慌，通过云平台的管理终端或者VNC登录，绕过系统本身的认证直接进入操作界面。第二，重点检查几个关键文件和目录，确认用户ID、密码配置、权限委派配置、认证模块配置是否被篡改。第三，修复完成后一定要验证，不仅要确认管理员能正常工作，还要确认普通用户没有越权。第四，花时间查清楚权限是怎么被改的，是密码泄露、内部误操作还是应用漏洞，查到根源才能彻底堵住。第五，修复之后要做全面的安全加固，包括改密码、清公钥、查定时任务、关多余端口。最后，如果发现篡改程度很深，比如系统文件大面积被替换、内核被植入后门，别犹豫，直接重装系统恢复数据，这是最干净最彻底的办法。

权限是服务器的命门，就像房子的门锁一样。门锁被人换了，你不能只把钥匙找回来就完事，得检查整个门框有没有被撬过，窗户有没有被打开过，甚至要考虑换一把更结实的锁。