xmlrpc.phpへのブルートフォース攻撃対策をしてみた

この記事は2017年8月12日に投稿・更新されたもので、内容が古い可能性がありますのでご注意ください。

こんにちは、おおぬき(@ishlion)です。

8月に入ってから当ブログxmlrpc.phpへのブルートフォース攻撃記録が見つかり、その対策をしたので記録として残しておきます。

ブルートフォース攻撃とは

https://ja.wikipedia.org/wiki/総当たり攻撃
総当たり攻撃(そうあたりこうげき)とは、暗号解読方法のひとつで、可能な組合せを全て試すやり方。力任せ攻撃、またはカタカナでブルートフォースアタック(英:Brute-force attack)とも呼ばれる。

wordpress界隈では管理画面へのユーザーID「admin」アタックでよく話題に上がるやつですね。IDをadminにしている人は変更しましょうねーっていうアレです。こんな実験をされている方もいるので読んでみてください。

【悪用厳禁】自分のWordPressブログにブルートフォースアタックをしてみた
自分のブログのセキュリティがしっかりしてるか気になったのでブルートフォースアタックを試した結果、やっぱりXSE…

で、wordpress上での管理画面へのブルートフォースアタック対策では下記の方法が有名だったりします。

ログインページへのブルートフォースアタック対策

ユーザーIDを「admin」以外に変更する

adminってとてもわかりやすくて覚えやすいIDなんですが、これを設定しているだけで攻撃者からの良い餌になってしまいます。ですので、adminというユーザーIDは絶対使用しないでください。もしadminでユーザーIDを作成してしまった場合は変更しましょう。

Admin renamer extended
Plugin to change your default admin username ( with GUI to change all other admin names too ).
Username Changer
Change usernames easily

プラグインは上記2種が有名どころ。また別で管理者アカウントを作り、そちらに権限を移した後に、adminを削除する方法もあります。

WordPressのユーザー名(admin)を変更・削除する方法 | WordPress資料一覧 | はっちゃんの初心者 向けWordPressセミナー

直接DBから変更する方法もありますね。

WordPressの登録ユーザー名、ユーザーIDを変更する方法 | WordPress(ワードプレス)のカスタマイズ専門・ホームページ制作会社

うちのブログではAdmin renamer extendedを使用しました。

投稿者アーカイヴのアドレスを変更させる

ユーザーIDをadmin以外のもので設定していても、デフォルト状態ではユーザーIDがもろバレになってしまいます。これはユーザーニックネームを設定していないため、ブログ上での表示名がユーザーIDそのもので表示されてしまうからです。ですので、wordpressインストール後には必ずユーザーニックネームを入力して、wordpress上で表示する投稿者名をニックネームにすることを推奨します。

投稿記事から「(ログイン)ユーザー名」がバレるのを防ぐ
ここ最近、アカウント乗っ取りやセキュリティ事故関連のニュースが相次いでいますが、WordPressで制作されたサイトも標的に会っているようです。一般的な手法としては「ブルートフォー…
WordPressの「ブログ用の表示名」と「ユーザー名」は、別のものにしておこう
Simplicityは、本文の右下に投稿者名が表示されます。 何故表示されるかというと、これがないと、ウェブマスターツールなどで「エラー: Missing required hCard “author”.」などと出るからです。 デフォ

この対策で表面上ではユーザーIDがバレることはないのですが、wordpressでは投稿者アーカイヴというものが作成されるため、ブログアドレスに「/?author=1」をくっつけてアクセスされるとここでユーザーIDがバレてしまいます。(数字はIDが作られた順番に振られているようです)そこでプラグインを使って、投稿者アーカイヴのURLに変更をかけます。

Edit Author Slug
Allows an admin (or capable user) to edit the author slug of a user, and change the author base.

この対策を行うことで、「/?author=1」にアクセスされてもユーザーIDが表示されなくなります。

プラグイン「SiteGuard」によるログインページ変更

SiteGuard WP Plugin | 国産WAFのJP-Secure

SiteGuard WP Plugin
SiteGurad WP Plugin is the plugin specialized for the protection against the attack to the management page and login.

一番お手軽にできるブルートフォース対策だと思います。SiteGuardに付いている他の機能と複合することでより高い防御力になります。

Google認証システムでログインを2段階認証化する

これは管理画面へログインする際、任意の6桁の数字を入力するいわゆる「ワンタイムパスワード」を使用したログイン方式です。Google認証システムについては、Seki’s noteさんの「Google 認証システムの仕組み」で詳しく説明されています。

Google Authenticator
Google Authenticator for your WordPress blog.

使い方はこちらで詳しい説明が書かれています。

2段階認証の必須アプリ! 「Google Authenticator(Google 認証システム)」の使い方と裏ワザ、注意点
先日、Amazonが2段階認証に対応した。他にGmailやDropbox、WordPressなど2段階認証に対応しているウェブサービスは多い。2段階認証にはSMSや音声通話でワンタイムパスワードを受け取る方法があるが、手軽なのはGoogle

