web-dev-qa-db-ja.com

xmlrpc.php POSTリクエストをブロックする方法

今日、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 例）

  • ですから、CPUスパイクが同時に見られない場合でも、これらのxmlrpc攻撃がディスクスループットのスパイクの原因になる可能性はあるのでしょうか。
  • ログには、これらのリクエストがブロックされている（403）ことが示されているので、Apacheサーバーがダウンするのはなぜですか？
  • 今後再発しないようにするにはどうすればよいですか？サーバーにfail2banがインストールされていますが、xmlrpcの特別な構成が必要な場合があります（サーバー管理についてはまだ初心者です）。
xmlrpc
2
Sulli

WordPressでは、xmlrpc.phpは、たとえば、 WordPressモバイルアプリを使用して、ウェブサイトと通信し、特定のアクションを実行します。ただし、デザインが悪いため、攻撃者は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を使用して、カーネルレベルでこのようなリクエストを送信する攻撃者をブロックする（fail2banによって制御されるiptablesを使用）と、さらに効率的ですが、そのような攻撃者のほとんどは、複数のIPアドレスを破棄すると、新しいIPがブロックされる前に何度も試行を試みるために、攻撃元が1つのIPから別のIPに移動し始めるのがわかります。 Apacheレベルのブロックは、xmlrpc.phpのallリクエストが確実にブロックされるようにします。

観察しているディスクスループットの急上昇は、これらすべての拒否のすべてのログメッセージを書き込むことから本質的にすべてである可能性があります。

私も同じような問題を抱えていましたが、顧客の不満はまずApacheがトラフィックを制限していたことでした。 Apacheのリソース制限が調整されたとき、膨大な量のリクエストが原因でWordPressのデータベースがクラッシュし始めました（かなり低スペックのシステムに配置されていました）。ソースIPをブロックすると、ソースが別のIPに移動し、数時間後にフラッディングが再開されます。 Apacheのレベルでxmlrpc.phpをブロックすることは簡単な修正でしたが、しばらくして攻撃者は彼らの努力が無駄であり、試行を中止したことに気づきました。しかし、常に他の人がいます...

4
telcoM