仙石浩明の日記

前回は、ssh のポートフォワーダには次の二点の欠点がある、 というお話をしました。

1. リモートホストにログインアカウントが必要
2. リモートホストへアクセスできることが必要

すなわち、ssh でポートフォワードを行なう場合、例えば

ssh -L 8080:intra:10080 remote "sleep 1d"

といった感じで実行しますが、ssh ログイン先である remote の セキュリティレベルを下げる要因となってしまう、という欠点です。

欠点 (1) を VPN-Warp ではどのように解決しているか

VPN-Warpでは、リモートマシンにログインアカウントは必要ありません。 リモートマシンに必要なのは、リレーエージェントと呼ばれるプログラムを 走らせることだけで、Linux 上でも Windows 上でも走らせることができますし、 Windows 版は、NT サービスとして実行することも可能です。

VPN-Warp ではユーザ管理をリレーサーバ上の DB で行なっていますので、 100万人規模のユーザに対しても余裕でサービスできます。 リモートマシンではユーザ管理を行なう必要がないので、 リレーエージェントを走らせるために必要な設定は、 ポートフォワード先 (上述の例だと intra:10080) の設定だけです。

リレーエージェントが行なうのは、 ポートフォワードに限定されているので、 セキュリティリスクを最小限に抑えることができます。

欠点 (2) を VPN-Warp ではどのように解決しているか

VPN-Warpでは、リモートマシンに直接アクセスする代わりに、 中継専門のリレーサーバを用います。 リモートマシン上で走らせるリレーエージェントが、 リレーサーバへアクセスしてリレーサーバと連係動作することによって、 ローカルホストがアクセスする対象はリモートマシンではなく リレーサーバになります。 ssh と VPN-Warpの違いを図で書くと次のような感じになります:

ssh のポートフォワードの場合:

ローカルホスト                          リモートホスト
    ssh ─────────────────→ sshd  ─→ intra
  8080番ポート …………………………………………………→ 10080番ポート

VPN-Warpの場合:

ローカルホスト         リレー           リモートホスト
    stone ─────→ サーバ ←──── relayagent─→ intra
  8080番ポート …………………………………………………→ 10080番ポート

図中 relayagent というのがリレーエージェントです。 VPN-Warpの場合、リモートホストへは外部からアクセスする必要が ないことに注意して下さい。 代わりに外部からのアクセスを受け付けるのは「リレーサーバ」です。

ssh の場合はリモートホストが外部からの攻撃に晒されるリスクがあるわけですが、 VPN-Warpの場合は、外部からの攻撃に晒されるのはリレーサーバだけです。

そしてリレーサーバは、KLab など VPN-Warp 提供側が運営するので、 VPN-Warp ユーザは外部からの攻撃を気にする必要がありません。

また、リレーサーバ自体は単にデータを右から左へデータを流すだけで、 ssh ログインアカウントのような侵入の足掛かりになるようなものは 何もありません。 もちろんリレーサーバは、専用のディレクトリへ chroot してから、 リレーサーバ専用のユーザ権限で実行するようにしています。

CTO日記のほうで 「VPN-Warp入門編」を始めた。 VPN-Warpというのは、port forwarder で、「relay agent」プログラムを動かしているマシンへ、「リレーサーバ」経由で TCP トンネルを掘ることができる。 つまり、イントラの中だろうが固定IPがついてない NAT の中だろうが、ダイアルアップするノートPCだろうが、インターネットへアクセスすることさえできるならば、relay agent を動かすだけで外部からアクセスできるトンネルが設置可能。

ssh の -R オプションと、-L オプションを組み合わせて同様のことが実現可能であるが、大きな違いは、ssh とちがってアカウントを作る必要がないこと。SSLクライアント証明書を発行するだけなので、異なるセキュリティポリシーのトンネルを何本でも手軽に設置できる。実際、KLab のインフラの各所で活用している。

KLabセキュリティ(株)の製品に VPN-Warp という SSL VPN ソリューションがあります。 この製品は、最初のプロトタイプを私が開発し、 社内インフラ構築で長年 (といっても KLab(株) が設立からまだ 6年なので、 せいぜいそのくらいですが) 使い倒すことによって信頼性があがってきたものを、 商品化したものです。 私自身が最初に開発した、という愛着もあるので、 「仙石浩明CTO の日記」という場を利用して、 VPN-Warp を内部構造も含めて解説していきたいと思います。

