仙石浩明の日記

2006 : April

2006年4月22日

評価面談

この時期、KLab と KLabセキュリティは 上半期 (9月~2月) の評価面談の季節です。 私は KLab の研究部門である Kラボラトリー (旧社名をとって名付けました) と、 KLabセキュリティの技術本部を担当しています。 昨日は、私の直接の部下の中で一番若い H さんの面談を行ないました。

H さんは昨年の新卒入社なので、まだまだ学ぶべきことはたくさんあるわけですが、 人一倍技術が好きなので、私としても大変期待しています。 いまは、いろんなこと (気配りとか、会社の業績とか) を気にするより、 好きなことを自由に学び、伸び伸びと育って欲しい、と思っています。

彼に話したのはこんなことです:

一点注意してほしい点をあげるとすれば、 様々な技術に関心を持つ際に、強弱のメリハリをつけることを意識する、 という点です。 WWWで公開される情報がどんどん充実していく昨今、 どのような技術でもかなり奥深いところまで WWW で手軽に入手できるように なっています。 このこと自体は素晴らしいことなのですが、 入手が手軽に可能ということが、 分かったつもりに陥るリスクを増やしているわけで、 この罠に陥らないよう注意してください。

特に関心を持った分野、たとえばベイズ理論やオートマトン理論などは、 通りいっぺんの理解にとどまらず、とことんまで勉強してやる、 くらいの意気込みで挑戦してほしいと思っています。

WWW の普及によって、広く浅く学ぶことは格段に容易になりました。 広い視野を持つことはとても大切なことなのですが、 各分野それぞれについて自身がどのくらいのレベルまで学べたか把握していないと、 ほんの表層をかすっただけで満足してしまいかねません。

だから、どんな分野でも、どんなに狭いピンポイントでもいいから 深く深く学ぶ経験が重要だと思うのです。 深く学べば学ぶほど、その深さが基準となって、 その他の分野への理解がどのレベルまで到達したか、 より正確に把握できるものでしょう。

浅くしか学んだことがなければ、その浅さがその人の限界になります。 なにを学んだとしても、自身がどのレベルまで理解できているのか、 自身が理解できていない深淵がどれだけ深いものなのか、 永遠に知ることはないでしょう。

だから、特に若いうちは、とことんまで学んでみて欲しいのです。 H さんには短期的な目標設定として、 古典的な教科書一冊を完全理解することを勧めました:

なにかひとつでいいので、半期かけてとことん学んでみてください。 ひとつの分野をどこまでも深掘りする、ということを一度でも経験した人は、 興味の対象がいろいろ移り変わっても、 分かったつもり状態に陥りにくいものです。 WWW上での学習だと、深堀する以前に興味が発散してしまうリスクがあるので、 評価が確立した古典的な教科書を一冊、完全理解に達するまで読み込む、 といった勉強方法のほうがいいかもしれません。

どんな分野の教科書でもいいと思いますが、 一例として私が学生時代に学んだ「古典的な教科書」を紹介しました:

Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)

27年前の本です! 秒進分歩ともいわれる技術革新のスピードの中で、 1/4世紀以上昔の本が今でも通用するのですから、愉快じゃありませんか。

- o -

追記:
やめるまではがんばりまっせ」から引用:

なんでかというと、結局わしは、会社のためとか、自分の給料を上げるためだけに仕事しているつもりはないからなのです。自分の実力のために、今吸収できるべきことは全て吸収し、機が熟したら、どこにでも飛び出せるようにしておこう、と思っているからです。だから、今は評価がなかろうがなんだろうが、とにかくやるべきことをバシバシこなさなきゃイカンと思っているのです。

その通りですね。 若いときは若いときしかできないことをすべきだと思うのです。 会社がどうなろうと、 スキルさえ身につければ技術者は勝ち残れるのですから。

Filed under: 技術者の成長 — hiroaki_sengoku @ 10:35
2006年4月21日

同時に考えよう (4)

パケットの気持ちになって考える

