この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
今まで行ってきた個人的活動の中で、ssh接続の安全性について疑問が出てきたのでその内容をまとめてみる。
■ 問題の原点
まず、世に存在するvpsやクラウドシステムには、基本的には2種類の構成が存在している。このうちコンテナ型と呼ばれる構成では、予め必要とされてるsshやメールなどの基本的な内容が初期段階より構成されており、コンテナを選択するだけですぐにシステムの構築が出来る、手軽さが売りになっている。このコンテナには、予めsshが組み込まれていることが多く、そのため管理者のpasswordがデフォルトで決めうちになっている場合も多い。管理者のpasswordをデフォルトで放置していた場合、外部からの攻撃によって、あっさりと侵入を許してしまうことがある。
本題は、ここからだ。このsshが最初からインストールされている＝ホストキーが最初から入っている＝同じコンテナを使う限りホストキーは変わらない。ということになる。
また、vpsやクラウドシステムが大規模になればなるほど、この傾向は強まり、/16レベル（65535台）で同じホストキーで稼働しているケースもある。
ホストキーが同じと言うことは、sshを構成する際に用いられるseedキーも同一の物を使用していると考えて良いだろう。このseedキーは、乱数を用いており、このseedキーを変更する事で、ssh通信を行う際の暗号化通信に於いて、幅（バラエティさ）を持たせている。
この問題は、2008年に指摘された、下記内容に非常によく似た傾向をもつと考えられる。
DSA-1571-1 openssl — 予測可能な乱数の生成
http://www.debian.org/security/2008/dsa-1571
DSA-1576-1 openssh — 予測可能な乱数生成器
■ ssh 通信をあとからクラックしてみる
既に、幾つかの同一vpsを契約し、同一コンテナを展開することでホストキーが一致する or 一定の範囲内に収まることを確認している。
このホストキー情報を元に、予め生成してあるレインボウテーブルを用い、通信内容をあとから解析することで、その内容について平文に戻すことにも成功した。*1
また、多くのsshは、opensslを元に構成されており、デフォルトコンポーネントとして、opensslが含まれる場合はこの脆弱性が如実に表れる傾向がある。*2
■ 対策方法
このため、コンテナベースのsshを用いる場合は下記に注意し、速やかに対応することを強く推奨する。
- コンソールベースでログイン可能な場合は、sshのホストキーを再生成する
- 上記に加え、鍵交換を用いる
ベストな対応方法は、２であるが、どうしても都合により対応で気なのであれば、１を実行することで、ホストキーが事前生成された一定の範囲外になることにより、このリスクを低減させることが出来る。
*1: やり方については公開しない
*2: sshのクラックほどたやすくは無いが
