特定のサブドメインだけを別サーバーで運用するDNSの設定

こないだツイッターで「特定のサブドメインだけ〇〇サーバーで運用したいのに、〇〇サーバーはサブドメインだけを指定できないから公開できない」という内容のツイートを見かけまして、それ根本的な間違いをしてるんじゃなかろうか?などと思ったんですが、多分公開できると思います。

こないだツイッターで「特定のサブドメインだけ〇〇サーバーで運用したいのに、〇〇サーバーはサブドメインだけを指定できないから公開できない」という内容のツイートを見かけまして、それ根本的な間違いをしてるんじゃなかろうか?などと思ったんですが、多分公開できると思います。

考えられる方法は2通りあります。

  1. サブドメインなしのメインドメインごと登録して設定する
  2. 特定のサブドメインをメインドメインとして登録し設定する

サブドメインなしのメインドメインごと登録して設定する

状況として次の場合を想定します。

  • ドメイン管理は株式会社Aドメイン
  • サブドメインなしの example.com はレンタルサーバーB
  • サブドメインありの hoge.example.com はレンタルサーバーC

株式会社AドメインのDNS(ネームサーバー)で example.com の設定が正しく出来ている場合、ブラウザに http://example.com と打ち込むと、水面下では次のような攻防が繰り広げられます。

イメージ:
.comのネームサーバーに聞く
ブラウザ「example.com さんのIPアドレスを教えてください」
ネームサーバー「example.com さんなら株式会社Aドメインに聞けば分かりますよ」
株式会社Aドメインのネームサーバーに聞く
ブラウザ「example.com さんのIPアドレスを教えてください」
ネームサーバー「example.com さんならレンタルサーバーBに聞けば分かりますよ」
レンタルサーバーBのネームサーバーに聞く
ブラウザ「example.com さんのIPアドレスを教えてください」
ネームサーバー「それなら 127.0.0.1ですよ」
127.0.0.1にアクセス » ページ読み込み

結論として、DNSとは即ち「たらいまわし」と言えます。

ここで、hoge.example.com だけは、レンタルサーバーCで運用する事にした場合、ブラウザに http://hoge.example.com と打ち込むと、株式会社Aドメインのネームサーバーはこう答えます。

「hoge.example.com さんならレンタルサーバーCに聞けば分かりますよ」

株式会社Aドメインのネームサーバーに問い合わせた段階で
サブドメインなしの example.com は レンタルサーバーB へ
サブドメインありの hoge.example.com はレンタルサーバーC へ
と振り分けられます。

ということは、こういう事になります。

レンタルサーバーB と レンタルサーバーC の両方で、example.com の設定をしていて支障はない。

わかるでしょうか?冒頭のツイート「〇〇サーバーはサブドメインだけを指定できないから公開できない」これは、何も問題がないという事です。

おそらく、ツイートした人は「◯◯サーバーではサブドメインだけの指定しかしてはいけない」と思っているのではないでしょうか。何故なら、サブドメインなしの example.com はレンタルサーバーBで使うから。でも、それは間違いです。

ちょっと、ややこしいですが、株式会社Aドメインのネームサーバーが正確にレンタルサーバーB と レンタルサーバーC への振り分けを行なってくれるなら、レンタルサーバーC へはサブドメインなしのexample.com の問い合わせは絶対に行われません。だから、レンタルサーバーC で example.com の設定をしても使われないだけです。使われないだけなので設定しても問題ないんです。

具体的には、レンタルサーバーCでサブドメインなしの example.com を登録してその中で、hoge.example.com の設定を次のようにすれば、レンタルサーバーCで hoge.example.com のサイトは運用できます。

a hoge xxx.xxx.xxx.xxx

特定のサブドメインをメインドメインとして登録し設定する

通常は、上の設定で問題ありません。

ただし、イレギュラーな方法としてレンタルサーバーCの登録ドメインを、サブドメインなしの hoge.example.com にしてしまうという方法も考えられます。サブドメインなしの hoge.example.com です。