むろん、パケット(といっても小包のことではなくて、IP パケットとかのことである) に 気持ちがあるわけではないが、 パケットからみたネットワークを無意識の思考で考えてみる、 という意味。

パケットの振る舞いを、意識した思考で考えていては、 あらゆる状況下での振る舞いを考えようとすると時間がかかりすぎる。 頭の中にネットワークのエミュレータを構築し、 無意識の思考でパケットをやりとりしてみればどうだろうか。

プログラムの気持ちになって考える

プログラムの視点、 ないしプログラムを実行する CPU の視点を、 無意識の思考で考えてみる。 プログラムを一ステップずつ意識した思考で追っていては、 いつになってもバグの原因に思い当たらないが、 頭の中にプログラムを思い描き、 無意識の思考で実行してみればバグの原因が「ひらめく」かもしれない。

将棋の駒の気持ちになって考える

寺尾創さまのコメントにある、 「直感で何通りか次々に解候補が無意識に浮かんでくる」というのは、 頭の中に将棋盤と駒があって、 無意識の思考で超高速に駒を動かしてあらゆる指し手を探索している、 ということなのか。 これが意識した思考だと、 あらゆる指し手を探索するには非現実的な時間がかかってしまうだろう。

Filed under: 自己啓発 — hiroaki_sengoku @ 18:37
2006年4月21日

VPN-Warp 入門編 (4)

前回は、VPN-Warp をポートフォワーダとして使う場合の、 基本的な設定方法について説明しました。 ローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合に、 ローカルホストで stone を走らせる方法について説明したわけですが、 stone はもともと VPN-Warp 専用のソフトウェアというわけでは決してなく、 stone は汎用リピータです。

つまり stone を使わなくても、 https リクエストをリレーサーバに送信することができるソフトウェアなら なんでも使うことができます。

試しに OpenSSL 付属の s_client コマンドを使ってみましょう:

% s_client -cert relay,10020-cert.pem -key relay,10020-priv.pem -connect relay.klab.org:443
CONNECTED(00000003)
        ...
subject=/C=JP/postalCode=106-6122/ST=Tokyo/L=Minato-ku/streetAddress=6-10-1 Roppongi/streetAddress=Roppongi-Hills Mori-Tower 22F/O=K Laboratory Co.,Ltd/OU=HTTP/OU=InstantSSL/CN=relay.klab.org
        ...
---
GET / HTTP/1.1

HTTP/1.1 200 OK

:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

最初の行の s_client コマンドの実行と、 後ろの方の「GET / HTTP/1.1」および続く改行二回が手で入力した部分で、 あとは s_client コマンドの実行結果です。 クライアント認証を行なうため、s_client の引数に証明書の

公開鍵 (-cert オプション)
relay,10020-cert.pem
秘密鍵 (-key オプション)
relay,10020-priv.pem

を指定しています。s_client は SSL 接続した後、サーバ証明書の内容などが、 どばっと出力されますが、その後「---」を表示してセッションが確立します。

そして、リクエストヘッダ (のようなもの)

GET / HTTP/1.1
(空行)

を送ると、レスポンスヘッダ (のようなもの)

HTTP/1.1 200 OK
(空行)

が送られてきて、ポートフォワード先とのセッションが確立します。 この例の場合では、確立した直後にデータが送られてきていますね:

:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

これは、KLab 社内の IRC サーバから送られてきたデータです。 KLab では技術的な打ち合わせは IRC で済ませてしまうことも多く、 隣の席にいる人との打ち合わせでさえ、IRC で行なうケースがあります。 IRC で話しておけば文字で残りますし、 リモートにいる人も議論に参加できるので、とても便利です。

KLab 社内 IRC はあまりに常用されているので、 いつでもどこでも IRC に参加しておきたいわけで、 そういうとき VPN-Warp はとても便利です。 つまり、stone をノートPC 上で NT サービスとして走らせておくだけで、 ノートPC がインターネットにつながってさえいれば、 ダイアルアップでつながっていようと無線LAN でつながっていようと関係なく、 6667番ポートを常に社内IRC サーバへポートフォワードすることができて、 ノートPC 上の IRC クライアントで localhost:6667 へ接続して 常にチャット状態にしておける、というわけです。

