经过数月的忽视、电子邮件争执和管理斗争，我们当前的系统管理员被解雇了，并将“服务器凭据”交给了我。这些凭据仅包含一个 root 密码，没有其他内容：没有程序、没有文档、没有提示，什么都没有。
我的问题是：假设他留下了陷阱，我该如何在尽可能少的停机时间内优雅地接管服务器？
以下是详细信息：
- 一台位于地下室服务器场的生产服务器；可能为 ubuntu server 9.x，带有 grsec 补丁（这是我上次问管理员时听到的传言）
- 一个包含所有内部文档、文件存储库、wiki 等的内部服务器。同样，ubuntu 服务器，已经有几年历史了。
假设两台服务器都已修补并且是最新版本，所以除非有充分的理由（即可以向高层管理人员解释），否则我宁愿不尝试以黑客方式入侵。
生产服务器托管了几个网站（标准 apache-php-mysql）、一个 LDAP 服务器、一个 ZIMBRA 电子邮件套件/服务器，据我所知，还运行了几个 vmware 工作站。不知道那里发生了什么。可能其中一个是 LDAP 主服务器，但这只是猜测。
内部服务器有一个内部 wiki/cms、一个从生产服务器复制凭据的 LDAP 从属服务器、一些 vmware 工作站和正在运行的备份。
我可以去找服务器群的管理员，指着服务器，告诉他们“sudo请关闭该服务器”，以单用户模式登录，然后按照我的方式操作。内部服务器也一样。不过，这意味着停机、高层管理不力、老系统管理员反驳我说“看到了吗？你不能做我的工作”和其他麻烦，最重要的是，我可能会失去几周的无薪时间。
另一方面，我只需以 root 身份登录并浏览服务器，尝试了解正在发生的事情。这样可以避免引发意外的所有风险。
我正在寻找一个折中的解决办法：尽量保持一切正常运转，同时了解正在发生的事情和发生的方式，最重要的是避免触发任何遗留的陷阱。
你有什么建议？
到目前为止，我考虑过使用内部服务器进行“练习”，断开网络，使用实时 CD 重新启动，将根文件系统转储到 USB 驱动器，并将其加载到断开连接的隔离虚拟机上，以了解以前的系统管理员思维方式（“了解你的敌人”）。可以使用生产服务器完成同样的操作，但完全转储会引起注意。也许我可以以 root 身份登录，检查 crontab，检查 .profile 中是否有任何已启动的命令，转储 lastlog，以及任何我能想到的操作。
这就是我来这里的原因。任何提示，无论多小，都会非常感激。
时间也是一个问题：触发事件可能在几小时或几周后发生。感觉就像是好莱坞的烂片，不是吗？
答案1
正如其他人所说，这看起来是一种松散的局面。
（从结尾开始）
- 全新部署
当然，您不能只是关闭服务器并让安装程序发挥它的魔力。
总体流程
- 获取备份服务器的预算（备份作为数据的存储）
- 创建数据快照，并在执行之前将其放置在那里任何事物
- 获得管理层的签字！
- 收集需求列表（是否需要 wiki、谁在使用 VMWare 实例，...）
- 来自管理层和
- 来自用户
- 获得管理层的签字！
- 关闭未列出的服务一周（一个服务一次 - 如果您只想关闭外部服务，但怀疑它仍可能在同一主机上的应用程序中使用，则 iptables 可能是您的朋友）
- 没有反应？-> 最终备份，从服务器中删除
- 反应？-> 与服务用户交谈
- 收集新需求和获得管理层的批准！
- 所有未列出的服务都停机一个月了，没有任何反应？->
rm -rf $service（听起来有些刺耳，但我的意思是停止这项服务） - 获取备用服务器的预算
- 每次将一个服务迁移到备用服务
- 获得管理层的签字！
- 关闭迁移的服务器（断电）
- 发现更多人向你尖叫 -> 耶，你刚刚找到了剩菜
- 收集新需求
- 重新启动并迁移服务
- 重复最后 4 个步骤，直到一个月内没有人来找你
- 重新部署服务器（并获得管理层批准！）
- 冲洗并重复整个过程。
- 重新部署的服务器是你的新备用服务器
你得到了什么？
- 所有服务的清单（为您和管理层）
- 文档（毕竟你需要为管理层写下一些东西，为什么不好好做一下并为你和管理层做点什么呢）
我曾经经历过那样的事情，那根本就没什么乐趣 :(
为什么你需要得到它经管理层签字？
- 让问题显而易见
- 确保你不会被解雇
- 解释风险的机会
- 如果他们不想让你做这件事也没关系，但毕竟这是他们在获得足够的意见来判断投资是否值得后做出的决定。
哦，还要向他们介绍总体计划在你开始之前，对最坏和最好情况下会发生的情况进行了一些估计。
它将要如果没有文档，无论是否重新部署都会花费大量时间。没有必要考虑后门，恕我直言，如果您没有文档，滚动迁移是达到可以为公司带来价值的理智状态的唯一方法。
答案2
您是否有理由相信前任政府留下了一些不好的东西，还是您只是看了很多电影？
我并不是想开玩笑，我只是想知道你认为存在什么样的威胁以及这种威胁有多大的可能性。如果你认为某种严重破坏性问题确实存在的可能性非常高，那么我建议你处理它就像是一次成功的网络入侵。
无论如何，在您处理这个问题时，您的老板都不希望出现停机中断的情况——如果系统出现故障（无论是真正的故障还是流氓管理员），他们对整理系统的计划停机和计划外停机的态度如何？以及他们的态度是否现实，以及您对此处确实出现问题的可能性的评估如何。
无论您做什么，请考虑以下事项：
拍摄系统 r 的图像现在就好。在做其他任何事情之前。事实上，拿走两个，把一个放在一边，不要再碰它，直到你知道你的系统发生了什么，如果有的话，这是你接管系统时的记录。
将“第二”组映像恢复到某些虚拟机，并使用这些映像来探测正在发生的事情。如果您担心在某个日期之后触发某些事件，那么请在虚拟机中将日期向前设置一年左右。
答案3
首先，如果你要花额外的时间在这上面，我建议你得到报酬对此表示赞同。从你的话来看，似乎你已经接受了无偿加班的事实 - 我认为不应该这样，尤其是当你因为别人的过错而陷入困境时（可能是管理层、老系统管理员或两者兼而有之）。
关闭服务器并启动到单用户模式（init=/bin/sh 或 grub 中的 1）以检查以 root 登录运行的命令。此时停机是必要的，向管理层明确表示，如果他们想确保能够保留数据，那么除了停机之外别无选择。
之后检查所有 cronjobs，即使它们看起来合法。还要尽快执行完整备份 - 即使这意味着停机。如果需要，您可以将完整备份转换为正在运行的虚拟机。
然后，如果您能获得新的服务器或功能强大的虚拟机，我实际上会逐个将服务迁移到新的干净环境中。您可以分几个阶段进行此操作，以最大限度地减少可察觉的停机时间。您将获得对服务非常必要的深入了解，同时恢复对基础系统的信心。
与此同时，你可以使用以下工具检查 rootkitchkroot工具。 跑步涅瑟斯在服务器上寻找旧管理员可能利用的安全漏洞。
编辑：我想我没有尽可能好地回答你问题的“优雅”部分。第一步（进入单用户模式检查登录陷阱）可能可以跳过 - 旧的系统管理员给你 root 密码并设置登录来执行的操作与自己rm -rf /删除所有文件几乎相同，因此这样做可能毫无意义。对于备份部分：尝试使用rsync基于解决方案，这样你就可以在线完成大部分初始备份并最大限度地减少停机时间。
答案4
您对安全问题有点儿过于偏执了。其实没必要这么偏执。（因为您说的是陷阱）。查看已安装的软件列表。查看正在运行的服务（netstat、ps 等），查看 cron 作业。禁用以前的系统管理员用户帐户而不删除该帐户（只需将 shell 指向 nologin 即可轻松完成）。查看日志文件。我认为通过这些步骤，以及您对公司需求的了解（您可以猜测服务器的用途），我认为您应该能够维护它们而不会出现任何重大失误。