【対策まとめ 2020年度版】WordPressへのブルートフォースアタック（総当たり攻撃）の現状と対策

ここのURLをクリップボードにコピー(copied!)

1. ブルートフォースアタック(総当たり攻撃)とは？

ブルートフォースアタック(総当たり攻撃)とは、WordPress管理ユーザのアカウントとパスワードの組み合わせを解読するために、考えられる全てのパターンを総当たりで試す攻撃方法です。

何千、何万パターンも試すため、サイトを乗っ取ろうとするロボット(ボット)と呼ばれる自動プログラムが攻撃を仕掛けてきます。

WordPressがなぜ標的になるのか？それはずばり…

専門知識がなくてもホームページを作成・管理できる反面、
便利な機能がゆえに「管理画面のURLが推定されやすい」や「管理者のユーザーIDが公開されている」などが理由として挙げられます。

また世界中のWebサイトのうち35%以上のシェア*をもつことも、標的となりやすい理由の1つだと思います。
※参考：W3Techs

これらから、「やっぱりWordPressってセキュリティ的には微妙なの？大丈夫？」と思われるかもしれませんが、安心してください。

適切に設定を行うことで、セキュリティを向上させることが可能です。

この記事では「WordPressの管理者ユーザーID、パスワードをブルートフォースアタックで盗み出されない方法」を紹介していきます。

2. 実際のアクセスログと、代表的な攻撃例

2-1. URLアクセス「/?author=1」を用いたユーザー名の特定

WordPressは標準の機能で、特定のURLにアクセスした際、独自の判断でとあるURLにリダイレクトされる機能を備えています。
その1つとして「ライター記事一覧画面」があります。

http://サイトのドメイン/?author=1

にアクセスすると、

http://サイトのドメイン/author/hogehoge/

というユーザー名が記載されたURLに自動的にリダイレクトされます。

ここでいう「1」はユーザーIDを指しており、大部分の方が「最初に発行した管理者ユーザーアカウント」がこれに該当するかと思います。

そのため、管理者アカウントのユーザー名の1つが「hogehoge」であることが露出してしまいます。

攻撃者はこのユーザー名を用いてログインを何度も試みる手法でパスワードを割り出します。
そのため、対策としては/?author=1にアクセスされた際、ユーザー名が露出させない対策が必要となります。

後述：ユーザー名を特定されない様にするプラグイン「Edit Author Slug」

2-2. ロボットによる管理ログイン画面への多重POST

ブルートフォースアタックでは、サイトを乗っ取ろうとするロボット(ボット)が、自動プログラムをもとに何千、何万パターンものログインを試してきます。

そのため、ログイン失敗の上限をカウントし、一定の上限回数以上のユーザーは管理者ではないと判別し、アカウントをロックすることで対策が可能となります。

後述：ログイン失敗の上限回数を管理できるプラグイン「Limit Login Attempts Reloaded」

2-3. xmlrpc.phpを使った攻撃例

WordPressにはピンバックやトラックバックで使われている「XML-RPC」という外部のサービスと連携するためのAPIが存在します。

このAPIの中にはWordPressアカウントの認証機能を持つものがあるため、攻撃者がパスワードを特定するためのブルートフォースアタックに使うケースが存在します。

実際のアクセスログがこちら

{ドメイン名}/xmlrpc.php にユーザー名とパスワードをPOSTすることで、戻されたその結果によりそれらが正しいかどうかが判別できてしまいます。

実際に試してみます。(他者のサイトに投げることは決してやめましょう)

以下のようなサンプルのXMLをPOSTしてみます。

<?xml version="1.0" encording="iso-8859-1"?>
  <methodCall>
    <methodName>wp.getUsersBlogs</methodName>
    <params>
      <param>
        <value>admin_user</value>
      </param>
      <param>
        <value>admin_password</value>
      </param>
    </params>
  </methodCall>

ターミナルで以下を実行してみます。

cat {サンプルのXML}.xml | curl -X POST -H "Content-type: text/xml" -d @- {WordPressサイトのドメイン}/xmlrpc.php

ログイン認証に失敗すると以下のようなレスポンスが得られます。

<?xml version="1.0" encoding="UTF-8"?>
  <methodResponse>
    <fault>
      <value>
        <struct>
         <member>
           <name>faultCode</name>
           <value><int>403</int></value>
         </member>
         <member>
           <name>faultString</name>
           <value><string>ユーザー名またはパスワードが正しくありません。</string></value>
         </member>
       </struct>
     </value>
   </fault>
  </methodResponse>

ログインに成功すると、

<?xml version="1.0" encoding="UTF-8"?>
  <methodResponse>
    <params>
      <param>
        <value>
          <array><data>
            <value><struct>
              <member><name>isAdmin</name><value><boolean>1</boolean></value></member>
              <member><name>url</name><value><string>{サイトのURL}</string></value></member>
              <member><name>blogid</name><value><string>{ユーザーID}</string></value></member>
              <member><name>blogName</name><value><string>{サイトのタイトル}</string></value></member>
              <member><name>xmlrpc</name><value><string>{ドメイン}/xmlrpc.php</string></value></member>
            </struct></value>
          </data></array>
        </value>
      </param>
    </params>
  </methodResponse>

