共用サーバーの対応に関して

共用サーバーの信頼性と対応に関して

先日の事なのだが、とある、共用サーバーで、ファイルシェアの実験をしていたところ、数時間後に不正ファイルを発見したので、即刻サーバー上の全ファイルを削除せよと言ってきた。
これ自体に驚いたのはもちろん。有料サーバーであるにもかかわらず、自分が収容している全てのドメインのデータを削除せよというもの。この措置に伴い、Webアクセスを凍結されてしまった。

1,050円/月と、そんなに安くないサーバーである。

この際だから、こんなとんでもないとこを言うサーバーとは、おさらばし、新たに収容先を見つけたほうが、精神衛生上好ましいのだが、共用サーバーというのは、サーバー機能の維持やメンテナンスを委ねることの出来る少しでも楽をしたいユーザーなら、1つや2つの所有経験があるだろうと思う。

そういう僕も、メールサーバーのメインサーバーに使っていたり、比較的主力のブログを立ちあげている共用サーバーなので、おいそれと引っ越せない理由もある。
しかし、いかがなものだろう、ユーザーにSSHターミナルを提供しておきながら、uname -aとか、df -h とか、htopなどを走行させると、当然の事のように、依然として不正アクセスとして検出されてしまうようで、不正アクセスと、不正ファイルの設置に関しては、とんと、心当たりがないのである。
青天の霹靂とは正に、こういうことを言うのだろう。

ただ、機械的に検出した不具合を、このような形で一切の警告もなく、一方的にWebアクセスを凍結してしまう事自体、サービスのあり方に、疑問を感じずには居られない。

とあるサーバーの名前を出そうかと迷ったが、これに関しては、今回は伏せておくことにする。
たぶん、思い当たるユーザーも少なからず居るのではないだろうか。
そうそう、共用サーバーを提供していて、Netowlの大株主であるところだ。
昔はこんなんじゃなかったんだけど。

ということで、そんなサーバーにあたってしまった不幸なユーザーのために、以下に対策を書いておこうと思う。
もっとも、SSH接続を許容しないサーバーには意味が無いが。

共用サーバーでは、実施してはいけないこと

  • ClamAVが検出するマルウェアやアドウェアを含むファイルの収納
    これが、厄介で、普段普通のユーザーは、Windowsを使っているので、他のVirus検出ソフトでは、検出されないが、ClamAVが、検出してしまうという、ケースが存在する。
    僕の場合は、これだった。ファイルのバックアップのつもりで、いろんなファイルを書き込んでいんだが、このファイルの中に、該当ファイルが、2つほど存在していた。
    もちろん、Windows用のVirus検出では、検出しない普通のフリーソフトである。
  • SSHターミナルでのサーバー情報の取得
    これは、サーバー運用側の手の内を垣間見ることになる行為なので、できるだけ避けなくてはならない。uname -a , df -h , htop , cat /etc/redhat-releaseなど、VPSを使っているユーザーには当たり前の行為でも、共用サーバーでは、あまり望ましい行為ではないらしい。
    ましてや、cat /etc/passwdなんて絶対やらないこと。(性質上、出来ちゃうけどね。)
  • ファイル同期プログラムの設置
    これは、こと、最近、サーバーのHDD容量が飛躍的に増え、僕が借りているサーバーは、借り始めた頃に5GBでしかなかったものが、現在では、200GBまでを許容するまでに至った。
    但し、1ホストあたりで150人程度ものユーサーを収容していながら、用意されているユーザーエリアは、1.5TBであった。本来なら、200x150=30TBが必要となるが、不思議なことに、ほとんどのユーザーは、概ね5GB以内の利用に収まっているのだから、仕方ない。
    でも、不用意にdf -hなどと、叩きたくなるのは、人情というもの。へー、そんなもんなんだと思うユーザーが居ても、運用が出来ている限り文句など言わないから。
    でも、先の、ClamAVが検出したマルウェアを同期対象に乗せてしまうと、マルウェアの拡散だと勘違いされてしまうので、要注意である。
  • コンソールコマンドの設置
    これは、好意的な意味で、自分が、このサーバーにどれだけの負担をかけているのかを把握して、正常な範囲で運用しようと本来あるべくもない、htopなどを設置してはダメだ。
    もちろん、ps -efなどと叩いても他のユーザーのプロセスが見えてしまうので、同じユーザーグループに存在している限り、それは避けられないが、場合によっては、不正行為とみなされてしまうので一応注意が必要である。
    また逆に、プロセスリストに、自分のパスワードが表示されてしまうようなバイナリープログラムの設置は、ご法度である。
  • 海外サーバーからのアクセス
    デリケートなコンソールコマンドは、国内から実施したほうが良さそうで、海外サーバーからのハッキング行為には、かなりナーバスになっているので、同じ理由で、複数のファイルをrsyncなどで同期をとるというのは、避けたほうが良さそうである。

以上にのべたような例は、最低限のマナーで、他にもいろいろあるかも知れない。
例えば、便利だからといって、Dropboxを設置するとか。
そういうのは、リソース制御の行き届いたVPSですべき行為なのだろう。