example.com は .com のサブドメインです。なのに、example.com をサブドメインなしのメインドメインとして登録できるなら、hoge.example.com もサブドメインなしのメインドメインとして登録できるという事になります。

その場合、設定は次のようになります。

a @ xxx.xxx.xxx.xxx

ただこの方法だと後々、example.com の全てのサイトをマルっとレンタルサーバーCで運用するとなった場合、設定をやり直さなくては面倒なので、最初の「サブドメインなしのメインドメインごと登録して設定する」方法でやっておいた方が面倒なことにならないのではないかと思います。

データベースが1つだけのサーバーでWordPressを複数設置する方法

ロリポップのロリポプランは格安で独自ドメインを50個まで使えますが、MySQLが1個しか使えません。では、独自ドメインがたくさん使えるのにブログはひとつしか作れないのかというとそうではなく、データベースのMySQLが1個しか使えなくてもWordPressを複数設置する方法はあります。

WordPressはデータベースにMySQLを使っているので、基本的に1つのWordPressを設置するごとにMySQLがひとつ必要になります。

お断り:このブログはMySQLが無制限に使えるバリューサーバーのスタンダードプランを使っています。ロリポップではありません。

たとえば、ロリポップ!のロリポプランは格安でドメインを50個まで使えますが、MySQLが1個しか使えません。では、ドメインがたくさん使えるのにブログはひとつしか作れないのかというとそうではなく、データベースのMySQLが1個しか使えなくてもWordPressを複数設置する方法はあります。

ひとつはマルチサイトにしてしまうことです。WordPressのインストール後にもマルチサイトへの設定変更はできます。ただし、マルチサイトではベースとなるドメインはひとつしか使えません。

マルチサイトの構成例

サブディレクトリ方式
  • http://example.com/山本のブログ/ <- ここで1ブログ
  • http://example.com/田中のブログ/ <- ここで1ブログ
サブドメイン方式
  • http://山本.example.com<- これで1ブログ
  • http://田中.example.com<- これで1ブログ

この例の場合、サブディレクトリ方式にせよ、サブドメイン方式にせよ、使えるドメインはexample.comのひとつだけです。

そうではなく、完全に別ドメインの hoge.comfuga.net の2つのWordPressサイトをひとつのデータベースで作るには、wp-config.php の $table_prefix を変更すれば出来ます。また、そのやり方で上のマルチサイトと同じ構成にも出来ます。

このページでは、マルチサイトの設定方法は説明しませんが、複数のWordPressをひとつのデータベースで設置する方法をロリポップを例にして書きます。

完全な別ドメインのWordPressサイトをひとつのデータベースで作る

wp-config.php の $table_prefix を変更してインストールするには、ロリポップの「簡単インストール」は使えません。

手動でWordPressをインストールする必要がありますが、そのやり方はロリポップ公式サイトのマニュアル「WordPress(ワードプレス)の設置」に書いてあります。

基本は上記ページの手順にしたがって、手動でインストールすればいいだけです。この時に wp-config.php の $table_prefix を変更します。

追記:
ロリポップの「簡単インストール」マニュアルに「WordPress(ワードプレス)複数インストール」というページが増えています。マニュアルページには「テーブル接頭辞」の設定をする項目がないのですが、自動で「テーブル接頭辞」を変えてくれるのであれば、ひとつのデータベースでも複数インストール出来ると思います。もし、できないのであれば今ご覧のこのページの通りにすればできます。

ロリポップを例にした複数ブログインストール方法

以下、ロリポップのマニュアルが古い部分と追加する手順だけをピックアップして書きます。

データベース作成
これは、ロリポップのマニュアル通りに行ないます。
アーカイブの入手
これも、ロリポップのマニュアル通りですが、2015年5月5日時点のWordPress最新バージョンは4.2.1です。
ファイルのアップロード
これも、ロリポップのマニュアル通りに行ないますが、アクセスして欲しいページが http://example.com/wordpress/ ではなく http://example.com/ であるなら wordpressという名前のフォルダは作らないでいいです。