Filed under: システム構築・運用 — hiroaki_sengoku @ 12:56
2006年4月20日

同時に考えよう (3)

相手の気持ちになって考える

相手のバックグランドを知る。 どういう生い立ちか、どういう環境で育ったか、何を学んだか。 バックグラウンドが分かれば、 物事をどうとらえ、どう考えるかが見えてくる。 あたかも自分の頭の中に、 相手の人格のエミュレータが動いているかのように。

意識した思考で、 相手の考えを一ステップづつシミュレートしていては遅すぎる。 あくまで相手の気持ちになりきることが重要。 無意識の思考で、相手の人格のエミュレーションができるようになれば、 無意識における相手の思考と、 意識した自分の思考をインタラクションさせることができるようになる。

無意識における相手の思考と、 現実の相手の思考との差をフィードバックさせて、 エミュレーションの精度を高めることができる。

Filed under: 自己啓発 — hiroaki_sengoku @ 15:20
2006年4月20日

面接FAQ: 高い技術力って例えばどんなことですか?

2000年に (株)ケイ・ラボラトリー (KLab の当時の社名) を創業してから 6 年、 当然ながら数限りなく採用面接を行ないました。 最近でこそ私の面接なしで採用された人達も増えてきたのですが、 一時は技術部門のほぼ全員が私の面接を経て入社した という人達だった時期もあります。

最終の役員面接というと、多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、応募者が戸惑うケースが多々ありました。 私としては、応募者に合わせてその都度、どういう面接方法が適しているか考えて、 質問する内容を変えてはいるのですが、 そうはいっても 100人以上も面接すればある程度パターンのようなものもでてきます。

比較的頻度が高い質問パターンを紹介し、 どう答えることができていたら採用になっていたか、 振り返ってみようと思います。 名付けて「面接FAQ」、面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。

- o -

KLab にあまり興味を持っていなかったけど (転職斡旋エージェントに勧められて) とりあえず面接を受けに来ました、 という応募者に、 なんとか KLab の魅力を伝えて、入社しようという気にさせるのが 面接官の腕の見せどころだと思うのですが、 それでもやっぱり面接での話の成り行き上、 志望動機について質問することはよくあります。

すると、「KLab の高い技術力が魅力的」、とか 「そういう高い技術を学び、身につけたい」、とかおっしゃるかたが 少なからずいます。 そういうことを言われてしまうと、 私はつい (^^;)、 「高い技術力って例えばどんなことですか?」と 聞いてしまうのです。 意地悪な質問ですね (_O_)。

多くの方は、そういう質問が返ってくるとは全く予期していなかったらしく、 ここで言葉に詰まってしまいます。 志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていないのです。 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね?

技術ってなんだろう…」 ふとそんなことを考えたことが一度でもあるような人ならば、 「技術を学びたい」なんて抽象的な言い方ではなく、 もっと具体的なことが言えると思うのです。 そして自分が何をしたいか、きちんとイメージできている人は、 KLab に入社したあと、ほぼ例外無く大活躍しています。

Filed under: 技術と経営 — hiroaki_sengoku @ 07:43
2006年4月19日

情報処理のキホン (2)

KLab の開発に参加いただいている協力会社の A 社の S 社長が、 tech ML に投げた問いかけに対し、 同じく協力会社の H 社の役員である K さんが応えました。

# KLab 社内の ML なのに、KLab 社員以外で話が盛り上がる
# こともあるのが、tech ML の大きな特長です (^^;)。

~~ Kさんのメール(一部抜粋)ここから ~~

> #どなたが「専門教育」を受けられた方なのかわかりませんが^^;
> ##ぜひ土日で古い教科書などを掘り出していただきたく:-)

今でもコンピュータでの処理(方法の)限界に関してはとても興味があり

オートマトンと計算可能性 情報処理シリーズ
有川 節夫 (著), 宮野 悟 (著)

あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

~~ Kさんのメール(一部抜粋)ここまで ~~

