本当にあった怖い話「サーバーがクラッキングに遭って復旧できなかった件の末路とやるべきだった事」

早川朋孝
EC専門のSE

2021.03.22 Web界隈のお話ウェブ運用

さくらインターネットやカゴヤなど、またAWSやgcpなど色々なサービス事業者から便利なサーバー周りのサービスが展開されており、気軽に使うことができる環境が整っている。一昔前ならルート権限のあるサーバーを操作するには、自分でサーバーを立てるとか、あるいは専用サーバーを借りるとか相当な費用と労力が必要だったが、今は安価にルート権限のあるサーバーを操ることができ、隔世の感がある。

とはいえ、サーバーを管理したりサービスを構築するのはやはりエンジニアでないとできないのが現実だ。セキュリティリまわりのリスクをゼロにすることなど不可能で、どんなに鉄壁にしても必ず穴はある。従って、サーバー周りのサービスはある日突然使えなくなることを前提に、日々の運用を設計しないといけない。こんなことはウェブエンジニアであれば当然理解しているが、理解していても面倒だから放置とか、あるいはリテラシーが低くてバックアップをとることを考えていないなどのケースがある。

今回は不運なことにウェブサイトが消失した事例を紹介しよう。

クラッキングされた事例

先月のことなのだが、ある会社から自社のウェブサイトが表示されなくなったから調べて欲しいと依頼を受けた。その会社のウェブサイトはさくらVPSを使っており、さくらインターネットのabuse対策チームからこんな連絡を受けたとのこと。
「abuse対策チーム」とはなんぞや？と思い検索したら、さくらインターネットが提供するサービス内から、不正アタックや権利侵害に関するものがあれば受け付けますよ、といいうものだった。さすがさくらインターネット、ちゃんとした会社である。いや、窓口があるのは当たり前か。
https://abuse.sakura.ad.jp/

さて、その会社がさくらインターネットから受け取ったメールは以下のようなものだ。少し長いが引用する。引用メールは長いので全部まじめに読む必要はない。

○○ 様

ご連絡いただきありがとうございます。
さくらインターネットabuse対策チームでございます。

ご連絡いただきましたところ恐れ入りますが、現状のまま制限を
解除いたしますと前回同様の症状が発生する可能性がございますため
制限を解除することができかねます。ご了承ください。

制限解除につきましては、本件のご回答及びその内容を確認、検討しました
うえで、弊社営業時間内での対応となります。あらかじめご了承ください。

なお、ご利用サーバにつきましては、管理者権限をお客様にお渡し
しているサービスとなりますため、原因については弊社にて特定
することができません。

恐れ入りますが、お客様にてご利用サーバ内に不審なファイルや
プロセス等が起動していませんか調査・ご対応を行っていただけますよう
お願いいたします。

また、一例となりますが、考えられる原因等については以下をご参考ください。

○考えられる原因
・CMS（WordPress・joomla!・など）やウェブアプリケーション、その他の
ウェブに公開したプログラムの脆弱性を悪用されている。
・CMS・ウェブアプリケーション類のログイン権限をもつユーザのパスワードが
漏洩し、悪用されている。
・アプリケーションサーバ、データベース他、ミドルウェアの脆弱性を悪用されている。
・アクセス制限を設定していないサービスを悪用されている。
・管理用ユーザ、一般ユーザ、試験目的のユーザアカウント等のパスワードが漏洩し悪用されている。

○必要な対策
・【重要】ご利用サーバ内の覚えのないファイル・フォルダを探し削除する
・【重要】不正なプログラムが動作していないか全てのプロセスを調査する。
・chkrootkit、rkhunter、maldetect等を活用し攻撃プログラムを捜索し削除する。
・悪用されたユーザアカウントがないか調べて対策する。

・重要なデータを他の環境にバックアップする。
・調査困難な場合・原因不明の場合は、OS再インストールを検討する。

○再発防止策
・不要なCMS・ミドルウェア・ソフトウェアを削除する。
・不要なサービスを停止する。
・不要なユーザアカウントを削除する。
・パスワードの管理ポリシーを検討する。

・OSのアップデートを実施する。
・ミドルウェア・ウェブアプリケーション・CMS等を最新のバージョンへアップデートする。

・iptables・firewalldなどファイアウォールを設定する。
・各ミドルウェアに固有のアクセス制限機能がある場合、設定する。

■注意事項・考えられるリスク
・対策が不十分な場合、再発する危険があります。
・調査対策が困難な場合は、OS再インストールをご検討ください。

▼OS再インストール(さくらのVPS)
https://help.sakura.ad.jp/hc/ja/articles/206207961

