我注意到我的 Apache 服务器今天宕机了,进入我的托管仪表板后,我看到磁盘吞吐量和 IOPS 激增。同时,我的日志中充满了以下几行:
108.162.215.47 - - [03/Feb/2019:06:25:01 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
108.162.215.47 - - [03/Feb/2019:06:25:02 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
108.162.215.47 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
172.69.33.204 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 2471 "-" "python-requests/2.21.0"
xmlrpc.php 是 Wordpress 用于与远程服务器通信的文件。众所周知,它是许多攻击的源头,通常建议阻止对它的访问(请参阅https://www.hostinger.com/tutorials/xmlrpc-wordpress例如)
- 所以我是否正确,这些 xmlrpc 攻击可能是导致磁盘吞吐量激增的原因,即使我没有同时看到任何 CPU 激增?
- 日志显示这些请求已被阻止(403),那么为什么我的 apache 服务器会宕机?
- 我该怎么做才能避免这种情况再次发生?我的服务器上安装了 fail2ban,但可能需要对 xmlrpc 进行特殊配置(在服务器管理方面我还是个菜鸟)
答案1
在 WordPress 中,xmlrpc.php
这是一个 API,例如 WordPress 移动应用可以使用它与网站通信并执行某些操作。然而,它的不良设计也让攻击者可以有效地尝试暴力破解 WordPress 管理员密码,并且如果您的网站允许评论和/或 pingback,还可以向您的网站添加评论/pingback 垃圾邮件。
如果您不使用 WordPress 移动应用程序或 pingback 功能,您可能需要完全禁用xmlrpc.php
。
但是,仅在 WordPress 级别禁用它可能还不够:由于垃圾邮件发送者/攻击者通常会生成大量请求,即使 WordPress 只是拒绝请求,将它们一路通过 Apache 和 PHP 解释器传递到实际的 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 级别进行阻止是简单的解决方法,一段时间后,攻击者发现他们的努力毫无结果,并停止了尝试。但总会有其他人……