WordPressのxmlrpc.phpへのpingback攻撃対処法

Share on Facebook36Share on Google+0Tweet about this on TwitterShare on LinkedIn0

wordpress-under-attack-crop

 

妙にブログのアクセスが減ってるなーと確認してみると

レスポンスが異常に悪い。

調査しようとSSHでサーバーに接続してもログインすら出来ない状態。

焦ってさくらのコントロールパネルから再起動してログを調べるとどうも攻撃にあってたらしい。

192.187.118.162 - - [03/Oct/2014:23:53:36 +0900] "POST /xmlrpc.php HTTP/1.0" 200 1029 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
192.187.118.162 - - [03/Oct/2014:23:53:37 +0900] "POST /xmlrpc.php HTTP/1.0" 200 1029 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
192.187.118.162 - - [03/Oct/2014:23:53:37 +0900] "POST /xmlrpc.php HTTP/1.0" 200 1029 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
192.187.118.162 - - [03/Oct/2014:23:53:37 +0900] "POST /xmlrpc.php HTTP/1.0" 200 1029 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
192.187.118.162 - - [03/Oct/2014:23:53:37 +0900] "POST /xmlrpc.php HTTP/1.0" 200 1029 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

こんなログが山盛り

※このIPは実際に攻撃してきやがったIPです

 

ご注意ください!!WordPressの脆弱性をついた攻撃が再燃しています。

http://www.denet.ad.jp/news/2014/08/wordpress.html

 

どうやらxmlrpc.phpの脆弱性を突いたPingback機能を使った攻撃が最近また流行ってると。

どーにかこーにか対策してみたので対策方法のご紹介でも。

リンクしたページにもあるように対策としては3つ

  • functions.phpの変更
  • プラグインの導入
  • .htaccessでの対策

 

functions.phpの変更

WordPressのコードを読むとストレスが溜まるので

WordPressの更新でいつ変更がかかるか分からないのでWordPressのphpファイルをいじるのはパス

 

プラグインの導入

対策用のプラグインを導入してみる。

Disable XML-RPC Pingback

https://wordpress.org/plugins/disable-xml-rpc-pingback/

イントールして有効化したのに攻撃は止まらず負荷も下がらない。

大元から切るしかなさそう。

 

.htaccessでの対策

結局.htaccessでの設定方法で攻撃者からのアクセスを撃退することが出来た。

色々試して有効だった設定をご紹介。

 

xmlrpc.php へのアクセスを全て制限

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from ALL
</Files>

こいつを.htaccessの上部へ追記。

xmlrpc.phpへのHTTP経由アクセスを全て拒否する設定。

ただこの方法だとアプリからの更新等のリモート更新関連もxmlrpc.phpへのPOSTで動作してるので

そこらへんの機能も全部動かなくなる。

 

管理コンソールからしか更新しないぜ!

という場合は問題ないけど自分の場合アプリから画像をアップしてるもんでそうもいかない。

 

xmlrpc.php へのアクセスを指定のIPのみ制限

<Files xmlrpc.php>
  Order deny,allow
  Deny from 192.187.118.162
  Allow from all 
</Files>

Deny fromで指定のIPからのアクセスだけ制限する。

この方法だとアプリとかの更新もOKやけど攻撃者が増えたりプロキシ経由の攻撃になると

いちいちDeny fromの設定を変えなきゃならないのでめんどくさい。

 

xmlrpc.php へのアクセスにパスワードをかける

<Files xmlrpc.php>
  AuthUserFile /var/www/foo/.htpasswd
  AuthGroupFile /dev/null
  AuthName "secret page"
  AuthType Basic

  require valid-user
</Files>

xmlrpc.phpへのアクセスにベーシック認証をかけてやることで攻撃者のアクセスを無効にする。

アプリからの更新は、HTTP IDとパスワードを設定出来るので問題無し。

 

wp-admin以下にベーシック認証をかけてる人も多いかと思いますが

そんな場合はこう

[WPのルートフォルダ]/.htaccess

<FilesMatch "(xmlrpc\.php|wp-login\.php)">
  AuthUserFile /var/www/foo/.htpasswd
  AuthGroupFile /dev/null
  AuthName "secret page"
  AuthType Basic

  require valid-user
</FilesMatch>

[WPのルートフォルダ]/wp-admin/.htaccess

AuthUserFile /var/www/foo/.htpasswd
AuthGroupFile /dev/null
AuthName "secret page"
AuthType Basic