で、私も話に加わってみました:

~~ 私のメールここから ~~

仙石です。おお、ついに tech ML で計算可能性の話題が...

K さん曰く:

> 「オートマトンと計算可能性」

このあたりの、一通り学べる本を読んでみると、 大学の専門課程で何をやってるのか知る事は、できそうですね。

# でも、知る事と理解する事は全く別物 ;-)

> あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

本当に重要なのは、この「おもしろい」という感覚かもしれませんねぇ...
計算可能性に関する「おもしろい」本としては、

決定不能の論理パズル―ゲーデルの定理と様相論理
レイモンド スマリヤン (著), 長尾 確 (翻訳), 田中 朋之 (翻訳)

あたりがおすすめ。いきなりこの本を読むと挫折するかも知れない ;) ので、
入門用としてはホフスタッターの不朽の名作:

ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版
ダグラス・R. ホフスタッター (著), Douglas R. Hofstadter (原著),
野崎 昭弘 (翻訳), 柳瀬 尚紀 (翻訳), はやし はじめ (翻訳)

があまりにも有名ですね。

# 20周年記念版が出たのか~
# ということはつまり、私が初めてこの本を読んでから 20年たった、という
# ことなのですね。う~ん歳をとったものだ...

Filed under: 技術と経営 — hiroaki_sengoku @ 19:27
2006年4月19日

PPPoE を横取りするには?

GCD LAN内で Real Player コンテンツを再生しようとしたら、 GCDゲートウェイで、外向きポート554番をブロックしていたので、 とりあえず特定の接続先だけ解除する。

これでコンテンツを見られると、思って再生ボタンを押すと、 いきなりゲートウェイがネットワークから見えなくなった。 NICごと死んだのか、IP, IPv6 ともに反応なし。 二つあるNICの両方が無反応なので、 原因はドライバより上のレベルにありそう。 あいにくゲートウェイにはディスプレイカードを入れていないので、 シリアル(RS-232C)経由でログインしてみると、 iptables のログが延々と出力されている。 大半が、root ネームサーバのポート53番から。 つまり DNS 問い合わせに対する応答パケット。 ということは、PPPoE が生きている。これはマズイ。

機能しなくなったゲートウェイが PPPoE をつかんだままでは、 MASTER に昇格したもう片方のゲートウェイが PPPoE できない。 正確に言えば、PPPoE 自体はできるのだがプロバイダがどちらの ゲートウェイへパケットを送ってくれるかは運次第。 事実、ほとんどのパケットは機能しなくなったゲートウェイ側に 届いたので、GCD からインターネットへの通信が事実上不可能になった。

冗長構成を組むとき最も難しいのが、いかにして中途半端な死に方を 回避するかだが、死んだゲートウェイに PPPoE を止めさせるのも、 なかなか難しそうだ。

  1. PPPoE している機能不全状態のゲートウェイには頼らず、
  2. PPPoE 先のプロバイダ側には手が出せない、

と仮定すると、どうすればいいだろうか。 機能不全状態のゲートウェイのNIC を LAN から切り離す仕掛けを 組み込むとかだろうか? (どうやって? ^^;)

Filed under: システム構築・運用 — hiroaki_sengoku @ 09:52
2006年4月18日

ポジティブシンキングでいこう

誰しも言うことで、なにもここで書かなくたって 誰しも百も承知だと思うが、 あまりに重要すぎるのであえて書く。

病は気から、ネガティブに考えれば必ず悪くなる。 悪くなる可能性のあることは必ず悪くなる。 ならば無理やりにでもポジティブに考えよう。 どうしてもポジティブに考えられなかったら、 まずは冷静に考えられるようになるまで考えるのをやめてしまえ。 家に帰って寝てしまえ。

冷静になって考えれば、どんな苦境に立った時だって、 大して不幸なわけじゃない。 どんなに困難な問題にぶちあたったって、 解決策が見つからなくたって、 解決策を見つけようとすれば経験値が上がる。 ポジティブに考えれば、必ずうまくいく。 失敗は成功の母、必ず次につながる。