wordpressというフォルダを作らないので、アップロード先は /wordpress ではなく / (スラッシュのみ)になります。

ただ、トップディレクトリに色々たくさん置きたくないという場合は、/wordpress など(名前は何でもいい)のディレクトリを作ってそこにまとめ、アクセスだけ http://example.com/wordpress/ ではなく、 http://example.com/ にする設定方法もあり、このブログはそうしています。その方法は、次のページを参考にしてください。

WordPress を専用ディレクトリに配置する – WordPress Codex 日本語版

インストール
インストールを次の通りに実行します。

Webブラウザで、自分のWordPressを設置したURLを開きます。
/ (スラッシュのみ)にアップロードしたなら http://example.com/ などの自分が公開するURLです。

するとブラウザで次のページが開きます。

WordPressのインストール画面

一番下の「さあ、始めましょう!」をクリック。

切り替わった次のページで、上記4つには自分が作成したデータベースの情報を入力します。

WordPressのインストール画面

そして最後の「テーブル接頭辞」をブログごとに書き替えます。

これは重複しなければ何でもいいのですが、たとえば http://hoge.com/ と http://fuga.net/ の2つのWordPressサイトを作りたいなら、 http://hoge.com/ の「テーブル接頭辞」を「hoge_」、 http://fuga.net/ の「テーブル接頭辞」を「fuga_」などとします。

データベース情報とテーブル接頭辞を入力したら、「送信」をクリック。

問題がなければ次の画面に変わります。

WordPressのインストール画面

「インストール実行」をクリック。

WordPressのインストール画面

「必要情報」を入力します。

この時のパスワードはデータベースのパスワードとは違う、WordPressにログインするためのパスワードを新たに作ります。パスワードを作る際はなるべく強力なものにします。

参考:gmailのパスワードは記号も使って複雑にした方がいいと思う話。WordPressもね

すべて入力が終わったら「WordPressをインストール」をクリック。

成功すれば次の画面に変わります。後は「ログイン」を押せばWordPressにログイン出来ます。

WordPressのインストール成功

その後、インストールしたファイルの「パーミッション変更」を忘れずに実行します。ロリポップの場合は次のとおりです。

./wp-config.php → 400
./wp-admin/install.php → 000

これでWordPressをひとつインストール出来ました。2つ目以降のインストールの際は、すでに済んでいる「データベース作成」と「アーカイブの入手」を飛ばし、「ファイルのアップロード」から始めます。そして「テーブル接頭辞」を違うものにしてインストールします。

インストールしたWordPressに、他のブログからデータをインポートする場合は、次のページを参考にしてください。

無料ブログからWordPressへデータを移動する手順

ちなみにですが、「テーブル接頭辞」を「hoge_」 と「fuga_」にして2つのWordPressをインストールした場合、MySQLの中では次のように、それぞれのブログ用に接頭辞で区別されたテーブルが作成されます。

mysql> show tables;
+-------------------------+
| Tables_in_wordpress     |
+-------------------------+
| fuga_commentmeta        |
| fuga_comments           |
| fuga_links              |
| fuga_options            |
| fuga_postmeta           |
| fuga_posts              |
| fuga_term_relationships |
| fuga_term_taxonomy      |
| fuga_terms              |
| fuga_usermeta           |
| fuga_users              |
| hoge_commentmeta        |
| hoge_comments           |
| hoge_links              |
| hoge_options            |
| hoge_postmeta           |
| hoge_posts              |
| hoge_term_relationships |
| hoge_term_taxonomy      |
| hoge_terms              |
| hoge_usermeta           |
| hoge_users              |
+-------------------------+
22 rows in set (0.00 sec)

参考:
wp-config.php の編集 – WordPress Codex 日本語版内の「$table_prefix : データベース・テーブル名の接頭辞

