Webサイトのお助け隊

改ざんの相談は、たいてい「ハッキングされました」という言葉では来ません。「サイトが表示されなくなった」「管理画面のログイン画面まで行き着かない」「消したはずのファイルがまた出てきている」。そういう症状の相談として届き、調べていくうちに侵入されていたことが分かる、という順番です。しかも厄介なのは、目に見えている壊れ方と、実際に起きていることの規模がまったく釣り合わない点にあります。1ファイルのパーミッションがおかしいだけに見えて、同じサーバーの契約にぶら下がった十数サイトが同時に汚染されていた、ということが実際に起きます。ここでは、改ざんサイトの復旧で実際に踏んだ手順と、そこで分かったことを時系列で残します。

症状の見え方と、実際に起きていることのずれ

ある共用レンタルサーバー上のサイトで受けた相談は、最初は「サイトが表示されない」というだけの内容でした。FTPでつないで見た限り、ルートの index.php のパーミッションがおかしい。それだけなら数分で終わる話です。ところがディレクトリ全体を舐めて確認していくと、ファイルの中身そのものが書き換えられており、あわせてパーミッションも変更されていました。この2つはセットで行われます。ファイルを汚染するだけでなく、管理者が自分で直せない状態を同時に作る、という手口です。だから「パーミッションを戻したのに直らない」「ファイルを上書きしようとしたら書き込めない」という状況が生まれます。

もうひとつ、この案件で見落としやすかったのが .htaccess でした。ルート直下だけでなく、各ディレクトリに置かれます。汚染された .htaccess はリダイレクトやアクセス拒否を仕込むので、「ログインページに辿り着けない」という症状を作ります。この症状はDNSの障害にも見えるので、ネームサーバーやAレコードを疑って時間を使ってしまいがちですが、実体はファイル1つです。改ざんを疑う場面では、.htaccess を必ず全階層チェックしてください。

初動が止まるのは、たいてい権限のところ

調査に入る前の段階でつまずくことがあります。渡されたFTPアカウントに書き込み権限がなく、パーミッションの変更もできない。この状態では汚染ファイルの差し替えも、退避もできません。実際、初動が1日以上止まった案件があります。改ざん対応は時間との勝負なので、この待ち時間はそのまま被害の拡大時間になります。

着手前に確認しておく項目は3つです。FTPまたはSFTPでファイルの書き込みとパーミッション変更ができるか。サーバーのコントロールパネルにログインできるか。データベースに接続できるか。ここが揃っていないなら、調査より先にアカウントの手配を進めます。

ログイン周りでもうひとつ詰まりやすいのが、二段階認証の設定単位です。サーバーへのログインと、サーバーパネルへのログインは別々に設定されていることがあり、依頼者側がこれを同じものだと思っていると、認証コードの受け取り待ちで無駄な時間が発生します。最初にこの違いを説明しておくと手戻りが減ります。感染しているサイトのファイルを手元の環境に落として調べる場合は、自分の環境側の安全確認も必要になります。

実際の対応記録

相談は1サイト、汚染はアカウント全体

複数のサイトを1つのホスティング契約でまとめて運用していた事業者からの復旧依頼です。相談として上がってきたのは特定のサイトの不調でしたが、同じ契約の配下を確認したところ、19サイト以上が同時に汚染されていました。ここが改ざん対応で一番大事な判断で、調査単位はサイトではなくホスティングアカウント全体になります。1サイトだけ駆除しても、隣のサイトに残った不正ファイルから再感染するためです。

不正に置かれたファイルには、名前の付け方に傾向があります。wp-pluggins.php のように、正規の wp-plugins に一文字足して見た目を似せたもの。mini.php、wp-charm.php、Me_Guard.php、dude.php のように、WordPressの構成とは無関係な短い英単語や、それらしいが実在しない名前。ファイル一覧をぱっと見て「WordPressのファイルっぽいけれど、こんな名前だったか」と一瞬迷うものは、まず疑ってください。判断に迷ったら、同じバージョンのWordPressを公式から落としてきてファイル構成を突き合わせるのが確実です。

検出したファイルはドメイン別の一覧にまとめました。どのドメインの、どの階層に、どのファイルがあったか。これを一覧の形にしておくと、被害の規模と残っている作業量が依頼者側にもそのまま見えます。復旧作業そのものより、この一覧が後の判断材料として効きます。

