タグ: セキュリティ

はじめに

自前NASにWordPressを導入してblogを発信していることを前提にしています。Synology NAS/Routerには、それぞれのマシンのログインや、Synologyが独自で提供する各種サーバーの守りは、それぞれのOS (DSM/SRM)で完結できます。しかし、WordPressは独自に守る必要があります。そのために、WordPressのためのプラグインが存在しています。

これまで、たとえば、スパム・コメントの対策には、「Throws SPAM Away」にお世話になっていました。その役割も、僕の知識も変化・発展したことで、reCaptchaなるGoogleが提供するセキュリティ対策へと移行しています。更に、冒頭で述べたように、WordPress自体を守るために、新たなプラグインとして「Statify」、「SiteGuard WP」を更に導入しました。

注) Throwは野球でいう「スローイング」のスロー、投げるの意。

試したプラグイン

reCAPTCHAで試したのは、2つ。一つ目の「reCAPTCHA in WP comments form」は、コメントの送信ができなかったので使えず、使えたのは2つ目の「reCaptcha by BestWebSoft」を稼働させることにした。

• reCAPTCHA in WP comments form
  • 8ヶ月前のupdateで、互換性テストがされておらず、結果的には、コメントの送信ができなかったため、使用できなかった。
• reCaptcha by BestWebSoft
  • Pro版もあり、メンテナンスはされています。Pro版でない無料版のまま使用することにした

プラグイン

reCAPTCHA in WP comments form

reCAPTCHA in WP comments form

reCaptcha by BestWebSoft

reCaptcha by BestWebSoft

Throws SPAM Away

日本語が含まれないコメントは、強制的にコメント送信しても廃棄するプラグインです。現在は使用していません。

Statify

Statifyの機能

「Statify」は、サイトのアクセス数をカウントしてくれるプラグインです。純粋なページへのアクセスに関して「Google Analytics」は、詳細なレポートを示してくれます。Statifyを導入する意義を確認するためにStatifyとの比較をしたところ、結果が異なっていました。Statifyでは、/login/へのアクセスがカウントされていたのに、Google Analyticsではカウントされていなかったのです。

/login/へのアクセスは、私が知らないアクセスでした。不正なアクセスを試みているものと判断できました。Statifyをインストールして約半日の集計で、すごい勢いでアクセス数が増えるのが観察されました。その反日での結果、/login/のアクセス数は、200を超えました(下図に205とある項目)。少し愕然としました。そんなにアクセスを試みるハッカーがいるものだと。「Statify」を、セキュリティ対策プラグインとして採用することにしました。

わかったこと

• Google Analyticsは、善意の第三者がページを閲覧することを前提にしたページモニタリング・ツールである。すなわち、Statifyがカウントするログインページのカウントはない。
• Statifyは、アクセスした数を実直にカウントしてくれる。すなわち、ログインページのカウントもしてくれるので、セキュリティ対策としてのモニタリング・プラグインとして使用が可能と判断した。

SiteGuard WP

SiteGuardの機能

Statifyが示した愕然する程のログイン画面への多数のアクセス数、この結果を受けて調べました。デフォルトのログイン・リンクは変更すべきなのです。プラグインを使用せずに、PHPファイルにコードを加える方法でも可能なのですが、30行から50行程度のコード追加が必要です。メンテナンスが大変そうなので、プラグインで対応することにしました。

「SiteGuard WP」は、デフォルトである/login/を、安易に想像できないパーマ・リンクに設定する機能を持っています。SiterGuard WPをインストールした途端、即時に/login/をランダムな数で修正するので、当然ですが、その瞬間から/login/へのアクセスの増加は無くなりました。変更後のパーマ・リンクのアクセスのカウントもモニターされていません。「SiteGuard WP」を、セキュリティ対策プラグインとして採用することにしました。

上記の機能と説明について、以下に捕捉します。

• ログインページ変更
  • /login/のデフォルトから変更
• 画像認証
  • bot対策です。かな文字を画像として表示して、それを入力するように促す機能

以上のSiteGuardによるログイン・ページの変更だけで不正ログインを試みる事例は、一時期極端に減少しました。しかし、運用開始から1週間後の夜中から今日の朝方にかけて約8時間程度で、3つのIPアドレスからの3,000回以上で、WordPressログイン画面に対してアタックを受けました。このログは、SiteGuardの「ログイン履歴」からわかったことです(下図参照)。Google Analyticsではカウントされ無いものです。

• XMLRPC防御
  • XMLRPC (XML形式のデータを使いHTTPの通信、RPC: remote procedure call)は、WordPressが開発された当時が実装されているログインしたりリモート制御したりするときに使用する通信機能の1つですが、現在ではREST APIというものに置き換えられています。
  • XMLRPCには全弱性があるため無効にすべきです。
  • XMLRPCにある1つの機能であるピンバック機能のみを無効化するか、XMLRPC全体を無効にするか、いずれかを選ぶことができます。

WordPressのxmlrpc.php詳細ガイド（xmlrpc.phpとは、セキュリティリスク、無効にする方法）- kinsta –

https://kinsta.com/jp/blog/xmlrpc-php/

ロックは完璧

以下の図は、ログ画面の一部です。内容を確認してみると、3つのIPアドレスからの不正なログインアタックが記録されているのが分かりました。下図の例では、3回失敗した後は、ロックされる設定にしているため、その後のアクセスはロックされているのが分かります。

次の対策

念の為、危険なIPアドレスを知った後の処置です。自前のSynology NASまたはSynology RouterがGeteになっているなら、ファイアウォールの設定をしておきます。完全に「出禁」に設定してしまうのです。

Synology NAS/Routerの場合は、下図を参考にして、以下の通りで設定します。

1. コントロールパネル (Synology Routerの場合; ネットワークセンター)→ セキュリティ → ファイアウォール (タグ)
2. ファイアウォール プロファイル → 規則の編集
3. 「作成」をクリック
   • 全てのポート
   • 特定IP → ソースIP → 単一ホスト(を設定)
   • 拒否
4. OKで登録

以上の手順で、危険と思われるIPアドレスをファイアウォールに登録しました。しばらくは、この方法で運用して様子を見てみます。

まとめ

コメントのスパム対策から始めたこの記事でしたが、それではサイトの守りはままならないことがわかってきました。AMPプラグインとの相性の問題から、一部のページの守りには、reCaptcha を使えています。しかし、ログイン・ページの守りは、これまでは不十分でした。純粋にアクセス数をカウントする「Statify」プラグインの導入をきっかけに、「SiteGuard WP」プラグインと併用することで、ログイン・ページの守りを強固なものにすることができます。確認された危険なIPアドレスはファイアウォールに拒否リストとして登録します。しばらくは、この運用で様子を見てみます。

編集履歴

2019/12/25,はりきり(Mr)
2021/01/07,追記(Statify, SiteGuard WPをセキュリティ対策プラグインとして採用)
2021/01/23,追記(WPへの不正アクセス試行を発見し対処する方法)
2021/09/17,追記(XMLRPC防御について),文言整備