フリーの定番ソフトを利用した
4段階 Linux サーバー防御法


第2の砦

サーバー・プログラムによる認証で守れ

再生攻撃

再生攻撃が出来る認証は論外である。 再生攻撃とは,正規のユーザーがサーバーへ送信したデータを記録しておいて, ちょうどテープ・レコーダを再生するがごとく 同じデータをサーバーへ送り付けることにより正規ユーザーになりすます攻撃である。

例えばtelnet プロトコルの場合, ユーザーがlogin 時に送るデータはユーザーIDとパスワードの組であり, 毎回同じであるから, 正規ユーザーがlogin するときに打ち込んだ文字列を そのまま「再生」すればlogin できてしまう。

読者の中にはどこで盗聴されるんだ, 盗聴なんて普通は有り得ないんじゃないか, という人もいるかも知れない。 たしかに現在のインターネットは1次プロバイダの回線を バックボーンとして構成されているから, 1次プロバイダ内で盗聴されるのでない限り盗聴される危険は現実にはかなり低い。

だから十分信頼できる技術力に定評のあるプロバイダだけを常に利用するのであれば, 盗聴を心配する必要はあまりない。 しかし考えてみてほしい。 常に信頼のできる端末だけを使っていると断言できるだろうか。 例えば私は出張先で端末を借りて インターネット経由で自分のサーバー・マシンへアクセスすることがある。 出張先のLAN でパケットを監視している人がいないとは断言できない。 特に大学のLANなどでは, 学生が軽いイタズラ心でtelnetプロトコルを記録し パスワード等を抽出していることも有り得る。 内部に悪い人がいなくても, LAN 内のいずれかのマシンが侵入されていて 盗聴のためのソフトウエアを仕掛けられている場合もある。

同じパスワードを複数のマシンで使っていると, 危険はさらに高まる。 例えばファイアウオールで守られたLAN に接続したマシンでは セキュリティの心配がないのでパスワードを平文のまま流すことが多いが, 同僚の中に悪い奴がいてパスワードを盗聴していたら, 同じパスワードを使っているすべてのマシンへ侵入されてしまう。

つまり再生攻撃が可能な認証を利用する限り, 認証データが安全なネットワークのみを流れているか 常に細心の注意を払わなければならず, そんな注意を払うくらいだったら, 再生攻撃が不可能な認証を使う方がよっぽど楽である。

再生攻撃が不可能な認証には, OTP, APOP などハッシュ関数を利用した認証や, SSL, ssh など暗号を利用した認証がある。 いずれもクライアント・マシンからサーバ・マシンへ認証のために送られるデータは 毎回異なるから, 攻撃者が盗聴して同じデータをサーバーマシンへ送ったとしても 侵入されることはない。

OTP(One Time Password,使い捨てパスワード)

telnet やftp を使う場合なら, OTP(One Time Password)を使えば良い。 これはOPIE(One-time Passwords In Everything)パッケージに含まれる。 OPIE をインストールしたマシンへtelnetでlogin したときの例を図3に示す。

 図3 OTP の例と OTP 計算機「dotkey95」

「otp-md5 470 as5266 ext」はチャレンジと呼ばれ, login ごとに異なる。チャレンジと, 秘密のパスフレーズ(パスワードに相当)をOTP 計算機に入力すると, 1回限りのパスワード(レスポンス)「WOK MOP GAY HAM CUP VAN」が出力される。 これをResponse:プロンプトが出たところで入力するとlogin できる。

パスフレーズは毎回同じものを入力するが, OTP の計算が端末の中で閉じていてパスフレーズが 外部に漏れる心配がないようにしておくのがミソである。 間違ってもリモートのマシン上で走るOTP 計算機を使ったり, X端末など盗聴される危険がある端末上でパスフレーズを入力したりしてはいけない。

一番確実なのはネットワークに物理的につながっているマシンには パスフレーズを打ち込まないことである。 すなわち, ネットワークに接続されていないマシン上でOTP 計算機を走らせ, 端末に表示されたチャレンジをOTP 計算機へ「手で」打ち込み, 計算されたレスポンスを「手で」端末へ入力する。 しかしこれはかなり面倒であるので, 次善の策として端末上でOTP 計算機を走らせ, チャレンジ&レスポンスの入力を自動化することになる。