むしろうまくいっているときほど慎重であれ。 成功は失敗の母、成功体験にとらわれれば、 いつか必ず失敗する。 勝って兜の緒を締めよ、落とし穴はいたるところにある。

Filed under: 自己啓発 — hiroaki_sengoku @ 19:02
2006年4月18日

VPN-Warp 入門編 (3)

前回は、ssh のポートフォワーダと比較して、 VPN-Warp には次の特長があることを説明しました。

  1. ログインアカウントが不要
  2. アクセス対象はリレーサーバのみ

例えばローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合、 次のように、ローカルホストで stone を、リモートホストで relayagent を、 それぞれ走らせます。

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

stone も、relayagent も、リレーサーバに対しては 「クライアント」であることに注意してください。 また、ローカルホスト、リモートホスト、リレーサーバ、 いずれにおいても、ssh の場合のようなログインは必要ありません。

必要なのは、SSL クライアント認証だけで、 stone/relayagent はクライアント証明書を使って リレーサーバへアクセスする、というわけです。 実際、リレーサーバは stone/relayagent にとって、 普通の https サーバのように見えます。 リレーサーバは、stone/relayagent 双方から SSL 接続を受付け、 もし同一のクライアント証明書を持っている組があれば、 それらを結び付ける役割を果たします。

具体的な設定方法

stone/relayagent それぞれの具体的な設定方法を見ていきましょう。

stone の設定

stone の設定ファイルは次のような感じになります:

-q key=private.pem
-q cert=cert.pem
relay.klab.org:443/ssl,http localhost:8080 "GET / HTTP/1.1" --
  • -q key= から始まる行は、SSL 証明書の秘密鍵ファイル、
  • -q cert= から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
  • relay.klab.org:443 はリレーサーバの指定、
  • 最後の localhost:8080 がローカルホストで listen するポートの指定です。

このような設定を行なうと、 stone は 8080番ポートで受けた接続を、 「https リクエストに乗せて」リレーサーバへ転送します。

「https リクエストに乗せて」というのはどういうことかというと、 例えば 8080番ポートに接続して「abcdefg」というデータを送信したとすると、 stone は以下のようなデータを、SSL で暗号化してリレーサーバへ送ります:

GET / HTTP/1.1

abcdefg

あまり「https リクエスト」のようには見えませんが (^^;)、 最初の一行がリクエストヘッダで、 空行をあけて、リクエストボディが続いている、と見なすこともできます。

実をいうとリクエストヘッダ (のようなもの) を送り終わった時点で、 任意のデータの送受信が可能で、 送信したデータデータはそのまま relayagent へ伝わります。 つまり、 8080番ポートが、relayagent へフォワードされる、というわけです。

relayagent の設定

relayagent の設定ファイルは次のような感じになります:

-n
-k private.pem
-c cert.pem
relay.klab.org:443
intra:10080
  • -n は、relayagent をポートフォワーダとして使う、という意味です。
  • -k から始まる行は、SSL 証明書の秘密鍵ファイル、
  • -c から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
  • relay.klab.org:443 はリレーサーバの指定です。
  • 最後の intra:10080 がポートフォワード先の指定です。

このような設定で relayagent を実行すると、 relayagent は、リレーサーバに対して以下のような「ポーリング」を https を装って行ないます。

GET /KLAB/poll HTTP/1.1
X-Ver: 2 relayagent.cpp,v 1.32 W (TAKUMI)

「X-Ver:」の次の数字「2」で、relayagent - リレーサーバ間の プロトコルのバージョン番号を伝えています。 続く「relayagent.cpp,v 1.32 W (TAKUMI)」は単に relayagent のバージョンを (トラブル時の解析用として) 伝えているだけで、通常は参照されません。

このリクエストヘッダ (のようなもの) を送り終わると、 リレーサーバは次のようなレスポンスを返します:

HTTP/1.1 200 OK
X-Customer: nusers=10&type=3&expire=1262271599&digest=0123456789abcdef0123456789abcdef