バリューサーバーで python の easy_install を使う

バリューサーバー で mysql-python を使いたかったので、easy_install を使ってインストールしました。バリューサーバーには既に easy_install は入っています。ただ、そのまま easy_install コマンドを実行しても、システム標準の場所にインストールしようとして失敗します。そこで、あらかじめ設定しておきます。.pydistutils.cfg を作ることで easy_install に –prefix オプションをつける必要はなくなります。また、sys.path に PATH の追加もしないで済むので楽になります。

バリューサーバー で mysql-python を使いたかったので、easy_install を使ってインストールしました。

以下は、valueserver.jp に SSH でログインして実行しています。

使いたいパッケージが入っているか調べる

前に書いた記事「python版phpinfo」の pyinfo.py をインストールして見てみます。

pyinfo.pyの導入

$ wget http://www.twoevils.org/files/pyinfo.txt
--2014-06-04 09:42:53--  http://www.twoevils.org/files/pyinfo.txt
www.twoevils.org をDNSに問いあわせています... 204.246.122.18
www.twoevils.org|204.246.122.18|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 11715 (11K) [text/plain]
`pyinfo.txt' に保存中

100%[===================================>] 11,715      --.-K/s 時間 0s      

2014-06-04 09:42:54 (78.6 MB/s) - `pyinfo.txt' へ保存完了 [11715/11715]

$ mv pyinfo.txt pyinfo.py
$ chmod 755 pyinfo.py

ブラウザで pyinfo.pyに アクセスして、表示してみると MySQL-Python は入っていませんでした。

pyinfo.pyの表示結果

そこで、独自にインストールします。

以下の作業は「さくらのレンタルサーバに Python モジュールをインストール」というページに書いてあることを、そのままバリューサーバーで実行しました。

easy_install の確認

バリューサーバーには既に easy_install は入っています。

$ which easy_install
/usr/bin/easy_install

ただ、そのまま easy_install コマンドを実行しても、システム標準の場所にインストールしようとして失敗します。

そこで「さくらのレンタルサーバに Python モジュールをインストール」に書いてある通り、あらかじめ設定しておきます。

*上記のサイトには、ローカルにインストールするオプションや、ローカルに入れたモジュールを使う方法も書いてあります。

site.USER_SITE の確認

Python を起動して、ユーザー・サイト用のディレクトリがどこに設定されているかを調べます。

$ python
Python 2.6.6 (r266:84292, Nov 22 2013, 12:16:22) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.USER_SITE
'/virtual/xxxxx/.local/lib/python2.6/site-packages'
>>>

設定されているのは ‘/virtual/xxxxx/.local/lib/python2.6/site-packages’ ですが、そのディレクトリは用意されていませんので、自分で作る必要があります。ちなみに、/virtual/xxxxx が自分のホームディレクトリになります。

$ mkdir -p ~/.local/lib/python2.6

.pydistutils.cfg の作成

.pydistutils.cfg を作ることで easy_install に –prefix オプションをつける必要はなくなります。また、sys.path に PATH の追加もしないで済むので楽になります。

$ echo '[install]' > ~/.pydistutils.cfg
$ echo 'user=1' >> ~/.pydistutils.cfg
$ cat ~/.pydistutils.cfg 
[install]
user=1

easy_install を使ってみる

後は、普通に easy_install コマンドでモジュールをインストールできます。

MySQL-Python をインストールします。

$ easy_install mysql-python
Searching for mysql-python
Reading http://pypi.python.org/simple/mysql-python/
Best match: MySQL-python 1.2.5
Downloading https://pypi.python.org/packages/source/M/MySQL-python/MySQL-python-1.2.5.zip#md5=654f75b302db6ed8dc5a898c625e030c
Processing MySQL-python-1.2.5.zip
Running MySQL-python-1.2.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-UDQRse/MySQL-python-1.2.5/egg-dist-tmp-yYD_3Q
/usr/include/mysql/my_config.h:14 から include されたファイル中,
                 _mysql.c:44 から:
