ここからは、調査項目ごとに各サービスの初期状態のセキュリティを見ていく(表5)。今回、4社5サービスのクラウドを調査したが、いずれも何らかのセキュリティのリスクを抱えていた。一見すると安全に見えただけに、これは厳しい結果といえる。
◯iptables
フィルターの設定状況を調査した。不用意に受け入れてしまわないように、初期状態では必要なポートだけ開いていることが望ましい。ところが、日本ラッドの「Osukini Server」以外は、フィルターが設定されていないか、設定されていても不要なポートが開いている状態だった。
Osukini Server以外のサービスでは、例えばWebやFTPなどのサーバーソフトをインストールすると、インストール直後からWebやFTPのサーバーが動作し始め、外部にサービスを提供し始めてしまう。“まだ公開していないつもり”だったのに、既に不正侵入されていたということになりかねない。
自宅サーバーの場合、ブロードバンドルーターのファイアウォール機能でフィルターを設定することも可能だ。だが、クラウドは起動したインスタンス上でフィルターを設定するのが常識。今回分かった初期状態の危険性を考えれば、「インスタンスを作成したら、まずはフィルターをチェックする」という習慣を身に付けておくことが重要だ。
◯アカウント管理
この項目では、SSH経由でリモートアクセス可能なユーザーの管理を調査した。(1)アクセスできるユーザーを限定しているか、(2)セキュリティ強度の高い認証方法を採用しているかがポイントになる。
Linuxディストリビューションのアカウントは、管理者権限でシステムを操作できる「rootユーザー」と、自分のホームディレクトリー以外は操作できない「一般ユーザー」に分かれる。サーバーを簡単に乗っ取られないようにするには、rootユーザーでリモートアクセスできない設定になっているのが望ましい。rootユーザーのリモートアクセスが可能な状態でも、あらかじめ設定した鍵ファイルを持っていない限りアクセス不可能な「公開鍵認証方式」を採用していれば、不正侵入のリスクを減らせる。
最も危険な初期状態は、rootユーザーがパスワード認証でログインできてしまうことだ。ドリーム・トレイン・インターネット(DTI)の「ServersMan@VPS」と、さくらインターネットの「さくらのVPS」が該当した。ServersMan@VPSでは安全性を高めるためか、SSH接続のポート番号をデフォルトの「22」ではなく、「3843」に変更してあった。
今回、初期状態でrootユーザーによるアクセスを許可していなかったのは、日本ラッドのOsukini Serverだけだった。ただし、さくらインターネットの「さくらのクラウド」はインスタンス作成時に公開鍵認証を設定できる。ニフティの「ニフティクラウド」については、公開鍵認証でのみ許可する設定となっている。
2つのサービスにおける公開鍵の扱いは、公開鍵をユーザー側から送るか、秘密鍵を受け取るかという違いはあるが、いずれもSSLで暗号化された通信で秘密鍵をやり取りするため、初期設定のままでも問題になることはない。
◯初期プロセス
初期プロセスでは、初期状態で起動しているプロセスの有無を調査した。クラウドの場合、リモートアクセス関連のプロセスは必須なので、ここではリモートアクセス関連以外のプロセスを対象とした。特に外部と通信しているようなプロセスには注意が必要だ。そのプロセスを経由して不正侵入される可能性がある。
待ち受けポート番号や起動しているプロセスは、
# netstat -na
# lsof -i
さくらインターネットが提供する2つのサービスのうち、さくらのVPSではリモートアクセス関連プロセスだけが起動していた(図6)。さくらのクラウドでは、SSHへのブルートフォース攻撃(考えられるすべての組み合わせを実行する「総当たり攻撃」)を防御する「fail2ban」のサービスが起動していた。今回は、これもリモートアクセス関連プロセスとみなした。
このほかニフティクラウドではプログラムとポート番号を関連付ける「portmapper」などが、Osukini ServerではWeb管理インタフェースを提供する「webmin」などが動作していた。いずれのプロセスも役割と用途、要不要を判断できるレベルだった。
ServersMan@VPSでは「smadmd」というプロセスが動作していた(図7)。独自の管理プロセスで、どういった処理を実行しているのか、ある程度は推測できる。だが、一般的なLinuxディストリビューションでは見掛けないプロセスなので、今回はあえて厳しく判断した。