VPN-Warp は、ふつうの SSL VPN に比べ、以下の特徴があります:

1. サーバ側の設定が簡単
   特殊な設定の必要がありません。 イントラネット上の Web サーバに専用ソフトウェアをインストールするだけです。
2. 既存のイントラネット環境を利用
   ファイアウォールの設定を変える必要がありません。
3. PC、携帯電話、PDA などから利用可能
   主要端末に対応しています。
4. ファイアウォール内部の情報を完璧に保護
   SSL により暗号化・認証 (クライアント・サーバ間の相互認証) で 高度なセキュリティを実現します。
5. クライアント側への簡単な導入
   特別なソフトが必要なく SSL 証明書のインポートだけで使えます。
6. 安定したシステム
   定評ある KLab のデータセンタを利用するため安心です。

VPN-Warp って何？

一言で言うと、ポートフォワーダです。 ssh のポートフォワードを使ったことがある人は多いと思うのですが、 基本はアレと同じです。 ssh だと、ローカルホスト (例えば自分の PC) 上で

ssh -L 8080:intra:10080 remote "sleep 1d"

などと実行することにより、 ローカルホストの 8080 番ポートを (remote から見て) intra:10080 番ポートへフォワードできます。 intra:10080 に、イントラへアクセス可能な http proxy が動いていれば、 ローカルホストの 8080 番ポートをイントラの http proxy として 使うことができるわけですね。

じゃ、ssh でいいんじゃない？ なんで VPN-Warp を使うの？

ssh のポートフォワーダには大きく分けて二つの欠点があります:

1. リモートホスト (この例では remote) にログインアカウントが必要
   ポートフォワードするためだけに、 ssh でログインできる権限を与える というのは、いかにも牛刀ですよね？ また、サーバのアカウントというのは滅多矢鱈に増やせるものでもないので、 例えば数千人を超えるユーザにサービスする方法としては現実的ではありません。
2. 外部からリモートホストへアクセスできることが必要
   この例の remote はイントラ内へアクセスできることが必要です。 イントラ内へアクセスできるサーバを 外部からアクセスできるセグメント (例えば DMZ) に置くのは 現実的ではありませんから、普通はいったん外部からアクセス可能な サーバ (例えばファイアウォール) の 適当なポート (例えば 10022 番ポート) で受けて、 それをイントラ内へフォワードするように設定しておくことになります。 DMZ に置くよりはマシであるものの、 外部から直接ログインできてしまうことにかわりはありません。

この二つの欠点は、どちらも「リモートホスト」の セキュリティレベルを下げる要因になります。 単刀直入に言えば、外部の第三者が「リモートホスト」にログインして フルコントロール権限を奪うリスクが高まっている、ということです。

次回は、VPN-Warp が上記欠点をどのように解決しているか説明します。

ネットが切れる不安という日記を見つけた。

引っ越し先には光ファイバーが入っていないのだ（汗） 明日、ＡＤＳＬが大丈夫かどうか確認して、なるべく間隔があかないように手続きをしないと。 今の時代、一日でもネットに接続できないと、なんだか不安になってしまう。

私も 6年前に引越したのだが、 ネットが切れる不安におそわれた。 なんとか間隔があかないように苦労したのを覚えている。 顛末は日経Linuxの連載の枕 (PDF版) に書いた。

引っ越し作業中も社宅でサーバーを動かし続ける必要があるわけですが，部屋中に電話線やらEthernetケーブルが張り巡らせてある状態で引っ越し作業ができるはずはないので，サーバー，ルーター，TA（Terminal Adapter），電話等のネットワーク関係を部屋の片隅の半畳程度の部分に再構築し，作業中絶対にこの部分には近付かないよう＊3 引っ越し業者の方にお願いすることにしました

当時はまだ ADSL のサービスが始まっていなかったので、OCN エコノミーを利用していた。だから TA。

