[うらうつ。総本部へ] [インデックスへ]
Wordpressが不正アクセスで使い物にならなくなった話
■要約
当サイトで運用していたWordpressが不正アクセスによってマルウェアに感染し、「404
Error」になって、安全のため当該ページ(300記事くらい)をすべて削除したという話です。
応急対応、再発防止策などをまとめましたが、とにかく教訓は、セキュリティを管理し切れない(更新しきれない)場合は、安易にWPを使わないほうが良いということに尽きます(管理するための方法は別記)。
(追記)どうも、Movabletype(MT)の脆弱性「も」同時に狙われた可能性があります。対策をとっても不審なファイルが毎日増産されていたので、さらに対策を追加しました。
■はじめに
- Wordpressは、もっともよく使われるCMSであるが、「もっともよく使われる」が故に狙われやすく、セキュリティ上の脆弱性というのは常に言われてきた。ちょっと更新を怠ると、マルウェア、不正アクセス、踏み台の餌食として簡単に狙われてしまう。
- 当サイトも「新着情報」と「Nicky」というコンテンツでWPを活用してきたが、更新が滞った隙をついて、餌食に。
-
「.htaccess」がすべてのフォルダに自動で大量生成され、まずWPは何をしても表示が不可能になり、そこから派生して、トップページすらまともに表示されないというとんでもない状態に。
■対策(さくらインターネットの場合)
<応急処置>
*WPはあきらめた
-
やろうと思えば、データベースさえ無事ならば、WPの再インストールと、旧WPフォルダ直下のコンテンツや設定ファイルの退避⇒再インストールした新WPのフォルダへの移動でWPのコンテンツ自体は、理論上は復旧可能だ。ただし、何らかの設定ファイルが汚染されていない保証はないし、旧WPフォルダをローカルでバックアップしているわけでもなかったので、危険と判断。WPのフォルダは全削除した。
*まずはサーバーパスワードの変更
-
WPのセキュリティーホールからの汚染である確率が高いが、念のため、サーバーのパスワードはより堅牢なものに変更。
<対応>
*ローカルファイルとの置換
-
サーバーのコントロールパネルで不正アクセスがあった日移行に更新されていたファイルを洗いだし、すべてローカルのバックアップファイルと置換。これで仕組み上、汚染のあったファイルは「きれいな」ファイルに置き換わった
。このサイトは、もともとHTMLや画像など静的なファイルが中心なので、これらのファイルの更新日時が正常(不正アクセス以前、不自然な時刻でない)であれば、それらのファイルは基本的には「きれい」と判断できる
。
*大量の「.htaccess」ファイルの削除
*サーバーステータス⇒「動作中のプロセス」から、不穏な動きをしているプロセスを停止
- 見たことのないPHPが勝手に稼働していたので、削除(こいつが、好き勝手に.htaccessを生成していた模様。消したらファイルの自動生成が止んだ)。
*データベースの削除
-
上記を受け、マルウェアの影響でデータベースそのものが汚染されている危険性もあると判断し、WPに紐づいていたデータベースをサーバーから完全に削除。これで300本近い記事はすべて復旧不可能に。
<再発防止策>
*WAF(Webアプリケーションファイアーウォール)の設定
- サーバーコンパネの「セキュリティ」からすべての運用ドメインに対して設定。
*海外IPの制限
- 海外からの不正アクセスの設定をサーバーコンパネから実施。
*パーミッションの設定を厳格に
- .htaccessファイルやHTMLファイルはすべて「604」にする。
*そもそも個人で、安易にCMSを運用しない
-
放置が生じてしまう管理状況のCMSは格好の標的。放置するくらいなら消すか、ローカルにバックアップを取って、すべて静的なコンテンツに替えるべき(CMSは、常にコンテンツが更新されることが前提のツール。そこまで更新頻度が高くない場合は、わざわざCMSでサイトを構築する必要がそもそもない)。
- それでも運用する場合は、常時SSL化および上記の対策は大前提として、「少なくとも毎日更新レベルの、頻繁な更新を行う」「管理画面を少なくとも毎日チェックする」「(かんたん設定などによる)初期設定のままでは使用しない」「WPが入っているとすぐにわかるフォルダに置かない」「常にWPのバージョン、プラグイン、テーマのバージョンを最新状態に保つ」「使用していないプラグインやテーマは放置せず、すべて削除する」「出所の怪しいプラグインやテーマは絶対に使用しない」「半年以上更新されていないプラグインはインストールしない(削除する)」「投稿ページにユーザー名を表示しない」「ユーザー名の表示が不可能な対策をとる」「ユーザー名はサイト上のHNではなく、推測不可能な文字列にする」「WP管理画面と、DBのパスワードは
頻繁に変更する」「信頼のおけるセキュリティプラグインを使用する」「1か月単位で放置してしまう場合は、躊躇なくWPおよびDBごと削除またはコンテンツのバックアップをローカルにとって、静的なコンテンツに移行させる」ということが最低限必要である。この覚悟がない場合は、基本的に個人で安易にCMSを運用することはやめたほうがよい。
<MTの脆弱性を狙われた(追記)> 上記の対策をとっても不審な事象が続いた。おそらく、movabletypeの脆弱性を付かれた攻撃「も」受けたため、対策を追加。
*MTの再インストール
- MTのインストールフォルダをすべて削除し、ローカルのバックアップを再インストール。
*MT関連のセキュリティ設定(パスワード含む)の見直し
- MTのパスワード、データベースのパスワードをより堅牢なものに変更。なおDBのPWを変更すると、MT管理画面が開かなくなるので、「mt-config.cgi」内のPW書き換えも忘れずに行う。
- パスワード変更後、「mt-config.cgi」のパーミッションは「600」に変更する。
*メールフォームの使用停止
- MTとは関係なしに、上記のWAF経由で不正アクセスが検知されたメールフォーム系のCGIの使用を停止
。サイト上からリンクをクローズするだけでなく、物理的にサーバーに残さない対応とした。
*MTインストールフォルダ直下より、実行系CGIの削除またはパーミッション見直し
- まずはmt-xmlrpc.cgiを削除する(最重要)。ただしこの場合、外部ソフトからの投稿は一切できなくなる
。
- トラックバックやコメントの機能はもともと使用していなかったので、mt-tb.cgiとmt-comments.cgiのパーミッションを「000」として、アクセスそのものを不可能にする。
- MTインストールフォルダのその他の.cgiファイルのパーミッションを、すべて「700」に変更する。
- MTインストールフォルダのパーミッションを「705」に変更する。
*データベースのアップデート
- 念のため、MTのデータベースのバージョンをアップデート。
<まとめ>
*ルートディレクトリ以下全ファイルを、ローカルのきれいなバックアップファイルで上書きする(バックアップできていないファイルはあきらめる)
- 汚染後のファイルはローカルにダウンロードしない。必ずローカルのきれいなバックアップでサーバー側を上書きする(一方通行推奨)。バックアップは重要。
*すべてのパスワードを変更する
- 堅牢なパスワードに変更。サーバーパスワードだけでなく、CMSの管理パスワードや管理画面のパスワードなども根こそぎ変更しておく。
*WP:管理できない場合は手を出さない
- 使い続ける場合は、常に最新版にアップデートする(プラグインも、テーマも)。
*MT:mt-xmlrpc.cgiを消す
- 外部ソフトからの投稿が一切できなくなるが、「臭いものは元から絶つ」のが鉄則。
[うらうつ。総本部へ] [インデックスへ]