/usr/include/mysql/my_config_x86_64.h:422:1: 警告: "HAVE_WCSCOLL" が再定義されました
/usr/include/python2.6/pyconfig.h:6 から include されたファイル中,
                 /usr/include/python2.6/Python.h:8 から,
                 _mysql.c:29 から:
/usr/include/python2.6/pyconfig-64.h:808:1: 警告: ここが以前の宣言がある位置です
zip_safe flag not set; analyzing archive contents...
Adding MySQL-python 1.2.5 to easy-install.pth file

Installed /virtual/xxxxx/.local/lib/python2.6/site-packages/MySQL_python-1.2.5-py2.6-linux-x86_64.egg
Processing dependencies for mysql-python
Finished processing dependencies for mysql-python

先ほどの、pyinfo.py にブラウザでアクセスしてみると MySQL (MySQL-Python) が enabled に変わっています。

pyinfo.pyの表示結果

サーバーの細かな設定が誰でも読めてしまうのは、セキュリティの心配があるので、当サイトでは確認終了後に pyinfo.py は削除しました。

$ rm pyinfo.py

クラッキング(ハッキング)被害を受けたサイト管理者がとるべき2つの重要な対策

生まれて初めてクラック(ハッキング)された。今回クラックされたのは自分が借りているバリューサーバー。今のところ やられたのはその中の1台のみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった。今現在は大丈夫でも、今後危険になる可能性が「ある」。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。では、どうしたらよいのか。今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

お詫び:
2014年1月19日17時頃から23時すぎまで、当サイトはクラッキング(ハッキング)被害を受けました。閲覧画面に下のような表示がなされましたが、閲覧された方に被害が及ぶ心配はありません。ご迷惑をおかけして申し訳ございません。詳細は以下の記事をご覧ください。


追記 2014年1月20日21:01
本日夕方17時過ぎから先ほど20時すぎまで、またクラックされましたが、今回は明確に原因を特定できているようです。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

特定の管理ユーザー以外昇格できないようにする設定ファイルに、とあるユーザー様が追加され、そのユーザー様領域内での不正なプログラムがおかれておりました。

当サイトを閲覧いただいた皆様には重ねがさね失礼いたしました。以下、本文です。


生まれて初めてクラック(ハッキング)された。まあ、共有サーバーである以上誰かがミスれば全体に影響するというのはある。今回クラックされたのは自分が借りているバリューサーバー(VALUE SERVER – valueserver.jp)。

今のところ やられたのはその中の1台、s1.valueserver.jpのみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった模様。今回、この記事を書いているテーマはここで、閲覧者に被害を及ぼす心配は「なかった」のであって、今現在は大丈夫でも、今後危険になる可能性が「ある」ということ。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。

詳しく説明するために、まず起こった状況から。

クラッキングされた画面

実際に受けたクラッキングの詳細

自分が気づいたのは23時過ぎだったんだけど、実際には17時頃に最初のクラッキングがあったらしい。最初というのは、その後再びファイルが書き換えられるアタックがあったから。最低でも2回侵入されている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/19(Sun) 18:58
今日の17時ごろs1サーバー内のファイル(ファイル名に”index”が含まれるもの)が別の内容に書き換えられたようです(添付画像参照)。

2014/01/19(Sun) 22:42
先ほど修正したはずなのですが、22:26 にまた index.html が
別のファイルに書き換えられました。(一部のディレクトリのみ)
もうどうにでもなれって感じです。

1回目の攻撃で黒地の画面に”Hacked by Jacko Nexus”と表示されるようになり、2回目の攻撃で画像が兵士のものに変更され、音も鳴るようになった。自分が実際に見ているのは音の出る方の画面。

クラッキング(ハッキング)の原因