ユーザー名とパスワードが一致した場合に上記のXMLが返されるため、管理ログイン画面のURLやユーザーIDを特定できないようにしても、これらの攻撃を避ける根本対応にはなっていません。

この「xmlrpc.phpを使った攻撃」の対策については、この後に紹介します。

3. 対策

3-1. WordPressを常に最新版にアップデートする

残念なことに、攻撃者による攻撃も日々進化していきます。
そのため、一定の対策をすれば終わりというわけではなく、サイトの運営者は常に最新の対策を打つ必要があります。

最も重要な対策の1つに「WordPressを最新版にバージョンアップする」があります。

攻撃対象となるWordPressの脆弱性は、バージョンアップによって塞がれることが多いため、できるだけ最新にするように心がけましょう。

しかしながらWordPressの自動アップデートは事前に確認なく行われるため、予期しないタイミングで意図しない不具合(プラグインとの兼ね合いなど)が発生する場合があります。

自動アップデートはOFFにし、開発環境でバージョンアップを行い、動作確認後に本番環境をバージョンアップする方法を用いることで、より安全な運用が可能となります。

3-2. xmlrpc.phpアクセスをブロックする

xmlrpc.phpへの攻撃に対する対策で最も簡単なのは、XML-RPCを停止させる方法です。.htaccessを用いてxmlrpc.phpへのアクセスを0.0.0.0にリダイレクトさせます。

※404ではWordPressがエラーページのレンダリングするため、無駄な負荷が増加するため
※以下.htaccessの記述については、各自環境に合わせてください

# xmlrpc.phpを停止
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase / 
RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]
</IfModule>

設置後、{ドメイン}/xmlrpc.phpにアクセスし、0.0.0.0にリダイレクトされていることを確認できれば押忍です。

しかしXML-RPCを停止してしまうと、ピンバックやトラックバック、これらを使った外部サービス連携(JetpackやAkismetなど)ができなくなります。

その場合、XML-RPCも管理ログイン画面同様、ログイン回数を制限するプラグイン「Limit Login Attempts Reloaded」を使うという方法もあります。こちらで後述しています。

3-3. BASIC認証で不特定ユーザーの管理画面アクセスをブロック

管理画面にBASIC認証をかけることで、そもそも管理画面にアクセスをさせなくします。
ドキュメントルートに設定している.htaccessに以下を追記します。

<Files wp-login.php>
AuthType Basic
AuthUserFile /path/to/.htpasswd
AuthName "Please enter your ID and password"
require valid-user
</Files>

これで攻撃者は、そもそもの管理ログイン画面にアクセスできなくなります。

しかしながらBASIC認証もブルートフォースアタックで突破される可能性があるため、完全な対処法ではないということは理解しておいてください。(その他の対策との併用が必要になります。)

3-4. ユーザー名を特定されない様にするプラグイン「Edit Author Slug」

Edit Author Slug

前述の/?author=1にアクセスされた際、ユーザー名が露出するしないように変更ができるプラグインです。

管理画面のユーザー設定(ページ下部)から、ユーザー名は違う文字列を設定することができます。

3-5. ログイン失敗の上限回数を管理できるプラグイン「Limit Login Attempts Reloaded」

Limit Login Attempts Reloaded

先述の何千、何万パターンものログインを試してくる攻撃者に対し、ログイン失敗回数をカウントし、設定上限値以上になった場合はそのアカウントをロックするプラグインです。

設定画面ではリトライ回数やロック時間、メール通知などの様々な設定が可能です。

アカウントがロックされた場合は、管理画面を経由してのサイト改ざんの恐れはなくなりますが、ロックされたアカウントが使用できなくなるため、運営としてもマイナスポイントです。

そのため、ユーザー名自体を割り出されないようにする対策が必要です。

3-6. 管理画面のURLを変更するプラグイン「SiteGuard WP Plugin」

SiteGuard WP Plugin

WordPressの管理画面は、標準でhttp://サイトのドメイン/wp-admin/でアクセスが可能です。
そのため、攻撃者の標的の多くはこのwp-adminに向けられます。

プラグイン「SiteGuard WP Plugin」では、このwp-adminを変更することができるため、攻撃されにくくなります。

まとめ

WordPressは標準で便利な機能がたくさんあり、世界的にシェアが非常に高いが、その反面サイト改ざんなどを狙う攻撃対象になりやすい。

WordPressに対する攻撃の一種である「ブルートフォースアタック」への対策は、以下を行っておく必要がある

xmlrpc.phpアクセスを.htaccessを用いてブロック(リダイレクト)する
管理画面にはBASIC認証をかける
プラグイン「Edit Author Slug」を用いて管理者ユーザー名を特定されない様にする
ログイン失敗の上限回数をプラグイン「Limit Login Attempts Reloaded」を用いて制限する
管理画面のURLをプラグイン「SiteGuard WP Plugin」を用いて変更する
WordPressのバージョンアップデートはできるかぎり行う