この、https レスポンスヘッダ (のようなもの) を受信した後、 relayagent はレスポンスボディ待ち状態 (ポーリング状態) になります。 この状態の時、 同じ証明書を持つ stone からの接続があると、 その情報がレスポンスボディとして送られてきて、 relayagent はそれを受けて intra:10080 へ接続を行ない、 stone と intra:10080 との間の通信が確立する、というわけです。

Filed under: システム構築・運用 — hiroaki_sengoku @ 16:42
2006年4月17日

新卒採用 (1)

大学4年/大学院2年の学生さんに、 どれだけこのページを読んでもらえてるか分からない (^^;) のですが、

KLab(株) CTO 仙石 (KLabセキュリティ(株) CTO を兼務) と語る、
「技術者の成長にとって一番役に立つ会社」
「技術者が自ら伸びていくことができる会社」とは?

と題する会社説明会が開催されるようです。

日時: 5/9(火) 13:30~15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20F)

会社説明会といいつつ、 要は私といろんな話題についてお話しましょう、 というノリですので、 私の日記 (CTO日記もよろしく) を見て、 波長が合いそうだと思ったかた、 ぜひ登録をお願いします。

4/27追記: 上記説明会は満席につき、現在は 5/15実施の説明会への登録を受付中です
5/8 追記: 上記説明会は満席につき、現在は 5/30実施の説明会への登録を受付中です

Filed under: 技術者の成長 — hiroaki_sengoku @ 17:11
2006年4月17日

オープンソースにこだわる

多くの会社と同様、KLab (および KLabセキュリティ) でも、 出来る限りオープンソースを利用するようにしています。 我々がDSASと呼んでいる システムインフラは、完全にオープンソースベースとなっており、例えば 「ファイアウォール兼負荷分散器兼ルータマシン」も Linux ベースとなっております。

なぜオープンソースにこだわるのか?

佐野氏のコラムに、 オープンソースにこだわる人の理由って正しい?:

    > オープンソースにこだわる人に理由を聞くと普通
    >
    >  1.無料だから
    >  2.大勢の人が使っているからバグが少ないと思われる
    >  3.ソースコードが公開されているから安心
    >
    > という答えが返ってきます。1と2はまあその通りだと思います。
    > しかし3は個人的にちょっと疑問です。
    > オープンソースにこだわっている人で、オープンソースソフトウェアの
    > ソースコードを実際に分析したことがある人って
    > どのくらいいるのでしょうか。
      ……
    > なのでオープンソースにこだわる理由を聞かれたらかっこいいこと
    > 言わずに素直に「無料だし機能に不満もないから」くらいにしておくのが
    > よいのではないでしょうか。

という問いかけがありました。さすが佐野さん、的を射た厳しいご意見ですね。 正直な話、KLab もオープンソースを利用しているといっても、 スミからスミまで分析しているわけではありませんし、 「無料だし機能に不満もないから」という面もあることは否定しません。 しかし、お客様にサービスを提供するという立場としては、 もう少し積極的な理由も持ちたいところです。

責任あるシステム運用を実現するためのオープンソース

システムにベンダ任せのブラックスボックスな部分があると、 その部分が原因の障害への対応は遅くなりがちですし、 原因究明を完全に行なうことができなければ、 再発防止策も対症療法的なものになりがちです。 これでは自信を持ってお客様にサービスを提供することができません。

KLab も以前は箱モノの負荷分散機を利用していたのですが、 クリティカルなバグに散々悩まされました。 この箱モノは L2処理に問題があり、 通信不良が発生するケースがあったのです。 もちろんベンダへは症状を報告していたのですが、 完全な対策には至らず、なんとか運用でカバーしていました。

これでは、いつ症状が再発するか分からず 精神衛生上もよろしくありません。 そこで、LVS (Linux Virtual Server) を使って Linux ベースの負荷分散機を 構築することにしました。 むろん、LVS のソースコードの全てを完全に把握しつくし、 LVS プロジェクトに貢献できるようになるまでには、 まだまだ道程が遠いのですが、 再現可能な障害であれば問題の所在を見つけ出せる程度の レベルには達することができていると思っています。 しかも、実はこうやって自前で構築した負荷分散機の方が、 それまで使っていた箱モノよりずっと安定して運用できてしまったのです。

