妙にブログのアクセスが減ってるなーと確認してみると
レスポンスが異常に悪い。
調査しようとSSHでサーバーに接続してもログインすら出来ない状態。
焦ってさくらのコントロールパネルから再起動してログを調べるとどうも攻撃にあってたらしい。
[cc lang=’text’ line_numbers=’false’]
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)”
[/cc]
こんなログが山盛り
※このIPは実際に攻撃してきやがったIPです
ご注意ください!!WordPressの脆弱性をついた攻撃が再燃しています。
どうやらxmlrpc.phpの脆弱性を突いたPingback機能を使った攻撃が最近また流行ってると。
どーにかこーにか対策してみたので対策方法のご紹介でも。
リンクしたページにもあるように対策としては３つ
- functions.phpの変更
- プラグインの導入
- .htaccessでの対策
functions.phpの変更
WordPressのコードを読むとストレスが溜まるので
WordPressの更新でいつ変更がかかるか分からないのでWordPressのphpファイルをいじるのはパス
プラグインの導入
対策用のプラグインを導入してみる。
Disable XML-RPC Pingback
イントールして有効化したのに攻撃は止まらず負荷も下がらない。
大元から切るしかなさそう。
.htaccessでの対策
結局.htaccessでの設定方法で攻撃者からのアクセスを撃退することが出来た。
色々試して有効だった設定をご紹介。
xmlrpc.php へのアクセスを全て制限
[cc lang=’apache’ line_numbers=’false’]
Order Deny,Allow
Deny from ALL
[/cc]
こいつを.htaccessの上部へ追記。
xmlrpc.phpへのHTTP経由アクセスを全て拒否する設定。
ただこの方法だとアプリからの更新等のリモート更新関連もxmlrpc.phpへのPOSTで動作してるので
そこらへんの機能も全部動かなくなる。
管理コンソールからしか更新しないぜ！
という場合は問題ないけど自分の場合アプリから画像をアップしてるもんでそうもいかない。
xmlrpc.php へのアクセスを指定のIPのみ制限
[cc lang=’apache’ line_numbers=’false’]
Order deny,allow
Deny from 192.187.118.162
Allow from all
[/cc]
Deny fromで指定のIPからのアクセスだけ制限する。
この方法だとアプリとかの更新もOKやけど攻撃者が増えたりプロキシ経由の攻撃になると
いちいちDeny fromの設定を変えなきゃならないのでめんどくさい。
xmlrpc.php へのアクセスにパスワードをかける
[cc lang=’apache’ line_numbers=’false’]
AuthUserFile /var/www/foo/.htpasswd
AuthGroupFile /dev/null
AuthName “secret page”
AuthType Basic
require valid-user
[/cc]
xmlrpc.phpへのアクセスにベーシック認証をかけてやることで攻撃者のアクセスを無効にする。
アプリからの更新は、HTTP IDとパスワードを設定出来るので問題無し。
wp-admin以下にベーシック認証をかけてる人も多いかと思いますが
そんな場合はこう
[WPのルートフォルダ]/.htaccess
[cc lang=’apache’ line_numbers=’false’]
<filesmatch “(xmlrpc\.php|wp-login\.php)”=””>
AuthUserFile /var/www/foo/.htpasswd
AuthGroupFile /dev/null
AuthName “secret page”
AuthType Basic
require valid-user
[/cc]
[WPのルートフォルダ]/wp-admin/.htaccess
[cc lang=’apache’ line_numbers=’false’]
AuthUserFile /var/www/foo/.htpasswd
AuthGroupFile /dev/null
AuthName “secret page”
AuthType Basic
require valid-user
[/cc]
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を使って
対策の設定を追記してやる。
全部拒否
[cc lang=’apache’ line_numbers=’false’]
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]
[/cc]
xmlrpc.phpへのアクセスは全部404にする。
Deny from でやった時と同様にこれだとアプリ等からの更新も全部404でエラーになっちゃう。
ブラックリスト形式
[cc lang=’apache’ line_numbers=’false’]
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]
[/cc]
特定のIPやリモートホストからのアクセスを404にする設定。
攻撃者は諦めてくれるけどこれも攻撃者が増えるたんびに設定変更が必要になる。
ホワイトリスト形式
[cc lang=’apache’ line_numbers=’false’]
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]
[/cc]
特定の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 を踏み台にして他サーバーへの攻撃が目的のはず…
踏み台を落とすほどやってどーすんの。
バカじゃねぇの。