さて、こんなメールが来た経緯を先方に質問すると、かなり昔営業されるがままにWeb制作会社と契約しウェブサイトとCMSを契約し、その管理にさくらVPSを使っているとのことだった。もちろんその人自身はhtmlも知らないど素人である。納品後自分でウェブサイトを編集したことは一度もないとのこと。ずいぶん前から業者と連絡はとれなったが、ウェブサイトは表示されているので気にしていなかったそうだ。

そんなある日、さくらインターネットからメールが来て、ウェブサイトも表示されなくなった。メールの内容がまったく分からないから相談したい、とのことだった。

時すでに遅し

復旧が可能かサーバーのログイン情報を預かりssh接続を試みたがすでにできない。というか、さくらインターネットから対策はいついつまでにやるよう連絡が来ていて、私が先方から連絡をもらった時点ですでにその期限を過ぎていた。SSH接続はロックされていて、CPUも制限がかかりできることがない。私は「もうできることないです」と先方に無情に伝えた。そう復旧不可です。

ウェブサーバーに限らず、人の作るシステムに障害はつきものである。障害やトラブルはいつ発生してもおかしくないくらいの認識をしておいて間違いない。先日のみずほ銀行のシステムトラブルもしかりだ。

みずほ銀行のエンジニアは今ごろ塗炭の苦しみを味わっているに違いない。お疲れ様です。
日曜に安いコストで銀行サービスを享受している一般の利用者が、少しシステムが止まったくらいで文句言うとかなめてるよね。そんなに都合よくシステムがお前のためだけに安定稼働するかよ。

— 早川朋孝 | Webエンジニア業界15年 (@ShiroTruffe) February 28, 2021

便利なシステムをいつでも使えるとつい勘違いしてしまうが、利用者にだけただひたすら都合のいいシステムなど世の中には存在しない。ある日突然トラブルが起きたり、使えなくなったりする。宇宙にある全ての物質は無秩序な状態に戻ろうするのだ。そうエントロピー増大の法則である。システムももちろんその対象だ。この辺りの話に関心がある方はデイヴィッド・クリスチャンの『オリジン・ストーリー』とか、私の愛読書『核は暴走する』を読んでください。

ウェブサーバーでとるべきバックアップ

さて、ウェブサーバーの話に戻すと、ここまで障害が起きることが分かっているのだから、復旧できるような体制にしておくしかない。どんなに万全な対策をとっても災害や情報流出、些細なトラブルがきっかけとなり事故は起きる。だからバックアップをとっておくのだ。

CMSを導入している場合、単に「バックアップをとる」と言っても色々なレベルのバックアップがあるので、具体的に説明しておこう。

ウェブサーバーとCMSのバックアップの種類

DBのdumpと画像などメディアファイル
CMSの設定ファイル
ディスクイメージ

DBのdumpと画像などメディアファイル

CMSを導入している場合DBのdumpと画像などメディアファイルさえあれば、復旧はたいていの場合なんとかなる。例えばWordPressなどのフリーのソフトウェアを使用している場合はソフトは誰でも入手可能なので、データベースと画像ファイルやCSSなどの外部ファイルさえあれば最終的に復旧はできる。最低限のバックアップだし、また扱うデータが少なくて済むので、日常的に取得するべきバックアップはこれだろう。ウェブサイトの更新頻度にもよるが、毎日とか週間といった頻度だ。

CMSの設定ファイル

DBのdumpや画像ファイルで記事を復元できても、デザインテンプレートなどは復元できない場合がある。これはCMSの仕様にもよるが、例えばWordPressの場合はデザインまでは復旧できない。したがってCMSの設定ファイルやデザインテンプレートのようなものもバックアップを必ずとるべきだ。これも更新頻度による。日常的に更新するならDBなどと一緒にバックアップを取得する運用体制にしないといけない。

ディスクイメージ

ディスクイメージとはOSを含むバックアップだ。これはデータ容量が極めて大きく扱いにくい。日常的にとるバックアップではないし、そんなのエンジニアでも面倒がってやらないと思う。しかしいざ有事の際は、別のサーバーにまるごと現環境を再現できるのだから、やはりとっておくといい。OSやミドルウェアなどの変更がある度にバックアップをとればいいだろう。

また、ライセンス購入したCMSなどの場合も、このディスクイメージがあると復元できる可能性がある。例えば販売元の会社がなくなってしまった場合などに備えてディスクイメージを作成しておくといいだろう。ただし、最初の書いた通りデータ容量が大きいので、サーバー容量が50%以下のときでないとディスクイメージは作成できない。

以上はCMSを使っている事を想定しているが、他にもバックアップを「どこに保存すべきか」など考慮すべき点はたくさんある。例えば、ある会社に一人しかエンジニアがおらず、バックアップをそのエンジニアに任せきりの場合、その人が退職したら、あるいは突然病気になったら、、他の人はバックアップの保存場所も分からない。こんなことはどこの会社でも起こり得ることだ。