今朝未明、bフレッツのメンテナンス工事があって、 GCDの対外線が切れた。 切れたこと自体は事前に NTT からアナウンスがあったことだし 問題はないのだが、

bフレッツが切れたことにより PPPoE を行っている pppd が終了すると、 /etc/ppp/adsl-lost が実行される。 GCD の adsl-lost は次のようになっている:

#!/bin/sh
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
. /etc/rc.d/hostname
MASTER_FILE="/var/run/keepalived_vrrp.MASTER"
if [ -f $MASTER_FILE -a "$1" = "/etc/ppp/pppoe.conf" ]; then
    rm -f $MASTER_FILE
    ERROR_FILE="/var/run/keepalived_vrrp.ERROR"
    echo 2 >> $ERROR_FILE
    /command/svc -t /service/keepalived/
fi

つまり、/var/run/keepalived_vrrp.MASTER を削除したうえで keepalived を再起動する。 すると、keepalived は BACKUP 状態に移行する。 すると、

/etc/rc.d/vrrp_notify INSTANCE VI BACKUP

実行されて、vrrp_notify が adsl-stop を呼び出す。

そして、adsl-stop が adsl-connect が強制終了する。 こうして完全な BACKUP 状態になるはずだった。

ところが

今朝起きて見てみると、 ゲートウェイが両方とも BACKUP 状態になっていた。(*_*)

片方のゲートウェイは PPPoE がつながっていて、 インターネットに正常に接続しているのだが、 あいにく BACKUP 状態なので、 GCD LAN のデフォルトゲートウェイアドレスである 192.168.1.1 を 持っておらず、 GCD LAN の他のマシンからインターネットへ接続できない状態に 陥っていた。

どうしてこんな事態になってしまったのか考えるより、 まずは復旧が優先ということで、 PPPoE がつながっているのに BACKUP 状態となっている 中途半端なゲートウェイ上で adsl-connect プロセスを殺し、 keepalived を再起動させて、 完全な BACKUP 状態へ移行させた。

すると、もう片方のゲートウェイが自動的に MASTER へ昇格して、 無事正常な状態に戻った。

その後、原因を調べていると、 前述したように adsl-stop が adsl-connect を強制終了させることが できずに adsl-connect が走り続けていたことが原因と判明。 つまり、adsl-connect が走り続けたために、 BACKUP 状態であるにもかかわらず PPPoE のリトライを行っていた。 そして bフレッツのメンテナンス工事の終了にともなって PPPoE が成功、 BACKUP 状態なのに PPPoE でつながっている、という状態が発生した。 この状態では、正常にインターネットにつながっているために、 MASTER に昇格することはなく、BACKUP 状態が継続する。

一方、もう片方のゲートウェイは、MASTER に昇格しようとして PPPoE を試みても失敗してしまう。 つまり MASTER へ昇格できない。 したがって、両方のゲートウェイが BACKUP 状態のままになる。

というわけで問題は adsl-stop が adsl-connect を 終了させることができない点にありそうだと推測。 あらためて adsl-stop を読みなおすと...

    # Kill pppd, which should in turn kill pppoe
    if [ -r "$PPPD_PIDFILE" ] ; then
        PPPD_PID=`cat "$PPPD_PIDFILE"`
        $LOGGER -p daemon.notice "Killing pppd"
        echo "Killing pppd ($PPPD_PID)"
        kill $PPPD_PID > /dev/null 2>&1 || exit 1
    fi
    ....
    # Kill adsl-connect
    $LOGGER -p daemon.notice "Killing adsl-connect"
    echo "Killing adsl-connect ($PID)"
    kill $PID > /dev/null 2>&1

以前このスクリプトを読んだときは見落としていたのだが、 「kill $PPPD_PID」の後に「|| exit 1」がついている！ なんだこれは！？

つまり、pppd プロセスが動いていなければ exit してしまうので、 adsl-connect を終了させないではないか！ 誰だ、こんな頭悪いコードを書いた奴は。

adsl-connect は pppd が失敗すると、 リトライするまえに 5秒 sleep する。 つまりこの 5秒間は pppd プロセスが無い。 だから、運悪く sleep 中に adsl-stop を実行すると、 adsl-connect が強制終了されずに残ってしまう。

