銀の鍵 (The Silver Key)

軽井沢の別荘に温度・湿度を測定するマイコンを設置し、そのデータを東京本宅まで転送して365日24時間に渡りデータを収集し、それをグラフ化しようと考えている。そのためには東京本宅入り口のルーターに、ファイル転送の為の「穴」をあけなければならない。

アクセス元が固定IPであるならば、ルーターまたはサーバーでアクセス元IPによるアクセス制御を設定してしまえば、まず安全な環境となる。しかし、軽井沢別邸のインターネット環境は、固定IPに掛かる余計な出費を嫌い、動的IPとなっている。また、本事案はゆくゆくは商用サービスとして昇華することが出来る可能性があるので、任意のクライアントIPからのアクセスを許可したい。なので、任意のアクセス元IPからのファイル転送を「セキュアに」実現する必要がある。

インターネットに任意のIPからアクセス可能な「穴」をあけるのは、実は非常に危険なことである。インターネットはもともと、米国防総省(DOD)において、核戦争にも耐えうるリライアブルな（信頼性の高い）ネットワークを実現するプロジェクトとしてスタートした。その後民間に払い下げられ、大学における学術ネットワークとして普及した。大学間であるならば、それ程「悪意のある」アクセスはないので、インターネットの原初のプロトコルは性善説に基づく「隙だらけ」なものとして始まり、その後商用利用が始まった段階で様々なセキュリティ問題をさらけ出し、泥縄式の対策によって今日に至っている。まぁ、とにかく世界の縮図みたいな感じの悪意が存在するのよ、インターネットにわ。

本題に入ると、sshを使ってファイル転送するのだが、任意のコマンドを実行出来てしまうシェルは渡したくないし、気前良くサーバーの全ファイルシステムをベロォ～～ンと開示する気は毛頭ない。要件としては：

• sshプロトコルを使ってファイル転送をする。転送ログを残せるのでsftpが良い。
• 特定ユーザー（この設定例では"goldcup"とする）のみアクセスを許可する。また、アクセスには公開鍵認証のみを許可する。
• サーバーのファイルシステムを隠蔽する。つまり、chroot jail環境とする。
• 通常管理業務用のOS標準添付のOpenSSHとは別のOpenSSHバージョンを利用したデーモン（sshd）を、ファイル転送専用に、通常のsshd(TCP/22)とは別のポート（この設定例ではTCP/12345とする）で稼動させる。

この目的のために調べてみると、sshと組み合わせてファイル転送のみを許可する仕組みを作ることができることが分かった。rsshというツールなのだが。

設定にあたって参考としたサイトは以下の通り。

1. Linux Configure rssh Chroot Jail To Lock Users To Their Home Directories Only
2. log of sftp in a chroot (with rssh)

他にもrsshソースに添付のCHROOTファイルにヒントが隠されている。

それでは私が実施した手順を紹介したい。まずはOS標準添付以外のもう一つのOpenSSHをソースからコンパイルする。OpenSSHのtarballはOpenSSHよりダウンロードできる。バージョン（実施例では、バージョンX.YパッチレベルZ）は最新のものがよいであろう。

OS標準のOpenSSHとバッティングしてしまっては困るので、色々とオプションを付けておいた。

次に、設定ファイル（/usr/local/openssh/etc/sshd_config）を編集しておく。

見たところ自明であろう。TCP/12345でssh接続要求を受付け、パスワード認証、チャレンジレスポンス認証を禁止し、rootユーザーでのログオンを禁止し、sftpサーバーは今回コンパイルしたものを使用する。

sftpサーバーのsyslog出力に関しては、log of sftp in a chroot (with rssh)に記述がある。私の設定例では、sftp-serverのログはsyslogファシリティLOCAL6（後にsftp専用として設定する）に出力される。VERBOSEとしてあるのは、sftpセッション中のユーザー操作を細かく記録したいから。sftpコマンドとしては記録されないが、セキュリティに関係するインシデントが逐一記録されるので、それからユーザーの実行しているsftpコマンドを推定することが出来る。

アクセス許可ユーザーについては、AllowUsers行（接続制限の設定）を指定してやればよい。逆に、DenyUsers行を指定する方法もある。ホワイトリスト方式なのかブラックリスト方式なのかということだ。便利な方を使えばよい。

更に、任意のIPからの不正アクセスが頻発すると予想されるので、接続制限の設定の「SSH の接続要求を制限する」の項にて紹介されているいわゆる「スロットル設定」を行っておく。短い時間にバコバコアクセスしてくる輩には接続を受け付けなくする設定だ。良くあるパスワードクラック攻撃を想定した対策だね。

最後に、Linux標準添付のinitスクリプト（/etc/init.d/sshd）をsshd2としてコピーし編集して、Linuxに登録する。そして、sftp転送専用のsshdインスタンス(/etc/init.d/sshd2)を起動する。

