いつも通り自分のサイトにアクセスしようとしたら、できませんでした。
調べた結果、
wordpressのxmlrpc.phpに対してブルートフォースアタックを仕掛けられて、
サーバーのメモリを全部消費して、動けなくなっていました。
ネットで調べてみるとここ半年くらいの間に発生しているクラック攻撃らしいです。
今までだとサーバーを再起動させれば、
クラック攻撃も収まり、普通に動くようになったんですが、
今回の攻撃野郎は、サーバーを再起動させた後もしつこく攻撃を続けてきました。
ということで本格的に対策を取る事にしました。
Apacheのアクセスログ
80.82.78.166 - - [07/Oct/2014:13:51:22 +0900] "POST /xmlrpc.php HTTP/1.0" 200 698 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 80.82.78.166 - - [07/Oct/2014:13:51:22 +0900] "POST /xmlrpc.php HTTP/1.0" 200 698 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 80.82.78.166 - - [07/Oct/2014:13:51:23 +0900] "POST /xmlrpc.php HTTP/1.0" 200 698 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 80.82.78.166 - - [07/Oct/2
IP調べたらオランダ(Ecatel LTD)からの攻撃でした。
xmlrpc.phpに対して何をポストしているのかわかりませんが、
数時間にわたって1秒2回ほどポストし続けてくれやがります。
おそらく無理矢理ログインしようとしてきているのか、pingbackで他のサイトを攻撃しようとしているのかのどちらかだと思われます。
その結果、私のサーバーのapacheのプロセス数が増加してメモリ不足に陥りました。
Out of memory: kill process 2615 (apache2) score 56222 or a child Killed process 2738 (apache2)
ひたすらapacheのプロセスをkillしていきますが、
メモリ不足でにっちもさっちもいかなくなっていました。
apacheのプロセス数を制限する
まず最初に、apacheのプロセス数の増加でメモリ不足になるという問題を解消します。
apacheの現在の設定
<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 15 MaxSpareServers 20 MaxClients 100 MaxRequestsPerChild 1000 </IfModule>
MaxClients(プロセス数)を100にしていますが、
1つあたりメモリを2%?くらい食っているらしく、
100個も動かせませんでした。
この数を40個に制限する事で、
apacheのプロセス数を制限してメモリ不足になるのを回避します。
<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 15 MaxSpareServers 20 MaxClients 40 MaxRequestsPerChild 0 </IfModule>
ついでにMaxRequestsPerChildの数をゼロにしておきました。ゼロにするとクライアントのプロセスが終わるまでリクエストを受け付けるようになります。今まではプロセスごとに1000リクエストに制限していました。
これでwordpressのxmlrpc.phpにブルートフォースアタックをかけられても、
メモリ不足にならずにサーバーを動かす事が出来ます。
xmlrpc.phpを制限する
apacheの設定を変える事で、ブルートフォースアタック中でもサイトのほうアクセスする事が出来るようになりました。
でも、肝心のブルートフォースアタック自体を防いでいないし、
サーバー自体にある程度の負荷がかけられた状態になっています。
ここでxmlrpc.phpを制限してブルートフォースアタックをさばきます。
xmlrpc.phpの名前を変える/削除する/パーミッションを変える
もっとも単純な方法は、xmlrpc.phpを削除してしまう事です。
そもそもxmlrpc.phpはアプリ経由で投稿したりするためのものです。
そんなの使わないから削除してしまえば良いのです!
と思ったのですが、wordpressをアップデートした際に不具合が生じるかもしれません。
xmlrpc.phpがアップデートするごとに復活するかもしれないし、アップデートの時にエラーなんかが出てくるかもしれません。
ということで、直接xmlrpc.phpを削除、名前の変更、ペーミッションの変更はお勧めできません。
.htaccessで制限する
xmlrpc.php自体を変更するのは危険だと思われるので、.htaccessでxmlrpc.phpへのアクセスを制限します。
もっとも適切なのが.htaccessに下記を追加する事です。
RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]
xmlrpc.phpファイルがあるフォルダと同じ場所
.htaccess
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule>
上記を設定して自分のサイトのxmlrpc.phpにアクセスすると、
http://0.0.0.0/に飛ばされるようになります。
ネット界隈ではこの方法が一番いい方法らしいです。
他に単純にアクセス拒否する方法があります。
.htaccess
<Files xmlrpc.php> Order allow,deny Deny from all </Files>
ただし単純にアクセスを拒否してしまうと、サーバーへの負荷が高まったままになるそうです。
攻撃者がアクセス拒否であきらめてくれると良いのですが、
しつこいやつの場合、サーバーの高負荷状態が続くそうです。
※別情報によるとアクセス拒否にしてもサーバーへの負荷は少なくできるらしいです。
その他の方法
他にもDisable XML-RPC Pingbackというプラグインがありますが、
これはGETにしか対応していなく、今回のようにPOSTで攻撃されると効果がありません。
functions.phpに下記のコードを追加する等がありました。
add_filter(‘xmlrpc_enabled’, ‘__return_false’);
ただし、wordpressのバージョンにより動かなくなるらしいです・・。
結局のところ、xmlrpc.phpに対してサーバーからアクセス制限をかけてやるのが無難な方法だと思います。
ここ数日、まったく同じIPより同様の攻撃をされておりました。
非常に参考になりました。
ありがとうございます。