この案件で分かった、構成そのもののリスクがひとつあります。複数ドメインを同じホスティングアカウントの配下に置いていると、1サイトの脆弱性が全ドメインへ波及します。加えて、制作の途中だったドメインや、まだ公開していない準備中のドメインまで汚染されていました。「まだ公開していないから安全」は成り立ちません。公開前でも、ファイルがサーバー上にあれば対象になります。復旧が終わったあと、再発防止としてサーバーの移設と、サイトごとの環境分離を続けて実施しています。

消したファイルが、名前を変えて戻ってくる

2サイトを別のサーバーへ移す案件の途中で、移行元に見覚えのない index.php が置かれているのを見つけました。削除して作業を続けると、今度は別のディレクトリの下にファイル群が見つかる。それも消すと、ディレクトリ名を変えて同じものが置かれる。段階的に再発したわけです。

原因は、CGIで動く古いバージョンのCMSでした。Movable Typeの5.2系がそのまま動いており、既知の脆弱性が放置されていました。そこからWebシェルを設置され、フィッシングサイトの踏み台にされていた、というのが実態です。wso.php のような、この種のファイルとしてよく知られた名前も含まれていました。

侵入されたファイルを見つける手がかりは、ログとファイル一覧の3点に集約できます。ひとつ目は、移行やバックアップ復元の直後に見覚えのないファイルが増えていないかの確認。ふたつ目は、サーバーのエラーログに、存在しないはずのディレクトリやファイルへのアクセスが記録されていないかの確認。攻撃側は既に設置済みのファイルを叩きに来るので、削除した後もアクセスの記録が残り続けます。3つ目は、アクセスログの不審なPOSTです。通常の閲覧でPOSTが飛ぶ場所は限られているので、それ以外へのPOSTは目立ちます。

この案件で確定したのは、ファイルを消すだけでは終わらないという前提です。バックドアは複数設置されているものとして扱い、サーバーの移行、関係するパスワードの全変更、使っていないSSHの無効化、CMSのメジャーバージョンアップまでを一括で実施しました。Movable Typeは5.2系から8系へ上げています。

作業中、サーバー会社のサポートにも確認を取りました。返ってきた回答は「新しいサーバーへの移行は速度の改善であって、セキュリティの強化ではない」というものでした。移行を提案する側にとっては都合のよくない回答ですが、そのまま依頼者に伝えています。侵入対策としてサーバーを移すだけでは不十分で、脆弱性の根本、この案件では旧バージョンのCMSを潰さない限り再発します。あわせて、共用サーバーでは同一サーバー上の他の利用者が高い負荷をかけたり乗っ取られたりすると、自分のサイトの表示速度や可用性まで巻き添えになる、という説明も受けています。

バージョンを上げた後には、コードのバグではない不具合も出ました。抜粋の文字数設定が140文字になっていたために画像のURLが途中で切れ、画像が表示されなくなるというものです。同じ構成の2サイトのうち片方だけ症状が出なかったので設定値の差分を探したところ、そちらは検証用に300文字に変えてあったことが分かりました。メジャーバージョンアップの後に出る表示崩れは、まずテンプレートの設定値を疑うのが早道です。

結果として、見覚えのないファイルの再出現は止まり、2サイトとも新しいサーバーで稼働しています。ただし移行当日には、予約フォーム、会場を紹介するページ、キャッシュ起因の表示不整合と、4種類の不具合が出ました。予約フォームはスマートフォン版とPC版で別実装になっており、片方だけ直して終わりにすると、もう片方でエラーが残ります。改ざん対応と移行を同じ日に行うなら、その日は丸一日空けておくのが現実的です。

どこまでやるかを、最初に線で引く

改ざん復旧の見積りが業者によって大きく違うのは、作業範囲の定義が違うからです。表示を戻すところまでと、原因まで潰すところまででは、工数が数倍変わります。前者は汚染ファイルの除去とコアの入れ替えで済みますが、後者は侵入経路の特定、脆弱性の是正、再発防止の構成変更まで含みます。

共用サーバー上の改ざん案件では、依頼者の本当の目的が「中身を確認して別のサーバーへ移したい」ことでした。そうであれば、完全な除去まで踏み込む必要はありません。目的に対して必要十分な範囲だけを実施し、そのぶん短期間で終えています。

