この記事を読むのに必要な時間は約 18 分です。
完全に誰得記事ですが、また何かしら同様のことが起きて作業が必要になった場合に備えて残しておきます。
実際に起きた事象
- レンタルサーバーから過量のメール配信の連絡
- 翌日にアカウント凍結の連絡
1. レンタルサーバーから過量のメール配信の連絡
対象のレンタルサーバー自体は既に4年程度は利用しているところで今まで特に問題なく運用が行えていました。
突如メールが送られてきたので何かと思って確認したところ、自分が利用しているドメインから大量のメール送信が行われているのでサーバーに不正アクセスされているのではないかという連絡でした。
ご利用の弊社サービス「xxxxxx.mixh.jp」にてSPAMメールの可能性がある、 大量のメール送信が行われていることを事を確認いたしました。 メールの大量送信に関しては、サーバー全体でのブラックリストへの登録など、 弊社ご利用中のお客様全体に多大なる影響がございます。そのため、急遽メールの送信制限をかけさせていただいております。 事後のご報告となり誠に恐縮ではございますが、何卒ご理解をお願いいたします。
メール配信などは行なっていないのでメール配信の制限自体は特には問題なかったので連絡を受けた後に指摘を受けた箇所を確認し、勝手に作成されていたメールアドレスなどを削除する対応やFTP内の記憶にないファイルの削除などを行い対応内容を返信しました。
2. 翌日にアカウント凍結の連絡
1件目のメールから対応期限が3日間で切られていて、次のアクションは返信が来たら考えようと思っていたら翌日には以下のメールが配信されてきました。
弊社サービス及び、他の利用者様に多大な影響を与える恐れがあるため お客様のサーバーアカウントにつきまして、凍結措置を実施させていただきました。 お客様アカウントの凍結解除は、初期化が必須となります。 同意いただき次第、初期化を行いますので、ご連絡くださるようお願いいたします。
実際にサイトにアクセスすると以下の画面が表示されるようになりました。

また、アカウントの凍結なので当然管理画面などにもアクセスできない状態です。
メールに記載されていたようにアカウントを復活させるには初期化が必要でサイトのバックアップ自体もう取得できない状態となっていました。
レンタルサーバー自体に自動バックアップの機能はありましたが、サーバー自体にアクセスできないとバックアップ自体が取得できないので復旧の対応方法に困りました。。
Google Compute Engineに乗り換えて復旧
サーバーから最新状態のバックアップが取得できないのでローカルにバックアップが無いか確認したところ、ファイルのバックアップが2021/11/15時点のものが見つかり、記事のバックアップが2020/8/16のものが見つかりました。
直近の記事やデータは残っていなかったのですが、これらのデータからサーバーを乗り換えてサイトを復旧することにしました。
レンタルサーバーではなくGCPを利用した理由
復旧先にレンタルサーバーを選択した場合、また今回のような事象が発生する可能性もあるためより自由度の高いパブリッククラウドを利用することにしました。
その中でも比較的簡単にWordpressの導入ができるGoogle Compute Engineを利用することにしました。
復旧手順
ここからは実際に復旧させた手順を備忘録として記載しておきます。
また、サイトと記事はバックアップの分は復旧させましたが、以下に関しては普及が不可でした。
- 記事のアイキャッチ画像
- サイト全体のデザイン
復旧の手順はGoogle Compute EngineにWordpressをインストールするところから実施しています。
- MarketplaceからWordpressをインストール
- SSL認証鍵の配置
- WordPressのファイルを復旧
- Cloud DNSを用いてドメインを設定
- Certbotを用いてSSL証明証の取得
- WordPressの記事を復旧
- 各種パスワード変更
- 失われた記事のサルベージ
- その他引っかかったとこなど
1. MarketplaceからWordpressをインストール

レンタルサーバーにはWordpressをボタン一つでインストールする機能があると思いますが、Google Compute EngineでもMarketplaceというサービスからWordpressのインストールが簡単に行えます。
マーケットプレースはGoogle Cloud Platformにさまざまなサービスを簡単に構築するためのサービスになります。
ここで WordPress Click to Deploy
と入力して検索するとWordpressを簡単にインストール可能なソリューション一覧が表示されます。
いくつかWordpressが表示されるのですが、赤枠で囲った通常のものを利用すると良いかと思います。
(個人的にWordpress High Availabilityが気になりましたが急いでいたということもあって避けました。ただ今もう一度説明読むとHigh Availabilityの方がオススメとは記載されていますね。誰のおすすめかわからんですが。)