速攻で adsl-stop から「|| exit 1」の部分を削除した。 これで安心 (だといいな)。

GCDバックアップ回線用のフレッツADSL では、 バックアップ回線ということで固定IPアドレスにはしていない。 どのくらい安定してつながっているか過去 10日間の統計を取ってみた。

毎分 ssh のテストログイン 14400回(=10*24*60)の結果:

思ったより IPアドレスの切換が激しい。 一時間も持続しないIPアドレスが半数以上にのぼる。 10時間以上安定していたのは 4例だけ。

前回は、 DB サーバへの通信を監視して、 UNIX でのユーザ権限と DB ユーザ名が一致する時に限り 通信を許可する方法について説明しました。

アクセス元となるクライアント側のマシンならば、 どのユーザがアクセスしているか容易に調べられるので、 通信の監視もアクセス元で行なった方が簡単です。

しかしながらこの方法では、 データセンタ内の全てのサーバで通信の監視を行わなければならず、 やや繁雑です。 また、UNIX でのユーザ権限ごとのアクセスコントロールを 実現する方法として、 前回は各ユーザごとに専用の UNIX ドメインソケットを用意し、 そのパーミッション設定でコントロールする方法を紹介しましたが、 当然のことながら DB アクセスを行うクライアントプログラムが UNIX ドメインソケットをサポートしていなければなりません。

DB サーバへの通信の監視をアクセス先、 つまり DB サーバー側で行うことができれば、 クライアント側は監視が行われていることを意識する必要がなくなります。 つまり前回説明した「入口規制」によるアクセス制限ですね。 クライアント側から見れば、 普通に DBサーバへ TCP 接続するだけなので、 どのようなクライアントプログラムでも利用可能でしょう。

この入口規制を実現するには、 どのユーザ権限でクライアントプログラムが動いているのか、 DB サーバ側から調べる必要があります。 しかしながら、TCP 接続ではサーバ側は送られてきた パケットを受け取るだけなので、 そのパケットを誰が送信したかまでは関知しません。 そこで、通信相手が誰なのか調べる方法を定めたのが、 RFC1413 で提案された IDENT プロトコルです。 IDENT プロトコルは、 受け取った TCP パケットに記録されている 送信元の IP アドレスとポート番号を手がかりに、 相手が誰かクライアント側へ問い合わせます。

IDENT プロトコルは、あまり使われなくなって久しいので、 まず簡単に紹介しましょう。

ホスト CLIENT からホスト SERVER の 12345番ポートへアクセスした 場合について考えます。 その接続状況は次のように netstat コマンドなどで確認できて、

SERVER % netstat
Proto Recv-Q Send-Q  Local Address  Foreign Address  State
tcp        0      0  SERVER:12345   CLIENT:45486     ESTABLISHED

この場合だと、CLIENT の 45486番ポートから SERVER の 12345番ポートへの TCP 接続が確立している (ESTABLISHED) ことが分かります。

このとき、SERVER は CLIENT に IDENT 問合せをすることによって、 CLIENT のどのユーザが TCP 接続の相手か調べることができます。

SERVER % telnet CLIENT 113
Connected to CLIENT.
45486,12345                                 … (1)
45486 , 12345 : USERID : OTHER :sengoku     … (2)
Connection closed by foreign host.

(1) が SERVER から CLIENT への問合せで、 送受信双方のポート番号の対を送信しています。 これに対し、(2) が CLIENT から SERVER への応答で、 TCP 接続の相手が「sengoku」であることが分かりました。

このように、通信相手が誰か手軽に確認できる便利なプロトコルなのですが、 相手ホストが信用できなければ当然 IDENT 応答も信じることはできません。 不特定多数のホストからの通信を受け付ける場合は、 IDENT 問合せを行なっても「正直な」応答が返ってくるとは期待できないわけで、 少なくともインターネット上ではあまり使われなくなったようです。

しかし データセンタのラック内のサーバであれば、 当然管理者が決まっているでしょうから、 全てのサーバで正しく IDENT 応答を返すように徹底することは容易です。 したがって、 IDENT プロトコルを使った入口規制を実施することができます。