スマホでワンパスを確認する場合はスマホ用アプリも同時にインストールしましょう。

Google 認証システム – Google Play の Android アプリ
2 段階認証を有効にしてアカウントを不正使用から保護できます。
Google Authenticatorを App Store で
「Google Authenticator」のレビューをチェック、カスタマー評価を比較、スクリーンショットを確認、詳細情報を入手。Google Authenticatorをダウンロードして iPhone、iPad、iPod touch で利用。

今回狙われたのは「xmlrpc.php」ファイル

で、前置きが長くなりましたが。今回狙われたファイルが「xmlrpc.php」。

xmlrpc.phpって何のファイル?

xmlrpcとは、スマートフォンアプリや外部システムから、リモートで記事投稿や画像のアップロードを行う際に利用されるプロトコルです。
WordPressにおけるxmlrpcへの脆弱性対応のお願い | スマートコネクト マネージドサーバ
http://support.mngsv.jp/info/news/1429/

基本Macや自宅のWinで記事を書いているので、「xmlrpc.php」ファイルはあまり気にしていなかったのですが結構来てたんですよね。で、上で挙げた対策をしても規制対象が違うのでこの「xmlrpc.php」ファイルへのブルートフォースアタックは行われてしまいます。(ちなみに当ブログにて、サムネで表示されてる失敗部分のログイン名は「Edit Author Slug」で変更かけたものになっていました。)

このまま放っておくとサーバへの負荷になるようでブログの表示が遅くなる原因にもなるらしい。

サーバーが高負荷の原因はWordPressのxmlrpc.phpを狙った攻撃だった
ブログにアクセスしたらなかなか読み込まない。なんか重たくなってる!異変にきづいてサーバーにターミナルでアクセスを試みるもつながらず。サーバーのコンパネから強制的に再起動をして復旧した。その原因を調べたらWordPressのxmlrpc.phpにあった。 xmlrpc.phpに大量のアクセス apacheのログを調べたら、このように断続的に大量のアクセスがあった。apacheのエラーログをみると「server reached MaxClients setting, consider raising the MaxClients setting」と設定数以上のアクセスで、高負荷状態になり接続できなくなっていた模様。 xmlrpc.phpはそもそも、これを使うことで標準の管理画面以外からもAPIを使って、記事の投稿ができるようになるもの。どうやらここへのブルートフォースアタックでのっとりをしようとしているか、Pingback機能を悪用して当サーバーを踏み台にして攻撃に利用するためにアタックされる事例が多いようだ。xmlrpc.phpは使わないので、早速対策をとった。 [対策その1] プラグインで無効化 Disable XML-RPC Pingbackというプラグインがあり、これを利用すればピンバック機能を無効にしてくれるため、踏み台にされることはなくなる。まずはこれを設定した。 [対策その2] xmlrpc.phpへのアクセス禁止 そもそもxmlrpc.phpへアクセスできないようにした。これはhtaccessに [code] <Files "xmlrpc.php"> order deny,allow deny from all </Files> [/code] のように記述すれば、xmlrpc.phpへアクセスしても403forbiddenエラーとなる。 [対策その3] 攻撃元IPを遮断 htaccessでアクセス拒否しても、apacheは経由するので負荷がかかることにかわりはない。そこで、iptable(ファイアーウォール)で攻撃してきているIPを遮断することにした。 [code] //遮断したいIP iptables -I INPUT -s 185.62.189.47 -j DROP //設定を保存 service iptables save //設定を反映 service iptables restart [/code] 攻撃してくるIPはその時によって変わってくるので、高負荷になった時にアラートをいれたり、監視できる仕組みをいれないといけない。面倒だな…。 その後、サーバー攻撃を受けたので繰り返さないようLogwatchで監視をはじめてみました。 https://iritec.jp/web_service/10284/ WordPressのセキュリテイ関連では、WordPress Popular Postsプラグインにも脆弱性がみつかりましたので、利用している方はご注意を。 https://iritec.jp/web_service/5041/ WordPressの高速化についてはこちら。 https://iritec.jp/web_service/4531/

ということで、対策を行ってみました。

.htaccessファイルでxmlrpc.phpへのアクセスをリダイレクトする

.htaccessにこの一文を追加すると、xmlrpc.phpにアクセスすると0.0.0.0にリダイレクトしてくれます。実際に、.htaccessへ書き込むとこのような形になります。

このような感じでリダイレクトされます。

まとめ

うちはまだそんなにアクセス数が多いわけではないんですが、それでも不正アクセス対策はしておいたほうがいいと思って今回対策をとりました。これでSiteGuardのログも少しは静かになってくれるかな…。

スポンサーリンク