被入侵的 DigitalOcean Droplet，进行 DDoS 攻击，调查原因的正确过程是什么？

Question

DigitalOcean 今天通知我，我在那里的 Droplet 已断开连接，因为它正在进行 DDoS 攻击。

他们让我调查并找出导致它的原因。

这是 Ubuntu 14，我在那里有 6 个 Apache VirtualHosts。所有人都活着。

我的一个站点是带有几个插件的 WordPress 安装。

另一个站点中有一些 Google Maps API 代码。

其余的只有我的原始代码。

我还没有进入服务器。一旦我这样做了，正确找到导致这种情况的软件的过程是什么？

我怀疑这是因为我的密码没有使用 SSH 密钥。

Answer 1

首先，我对不得不处理这样的事情表示哀悼。但是你可以清理它。首先，我只需要解决这个问题：

我怀疑这是因为我的密码没有使用 SSH 密钥。

99% 的人肯定不是这样。在我 20 多年的经验中，我亲自处理和清理的几乎所有 Web 服务器危害都来自应用程序级别的缺陷，而不是任何与 SSH 或 SFTP 相关的问题。事实上，大多数 Web 开发人员/管理员永远不会处理 SSH/SFTP 级别的妥协；前端代码中的缺陷是许多恶意软件和对公共网络系统无端入侵的主要入口点。

在您的情况下，您声明以下内容：

这是 Ubuntu 14，我在那里有 6 个 Apache VirtualHosts。所有人都活着。

我的一个站点是带有几个插件的 WordPress 安装。

另一个站点中有一些 Google Maps API 代码。

我的猜测是——除非你保持最新的 WordPress 更新/补丁——你的 WordPress 安装很容易受到攻击。不仅是核心 WordPress，还有插件。

备份现有的代码库、数据库和配置。

我要做的第一件事就是index.php在这些站点的每个根索引中设置一个表示“停机维护”的 Apache 虚拟主机。我还会通过 TAR/Gzip 存档制作每个虚拟主机安装的副本，并下载以进行潜在的取证。这应该为所有 Apache 虚拟服务器完成，包括 MySQL 数据库的转储以及相关的配置文件。

检查/tmp/目录是否有任何感染迹象；如果需要的话，把它吹走。

我建议您做的下一件事是转储并/tmp/在服务器上重新创建目录。原因是 Linux 网络服务器上的许多恶意软件感染将大量有效负载放在/tmp/目录中。我在这里更深入地研究这个答案，但归结为执行以下操作。

所以首先，查看/tmp/目录，看看那里有什么不应该在那里的东西。Linux 系统上 10 个恶意软件中有 9 个能够将自己安装在/tmp/.

如果您不确定里面应该/不应该/tmp/有什么，那么您可以做一件简单但极端的事情来清除坏的东西。只需在命令行中在线运行它：

rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp

或者像这样单独运行每个命令：

sudo rm -rf /tmp 
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp

然后重新启动服务器以查看是否可以解决问题。如果是，恭喜！但是您还没有摆脱困境，因为无论导致原始系统的原因仍然可以渗透您的系统，它们再次感染您只是时间问题。这意味着，这可以清理由系统弱点造成的混乱，但您需要找出该弱点可能是什么并对其进行加固。

Bash“shellshock”漏洞检查。

在另一个答案中，我提供了有关如何检查bash“shellshock”漏洞的提示。该站点提供了很好的测试工具来查看您的服务器是否容易受到bash“shellshock”攻击。老实说，这是自发现以来我不得不修补的最常见的安全漏洞之一。所以很有可能这也可能是服务器上的一个弱点。至于如何修复bash发现的漏洞，请参阅下面关于如何升级/修补所有操作系统级组件的部分。这样做，也bash应该升级/修补。

升级/修补所有操作系统级别的组件。

现在这听起来可能令人生畏，但现实是 Linux 系统一直在发布安全补丁。如果您使用的是像 Ubuntu 或 CentOS 这样的标准化 Linux 安装，那么您可以像这样通过您的软件包安装程序简单地运行更新/升级。在 Ubuntu 上，只需执行以下操作：

sudo apt-get update

sudo apt-get upgrade

现在，如果您有一段时间没有更新系统，您可能会看到大量需要处理的补丁和更新。不要惊慌！这是正常的。只要运行update和upgrade等待。之后可能必须重新启动，但完成后，您的核心操作系统应该已完全打好补丁并保持最新状态。

评估 Apache 虚拟服务器代码系统的代码库；WordPress 和 Google API 的东西。

振作起来：这是更丑陋的部分。您应该下载并评估可能被感染的代码库。希望只有一两个站点受到损害。如何解决每个设置的特殊性，但通常你应该做的是将每个站点加载到开发环境中，升级 WordPress 核心，升级插件，检查是否一切正常，然后认为代码干净/稳定的。

现在我已经大大简化了这一步。但现实情况是，即使在进行补丁和升级之后，您的 WordPress 核心中仍然可能存在恶意软件代码。因此，您可以做的另一件事是从头开始重建每个 WordPress 站点。保留数据库、模板并基本上从一个新的、干净的 WordPress 核心重建站点。

是的，这听起来像很多工作，但是如果您有那么多具有不同代码库的虚拟服务器，则别无选择。

验尸建议。

这并不适用于所有人，但我会这样说：备份甚至可能是干净代码库的 GitHub 存储库是清理混乱的方法，而无需我上面提到的最后一个混乱的“评估”步骤。

我所做的是在我工作的任何数据库驱动站点上运行常规 MySQL 转储，并确保 GitHub 中有一个干净的核心代码库。然后，如果发生恶意软件感染，我可以挖掘 MySQL 备份，甚至从 GitHub 重新部署干净的代码，以确保代码库是干净的。如果服务器本身只是过去的信念？好吧，只需转储受感染的系统，重建一个新的 Linux 系统，部署代码，导入数据库，调整配置并收工。

请记住，99% 的网站只是一个数据库、代码库和一组配置。如果您有一些干净的方法来“冻结”或备份未受感染的代码和 MySQL 数据库的备份，那么您所要做的就是处理配置内容。与从头开始清理代码相比，这是一个小痛苦。