まず DB サーバを、UNIX ドメインソケットでのみアクセスを受け付ける ように設定します。 このソケットは、local ユーザが勝手にアクセスしたりしないよう、 DB サーバを実行するユーザ権限でのみ読み書きできるように 設定しておくとよいでしょう。

次に、特定のポートで listen し、接続を受け付けたら この UNIX ドメインソケットへ中継するプログラムを、 DB サーバを実行するユーザと同じユーザ権限で走らせます。 この中継プログラムは、 中継する際に接続元ホストに対して IDENT 問合せを行ない、 IDENT 応答で得たユーザ名と、 通信を監視することによって得られた DB ユーザ名が 一致しない場合は通信を遮断するというわけです。

このような仕掛けにより、 クライアント側のユーザは、 仕掛けを意識することなく DB サーバにアクセスすることができます。 そして、 何かのはずみに別の DBユーザのパスワードを知り、 その DBユーザになりすましてアクセスしようとしても 通信は遮断されます。

一般に、マシン C からマシン S へのアクセスを制限するには、

(IN) マシン S でアクセスを受け付けるところで制限する「入口規制」
(OUT) マシン C でアクセスを出すところで制限する「出口規制」

の2通りの方法があります。一般にアクセス制限というと (IN) の入口規制を用いることが多いのですが、 これはアクセスを出すマシンが特定できないか、 あるいは特定はできるのだけどマシンの数ないし種類が多過ぎるためです。

例えば、マシン S へのログインを制限したい場合を考えてみましょう。 一般的にはアクセス元となりうるマシンは特定できないか、 特定できたとしても数が多いでしょうし、 そのマシンで動く OS の種類も多種多様でしょう。 アクセス元となりうるマシンの全てで、 アクセスを出すことを制限しようとするのは非現実的です。 なので普通はアクセスを受け付ける側のマシン S で クライアントの認証を行なってアクセス制限をします。

例えば ssh の場合ならどこのマシンからのアクセスであっても、 秘密鍵を持っていることを証明できるならアクセスを許可し、 そうでなければ却下します。 アクセスを出す側のマシンでは何の出口規制もなく、 アクセスを受け付ける側のマシンでの入口規制だけですね。

ところが、データセンタのラック内のマシンに限定すれば、 事情は変わってきます。 ラック内に入れてあるマシンの数は高々有限 ;) ですし、 多くの場合全てのマシンで同じ OS が動いているでしょうし、 管理の都合からいえば全てのマシンを同じチームが管理すべきでしょう。

このような特殊な環境下では、 (OUT) の出口規制も現実的な方法となります。 例えば DB サーバへのアクセスを考えると、 DB サーバは通常のサーバ認証のみであっても、 クライアント側でアクセスを出すのを制限する出口規制を設けることによって、 セキュリティを向上させることができます。

クライアント側の OS が Linux であれば、 出口規制の方法として iptables の OUTPUT チェインを使うことができます。 例えば DB サーバが 12345番ポートでアクセスを受け付けているならば、 ラック内の全マシンにおいて

iptables -N dbaccess 2>/dev/null || iptables -F dbaccess
iptables -A dbaccess -j ACCEPT -m owner --uid-owner dbuser  …(2)
iptables -A dbaccess -j DROP                                …(3)

iptables -A OUTPUT -j dbaccess -p tcp --dport 12345 --syn   …(1)

を実行しておきます。

DB サーバへアクセスを出そうとして、 DB サーバが動いているマシンの 12345番ポートへの接続しようとすると、 まず OUTPUT チェインの (1) のルールによって dbaccess チェインへジャンプします。 アクセスを出そうとしたユーザが dbuser であれば、 dbaccess チェインの (2) のルールによって通信が許可されますが、 dbuser 以外のユーザであれば、 (3) のルールによって通信が却下されます。

つまり、dbuser 以外のユーザは、たとえ DB のパスワードを知っていても、 DB にアクセスできない、というわけです。

DB にアクセスしたいユーザが増えてくると、 そのたびに iptables の設定を変更するのは面倒ですので、 DB サーバへ接続できるユーザは一つだけ (例えば dbuser) にしておいて、 そのユーザ権限で中継プログラムを動かすようにすると便利でしょう。