ただし、この形を取るときに絶対に外せない手続きがあります。「できていないこと」を文章で残すことです。この案件では、完全な除去ではないため、そのままの状態でサイトを公開して使い続けることはできない、と明記しました。汚染の原因が脆弱性のあるプラグインなのか、パスワードの漏洩なのかは特定できていません。原因を特定しないまま再公開すれば、同じ経路からまた入られます。ここを曖昧にしたまま「直りました」と報告すると、後で「直したはずなのにまた壊れた」という話になります。

期間について正直に書くと、改ざん復旧は着手前に日数を確定できません。開けてみるまで汚染の範囲が分からないためです。共用サーバー上の案件では、当初の予定から5日ずれています。納期は「調査後に確定する」という形で留保しておくのが、双方にとって現実的です。

復旧の後に変えたこと

直すことと、二度目を防ぐことは別の作業です。復旧が終わった時点で手を止めると、しばらくして同じ相談が来ます。実際に実施した再発防止は、認証情報の全変更、使っていない接続口を閉じること、サイトごとの環境分離、そしてCMSとプラグインを最新に保つ運用への切り替えでした。

認証情報の変更は、WordPressの管理者パスワードだけでは足りません。FTPとSFTP、サーバーのコントロールパネル、データベース、そしてサーバー会社のアカウントまで含めて変えます。侵入時に持ち出された可能性のあるものは、全部です。長期間更新されていないプラグインは、更新するのではなく外すという判断も要ります。

運用側では、サーバー移行を伴った場合に必ず案内することがひとつあります。旧サーバーのFTP設定を、依頼者の端末から削除してもらうことです。これを伝えないと、依頼者が旧サーバー側のファイルを編集してしまい、「編集したのに反映されない」というトラブルになります。改ざん対応の後で旧環境を残しておくと、そこが放置されて再び踏み台になるので、止める時期も一緒に決めておきます。

そして、証跡を残すことです。作業前の状態、検出した不正ファイルの一覧、実施した内容と実施していない内容。改ざん対応では、復旧の直後に「見た目が変わった」「別の不具合が出た」という指摘を受けることがあります。それが作業によるものか、もともとの状態かを客観的に示せるかどうかは、作業前の記録があるかどうかで決まります。日常の保守で更新履歴とバックアップを残しておく体制は、WordPress保守の対応内容としてまとめている範囲そのものです。

なお、改ざんが原因かどうかの切り分けで迷う症状もあります。画面が真っ白になるだけなら、テーマやプラグインの更新が原因のことも多いので、WordPressが真っ白になる原因と、上から順に潰す切り分け手順を先に一周してください。サーバー側のエラーとして返っている場合は500 Internal Server Errorの原因を絞り込む順番、ログイン画面の周りで詰まっている場合はwp-adminに入れない時の対処、リダイレクトループと白紙の画面が、それぞれ対応する切り分けになります。

よくある質問

不正なファイルを自分で削除すれば直りますか

表示は戻ることがあります。ただし、それで終わったことにはなりません。バックドアは1つとは限らず、複数設置されている前提で考えてください。実際に、見覚えのないファイルを削除したら別のディレクトリにファイル群が見つかり、それも消したらディレクトリ名を変えて置き直された、という経過をたどった案件があります。削除で表示が戻ったなら、そこからが調査の始まりです。

新しいサーバーに移せば安全になりますか

なりません。サーバー会社に確認した際も、移行は速度の改善であってセキュリティの強化ではない、という回答でした。汚染されたファイルをそのまま持っていけば、新しいサーバーでも同じことが起きます。移行が有効なのは、環境を分離する目的や、旧環境ごと切り離す目的で行う場合です。根本の脆弱性、たとえば古いバージョンのCMSやプラグインを放置したままなら、どこへ移しても再発します。

どこから侵入されたか特定できますか

状況によります。アクセスログとエラーログが十分な期間残っていれば、不審なPOSTや存在しないファイルへのアクセスから経路を絞り込めることが多いです。一方で、共用サーバーのログ保存期間が短く、侵入から発覚までに時間が経っていると、特定できないまま終わることもあります。特定できなかった場合は、そのことを前提として扱ってください。原因不明のまま再公開するのと、原因を潰してから再公開するのとでは、その後の運用の意味が変わります。

復旧にはどれくらいの期間がかかりますか

着手前には確定できません。汚染の範囲はファイルを開けてみるまで分からず、1サイトの相談が実際には十数サイトの調査になることもあるためです。調査で範囲を確定してから期間を出す、という進め方にしています。急ぎの状況であれば、まず表示を戻すところまでを先に行い、原因の調査を並行させるという分け方もできます。