require valid-user

AuthUserFileを同じファイルにしてやることで/wp-admin/以下のパスワードと

xmlrpc.phpのパスワード、ついでにwp-login.phpのパスワードも共通化しておくと

アプリで設定したIDとパスワードで全てアクセス可能に。

 

ただこれらの方法だと、攻撃者に返すレスポンスが

  • 401 Unauthorized
  • 403 Forbidden

になる。

これらのレスポンスだと攻撃者がなかなか諦めてくれない。

しつこい。

 

被害にあってない人に聞くと、どうやらドメイン直下に xmlrpc.php が見つかると

がんがん攻撃してくるようで。

 

なら 404 Not Found を返して

「xmlrpc.phpはそこにはねぇよ」と返せば

諦めてくれるはず。

 

なのでmod_rewriteを使ってレスポンスをコントロールしてやることに。

 

mod_rewriteを使って404 Not Foundにする

この場合ベーシック認証でやるのはなかなか難しいので

全部拒否かIPかリモートホストでの制限になりますな。

WordPressで.htaccessに設定しているmod_rewriteを使って

対策の設定を追記してやる。

 

全部拒否

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /

  RewriteCond %{REQUEST_FILENAME} xmlrpc\.php$
  RewriteRule .* / [R=404,L]

  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

xmlrpc.phpへのアクセスは全部404にする。

Deny from でやった時と同様にこれだとアプリ等からの更新も全部404でエラーになっちゃう。

 

ブラックリスト形式

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /

  RewriteCond %{REQUEST_FILENAME} xmlrpc\.php$
  RewriteCond %{REMOTE_ADDR} ^192\.187\.118\.162$ [OR]
  RewriteCond %{REMOTE_HOST} ^no-rdns\.offshorededicated\.net$
  RewriteRule .* / [R=404,L]

  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

特定のIPやリモートホストからのアクセスを404にする設定。

攻撃者は諦めてくれるけどこれも攻撃者が増えるたんびに設定変更が必要になる。

 

ホワイトリスト形式

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /

  RewriteCond %{REQUEST_FILENAME} xmlrpc\.php$
  RewriteCond %{REMOTE_HOST} !^localhost$
  RewriteCond %{REMOTE_HOST} !\.jp$
  RewriteCond %{REMOTE_HOST} !\.bbtec\.net$
  RewriteCond %{REMOTE_HOST} !\.amazonaws\.com$
  RewriteCond %{REMOTE_HOST} !\.mopera\.net$
  RewriteCond %{REMOTE_HOST} !\.spmode\.ne\.jp$
  RewriteRule .* / [R=404,L]

  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

 

特定のIPやホスト以外のアクセスを全部404にしちゃう設定。

  • RewriteCond %{REMOTE_HOST} !^localhost$ で管理画面からのアクセスを許可
  • RewriteCond %{REMOTE_HOST} !\.jp$ で日本からのアクセスを許可
  • RewriteCond %{REMOTE_HOST} !\.bbtec\.net$ YahooBBは許可してやる
  • RewriteCond %{REMOTE_HOST} !\.amazonaws\.com$ AWSからのアクセスも許可
  • RewriteCond %{REMOTE_HOST} !\.mopera\.net$ でテザリングやSIMフリーで使うmopera.netのアクセスを許可
  • RewriteCond %{REMOTE_HOST} !\.spmode\.ne\.jp$ SPモード接続のアクセスも許可

これなら日本ならだいたいのアクセスを許可出来るし、

それ以外は404を返してすぐ諦めてくれそうなので良い感じ。

2014-10-06 追記

localhostの記述を追加

これが無いと管理画面からのメディアの参照やアップロードがうまくいかない。

 

結論

  • ベーシック認証をかける
  • 日本以外は404にする

アプリからの更新等を可能なまま対策するならこのどちらかの対策が良いと思われ。

お使いのサーバーや環境に応じた対策をどうぞー

 

蛇足

うちのサーバーは

192.187.118.162

http://192.187.118.162.ipaddress.com/

からの攻撃が激しすぎてサーバーが落ちたりしてたんですが

この攻撃は xmlrpc.php を踏み台にして他サーバーへの攻撃が目的のはず…

 

踏み台を落とすほどやってどーすんの。

バカじゃねぇの。

 

Share on Facebook36Share on Google+0Tweet about this on TwitterShare on LinkedIn0

あわせて読みたい

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /var/www/junkpot.net/tech/html/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273