この目的にかなうOTP 計算機はいろいろなものが公開されているが, 私はWindows 98/95/NT上で動作するdotkey95 (http://ftp.vector.co.jp/soft/win95/util/se049268.html参照) を愛用している(図3)。

dotkey95 をタスクトレイへ入れた状態で 端末エミュレータ上に表示されたチャレンジの部分をクリップボードへ入れると, 自動的にパスフレーズを入力するためのウィンドウがポップアップし(図3左), パスフレーズを入力するとレスポンスを計算して自動的に送信してくれる(図3右)。 つまり普通のtelnet でlogin するのとほとんど同程度の手間で OTP を使うことができる。

 図4 WorkPad 上の OTP 計算機「pilOTP」 文字が化けるのはご愛敬。日本語に対応していないだけで動作に支障はない。

他人の端末を借りてtelnet する場合は, いちいちdotkey95 等のソフトウエアをインストールするわけにはいかない。 こういうとき便利なのがPDA 上で動くOTP 計算機である。 私は常にIBM社製WorkPad 30J を持ち歩いているので, これにOTP 計算機ソフトpilOTP (http://astro.uchicago.edu/home/web/valdes/pilot/pilOTP/参照) をインストールしている(図4)。 ネットワークにつながっていないPDA であるから 安心してパスフレーズを打ち込むことができる。

さて, OTP を使えば再生攻撃には対抗できるが, telnet セッションの内容はすべて平文でインターネット上を流れるので 盗聴される危険がある。 だから侵入者の役に立つようなデータを流すことはご法度である。 特にユーザー・アカウントの新規作成など管理作業はしてはいけない。

ssh(Secured Shell)による暗号化

telnet の代わりにssh を使ってセッション全体を暗号化すれば, 盗聴を防ぐことができるし, 使い勝手の点でtelnet の方が勝るということはないのだから, 常日頃から(LAN 内の通信でも!)ssh を使うようにすべきである。 telnet +OTP はssh が何らかの原因で使えないときの 非常用のlogin 手段と思ったほうが良い。 例えば他人の端末を借りるときは, たとえその端末にssh がインストールしてあったとしても 自分の秘密かぎをインストールするのは面倒だし危険が伴うので, telnet+OTP の方が適しているといえる。

ssh で使われている暗号化方法は, 通常の目的には十分過ぎる強度を持ち, 通信路上での盗聴を心配する必要はないが, 注意すべきは接続元のマシンのセキュリティである。 ssh は通信に先立ち, 双方のマシンが持っている秘密かぎを使ってお互いの認証を行なう。 秘密かぎ自体は通信路上を流れないので, 通信経路上の第3者が秘密かぎを盗むことは不可能であるが, もし攻撃者がどちらかのマシンへの侵入に成功したらどうなるだろう。 そのマシンが持つ秘密かぎを盗んで, そのマシンになりすまし, 相手マシンへ侵入することまで可能になってしまう。 つまりssh でお互いを信頼し合うマシン群は一蓮托生(いちれんたくしょう) ということである。

もちろん, ssh には秘密かぎをパスワードで保護して, たとえマシンが侵入されても秘密かぎが盗まれないようにする仕掛けがあるが, ユーザーによるパスワードの管理がずさんであれば役に立たない。 ssh を使ったlogin が許可されているユーザーに対し, 秘密かぎの管理を慎重に行なうよう徹底すべきである。 特に, インターネットに常につながっているマシンに秘密かぎを保存する場合は, そのマシンのセキュリティが十分なレベルにあるか確認すべきであり, もし侵入される恐れがあるならば, そのマシンからのlogin を禁止すべきである。

手軽な暗号化の方法「stone」

Webの暗号化方式として有名なSSL(Secure Socket Layer)であるが, 拙作「stone」 (http://www.gcd.org/sengoku/stone/Welcome.ja.html参照) を使うと, 任意のプロトコルをSSL で暗号化することができる(図5)。

 図5 stone で暗号化する

再生攻撃可能なプロトコルも, SSL で暗号化すれば, 流れるデータは毎回異なったものになり, セキュリティ・レベルを向上することができる。

(第3の砦)


本稿は日経Linux 創刊 2 号 (1999 年 11 月号) に掲載された、 特集 2: Linux サーバのセキュリティを高める, PART 2「フリーの定番ソフトを利用した 4 段階 Linux サーバ防御法 ---4 つの砦でクラッカーを撃退せよ---」を日経BP 社の許可を得て転載したものです。

Copyright(C)1999 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます

| home | up |

sengoku@gcd.org