起動したかどうかは、ポート（TCP/12345）を見るなり、プロセスを見るなりすれば確認できる。

sftp専用のsshdは起動した？よかったね。

一応念のため、scpとsftpを使用可能とし、先ほど入れたOpenSSHバージョンX.YpZのバイナリを指定する。

忘れないうちに、sftpユーザー（goldcup）を作成し、そのログインシェルをrsshに変更しておこう。

rsshの設定ファイル(/usr/local/rssh/etc/rssh.conf)も編集しておく。

sftpのみを許可し、chroot jailは/home/jailとしている。

まだまだ設定は続くよ。次はchroot jail設定をやるんだから！！

実は、chroot jailは万能ではない。Best Practices for UNIX chroot() Operations に色々と注意点が書いてある。jail内に使わない余計なファイルを置いたり、外部ファイル・ディレクトリへのハードリンクを置いたり、setuid-rootプログラムを置いたりしない事は常識かな。jailに閉じ込めるプロセスをroot権限で走らせるのももちろんご法度。root権限を盗られてしまうと、jail環境外へ通じる道が開けてしまう可能性が高くなるらしいからね。

まぁ、そういうことだ。今回はrsshでchrootするので、「親」のsshdはroot権限が必要だね。しかし、sftp-serverが起動すると、これはsftpユーザーの権限で稼動するので安心だ。試しに私のところでsftp-serverが稼働しているサーバー上で、sftpクライアントで接続中のプロセスのステータスを覗いてみると：

興味があるのは、Uid/Gidの行だ。これだけでは良く分からないが、uid and gid fileds from /proc/pid/status によれば、左から順番に、実(real)UID、実効(effective)UID、保存(saved-set)UID、ファイルシステム(file system)UIDという順番らしい。GIDも同様。これらはすべてsftpでアクセスしているユーザー(goldcup)のものでありroot(UID=0,GID=0)ではないので、ひとまず安心であろう。

ではchroot jail設定を始めよう。参考とした記事は、Linux Configure rssh Chroot Jail To Lock Users To Their Home Directories Only。実は、rsshにLinux用のchroot jail作成用のスクリプト（mkchroot.sh ）があるらしいのだけれども、僕は試していない。まぁ、手作業で汗をかけば、原理原則も見えてくるだろうから、今回は手作業でjail環境を構築した。

chrootのベースディレクトリは/home/jail。ここに必要なディレクトリを作成し、ファイルをコピーしていく。（私の例では64bit版Fedora 10なので、libディレクトリではなく、lib64ディレクトリが必要となる。）また、sftpで転送してきたファイルはバッチ処理するはずなので、バッチが稼動するユーザーとグループ（それぞれbatchユーザー、batchグループとする）を用意しておき、goldcupのchroot jail内ホームディレクトリのオーナーグループをbatchグループとし、かつ同ディレクトリのsetgidビットを立てておくことにより、同ディレクトリ内で作成されるファイルのグループオーナーが自動的にbatchグループによる所有となるようにしておく。rssh.conf中のumask設定を"002"としておいたのは、転送してきたファイルに対するグループ書き込み許可をデフォルトで付与したいから。（効いていないようなので、sftpバッチ処理中で明示的にchmodしているが。）

僕のサーバーもそうだけど、Fedoraを使用していると、ディレクトりのsetuid/setgid/stikcy等のファイルアクセスモードビットを立てると、二度と解除できなくなる事がある旨を指摘しておこう。おそらくCentOS等ではこのようなイレギュラーな問題が起こることはないはずなのだが。

特に、rssh_chroot_helperはもともとsetuid-rootプログラムだ。chrootするために必要な権限なんだろうね。しかし、chroot jail内では、もはや必要ない権限なので、setuidビットは明示的に外してある。chroot jail内のrssh_chroot_helper実行イメージから未ロードのページキャッシュをメモリ上にロード出来さえすればいいのだから。chroot jail内でroot権限を取得させるような設定は絶対にダメ！ダメ！

/home/jail/etc/passwdファイル中のエントリーは、sftpログインするユーザーと、batchユーザーのみにしておこうね。

batchユーザーは不要かもしれない。また、シェルの部分を編集して、/sbin/nologinとしている。chroot jail内で必要な情報は、sftpユーザーのUID/GIDのみなのよ。もっとも、rssh実行イメージがchroot jail内に存在するので、ちょっと良く調べればバレバレなのであるが。/home/jail/etc/groupファイルも同様にね。chroot jail内に侵入する攻撃者に余計な情報を提供する必要はないんだから。

さて、次のステップとして、各実行イメージが必要とする共有オブジェクトをchroot jail内にコピーする必要がある。各実行イメージに対してlddコマンドを当てて調べることが出来るけれども、いちいちこれを手でやっているのは大層なので、Linux Configure rssh Chroot Jail To Lock Users To Their Home Directories Onlyにて紹介されているl2chrootスクリプトを利用する。chroot jailのベースディレクトリを/home/jailに変更したものはこちら。