ベンダの都合に振り回されないためのオープンソース

プロプライエタリなソフトウェアを使っている場合は、 ベンダがサポートを停止するリスクというのも考えておかねばなりません。 ベンダがサポートを止めたことを理由に、 弊社のお客様に対するサービス提供を止める、というやり方も 無いわけではありませんが、 技術会社を標榜する KLab としては、 あまりそういう言い訳はしたくありません。

すると、 ベンダがサポートを止めたときのことまで考えておく必要がありますが、 あいにくソフトウェアの使用許諾というのは一般に不平等契約で、 ソフトウェアを使用する側には打つ手がないことが多いようです。 ベンダの都合に振り回されるよりは、 いざとなったら自前で解決できるよう、 ソースがオープンになっているソフトウェアを選ぶ方が 結果的に楽といえるのではないでしょうか。

なんかプロプライエタリって馬鹿みたいだな」 (ここギコ!) で、

    > プロプライエタリなソフトの方がよっぽどリスクだらけちゃうの?
    > わざわざクソ高い金払うのに、と思えてくる。

という意見も出ているように、 ベンダのサポートがアテになるケースばかりとは限りません。

自由なシステム構築を実現するためのオープンソース

どんなに柔軟性が高いソフトウェアでも、 カスタマイズで可能な範囲というのはタカが知れています。 ソースを改変することによって得られる自由とは雲泥の差でしょう。

KLab としては、 他社では行なっていないような方法で、 耐故障性を向上させたり、 性能を向上させたり、 より低コストな運用を実現したり することによって、 差別化をはかっていきたいわけで、 そうなるとベンダの製品を使うよりは、 オープンソースを使うべき、という選択になります。

実際にどのようにオープンソースを活用しているかは、 DSAS開発者の部屋などで 紹介していきたいと思っておりますし、 オープンソースを活用していく過程で我々のレベルが上がって、 オープンソース界に貢献できるようになれれば、 それは我々にとって望外の幸であり、 それを目指して研鑽を積んでいく所存です。

Filed under: システム構築・運用,技術と経営 — hiroaki_sengoku @ 06:19
2006年4月16日

getnameinfo のバグ? (2)

昨日、getnameinfo の問題について述べたが、 念のため、glibc のソースを確認してみた。 手元に展開してあった glibc-2.3.5 を見ると、 glibc-2.3.5/inet/getnameinfo.c の 440行目で、

      case AF_LOCAL:
        strncpy (serv, ((const struct sockaddr_un *) sa)->sun_path, servlen);
        break;

とある。sun_path が 0 終端されていないと、 sun_path が実際に何バイト確保されているかとは関係なく、 servlen バイトがコピーされてしまう。

getnameinfo の salen 引数のチェックは、 同じく getnameinfo.c 182行目の、

    case AF_LOCAL:
      if (addrlen < (socklen_t) (((struct sockaddr_un *) NULL)->sun_path))
        return EAI_FAMILY;
      break;

だけであった。 つまり sun_path の部分が 0 バイトでもエラーにならない。

今回の問題とは関係ないが、

(socklen_t) (((struct sockaddr_un *) NULL)->sun_path))

という書き方は参考になる。 stone.c では

(((struct sockaddr_un*)sa)->sun_path - (char*)sa)

と書いていたのだが、 NULL を使えば簡潔に書ける、 というのは目から鱗だった。

Filed under: stone 開発日記 — hiroaki_sengoku @ 08:17
2006年4月16日

交通広告: 個人情報スキャナ P-Pointer

KLabセキュリティの主力製品である、 個人情報スキャナ 「P-Pointer」 の広告を、4/14 から一ヶ月間、地下鉄に出すことにしてみました。 インターネット広告が伸びつつある今、 時代に逆行しているようですが、 交通広告という従来型の広告がどれだけ効果があるか楽しみです。