今回の場合、かろうじて問題となっていたファイルを全て削除することによって、事なきを得たが、当然の事ながら、バックアップはとってから、tar cf backup.tar . とバックアップを取得したいルートへ行ってtarファイルを作りまくったり、そのバックアップファイルを他所のサーバーへscp -Pxxxx backup.tar hoge@domain.com:/home/hoge/とかして、転送しておくことになる。もし悪意のあるユーザーなら、一旦ファイルを削除してから、もう一回書き戻せばOKということで、SCPによって生じたトラフィックそのもののほうが、サーバー管理側にとっては不利益になるハズ。

こういった行為を実施させねばならないといった管理体制に問題があるとしか言い様がない大変愚かな行為であろうと、思うのは、僕だけではないと信じたいところである。
まあ、総じて言うのであれば、今回のようなケースは、表面化しない不利益のために、いちゃもんをつけてきているだけのことなので、リソースの無駄遣いはするなと暗に言っているに過ぎないのだろう。
ただ面白いことに、SSHコンソールから、clamscan hogeなどといった操作が出来るらしいので、マニュアルには乗ってない操作だけど、やってもいいのかな。ダメって言われるかもね。

いやはや、使いにくくなったものである。
ご時世ですかね。

VZ SystemでのFUSEの扱い

BudgetVMでは、デフォルト設定では、FUSEが走らない。
このことは、ホストシステムが、カーネルレベルで、fuseライブラリーをmodprobeする必要があり、ユーザー側では、どうにもならない。
何度か、メールでやり取りをし、やっと納得していただいた時点では、FUSEが走行していて、wdfsなどを利用して、WebDAVドライブをマウントして使うことが出来た。

そのメールのやり取りの中で、mod probe fuseを実施しても、次回のリブートの時点でfuseは読み込まれませんので、対策してくれといって、手順までも明確に伝えたのだが、どうにもなっておらず、システムリブートがあるたびに、メールで modprobeしてね。と、何度か依頼して対応していたのだが、やはり、手順が標準化されていない為、継続的に運用するには至らなかった。

ホストマシンが再起動されるたびにメールで依頼していたのでは、些か面倒になって、まあ、こんなものかもなーと思いつつ、現在に至っているわけなんだけど、対応が柔軟であることはかなり評価に値するものの、標準サポートが受けられないというのは、もったいない限りである。

そこら辺は、日本のVZシステムは、カーネルベースが、CentOS5がほとんどなので、前にも書いたスワップファイルが使えない。ここのように、128MB Burst 256MBなサーバーで、まともにWordPressが走るだけでも、かなりありがたいわけだが、ファイル連携を考えると、ftpや、scpあたりでファイル交換をするより他に方法が無いので、fuseは少なくとも走って欲しいと思うのは、僕だけではないと思うのだが。

まあ、念の為に、対応いただけるような場合も含めて、対応を以下に書いておこうと思う。(半分備忘録ですが)・・

ホストシステム側での対応

OpenVZ Containerの設定

たぶん、一行目の yum install fuse fuse-libs –enablerepo=rpmforgeあたりは、実施しなくてももともと入っている可能性はあるが問題は、OpenVZ Containerの設定ファイルの中に、デバイスノードが追加されていないので先ずは、そこを変更する。

# yum install fuse fuse-libs --enablerepo=rpmforge
# vzctl set container-id --devices c:10:229 --save
# vzvtl restart container-id

以上の操作で一応、OpenVZの仮想サーバー上で、/dev/fuse というノードができる。

ホストサーバーの起動プロセスの書き換え

modprobeで自動的に読み込む方法が見つからないので、とりあえず、以下の例のように、rc.sysinitを編集し、次回の再起動後に、自動的に、modprobe fuseが実行されるようにしておく。
下記の赤い部分を書き加えておく。

For example.

# vi /etc/rc.d/rc.sysinit

#-- 中略 --
# Only read this once.
cmdline=$(cat /proc/cmdline)
# Initialize hardware
if [ -f /proc/sys/kernel/modprobe ]; then
   if ! strstr "$cmdline" nomodules && [ -f /proc/modules ] ; then 
  sysctl -w kernel.modprobe="/sbin/modprobe" >/dev/null 2>&1
   else
       # We used to set this to NULL, but that causes 'failed to exec' 
messages"
       sysctl -w kernel.modprobe="/bin/true" >/dev/null 2>&1
   fi
fi
#<--- added by here --->
modprobe fuse
#~~~~~~~~~~~~<--end -->
touch /dev/.in_sysinit >/dev/null 2>&1
# Set default affinity
# -- skip --

:wq!

以上の対策をするか、または、専用カーネルを再構築するかということになるが、たぶん、日本のOpenVZシステムを提供しているプロバイダーは、専用カーネルを使っていろのだろう。

別途、BudgetVMに良く価格体系が似ているFrantechのOpenVZは、カーネルベースが古く、Swapが使えない代わりに、fuseは標準でサポートされている。ServerQueenは、いずれもサポートされない。
日本で言うところの、Serversman@VPSあたりは、Frantechにかなり近いカーネルとかんがえられるが、現時点で、このSwapファイルを有効にする代わりに、メインメモリーの割り当てを大幅に増量しており、490円/月の価格体系で、保障メモリー:1GB burst:2GBでディスク領域が、50GBというサービスを展開しており、こちらの方は、いずれもサポートされる。望むところとしては、保障メモリー:512MB Burst:1GBといったベースの安価なバージョンがあっても良いと思うのだが・・

なんとか、ここらへんは完全な対応を望みたいところである。