このスクリプトを使って、chroot jail内の各実行イメージが使用する共有ライブラリをchroot jail内にコピーする。

原理的にはこれだけでOKなはずなのだけれども、現実にはそうは立ち行かない。rsshのtarball中、CHROOT文書に書いてある通り、認証関係のライブラリをchroot jail内にコピーしておかなければならない。通常のセットアップであるならば、/lib64/libnss_files.so.?だけれども、LDAP認証でログインする人ならば、/lib64/libnss_ldap.so.?ファイルが必要となるらしい。僕の場合は前者なので、当該共有オブジェクトをコピーすると共に、/lib64中と同様にシンボリックリンクを張っておく。

よし、これでchroot jailの準備は終わったね。

まだまだ！！何だ、もう疲れちゃったの？sftpの出力を記録するsyslogの設定が残っているんだけど。しかも今回はchroot jailとなるので、その点も考慮する必要がある。

古き良きsyslogであるならば、Linux Configure rssh Chroot Jail To Lock Users To Their Home Directories OnlyのModify syslogd configurationの項が参考となる。 /etc/sysconfig/syslogファイルを編集して、chroot jail内に追加のログ用Unixドメインソケットを作成するようにして、syslogを再起動する。この設定例ではLOCAL6ファシリティをsftpサーバー用に割り当てる設定を追加している。sftpのログは/var/log/sftp.logに保存される。

さて、僕のサーバーの場合は、より新しいrsyslogとなっている。いくつかやり方はあるんだろうけど、rsyslog.confの編集だけで、syslogと同様にchroot jail内Unixドメインソケット追加とLOCAL6ファシリティの追加ができる。もちろん、設定ファイル編集後、rsyslogを再起動する。

これで一式設定が済んだね。やっと動作確認に入れる。

sftpクライアントは、私のThinkPad X121e Windoes 7 64bit。これになぜかOpenSSHが入っているのが、とってもマジカル！Installing OpenSSH on Windows 7の手順に従ってインストールしてある。（確か、動かすために、ちょっと手順を追加したか、ひねった記憶があるが・・・）外部からThinkPadにアクセスするようなsshdは入れていない。あくまでもクライアントのみ。空パスで鍵ペアを作成し、公開鍵認証が出来るようにセットアップしておく。公開鍵はchroot jailしたホームディレクトリ（/home/jail/home/goldcup/.ssh）ではなく、chrootする前のホームディレクトリ（/home/goldcup/.ssh）に仕込む必要がある。公開鍵認証設定手順については、例えばSSH公開鍵認証手続きをみてやっといて。Windowsの場合、HOME環境変数に自分のホームディレクトリ（C:\Users\【ログイン名】）を設定しておき、その配下に".ssh"ディレクトリを作成して鍵を保管するようにすると良い。

さて、sftpによる対話的セッションの確立とファイル転送を早速実施してみた。

転送先サーバーは、yggdrasil（ユグドラシル＝世界樹）。このWEBサーバーのプライベートな名称なの。テストアカウントは、goldcup。待ちうけポートはTCP/12345。転送ファイルは、test.txt。sftpセッションを確立後ホームディレクトリへ移動して、ファイルを転送後、パーミッションを660に設定している。chroot jail内ホームディレクトリをsetgidしているためか、ファイル転送しただけだとパーミッションが000となってしまうんだよね。

転送先サーバー上で、ファイルが出来ていることを確認する。

これならば、batchグループのユーザーによるバッチ処理でもゴリゴリと転送ファイルを処理・加工できるよね。

同じ処理を対話的セッションではなく、バッチファイル(batch.txt)にまとめて処理することができる。

こりゃ、楽チン。

一方、これら一連の操作をすると、サーバー上のログにきちんと記録が残っているのが分かる。

chroot後もきちんとログが残っていることに注意して欲しい。これなら運用だってばっちりでしょう？

このセットアップ方式だと、転送先サーバーのTCP/22とTCP/12345のsshd側の鍵が異なっているので、同一クライアントマシンから両ポートにアクセスするたびに%HOME%/.ssh/known_hostsに書かれているサーバー側の認証トークンのようなものが違っているよと警告されて、サーバーのエントリーをknown_hostsから削除しないとサーバーへアクセスできなくなる。だから、バッチ用クライアントからOpenSSHでアクセスするのは、TCP/12345のみにするとよい。TCP/22のシェルが欲しければ、PuTTY等を使えば問題なくサーバーへアクセスできる。

最後に一言。今回設定したサーバーがルーターやファイヤーウオールの背後にあるのであるならば、NAT設定をきちんとしておくことだ。TCP/12345へ転送するグローバルIPとポートを設定しないと、パブリックなインターネットからアクセスできないよ。個別サイトの問題だし、本稿の範囲を逸脱するので、詳述は致しませんがね。