如何阻止 xmlrpc.php POST 请求

Question

我注意到我的 apache 服务器今天宕机了，在我的托管仪表板中，我\xc2\xa0 看到磁盘吞吐量和 IOPS 出现峰值。与此同时，我的日志中充满了这些行：

\n\n

108.162.215.47 - - [03/Feb/2019:06:25:01 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"\n108.162.215.47 - - [03/Feb/2019:06:25:02 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"\n108.162.215.47 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"\n172.69.33.204 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 2471 "-" "python-requests/2.21.0"\n

\n\n

xmlrpc.php 是 Wordpress 用于与远程服务器通信的文件。众所周知，它是许多攻击的来源，通常建议阻止对其的访问（例如，请参阅https://www.hostinger.com/tutorials/xmlrpc-wordpress ）

\n\n

\n
• 那么，即使我没有同时看到任何 CPU 峰值，这些 xmlrpc 攻击也可能是磁盘吞吐量峰值的原因，我对吗？
\n
• 日志显示这些请求已被阻止（403），那么为什么我的 apache 服务器会宕机呢？
\n
• 我应该怎么做\xc2\xa0才能避免这种情况再次发生？\xc2\xa0我在我的服务器上安装了fail2ban，但也许我需要对xmlrpc进行特殊配置（我仍然是服务器管理方面的菜鸟）
\n

\n

Answer 1

在 WordPress 中，xmlrpc.php是一个 API，例如 WordPress 移动应用程序可以使用该 API 来与网站进行通信并执行某些操作。然而，其糟糕的设计也让攻击者可以有效地尝试暴力破解 WordPress 管理员密码，并且如果您的网站允许评论和/或 pingback，则可以向您的网站添加评论/pingback 垃圾邮件。

如果您不使用 WordPress 移动应用程序或 pingback 功能，您可能需要完全禁用xmlrpc.php.

然而，仅仅在 WordPress 级别禁用它可能还不够：由于垃圾邮件发送者/攻击者通常会生成大量请求，因此通过 Apache 和 PHP 解释器将它们一路向上传递到实际的 WordPress 代码可能需要大量负载，甚至如果 WordPress 只是拒绝该请求。因此，您需要尽早执行拒绝。

在 Apache 中拒绝它是编译后的高度优化的 C 代码中的简单字符串匹配操作，该操作非常高效。在 WordPress 级别进行拒绝涉及 PHP 解释器，也可能涉及 WordPress 的数据库，这使得拒绝操作在所需的 CPU 功率方面成本更高。

在 Apache 2.2（或启用了旧访问控制语法模块的 2.4）的配置中，您可以通过向<VirtualHost>站点块中添加如下块来实现：

<files xmlrpc.php>
  order allow,deny
  deny from all
</files>

使用 Apache 2.4 更新的访问控制语法，它将是：

<files xmlrpc.php>
    Require all denied
</files>

使用fail2ban在内核级别阻止攻击者发送此类请求（使用iptables由 控制fail2ban）会更加有效，但由于大多数此类攻击者可以使用多个 IP 地址，因此您可能会看到攻击源开始从一个 IP 转移到一个 IP 地址。另一个是为了在每个新 IP 被阻止之前进行多次尝试。Apache 级别的阻止将确保所有请求都xmlrpc.php将被阻止。

您观察到的磁盘吞吐量峰值可能基本上全部来自写入所有这些拒绝的所有日志消息。

我曾经遇到过类似的问题，然后客户首先抱怨 Apache 限制流量：由于垃圾邮件发送者的所有尝试，合法流量被推到一边。当 Apache 的资源限制被调整时，WordPress 的数据库由于请求量巨大而开始崩溃（它位于一个相当低规格的系统上）。阻止源 IP 只会导致源转移到另一个 IP，并在几个小时后恢复泛洪。xmlrpc.php在 Apache 级别进行阻止是很容易解决的问题，不久之后，攻击者发现他们的努力毫无结果，并停止了尝试。但总会有其他人...