baserCMS 当たり前にやっておきたいセキュリティー対策の基本

最近、とあるbaserCMS利用のWebサイトのハッキング騒ぎに関わることがあったので、あらためてbaserCMSのサイト運用や管理において、やっておくべきセキュリティー対策の要点を自分なりにまとめてみました。

まず、何をおいても、ユーザーIDとパスワード。これを安易なものにしてしまったり、他のサイトと使いまわしてしまったり。それが原因で、あっさりサイトを乗っ取られてしまうというのは、結構なケースであるのではと思います。 実際、今回、関与した事件もそれで、ユーザーIDは、ほとんどサイトドメインから類推できそうな名称、パスワードは、あっさりしたものをその他のシステムやサービスなどでも使い回していたとのこと。挙句、Google Chromeからパスワード流出の警告が数週間前に来ていたにも関わらず、まぁ大丈夫だろうとパスワード変更の対策なども特段講じずにいたところ、数日前にいきなりサイト内のリンクページが別サイトに飛ばされたり、といったことになってしまったのだそうで、なんとも恐ろしい話です。。。

ここで、注意喚起です。baserCMSの場合（他のCMSでも事情は大して変わりませんが）、うっかりするとアカウント名（ログイン）は、比較的容易に想像がついてしまう場合があります。 例えば、ブログ記事の出力用phpファイルで以下のように記述し、「投稿者名」を表示させている場合です。

<?php $this->Blog->author($post) ?>

ここで言う「author」とは、管理画面＞設定＞ユーザー管理 で入力する以下の項目のいずれかで、② ③ の優先順位で「投稿者名」として表示されることになります。 ① ③ は、必須入力ですので、基本は ① ③ を同じ内容にしないと言うことをまずは心がけたいところです。できれば、① ③ とは違うニックネーム ② を指定しておけば尚よしです。そうすればアカウント名は表立っては伏せることができます。 うっかり間違って ① ② ③ を同じ内容にしてしまって、そのアカウントが「システム管理グループ」だったりすると、意図せず、いきなり「admin権限のアカウント名が流出する」と同義になってしまいます。 ちなみにサンプルに挙げたアカウント情報は、 ① ② ③ それぞれ違った内容ではあるのですが、このアカウントが「システム管理グループ」に属するユーザーですから、アカウント名「admin_01」は最悪のネーミングです、このあたりも気をつけたいところです。

次にできること。管理画面のURLを容易に見つけられないようにします。 ブルートフォースアタックと言われる総当たりでパスワードを入れようとする力技の攻撃も、そもそもログイン画面が分からなければ入れようがありません。なのでやらないよりは、やった方がもちろんいいですよね。

通常の「/admin」ではなく任意の文字に変更します。 方法は簡単で、/app/Config/core.php ファイルの172行目あたりの以下の記述を任意の文字に変更するだけです。

Configure::write('Routing.prefixes', array('admin'));

を例えば、

Configure::write('Routing.prefixes', array('hoge'));

といった具合です。

次に、主要なファイルやフォルダ（ディレクトリ）は、適当に放置せず、キチッとパーミッションの設定をしましょう。これも意外に重要です。 共用サーバーでbaserCMSのサイトを運用している場合、 パーミッションは、利用しているホスティングサービスのサーバー仕様やレギュレーション（セキュリティーポリシー）毎に違ったりしますので、一概にこうすべきとはなかなか言えないものですが、利用しているホスティングサービス毎にアナウンスされている推奨値などを参考にして、運用上の不具合が出ない範囲で、セキュアにしていくという方向性かと思います。 LOLIPOP!を例にとれば、 通常のphpファイルは、主に「CGIの実行ファイル」のパーミッションを参考に考えて良いかと思います。 その上で、主要なファイルのよりセキュアな運用を考えていくのであれば、 例えば、パーミッション600の場合は、「ユーザ　書き込み」権限を可能であれば外してパーミッション400にしておきたい、 例えば、パーミッション604の場合は、「ユーザ　書き込み」権限を可能であれば外してパーミッション404では運用できないか、 という発想ですが、実際、ユーザーの書き込み権限を外してしまうと、自身がFTPでサーバーにアクセスして当該ファイルの書き換えをしようとしてもエラーになってしまいますし、アプリ（baserCMSの管理画面での操作）で「保存」「書き換え」ができないといったケースに見舞われる可能性があります。また、.htaccessファイルの「その他　読み」権限を外してしまうと403エラーになって、そもそもサイトが表示できなくなってしまいます。 そのあたりを加味して、重要なファイルをどういうステータスのときにどのように保護するかというポリシーを考えておくことが必要です。 インストール時、アップデート時、サーバー移設時、メンテナンス時、デバッグ時、通常の運用時とステータスは様々です。当然すべてのステータス時に無理なく運用ができ、理想とするセキュアな状況を作るというのは困難で、落とし所を見出すか、通常の運用時に如何にセキュアにするかを目標とするかが、考え所ということになります。 具体的には、例えば.htaccessファイルのパーミッションを考える場合、推奨値は、604となっています。.htaccessファイルの性質上、「その他　読み」権限を外してしまうわけにはいきません。となると、「ユーザ　書き込み」権限を外して404で運用するという発想はありです。なぜなら.htaccessファイルの性質上、再々設定値を変えると言ったことはありませんし、インストールした後、アップデート時にも書き換えるケースもほぼありません。ということは、404の運用は、セキュアで運用上も無理はないことがわかります。 あるいは、なるべくリスクを生まず実用的なパーミッションを考えるのであれば、主要なファイルにおいて不用意に「ユーザ」以外の「書き込み」権限を与えない（相当な例外的なケースを除いて）ということに重点をおいて、データベースの情報などが記載されている/app/Config/databese.phpなどは、かさねて「ユーザ」以外に「読み」権限も与えないということを心がけると十分にセキュアな運用になるはずです。

ちなみに、私がLOLIPOP!で運用している主要ファイル、フォルダのパーミッションは、以下の通りです。

/app/Config/databese.php　パーミッション：400（r--------）
/app/Config/install.php　パーミッション：400（r--------）
/app/Config/setting.php　パーミッション：600（rw-------）
.htaccess　パーミッション：404（r-----r--）
ディレクトリ　705（rwx---r-x）

/app/Config/databese.phpと/app/Config/install.phpのパーミッションのみ、よりセキュアに400で運用し、サーバー移設時、メンテナンス時、デバッグ時といったステータスでは、「ユーザ」の「書き込み」権限をあらためて与えてやるという運用です。 パーミッションを変更した場合は、通常の運用操作（記事の作成、保存、ユーザーの作成など）が問題なくできるかを確認しておくといいかもしれません。

最後に言わずもがなのパスワードは、できれば8桁以上の英数字を含んだ乱数にしましょう。この条件でパスワードの組み合わせは、なんと200兆通り以上になるそうです。 基本的なことが実はとても重要だということですね。