クリックして運用開始を行うことでセットアップが始まります。

インスタンスの場所やサーバースペックなどを選択してインストールを進めます。
基本的にはデフォルトの設定でも問題無いですが、好みに応じてスペックアップしましょう。
目安の月額料金は右側に表示されます。(下の画像例だと月額68円だけどほんとか?)
おすすめの設定としてはZoneはasiaにして、ディスク容量を30GB程度にまで増やしておいた方がレスポンスが早くなるので自分はそう設定しました。

2. SSL認証鍵の配置
続いて、Wordpressのファイルなどを復旧する際にSFTP等で接続したいので作成したGCEに対して認証鍵を設定します。
端末によって多少コマンドが変わる可能性はありますが、以下のコマンドで認証鍵(公開鍵と秘密鍵)を作成します。
ssh-keygen -t rsa -C ユーザー名 -f ~/.ssh/wordpress
このコマンドでユーザー名を変更して実行すると以下の2つのファイルが作成されます。
- wordpress
- wordpress.pub
このwordpress.pubの方が公開鍵になります。
公開鍵をサーバーに登録することで自分の端末から秘密鍵を用いてSSHでアクセスが可能になります。
Compute EngineのVMインスタンスを確認すると先ほど作成したワードプレスのインスタンスがあると思うのでクリックして編集を押下します。

端末で作成した公開鍵の中身を認証鍵として登録します。
項目を追加
を押下して出てきたテキスト欄に貼り付ければOKです。

これでSSH認証が可能になりました。
それと今回はセキュリティを高めるために接続のポート番号の変更対応も行なっています。
- 22番のポートでの接続禁止&別ポート番号開放
- Firewallで閉じるのと開くの2つのルールを作成し、ネットワークタグでインスタンスと紐付け
- インスタンス内のsshd_configで接続ポートの変更、ssh再起動
また、自端末からはSSHでの接続を簡単にするためにconfigファイルを用いて接続のコマンドを簡易化しています。
3. WordPressのファイルを復旧
サーバーへのアクセスを鍵認証で行えるようになったので実際にWordpressをバックアップしてあったファイルから復旧していきます。
コマンドライン上で操作しても良かったのですが、GUIの方が慣れているのでFTPクライアントのCyberduckを用いて諸々の操作を行いました。
Cyberduckから新規接続で接続情報を入力します。
この際に接続方式をSFTPにしてSSH Private Keyで先ほど作成した秘密鍵を指定するようにします。
- 接続方式:SFTP
- サーバー:GCEの外部IP
- ポート:変更したのであれば変更後のポート番号
- ユーザー名:ssh-keygenコマンド実行時に-Cで指定したユーザー名
- パスワード:ssh-keygenで指定したなら指定した値
- SSH Private Key:ssh-keygenで作成された秘密鍵

これで接続できたら以下の階層に移動します。
/var/www/html
するとこんな感じのファイルがあると思うのですが、phpmyadminとwp-config.php以外のファイルは削除します。

削除する際に権限が足りないというエラーが出た場合には権限を付与する必要があります。
自分の場合は手っ取り早くやるために一時的に書き込み権限を全ユーザーに付与して対応しました。
sudo chmod a+w html
また、削除してバックアップからファイルを戻した後には所有者の変更なども行なっています。
所有者の変更を行なっていないとテーマの更新時にエラーが出たり、ワードプレスの更新にエラーが出たりなどの問題が発生します。(実際にエラーが出て最初混乱したのが私)
なので手順的には以下のようになります。
- 全ユーザーに書き込み権限付与
- コマンドラインでSSH接続してコマンド実行
sudo chmod a+w
- phpmyadminとwp-config.php以外削除
- CyberduckのGUIから操作
- バックアップファイルからwp-config.php以外を追加
- CyberduckのGUIから操作
- ファイルとフォルダの権限変更
- コマンドラインでSSH接続してコマンド実行(一括でファイルとフォルダそれぞれ設定)
sudo find /var/www/ -type f -exec chmod 664 {} \;
sudo find /var/www/ -type d -exec chmod 755 {} \;
- 所有者の変更
- コマンドラインでSSH接続してコマンド実行
sudo chown -R www-data:www-data /var/www
4. Cloud DNSを用いてドメインを設定
まだ記事は入っていませんが、テーマやプラグインなど諸々の復旧を行いました。
そのため、先に記事を入れても良いのですがワードプレスまわりがhttpで接続しようとするとエラーが発生するので先にSSL化をしてワードプレスなどにhttpsで接続できるようにします。
またこの際にDNSはドメインを取得したお名前.comを利用していたのですが、GCPのCloud DNSを利用することにしました。
Cloud DNSでの設定は詳細は省きますが手順としては以下のように行なっています。
- Cloud DNSでゾーンを作成
- Aレコードの作成:GCEの外部IPを指定
- CNAMEの作成:www.hogehoge.comに対してhogehoge.comを設定
- お名前.comでドメインに対してネームサーバーを変更
- 反映に最大72時間かかるので先に設定してしまってOK
Before/Afterを図にするとこんな感じ

