WordPressへのパスワード総当りやXML-RPC攻撃をfail2banで緩和するプラグイン「WP fail2ban」

　2024年8月9日
wrench-in-hands_sizeXS.jpg

WordPress のログインパスワードに対するブルートフォース（総当り）攻撃や、XML-RPC 攻撃を fail2ban で緩和するプラグイン「WP fail2ban」を紹介しておきます。

詳しくないとつまづくポイントが多い方法ですが、分かっている方向けに端折って書かせていただきます。

分からない場合は無理にこの方法は使わず、.htaccess でIPアドレス毎にアクセス制御をかける方法（イタチごっこ）や、Wordpress の XML-RPC の無効化、XML-RPC のうち pingback 機能だけを無効化する方法などを検討すると良いでしょう。

ただし、それらの方法では大人の事情で不都合があるときには、今回の方法も選択肢のひとつとなります。また、複数策を組み合わせて防御を強化する手もあります。

fail2banでWordpressのXML-RPCへの攻撃などを緩和する設定

WordPress プラグイン「WP fail2ban」は WordPress の XML-RPC は止めずに、あるパターンでアクセスしてきた IP アドレスだけを別ソフト「fail2ban」で BAN します。

つまり、Linux 上で動作する「fail2ban」と WordPress プラグイン「WP fail2ban」は別ソフトで、syslog を介して協調動作する関係性となります。

この記事では、

  • 大前提としてLinux サーバー上ですでに「fail2ban」が動作している
  • Linux、syslog、WordPress、PHP、fail2ban、TCP/IP周りについて、一定以上理解している

ことを前提に話しを進めます。

大まかな設定の流れは以下のとおり。

  1. WordPress XML-RPC API への攻撃などを syslog に書き出す WordPress 用プラグイン「WP fail2ban」をインストール
  2. fail2ban に syslog を読ませて適宜 BAN する設定をする

インストール

まず、WordPress用プラグイン「WP fail2ban」をインストールします。

インストール後はプラグインを有効化しておきます。

「WP fail2ban」の設定はwp-config.phpで

「WP fail2ban」は、WordPress の認証失敗や XML-RPC でのアクセスなどを syslog に書き出すだけの単純なプラグインです。

初期状態では WordPress へのログイン失敗だけを PHP の syslog() 関数で書き出しますが、その他にも、

  • XML-RPC のピンバック要求
  • ユーザー名列挙要求
  • 特定ユーザーでのログイン拒否
  • コメントスパムの送信

も syslog へ書き出し、アクセスを遮断可能。

有料版ではプラグイン管理画面からこれら大部分の設定ができますが、wp-config.php に設定を追加すれば、プラグイン管理画面から設定できない項目や無料版ユーザーでも BAN 対象のイベントを追加できます。

以下は、wp-config.php の設定例。（すべて初期値で動作させるなら設定は不要）

// LOG_AUTHPRIV（/var/log/secure）へログ出力
define('WP_FAIL2BAN_AUTH_LOG', LOG_AUTHPRIV);

// XML-RPC pingbacks フラッド攻撃対策
define('WP_FAIL2BAN_LOG_PINGBACKS',true);

// XML-RPC 経由でのユーザー列挙をブロック
define('WP_FAIL2BAN_BLOCK_USER_ENUMERATION',true);

// SPAMとマークしたコメントの投稿元をブロック
define('WP_FAIL2BAN_LOG_SPAM',true);

wp-config.php で設定できる内容については、公式ドキュメントを参照。

fail2banのfilter・jailを設定

次に「fail2ban」に syslog を読ませて必要なら BAN しますが、WordPress プラグインの権限では「fail2ban」の設定は変えられないので、手作業での追加設定が必要です。

以下にその手順を示します。

プラグインをインストール後、WordPress のプラグインディレクトリ以下の /wp-fail2ban/filters.d/wordpress-XXXX.conf

から、以下のいずれか1つを /etc/fail2ban/filter.d にコピーします。

  • wordpress-extra.conf
  • wordpress-hard.conf
  • wordpress-soft.conf

（※ 権限に注意。例：root:root ）

例としてここでは wordpress-hard.conf を選んだとします。

この場合、fail2ban のドロップイン /etc/fail2ban/jail.d/ に、以下のようなファイル jail.local を作成します。

[wordpress-hard]
enabled  = true
filter   = wordpress-hard
# Ubuntu
# logpath  = /var/log/auth.log
#
# RedHat
#logpath  = /var/log/messages
logpath  = /var/log/secure
maxretry = 5
port = http,https
bantime = 900
findtime = 900