東京メトロ 地下鉄 半蔵門線 に掲載した、 P-Pointer の 窓上広告:
P-Pointer 交通広告

一般的には、窓の上の広告なんて (見上げないと見えないから) 誰も見ないだろうということで、 吊り広告などに比べると安価な窓上広告なのですが、

      我々がリーチしたい人達はラッシュの時間帯に乗る通勤客
        ↓
      ラッシュ時間帯の田園都市線は死ぬほど混む
        ↓
      とても新聞とかを読めるような状態ではない
        ↓
      地下鉄だから景色を見るわけにもいかない
        ↓
      仕方ないんで窓の上の広告でも見るか

となるので、 混雑する通勤路線であればあるほど窓上広告は効果的だと想像した次第です。 私自身、毎朝毎晩、ラッシュの田園都市線 (渋谷から西へ伸びる東急路線です。地下鉄半蔵門線と相互乗り入れしています) で通勤していて、 窓上広告を見る機会が多かったりしますし、 沿線にはいわゆる「IT業界」の会社が多く、 「個人情報」にセンシティブな人が多いだろう、 ということで半蔵門線を選びました。

Filed under: 技術と経営 — hiroaki_sengoku @ 06:40
2006年4月15日

getnameinfo のバグ? (1)

UNIX で TCP接続を accept したとき、そのソケット sd に対して

struct sockaddr_storage ss;
struct sockaddr *from = (struct sockaddr*)&ss;
socklen_t fromlen = sizeof(ss);
getpeername(sd, from, &fromlen);

などとすれば、接続元のアドレスが from に返る。 UNIXドメインソケットを listen し accept した場合は、

from->sa_family ← AF_UNIX
fromlen ← 2

という値が返るようだ。

ところが、
この返り値を getnameinfo に与えると、 fromlen で指定したサイズを超えて UNIX ドメインソケットのファイル名を読もうとする 問題があるようだ。

たとえば次のようなテストプログラムを書いてみる:

#include <stdio.h>
#include <sys/socket.h>
#include <netdb.h>
#include <sys/un.h>
#define STRMAX  256
main() {
    struct sockaddr *sa;
    socklen_t salen;
    struct sockaddr_un sun;
    char name[STRMAX+1];
    char serv[STRMAX+1];
    int err;
    bzero(name, STRMAX+1);
    bzero(serv, STRMAX+1);
    sa = (struct sockaddr*)&sun;
    salen = sizeof(sun);
    sun.sun_family = AF_UNIX;
    strcpy(sun.sun_path, "/tmp/sock");
    salen = sizeof(sa_family_t);
    err = getnameinfo(sa, salen, name, STRMAX, serv, STRMAX, 0);
    printf("salen: %d, err: %d, name: '%s', serv: '%s'\n",
           salen, err, name, serv);
}

salen は 2 であるので、 sun.sun_path の部分の値は無視すべきであるのに、 serv には、"/tmp/sock" の値が返ってしまう。 sun.sun_path の部分が初期化されていなければ、 不定値が返るだろう。

実際、stone では struct sockaddr_storage を初期化せずに getpeername を呼び出して長さ 2 の struct sockaddr_un を受け取り、 これを getnameinfo の引数として与えると、 dserv に不定値が返ってきてしまった。

本来ならば、getnameinfo は長さ 0 のパス名を返すか、 あるいは UNIX ドメインソケットは扱わない、 ないしは長さが異常ということで EAI_FAMILY を返すか、 どちらかであるべきではなかろうか。 少なくとも glibc-2.3.5 と、glibc-2.2.5 では、 この問題があることを確認した。

とりあえず、stone は AF_UNIX のときは getnameinfo を呼ばずに sun_path を dserv へコピーするように修正した。

$Id: stone.c,v 2.2.2.19 2006/04/14 23:35:18 hiroaki_sengoku Exp $

Filed under: stone 開発日記 — hiroaki_sengoku @ 09:58
2006年4月15日

VPN-Warp 入門編 (2)

前回は、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 してから、 リレーサーバ専用のユーザ権限で実行するようにしています。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:01
« Newer PostsOlder Posts »