例えば、DB にアクセスしたいユーザ user1, user2, user3, user4 が あるとします。 まず、DB 上に同名のユーザアカウントを作ります。 次に、ラック内の全サーバにおいて、 ユーザ毎に UNIX ドメインソケットを listen し、 そのソケットへ接続があったら、 それを DB サーバへ中継するプログラム (ここでは dbrelay と呼ぶことにしましょう) を動かします。 例えば次のようなソケットをオープンすることになるでしょう。

/home/user1/socket
/home/user2/socket
/home/user3/socket
/home/user4/socket

各ソケット (あるいはソケットを置いてあるディレクトリ) は、 自分以外のユーザは読み書きできないように パーミッションを設定します。 つまり dbrelay は root 権限で起動する必要があります。 さらに、前述したように DB サーバへアクセスするには dbuser ユーザ権限で実行する必要がありますから、 各ソケットをオープンした後は、 dbuser ユーザ権限に setuid する必要があります。

そして、ここが肝なのですが、 dbrelay は DB サーバへの通信を監視し、 接続を受け付けたソケットのユーザ名と、 DB へのアクセスを行なう DB ユーザ名が一致しない場合は 通信を遮断します。

以上のような仕掛けにより、 例えばユーザ user1 は、 /home/user1/socket へ接続することによって DB サーバへアクセスできるが、 そのとき使用できる DB ユーザ名は user1 だけで、 それ以外のユーザ名で DB へアクセスしようとしても dbrelay によって 通信を遮断されることになります。 しかも /home/user1/socket は user1 以外は読み書きできません。 つまり、各ユーザは自身のユーザ名以外では (仮に他の DB ユーザのパスワードを知っていたとしても) DB へアクセスできない ということになります。

KLab が運用しているコンテンツで使用している DB サーバは、
パスワードを知っているだけではアクセスできません。
どういう仕掛けになっているかの説明は後のお楽しみ、ということで
まずは前振りから...

パスワードというのは知る人が多くなればなるほど漏れるものですし、
ひとたび漏れてしまえば、どこまで漏れるかコントロール不能です。
したがって DB に限らず、KLab ではパスワードへの依存を
できる限り減らしています。

例えば、サーバへのログインは、必ず ssh の RSA 認証を使うことを必須とし、
コンテンツ管理のためのページでは SSL クライアント認証を行なっています。
つまり、秘密鍵を持っている人のみがアクセスできるようにしておいて、
秘密鍵自体は各人の責任において管理してもらう、という方式です。
万一、サーバへ不正なアクセスが行なわれたら、
誰の秘密鍵によってアクセスされたかログが残りますから、
誰の責任か明確になるわけです。

ところが、プログラムが DB サーバなどへアクセスする場合は事情が
変わってきます。まず、

(1) プログラムには責任を負わせることができない ;-)

そのプログラムを開発したり運用したりする人が、
秘密鍵を管理するしかありませんが、
秘密鍵というのはあくまで一人の個人が管理するからこそ
責任を負わせられるのであって、
共同管理ということにしてしまっては、
万一漏れた時に、どこから漏れたのか調べようがなくなります。

かといって、そのプログラムが動作する時に用いる鍵の管理を、
一人の個人が管理するルールにしてしまうと、
運用がとても大変になります。
障害が起きた時に、その人がいなければ原因究明もままなりません。

二番目の問題として、

(2) DB アクセスには高いパフォーマンスが要求される

人がサーバ等へログインするときは、所詮は人間のスピードですから、
大したレスポンススピードは必要ありません。
秘密鍵による認証を行なう余裕は充分にあります。
一方、Web アプリケーション等のプログラムが DB サーバへアクセスする場合は、
ページのヒット数が高ければ高いほど、高いパフォーマンスが要求されます。

コネクションをプールするなどの手法によって、
認証コストを下げることは可能であるものの、
プログラム－DBサーバ間の通信路の暗号化などを行なっていては、
暗号化処理のぶんだけサーバ負荷が余計にかかります。
つまり DB サーバへのアクセスに SSL クライアント認証を行なう、
などの方法は、なるべくなら避けたいところです。

ではどうすればいいでしょうか？
(続きは次回に)