logpath は、OS・設定ごとに適切な場所を指定すればOK。

各 OS・ログファシリティごとのデフォルトのログ出力先は以下参照。

実運用上は findtime、bantime、maxretry あたりにも「賢い値」の設定が必要。攻撃者が再攻撃を諦めるどうかはここにかかってきます。（後述の累犯者設定と組み合わせるとなお良い）

fail2ban の jail 設定の書式については $ man jail.conf を参照。

最後に fail2ban デーモンをリスタートして、エラーが出なければ設定は完了です。

動作確認は管理画面のログイン失敗で

「WP fail2ban」が正しく動作していれば、WordPress の管理画面へのログイン失敗時に以下のようなログが出力されます。

May 16 18:42:07 localhost wordpress(192.168.XXX.XXX)[55639]: Authentication failure for admin from 192.168.XXX.YYYCode language: plaintext (plaintext)

これを fail2ban が読んで条件を満たした接続元は BAN、喪が明ければ UNBAN となります。

「WP fail2ban」のデフォルトでは、ログは syslog のファシリティ「LOG_AUTH」へ出力されます。

これは RedHat 系では、基本的には /var/log/messages にあたります。

WP fail2ban のハマりどころは syslog 周りですので、まずはログ確認をもって（中途半端ですが）動作確認の一端とし、さらには fail2ban のログや WEB サーバーのアクセスログでも BAN やアタックの減少を確認するのが良いでしょう。

XML-RPC pingbacks 対策なら別手法が楽かも

とりあえず、xml-rpc.php 宛に大量の pingback 要求が投げられてサーバーのメモリ・CPU 資源が不足しているのであれば、今回の方法でなく XML-RPC pingbacks だけを停止した方が手軽で確実でしょう。今回の方法では BAN 判定までのわずかな間も踏み台にはなるため、pingbacks を停止してしまった方がより、周りに迷惑を掛けずに済むと思います。

ちなみに今回の方法で注意すべきは、fail2ban の BAN 判定条件です。

例えば、初期値のままで fail2ban を運用したとしても攻撃者は設定値をお見通しですので、閾値をくぐり抜けられるよう1IPあたりの攻撃頻度を下げ、かつ、攻撃元を分散することで攻撃量を維持してきます。

このあたり、攻撃者に「このサーバは使えない」と思わせるのが腕の見せどころでして、必要なら他の防護策も組合わせて使うのが良いと思います。

というあたりが、今回の方法が万人向けではない理由にはなってきます。

攻撃手法の確認にはパケットキャプチャが便利

繰り返しますが、今回のプラグイン「WP fail2ban」は、ログインの失敗、および一部の XML-RPC 要求などを、ある条件の場合だけ大雑把に syslog に書き出してくれる機能しか持っていません。

そのため、「WP fail2ban」がログ出力しない XML-RPC への攻撃、にはなんら効果が無い事は理解しておく必要があります。魔法の杖じゃない。ということです。（以下はログが吐かれないアクセス例）

WPfail2banToMitigateXmlRpcAttack_2_sh

という事で、tcpdump や Wireshark などのネットワークキャプチャを使って攻撃内容を把握することも重要です。

なお、fail2ban でBANされた攻撃者が攻撃を継続した場合、 攻撃者はSYN_SENT の状態で待たされ、TCP再送処理を走らせるケースがほとんどでしょう。

WPfail2banToMitigateXmlRpcAttack_1_sh

こういうのも自分の目で確認しておくと、あー、ちゃんと動いてるなー、と安心できると思います。

ただし、現在では HTTPS の普及により直接電文を確認するには、何らかの工夫が必要にはなりますが。

fail2ban の累犯者向けBAN設定がお便利

fail2ban のBAN設定の加減が悩ましい場合は、初犯には緩めにしておき、執拗に攻撃を繰り返してくる輩にだけ、より厳しい長期BANを喰らわせる、という方法もあります。

✓ 関連記事

fail2banでしつこい攻撃者だけ長期BANする方法

サーバ運用をしていると、アタックを受ける事は日常茶飯事です。 ですから、例えばブルートフォース攻撃緩…

実効的な対策は取りつつも、運用上のミスには優しい。といういい塩梅を狙うわけです。

参考・情報：

WP fail2ban 公式設定マニュアル（Ver 5.2）：

※2024/5/16 記事リライト、最新化。現在でも使われている方法です
※2015/2/16 文章ブラッシュアップ

Hatena Pocket Line
#CentOS #Linux #WordPress #サーバ運用 #サイト運営 #セキュリティ
« 前の記事 «
» 次の記事 »

こんな記事も読んでみませんか？

コメントを記入