ConoHaのVPSを使うこのブログが突如使えなくなった後に復旧した話

こんにちは。那須野です。

2021年は（も）超忙しいけれども1ヶ月に1回はブログを書くぞと意気込んでいたのに、なんと2ヶ月もブログ更新無しでした。というのも実はその裏には、5月末にこのブログに突如としてアクセスできなくなったという事案がありました。なんとか復旧できたので、経緯と応急処置と対策を備忘録としてメモしておきたいと思います。

ハッキングという恐怖

最後のブログ更新が2021/5/1。5月が終わり、なんとか月イチの更新をしようとブログに久しぶりにアクセスしようとしたのが6月頭の某日。なぜか開けずタイムアウト。何か調子がおかしいのだろうか。WindowsではなくAndroidスマホで開いても、iPhoneで開いても、macで開いてもダメだった。嫌な予感がした。

正直、ここ1ヶ月は一切触っていなかった。

とある文字が頭をよぎった。

「ハッキング」

一般的なセキュリティ対策しかしていない弱小Wordpressブログは、一流のハッカーに狙われてはひとたまりもない。狙われる理由に心当たりは無いが、何かの流れ弾を食らう可能性が無いわけではない。ブログをはじめて早8年。ビジネスパーソンとしてのスキルアップのために始めたこのブログは、ある意味自分の分身だ。寒気がした。

普段の癖として、とりあえずサーバーの再起動を試みた。システムの不具合の半分は「とりあえず再起動」で解決するというのは私の経験則だ。ConoHaのコントロールパネルから、再起動した。何も変わらなかった。サイトは開けないままだった。

サーバーを調査しようとmacのターミナルからアクセスを試みたが、なんとssh接続ができない。WindowsのWinSCPでも試したがssh接続できない。どちらのケースでも、謎のタイムアウト。何も情報がない。何が起きているか、全く想像がつかなかった。

システム界隈あるあるとして、トラブルを抱えた人が「何もやっていないのに不具合が起きました」と宣う『99%何かやってしまっているしかなさそうな事案』という笑い話はあるが、今回、私は本当に何もやっていない。Wordpressの管理画面はおろか、ブログのページすら見ていない。とにかく謎だった。

念のため、Conohaの障害報告がないか確認した。該当しそうなものは無い。障害報告メールも受け取っていない。絶望のカウントダウンが迫ってくる音が聞こえた。

そういえば…GoogleAnalyticsを入れていたのでアクセス状況から情報が分かるかもしれない。恐る恐る画面を開くと、そこには1つの明確な情報があった。

5/25以降のアクセスが一切ない。5/24-5/25に何かが起こったということが分かった。ただし、分かったのは日付だけ。これ以上はGoogleAnalyticsからは分からなかった。

束の間だけの安心

GoogleAnalyticsから少しの情報を得た私は、何か他に手掛かりがないか頭を巡らすと、そういえばConohaのコントロールパネルからコンソールに入れることを思い出した。このコンソールは、最初にサーバーを立ち上げるときに一瞬入ったが使いにくいのですぐにやめてmacのターミナルに切り替えたという代物だ。あまり期待していなかったが、藁にも縋る思いでrootログインを試みた。

ログイン…できた…

正直、ログインしたあとに表示されるのは「Last login: {date} ...」という簡素な文字だけであるため、一瞬何が起きたか認識できなかったが、コンソール経由とはいえどログインできたという事実を前に、データが残っているかどうかを急ぎ確認しにいく自分がそこにはいた。

なんと、ファイルのデータも残っているし、データベースのデータも残っていた。ひと安心したものの、たとえデータベースのデータをdumpしたところで、ssh接続できない現状ではデータをConoHaのVPSからサルベージすることはできない。これを機にAWSへの鞍替えを考えていた私にとって、データはあるもののWebにはアクセスできず、データのサルベージもできないこの状況は非常に歯がゆいものであった。

各種サーバー設定を見たが、ポート番号が変更されたわけでも、認証鍵が変わったわけでも、許容されるアクセス方法が変わったわけでもなかった。ユーザー情報が変わっているわけでもなく、何か悪意のあるハッキングを受けたわけではなさそうだった。この結果に、安心ではなく、ある種の薄気味悪さを感じていた。

そして・・・よくよく考えれば、ターミナルやWinSCPからはssh接続できないのにコンソールからはログインできるというのはsshサーバーが落ちている可能性があると思い浮かんだ。すぐさま「service sshd restart」をかけたが、結果は何も変わらなかった。まさに、万策尽きた状態であった。

転機

多忙の続く自分は、そうやすやすと時間を取ることができない。一通りの調査が失敗に終わった結果として、また1ヶ月が経過した。そして今日、某氏に本件を相談したところ、とあるブログ記事が返ってきた。

ConoHa VPSのハードウェア障害によるSSH接続不可・Webサイトアクセス不可の対処方法

日時が完全に一致するわけではないが、事象が完全に一致している。内容をざっと洗ったところ、対策の差分として、iptables（ファイアウォール）のリスタートが言及されていた。

「iptables…お前なのか…？」

改めてコンソールにログインし、「service iptables status」で確認すると、

と表示され、まさかの『inactive』状態が判明。ブログ記事の状況とは違っていたが、これが本命だと思われた。続いて、おそるおそる「service iptables restart」をかけると、

…ブログが…表示された（！）

続いてWordpressの管理画面にも無事ログインでき、ブログ記事とはちょっと症状が異なる（軽微である）ことは気になったが、ひとまずは事なきを得たのだった。

対策

今回は幸運にも結果オーライではあったものの、やはりハッカーに狙われたら一貫の終わりという恐怖はぬぐえないわけです。やはり、ちゃんとバックアップを取っておこうと考えました。

やはり使うならAWSでしょう。Amazon S3に手軽にバックアップできるプラグイン『BackWPup』を使うことにしました。設定のプロセスは以下の通りです。

1. BackWPupをインストールし、有効化する。
2. AWSのIAMにて、バックアップ作業用のユーザーを『AmazonS3FullAccess』ポリシーをアタッチして作成し、アクセスキーIDとシークレットアクセスキーを取得する。
3. Amazon S3にて、バックアップ先のバケットを作成する。
4. BackWPupの『Add new job』にて、上述のアクセスキーとシークレットキーを使って週1程度でデータベースとファイルのバッグアップを設定する。他の設定は、だいたいデフォルトのままで。

これにてひとまず安心です。ヒヤヒヤしましたが、いったんは結果オーライということでConoHaのVPSを継続しようと思います。

でも…ビジネスで使うのはもうVPSではなくAWSやGCPやAzureなどのパブリッククラウドになってきているので、VPSを継続するメリットが薄くなっているというか、パブリッククラウドの運用経験を積み上げるメリットが日に日に大きくなっているので、いずれ考えましょうか…