正確な原因は攻撃した側と、被害を受けたサーバー管理者しかわからないので、バリューサーバーの発表を待つ必要がある。もちろん待っても本当の原因を発表するとは限らないけど。ただ、フォーラムの情報を見るとポートに穴が開いていたらしい。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/20(Mon) 01:00
はてなブックマーク ( http://b.hatena.ne.jp/entry/kumalog.com/2014/01/19201213.php ) で以下のような指摘がありました。
—————
s1.valueserver.jpの31337ポート(トロイの木馬に感染したときの
Back Officeポート。通称「エリート」ポート)が空いているね。
—————
確認したところ現在も開いたままなので、まだ色々まずいかも知れません。

2014/01/20(Mon) 05:27
こんばんは。
はてなブックマークで31337ポートが空いてるよって書いた者です。
HTTP復旧したようですね。もう31337ポートは空いていません。
おそらくセキュリティパッチを当ててサーバーを再起動したか、
新しい筐体にユーザーのデータを移して起動させたのかと思います。

私はここのサーバーを使っていないので、NULLさんが指摘された
PHPのバックドアのファイルが残っていないか気になるところですが、
これでしばらくは大丈夫かなと思います。

#しかし未だ開ける必要のないポートが沢山開いている…。
iptablesでファイアウォール設定とかやってないのでしょうね…。
OSやミドルウェアの更新とかも定期的にやらずに放置だったのでしょうね…。

クラッカーは、おそらく開いているポートから侵入したのでしょう。

追記:[2014/01/20 21:30] 原因が公式発表されました

  • あるユーザーにて、WordPressの脆弱性をつき、不正なプログラムが設置された
  • そのプログラムからシステムの脆弱性つかれ、インデックスページを書き換えるプログラムを実行された
  • インデックスページを設置されているサイトにおいて、id.htm、in.php、index.php、index.htm、index.html の内容が変わり、動作しなくなった

被害を拡大しないためにするべきこと

バリューサーバーの対応が出来たので多分、今すぐ再侵入される可能性は低いと思う。しかしまだ問題が残っている。それはクラッカーによって書きこまれたPHPのバックドアファイルだ。これが残っている以上、いつでもクラッカーは攻撃を仕掛けられる。どういうことかというと、実はフォーラムにこのように書きこまれている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/20(Mon) 01:27
Tomさんの
>~/inphpの内容
>http://dwm.me/download/in.txt
がかなり興味深いですね。

デコードすると分かるのですが、バックドアとして機能するようです。
これは早急に対策しないとマズイです。
いつ悪意のあるページに書き換えられてもおかしくありません。

追記:http://dwm.me/download/in.txt
このファイルですが削除されたみたいです。
アップしたのは私なんですが、消したのはおそらく管理サイドだと思うので再アップはしません。
ソースは公にしないほうがいいとも思うので。

そのバックドアとは何なのか。

IT用語辞典より

バックドア 【 backdoor 】

クラッカーにより侵入を受けたサーバに設けられた、不正侵入を行うための「裏口」。

クラッカーはコンピュータへの侵入に成功すると、次回も侵入できるように、管理者に気づかれないようこっそりと侵入経路を確保する。これがバックドアである。

簡単に言えば、今は「ターミネーター2」でシュワちゃんが溶鉱炉に入ることになった時のような状況。ファイルがある以上、それを消し去らないとまた敵が攻撃してくる。

では、どうしたらいいのか。自分は対策には2種類あると思っている。それは具体的な対策と潜在的な対策だ。具体的な対策を書く前に、潜在的な対策を書いておきたい。

発信者の責任

もしも推測の通りポートの穴が原因なら、それはバリューサーバーの管理責任といえる。しかし、そのサーバーを使ってサイトを公開している以上、忘れてはいけないことがある。自分たちは、あくまで発信者なのだ。サイトを訪れた閲覧者に不利益をもたらすことをしたのなら自分にも責任が生じる。

これは今月本当にあった話だけど、テレビ番組でダンサーがFUCKと書かれた衣装を着て踊ったとする。しかも子供向けの番組で。これはダンサーだけの責任だろうか?放送局にも責任はあるのではないか?いや、むしろ局側の責任のほうが大きいのじゃないか。

そしてブログというのは例え小さかろうがメディアであるということ。メディアである以上、テレビと同じ立場だ。配信する側には責任がある。バックドアからウィルス的なものを仕込まれ閲覧者に感染したら、そのサイトにも責任が生じる。

参考:社員にTOEIC受験を義務づけるのは楽天やUNIQLOより放送局にお願いします | More Access! More Fun!

f83e2898

被害を受けるのはサーバーのユーザーだけとは限らない。自分のサイトを開いた人が何かを仕込まれるかもしれない。もしそうなった時、責任はそのサイトにもある。それが情報を発信する側の責任だ。

昨年あった「あし@」の詐欺広告

昨年、あし@のサーバーが乗っ取られ、パーツを貼っているブログに強制的に詐欺広告が表示されるという事件があった。

あし@で表示された詐欺広告

「あしあっと事務局」がユーザーに送ったメールより

この度、2013年9月20日に、あし@の広告を配信しているアドサーバーの広告管理アカウントの一つに部外者からの侵入があり、広告の内容の一部に改変が加えられた事で、あし@の広告が表示されると、予期せぬポップアップ広告が表示されいるという現象が発生しておりました。
ご迷惑をおかけ致しましたブロガー様、読者様には深くお詫び申し上げます。

この時、気になったことがある。「あし@」が設置された状態で放置された、更新していないブログの多くが管理者の気づくことなく「詐欺広告」を表示し続けていたという事実。そして、それに引っかかり詐欺ソフトを買ってしまった人物もひとり知っている。

もちろん一番悪いのはクラッカー(ハッカー)だ。そして、それを防げなかった「あし@」にも責任はあるだろう。それが原因かどうか知らないが「あし@」は今月いっぱいでサービスを停止する。

では、この広告を配信してしまった「ブログ」には責任がないのだろうか?自分は「ある」と思っている。ましてや、更新せず放置したまま気づかなかったブログ管理者の責任は大きいと思う。

クラッカーの攻撃を受けたサーバーにとって、侵入を許してしまうのはある意味やむを得ない部分もあって、防げなかったことを強くは攻めるつもりはない。同じように、ブログで使っていたパーツが知らないうちに詐欺広告を表示していたとしても、ある意味やむを得ない。というか貼っている以上防ぎようがない。

問題はいかに早く気がつくかだ。そして気がついたらいかに早く対処するかだ。2次攻撃を受けるまで気がつかなかった自分が言えることではないが、サイト管理者は責任を持って対処しないといけない。

共有サーバーには自分以外のサイトもある

そして、共有サーバーを使っている以上、自分がバックドアを仕込まれたら他の全員に迷惑をかけることになる。今回の責任がバリューサーバーだとしてもバックドアを削除せずに残したままにしておいたのなら、次の被害を受けた時の責任はそのサイトにもある。それが共有サーバーなら他の全員に被害が出る。

実際、昨年「ロリポップ」が乗っ取られた時の状況は、たったのひとりから発生した可能性もある。

【緊急警報!!】ロリポップとGMOのinterQのWordPressが軒並み乗っ取られてます | More Access! More Fun!

サーバクラックではないとすると、1人のアカウントに侵入し、同じサーバ上のWordPressをすべて乗っ取ったというのが一番考えられるのではないかと。共有サーバでWordPressを使う危険性がまざまざと浮き彫りになったわけです。

具体的な対策

では、どうしたらよいのか。バリューサーバーのユーザーは、おそらく自分で対処できるベテラン揃いだと思う。けど、今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

トップディレクトリに5つのファイルが書きこまれているので全て削除。

  • id.htm
  • in.php
  • index.php
  • index.htm
  • index.html

このうちの少なくともどれかひとつは、元からあったファイルの名前ですが、改ざんされています。削除して作りなおしてください。特に重要なのが「in.php」で、これが問題のバックファイルです。

5つのファイルが書きこまれているのはトップディレクトリだけですが、その他のディレクトリにindex.* (index.で始まるファイル)がある場合、すべて確認、訂正します。

静的なHTMLだけなら、これで完了と思われます。

WordPressの場合

WordPressの場合も、トップディレクトリのindex.phpを書きなおすだけでサイトは表示されるようになります。しかし、トップディレクトリの修正だけでは管理画面にログインできません。wp-admin/index.phpも書き換えられています。

WordPress3.8の初期状態のindex.phpは以下のとおりですが、すべて改ざんされていました。

wordpress $ find . -name index.* -print
./wp-content/index.php
./wp-content/themes/twentyfourteen/index.php
./wp-content/themes/index.php
./wp-content/themes/twentytwelve/index.php
./wp-content/themes/twentythirteen/index.php
./wp-content/plugins/index.php
./wp-content/plugins/akismet/index.php
./wp-admin/user/index.php
./wp-admin/index.php
./wp-admin/network/index.php
./index.php

バックアップがない場合、英語版の wordpress.org または 日本語版の ja.wordpress.org のどちらかから.zipファイルをダウンロードして解凍。中にあるindex.phpをそのまま再設置します。英語版も日本語版も index.php は同じなので日本語版でなくても大丈夫です。

インストールしているテーマやプラグインの中にもindex.*があるのですべて修正します。

WordPressを専用ディレクトリにインストールしている場合、トップディレクトリのindex.phpの中身は1行だけ違います。それについてはWordPress Codexの「WordPress を専用ディレクトリに配置する」を参照してください。

今回の攻撃ではDB(データベース)の改ざんは、確認されていません。

サーバーアカウントを凍結された

無料で使っている海外サーバーのアカウントが停止された。負荷をかけすぎたらしい。

Suspended (Suspended for violating 20%+ CPU usage limit for more than 1000 times. Please upgrade to our premium UNLIMITED hosting at www.hosting24.com to get your account reactivated.)

suspendedメッセージ

原因は先日公開した「記事一覧ナビモジュール

ファンブログのサーバーのデータベースにアクセスできない都合上、ソケットを使って
サーバーからHTMLを読み込み、データを解析。それを送信していた。

当然、高負荷をかけるよな。

無料サーバーで金払ってねえし。
しかも規約もある。けど英語で書いてあんだよ、この規約が。だから読んでねえ。

まあ、普通に考えて悪いのはこっちだな。文句を言うつもりはないけど、他の人の参考のために書くと、サスペンドと同時にFTPからもコンパネのファイルマネージャーからもデータにアクセスできなくなった。つまりファイルはダウンロードできない。

サポートと交渉すればアクセスできるようになるかもしれない。英語で書けば。

サーバーは000webhost.com。普通に使う分にはいいサーバーだと思う。

とりあえず、ローカルのデータを別サーバーに上げて、設定し直さないといけない。

現在このブログで影響しているのは「記事一覧ナビモジュール」「楽天ウエブサービスで検索窓」「amazon探検隊!整いました」「別ブログの最新記事を自動でリンクして紹介」「コバヤCチェッカーを公開します」「お友達の最新記事を表示しよう!」「Twitterで愛の劇場」「年齢計算フォーム」他。

迷惑かけてるのはケメさんだけかな?ケメさんすいません。

ブログの記事を直してリンク先を変えるか?DNS設定し直して数時間待つか?
どちらにしても復旧には時間がいります。

こういうことが起こってみると、データベースに直接触れるサーバーでWordPress使うのが
いちばん楽だな。SQL発行できればこんな面倒くさくて高負荷な非効率作業をしなくて済むし。

参考までに、000webhost.comでもWordPressはインストールして使えます。
当然データベースにもアクセスできる。phpMyAdminまたはPHPのソース経由ということになるけど(SSHではサーバーにログインできない)自由に触れます。ただし使える言語はPHPだけです。