5. Certbotを用いてSSL証明証の取得
続いてDNS設定したドメインに対してサーバー側で証明書を発行します。
簡易的にLetencryptoを使いました。
以下の公式サイトで利用しているソフトウェアとOSを入力することで適切なコマンドを指定してくれます。

ソフトウェアとOSはマーケットプレースからデプロイした後の画面に表示されているのでそこを参照してください。
自分の時はApacheとDebian10だったのでそれを選択してコマンドを確認しています。
基本的には出てきたコマンドの指示通りに入力するだけで取得可能です。
一点、サブドメイン含めて複数のドメインの証明書をまとめるためにコマンドを変える必要があります。
実際に証明書を発行する際に-dのオプションで取得するドメインを全て記載します。
sudo certbot --apache
↓
sudo certbot --apache -d hoge.com -d www.hoge.com
もし間違えてデフォルトのコマンドで実行しても後から-dのオプションを指定したコマンドを実行し直すことで設定の上書きが可能です。
certbotでは対話式で進んでいくので適当に答えながら進めばOKです。
設定が完了するとhttpsで接続が可能になります。
6. WordPressの記事を復旧
httpsでワードプレス管理画面に入れるようになったので次に記事をバックアップからインポートしていきます。
その前にワードプレスとドメイン名を紐づける必要がありました。
IPアドレスのままワードプレス管理画面にログインして以下から設定を変更します。
設定 > 一般設定
- WordPress アドレス (URL)
- サイトアドレス (URL)
この2つに今回設定したドメインを指定します。
> https://hoge.com
ワードプレスの記事のインポートは標準のインポートのプラグインを用います。
これで基本的には記事が入るのですが、標準だとアイキャッチ画像が全て抜け落ちるらしく再設定が必要です。
アイキャッチ画像までバックアップとしてとっておくには専用のプラグインなどを利用する必要があるとのこと。
7. 各種パスワード変更
本来最初にやるべきですが、Marketplaceを利用してワードプレスをインストール直後はパスワードが初期設定されていますが、こちらは自分でしっかりと変更しましょう。
- WordPress管理画面
- phpMyAdmin管理画面
8. 失われた記事のサルベージ
バックアップができていた記事に関してはこれで復旧ができているのですが、バックアップ後に作成した記事は以前復旧ができていません。
この部分に関してはWayback Machineを用いて可能な範囲で救出します。
Wayback Machineは各サイトのスナップショットを管理しているサイトです。
そのため過去の特定の日付時点のサイトを閲覧することが可能です。
ここのスナップショットが撮られるタイミングは決まっておらず、1ヶ月ごとに撮られたり3ヶ月ごとに撮られたりと不定期です。
そのため、運よく直近でスナップショットがあれば多くの記事が復旧可能です。
自分の場合は2021/12/26が最新となっていたため、多くの記事がサルベージ可能でした。
(といっても最近は記事の記載が少なかったので8件程度ですが)

ここから各記事を開いてDevelopperツールなどで内容を持ってくることで簡易的なサルベージが可能です。
こんな感じでsection以下をHTMLでコピーしてVSCodeなどで過不足を編集するイメージです。

実際に私はVSCode上で以下のように対応しました。
1. imgタグのsrcのwayback machine部分のhttps://...を削除
2. rootのsectionを削除
3. classに付属されている`error`を削除
4. imgタグのdata-srcのdata-部分を削除してsrcに
5. data-was-processedの記載を削除
6. デザインが崩れている部分を削除
- スポンサードリンクまわり削除
- CTAでデザイン崩れていた部分削除
3〜5は恐らくは画像のLazyLoad関連だと思うのですが、そのままだと画像が表示されない部分があってこれらの対応を行うことで画像が表示されるようになりました。
今回の惨事を繰り返さないために
- バックアップを別のサーバー or ローカルに保存するようにする
- アイキャッチ画像もバックアップとして取得できるようにする