私の知る範囲においては今回、Sakuraインターネット(それも比較的古いサーバー)とXREA(やっぱり旧くからあるサーバー)上のCMSが攻撃対象となっていた。巷ではWordPressの被害が耳目を集めるが、それでもWordPressは今回のようなクラシックなコメントスパムに対しては頑健のようで被害が比較的軽微であったのに比し、MTOS(MovableType Open Source)のほうは、事後の復旧に手間がかかったという意味で、被害が深刻であった。

MTOS含めMobableTypeサイトへの大量コメントスパムはすでに2年ほど前から話題となっていて対策も公表されてきた。知っていれば適切な対応はできたのだろう。知らないあんたが悪い。けど、自分が見たいもの聞きたいものしか見えない聞こえないヘタレな生態ゆえ、事後にあがくとどうなるか、ここで報告するのはある種のドキュメンタリーであって、しかしベストプラクティスではない、反面教師的な顛末である。

MTOSの開発が現在の5.2.7をもって終了の見込みというニュースが驚きをもって迎えられたことは記憶に新しい。この夏のサプライズの一つであった。セキュリティ上の問題などのサポートを2015年10月までSixApart社が継続的に行うと公表されても、そろそろ潮時かなと感じた諸兄は少なくないでしょう。2年という時間が永遠ということにも聞こえかねないIT業界にあって、しかし、成長の見込みを断たれたプラットフォームに貴重な時間を割くのは、やはりもったいない。

そういうタイミングでのコメントスパム、なのである。狙いは管理画面の乗っ取りにあるらしい。ログをみると、攻撃は5月に始まった。一つ一つのコメントのサイズが大きい。そして、一時間に200件ほどの書き込みが行われ、データベースのサイズが急膨張する。コメントユーザとして登録可能なサイトでは、数千のユーザが新規登録され、コントロール画面へのログインが試みられていた。IPアドレスを調べると、大多数が中国に割り当てられたものであり、それに交じって、米国テキサス州からのものも含まれた。

XREAの無料サービスのように容量の限られたサービスでは、知らぬ間に、あっというまに制限を超過し、コンテンツの破壊に繋がる可能性がある。今回のケース、XREAではしばらくの間サイズ超過を猶予してくれるようで、なんとか復旧が可能となった。

MTOSにしてもWordPressにしても、コメントがつけばメールで知らせて来るような設定としているのが普通である。のではあるのだが、どうせ今回もスパムだろうと、放置する。そういう習慣になっていても不思議ではない。スパムコメントも通常は、せいぜい数行のもの。だからそれが原因でパンクするなんて、想像だにしない。結局、コメントは数万件に及ぶまで、気がつかない。

昨年の今頃は、SEO、検索エンジン最適化の手段として、ぺらぺらのサイトを大量に作ってリンクする方法に効果があると信じられていた。今は、違う。個々のコンテンツがそれなりに充実していないと、むしろ逆効果となる。今回狙われたのは、そういう、過去のSEOの遺物であった、ということができるかもしれない。となれば、対処しなくてはならないサイトの数が多いということになる。サイトを作り直す、という作業が現実的に難しくなる。そこで探されるのが、応急処置である。

攻撃の標的となっていることが明らかとなった段階で、コメントの書き込みを無効化する、これを真っ先に行うことは言うまでもない。次に、コメントの削除である。MTOSにはコメント全部削除の機能がついているはずが、データベースとしてSQLiteを使っている場合、1000件を超える処理をしようとした段階でエラーを起こす。それは記事が1000件を超えて再構築する場合でも同じ。だから、数万件のコメントを200件づつ手動で削除という、気の遠くなるような作業が残される。たかが数百回と思うなかれ。単純作業で、それも一回の処理に30秒を超える時間がかかるのだ。

そこで応急処置として今回、データベースを直接操作することにした。リスクの高い方法で推奨なんてできない。あくまで自己責任の世界。SQLiteの場合は、mt.dbというファイルをFTPでダウンロードして、SQLite Database Browserというフリーソフトで読み込み、mt_commentというテーブルのレコードを全削除する。DELETE * from mt_comment;とかなんとかいうSQL文を入力して実行し、コンプレスする。これを再度アップロードすれば、少なくとも表面的には、スパムコメントだけ取り除かれた、以前のサイトの状態にもどる。

MySQLを用いたMTOSサイト、今回はXREA上のものだが、PhpMyAdminを用いて、mt_commentテーブルをTRUNCATE、要するにレコード全削除を実行した。こうしてこちらでもデータベースのサイズが通常にもどり、少なくとも表面的には以前と同様の機能を取り戻すことができた、ように見える。

ただ、常識的には、レコードの数など他のテーブルで管理してないほうが不思議であって、今回のようないささか乱暴な方法で本当によかったのか、応急処置とはいえ、自分でも疑問を感じる。その副作用や、もっとましな方法についてご存じの方は、ぜひお教え下さい。