Firewall Piercing mini-HOWTO Francois-Rene Rideau, fare@tunes.org v0.3b, 27 November 1998 高橋 聡 hisai@din.or.jp 4 Sep 1999 インターネット接続しているファイアーウォールを意識せずに、各種のネット ワーク・サービスを利用する方法を案内します。telnet プロトコル に PPP プロトコルを乗せて実現します。 ______________________________________________________________________ 目次 1. 付記 1.1 おことわり 1.2 法的なこと 1.3 謝辞 2. 序論 2.1 はじめに 2.2 セキュリティ上の問題 2.3 他に必要なもの 2.4 ソフトウエアのダウンロード 3. 問題点を理解する 3.1 問題点を明確にする 3.2 問題点 3.3 さらに面倒なこと 4. 解決するには 4.1 原理 4.2 fwprc 4.3 .fwprcrc 5. 反対側から穴をあける 5.1 基本的な考え方 5.2 電子メールのやりとりのしかた 6. 最後の注意点 6.1 その他の設定 6.2 このドキュメントの改訂について 6.3 とても大切なおことわりの繰り返し --- 本当です!!! ______________________________________________________________________ 1. 付記 1.1. おことわり 大切なことなので、必ず読んでください!!! このドキュメントの内容について、一切責任は負いません。どんな障害が生じ ても、それは私の過失ではありません。このドキュメントに書かれている手段 をとることによって生じるリスクを理解できないならば、決して利用しないで ください。利用する場合は、あなたの職場のコンピュータが壊れても、業務に 支障がでても、また会社に多額の損害を与えてもかまわない、と腹をくくって ください。私に泣きついたりしないでくださいね。 1.2. 法的なこと Copyright (C) 1998 by Francois-Rene Rideau. このドキュメントは、フリーソフトウエアです。Free Softweare Foundation が出している GNU General Public License の 第二版もしくはそれ以降の版 に従う限り、この文書を配布または変更できます。 1.3. 謝辞 「おことわり」以外の部分を大幅に修正しましたが、Term-Firewall mini- HOWTO の著者である Barak Pearlmutter 氏 には たいへんお世話になりました。彼の mini-HOWTO はいくつかの欠点があるとは いえ、ファイアーウォールに穴を開けることについて、必要不可欠な情報を与 えてくれました。また、この mini-HOWTO の手本になっただけでなく、書き上 げるにあたっての励みにもなりました。 2. 序論 2.1. はじめに システム管理者とユーザでは、システムを利用するに当たって、制限を受ける 事項やシステムに対する理解度に差があります。そこでユーザ自身がファイア ーウォールの存在に気づいた時に、何とかそれを越えようとしたくても、四苦 八苦することになってしまいます。このドキュメントでは、ファイアーウォー ルを気にせずに、インターネットで良く使われるサービスを利用する方法を説 明します。それも特別な手段ではなく、手軽に行えます。telnet セッション 越しに IP エミュレータを動かして実現します。 このドキュメントのアイディアは、Barak Pearlmutter 氏 が書いた Term-Firewall mini-HOWTO からもらいま した。このドキュメントは Term という、あのなつかしい、今ではサポートさ れていないプログラムを使って書かれています(それでも当時は素晴らしいプ ログラムでした)。Term は、古くさく、移植性のない実装になっています。標 準とはいえない telnet の実装で見られるような独自さと同様に。 2.2. セキュリティ上の問題 システム管理者がファイアーウォールを立てているのは、もちろん理由があっ てのことです。したがって、このソフトウエアを使用するに当たっては、管理 者から許可を得た方がよいと思います。一方、あなたが外部に telnet できる という事実 (これはハックキングを行うための必要条件です)は、特定の外部 のシステムにアクセスする権利を持っていることを意味します。つまり特定の システムに何らかのかたちでログインするには、あなたがそのシステムのユー ザとして認められている必要があります。 セキュリティのことを考えると、ファイアーウォールのすでに開かれている穴 を利用することは、とても お手軽な 方法です。この方式なら、あるプログラ ムが本来利用しているプロトコルをそのまま使えるからです。逆にこの方法が とれない場合は、特定の用途のためにプロクシ機能をもつ特別のプログラムが 必要になるか、既存のプログラムの改造(とコンパイル)を行う必要がでてきま す。こんなことをすると、不愛想で無能な管理者が設定ミスをおかすことにな るかもしれません。また、ファイアーウォールによってサポートされているサ ービス(Web 等)で、普段使っている通常のサービス(電子メール 等)を利用す るためには、あるプロトコルを許可されたプロトコルに変換するプログラムを 必要なプロトコルの分だけ、インストールするはめになるかもしれません。 その上 SLiRP のようなユーザ・レベルの IP エミュレータを使うことによっ て、外部からのファイアーウォールの穴を利用した攻撃を防ぐことができるは ずです。あなたがあえて不正行為を許可しなければ、他の手段を駆使しても、 ファイアーウォールの穴を攻撃できないはずです(ただ、攻撃者はずるがしこ く、ルートの権限を持つ人やそれに類する人は、リモート・ホストからあなた の行為を監視することもできますが)。 総合的に判断して、この方法は 比較的 安全なはずです。しかしこれは、あな たが設定した特定の環境に全面的に依存した方法なので、私は何の保証もでき ません。インターネット経由の接続は、この手段を使おうが使うまいが、本質 的に安全なものではありません。ですからこの手段に加えて、何らかの暗号化 をほどこすといった対策をあなたが講じていないのなら、安全は保証されてい る、などという思い込みを間違ってもしないでください。 今までのことをまとめると、あなたが何をしているかを理解していないなら、 この手段を活用しないでください、ということです。再度「おことわり」を読 んでください。 2.3. 他に必要なもの このドキュメントは、あなたが次のことを理解していると仮定して書かれてい ます。 o ネットワークの設定方法を知っていること。 o ファイアーウォールの両側にシェル・アカウントを持っていること。 o 相手側にも telnet(もしくは ssh(Secure Shell)やそれと同等の機能をも つもの)が利用できるアカウントを持っていること。 o 両側にある自分のシェル・アカウントで IP エミュレータを実行できるこ と。 o エミュレートされた IP 接続上で動くプログラムを両側に持っているこ と。 どんなプログラムでも、この接続方法を利用できます。ローカルのエミュ レータは、 Linux カーネル とやりとりしている pppd か、再コンパイル が必要で、かつ特別なライブラリをリンクする必要がある Term のような プログラムが使われます。 IP エミュレータについては pppd にしても SLiRPにしても、まともな Linux ディストリビューションであれば付属しているはずですし、ftp サイトでも見 つけられます。もしリモートのシェル・アカウントが一般ユーザのものだけな らば、SLiRP で実現してください。 2.4. ソフトウエアのダウンロード 下記にあげたソフトウエアのほとんどは、標準的なディストリビューションに 付属しているか、場合によっては、そのコントリビューションに含まれている はずです。少なくとも最後の 2 つを除いて、rpm パッケージで利用できま す。もし最新のバイナリやソースを落してきたいならば、下記のアドレスを利 用してください(結局最後のソフトウエアの内の 1 つは、 Linux では動かな いかもしれませんが)。 o SLiRP は、 か、 に、 o zsh は、 に、 o ppp は、 に、 o fwprc と cotty は、 にあ ります。 3. 問題点を理解する 問題点を理解すれば、もう最初の半分を解決したことになります。 3.1. 問題点を明確にする もしこの手段を使いたいなら、まずこれがどのように機能するかを考えてみる 必要があります。そうすれば、何かおかしくなった場合に、どこに見当をつけ たらよいかがわかります。 問題点を理解するはじめのステップは、関連した考え方に名前をつけて区別す ることです。 それではまず、「ローカル」という言葉は、相手に接続を仕掛けるマシンを意 味し、プログラムやファイルもそのマシン上にあることとします。反対に、 「リモート」という言葉は、接続の相手側を意味します。 3.2. 問題点 最終目標は、ローカルの IP エミュレータ入出力を、それに対応するリモート の IP エミュレータに渡すことです。 IP エミュレータ間のやりとりを行う経路は、直接接続されているデバイ ス(pppd の場合)か「現在使用している tty」のどちらかになります。 telnet セッションは前者ではなく、後者に当てはまるのですが、扱いづらい面があり ます。というのも、コマンド・ラインからローカルのエミュレータを実行する と、「現在使用している tty」は、リモート・セッションではなく、コマン ド・ラインを使っているユーザに接続されてしまうからです。もちろん新たに セッション(ローカルもしくはリモートで)を新規の端末から立ち上げる必要が ありますが、両側の IP エミュレータの起動と起動後の接続を同期させなけれ ばなりません。あるセッションの不要な出力を、もう一つのセッションのコマ ンドとして実行してしまうことだけは、避けなければいけません。そうしない と、繰り返し不要なコマンドが実行されてしまいます。 3.3. さらに面倒なこと 最も簡単な方法は、ローカルの IP エミュレータがカーネルのネットワーク機 能である pppd に IPパケットのデータを渡す方法です。しかし pppd は結構 まぬけで、 /dev もしくは、現在使用している tty からしかデータを受け取 れません。受け取るのは tty からで、パイプ経由ではだめなのです(これはい わゆる仕様というやつでしょう)。つまり、リモートの pppd で telnet セッ ションの tty を使用する分にはよいとしても、ローカルの pppd では、接続 すべき telnet セッションを pppd が横取りしてしまうので、具合が悪いこと になります。そのようなわけで、ある種のラッパーが必要になってきます。 telnet は たいていの場合、パイプをうまく利用できます。ただ、やはり現在 使用している tty デバイスの制御を行うため、動作に支障が生じてしまいま す。また telnet を tty を利用せずに使用すると、データのやりとりが競合 状態になってしまいますので、「遅い」コンピュータを使っていると、接続が できなくなるかもしれません(fwprc 0.1 は、Pentium/MMX 233 では問題なく 動作しましたが、 6x86-P200+ では 6 回中 1 度だけ動き、486DX2/66 では全 く動作しませんでした) [注: すっきりとしたパイプの対を使わないで、「同じ」仮想ファイルを使っ てファイルを読み書きするという "tty" デバイスの原理を発明した馬鹿野郎 (たぶんそいつは MULTICS 使いだと思うけど、それを真似したバカな UNIX な 人もいるはず)を見つけたらシメてやる! !] 4. 解決するには 4.1. 原理 fwprcがファイアーウォールに穴を開けるプログラムです。「tty プロクシ」 として機能するcottyを利用しています。これは仮想的に 2 つの tty デバイ スを開きます。それぞれのデバイス上でコマンドを実行すると、その出力がそ のままコピーされて、相手へのコマンドの入力として tty に渡されます。コ マンドは、リモート側へ telnet 接続を通じて渡され、相手側は、ローカルの pppd が受け取ります。そこで pppd は 通常のチャット・スクリプトを扱う場 合と同じように、telnet セッションを開いて、制御を行えるようになりま す。 4.2. fwprc 私が、ファイアーウォルに穴をあけるスクリプト fwprc を書きました。スク リプトのセルフ・ドキュメント化もきちんとしてあります。cotty (fwprc 0.2 以上のバージョンで必要になります)とあわせて、私のサイトである から落すことができます。この ドキュメントを書いている時点での最新バージョンは、 fwprc 0.3a と cotty 0.3a です。 「fwprc」という名前はあえて読みづらく、かつ発音しにくくしました。そう すればファイアーウォールの件で日頃イライラさせられている、無能で偏執的 な管理者を混乱させることができるからです(もちろん理にかなったファイア ーウォールも存在しますし、それらは無くてはならないものです。セキュリ ティは、正当な 環境設定の一部ですから)。声を出して「fwprc」を読まなけ ればならない時には、思い付く中で一番不快に感じる読み方を選んでくださ い。 コンテスト! 私に「fwprc」の読み方を .au 形式で録音されたオーディオ・ ファイルにして送ってください。最も不快なものには、フリーでアップグレー ドできる権利を差し上げ、fwprc 1.0 のページにお名前を掲載します! いくつかの設定でこのプログラムをテストしました。いずれもリソース・ファ イルをいじって設定しました。しかしやはりマーフィーの法則には逆らえず、 あなたは困った状況に陥るかもしれません。そんな時には、ご自由に改良をし ていただいて結構です。そうすれば、これから設定することになる他のみなさ んは、より簡単に利用できるようになるでしょうから。 4.3. .fwprcrc fwprc は、.fwprcrc ファイルを使ってカスタマイズしますので、ファイアー ウォールの両側で同じような設定ファイルを作る必要があります。異なるいく つかの設定を使い分けることももちろん可能ですが(私は そうしています)、 それは読者の方への宿題としておきましょう。 まず fwprc の該当する部分をコピーして、.fwprcrc という名前のファイルを ホーム・ディレクトリに作ってください。次に、あなたの環境にあった設定に なるように、変数の値を変更します。最後にその設定ファイルを相手側のホス トにコピーして、テストしてください。 デフォルトの設定では、pppd をローカルで使用して、リモートでは slirp を 使うようになっていますので、下記のように適切に再設定してください。 remote_IP_emu () { remote_pppd } SLiRP は pppd より安全性が高く、相手側にアクセスする方法も簡単です。な ぜなら、リモート側のマシンで root の権限を必要としないからです。安全な 理由はまだあります。接続されているマシンから直接くるパケット以外は、 まったく受けつけないためです(マスカーレーディングでサブネットのルー ティングをするとこのメリットはなくなります)。 SLiRP の基本機能はうまく 動きますが、まだまだこれからの機能(例えばランタイムな制御)もあります。 もちろんフリーソフトですから、ソースをハックして、必要な機能をどんどん インプリメントしてください。 5. 反対側から穴をあける 5.1. 基本的な考え方 telnet がファイアーウォールの片側からしかできない場合があります。しか しそういう状況でも、いくつかの通信手段を利用することが可能です(電子メ ール等)。その通信手段が用いているメッセージの交換方法がどのように行わ れていても、 telnet が「許されている」側から、ファイアーウォールの反対 側のマシンに接続できれば、ファイアーウォールを通過してメッセージを伝え ることが可能です。 fwprc は PGP(Pretty Good Privacy)を使って認証された電子メールのような メッセージがくると、自動的に相手に対して接続を行う機能をもっています。 fwprc にメッセージを伝えるプロトコルのフィルタとして procmail(1) を登 録するだけで OK です(具体的な設定方法は fwprc に付属しています)。ただ し注意してもらいたいのは、pppd を適切なユーザ権限で実行するためには、 root に setuid するラッパーをつくらなければならないことです。具体的な 方法は fwprc に付属する解説書を読んでください。 また、通信内容が認証されていても、決して接続自体がセキュアなわけではあ りません。本当にセキュアな接続をしたいなら ssh(できたら telnet を経由 して)を使用すべきです。このようなわけで telnet 経由の通信で行われてい ることに対して、注意を払う必要があります。また本当にセキュアな通信をし たいなら、ssh を使用してください。これに関連した情報およびご意見をどし どしお寄せください。 5.2. 電子メールのやりとりのしかた あなたが、ファイアーウォールに守られている環境にいるならば、procmail も telnet も許可していないメール・サーバを利用している可能性がありま す。でもご心配なく! fetchmail(1) をデーモンとして動かして、クライア ントの Linux マシンとやりとりさせれば大丈夫です。さらに cron で 自動的 に 1 〜 5 分間隔でポーリングさせます。fetchmail は、ローカル・アドレス 宛のメールを sendmail(8) を利用してフォワードすることができます。配送 に procmail(1) を使うように設定することもできます。もしバックグラウン ドのデーモンとして fetchmail を動かすと、 fwprc から fetchmail を動か そうとした時に、すでにデーモンとして動いている fetchmail がじゃまをし て起動できません。もちろん ダミーのユーザの権限でデーモンの fetchmail を動かすというのも 1 つの手です。あまりに頻繁にポーリングすることは、 サーバにとっても、自分のクライアント・マシンにとっても、好ましくありま せん。反対にポーリングをあまりしないようにすると、メッセージが読めるま でに時間がかかり、投稿とのタイミングがずれてしまいます。私は 2 分間隔 でポーリングしています。 6. 最後の注意点 6.1. その他の設定 telnet を許している他にも、いろいろなポリシーを持つファイアーウォール が存在しています。パケットがファイアーウォールを経由して常にやりとりさ れて情報が行き来しているならば、それを利用してファイアーウォールに穴を 開けることは可能です。要するに、穴を開けるプログラムを書きあげるのが、 手間がかかるか、かからないか、という違いがあるだけです。 簡単に解決できる場合もあります。pty 越しに ssh を動かしてそのスレーブ の tty で pppd を動かす方法です。 cotty 0.3a を使って実現できるはずで すが、fwprc を改造して、この機能を組み込んでいる人はまだいません。今晩 の練習問題としていかがですか? 面倒くさいファイアーウォールをわきに置 いといて、何とかしたいと思われる方には、セキュアな「VPN(Virtual Private Network)」を構築することをお勧めします。詳しくは、VPN mini- HOWTO を見てください。 もし 7 ビットしか通さない回線をまたぐ必要がある場合は、PPP ではなく SLIP を使う必要があると思います。私は試していませんし、今後も試せない と思います。というのも、最近はおよそ 8 ビット クリーンな回線がほとんど ですから。 さて、もしファイアーウォールを通過できる手段が WWW プロクシだけなら(普 通にインターネット接続しているネットワークの最低条件でしょう)、入出力 用のバッファを持つデーモンを書いて、HTTP 接続を利用してバッファのデー タを送り出したいと思うのではないでしょうか。これは fwprc を動かし て、HTTP 越しに telnet を行うことで実現できます。速度が遅く、きびきび と反応しないでしょうが、fetchmail(1) や suck(1) といったバッチ処理系の プログラムで利用する分には、十分です。 これ以上にパフォーマンスを上げたかったり、もっと厄介なプロトコル(DNS クエリー・パケットや ICMP パケット等)を素通ししたい場合は、かなり面倒 になります。たとえば、Fox プロジェクトで行われているように IP スタック をハックして、パケットやプロトコルの種類に依存しない、統一的にネットワ ークを扱える機能を自分で実装する必要がでてきます。それを行った上ではじ めて、HTTP や DNS、ICMP 越しに IP で接続できます。プロトコルが複雑なだ けでなく、カーネルとのインターフェースを作り込む必要があるので、インプ リメントはかなりたいへんな作業になります。 訳註:「Fox プロジェクト」については、 The Fox Project: Advanced Languages for Systems Software を参照してください。 また このプロジェクトによる ネットワーク・プロトコル・スタックの実装に ついての資料は、 Fox Project Publications にある、「Signatures for a Network Protocol Stack: A Systems Application of Standard ML, Edoardo Biagioni, Rober Harper, Peter Lee, and Brian G. Milnes」を見てください。 ところで、HTTP プロトコルを利用してファイアーウォールに穴を開けるな ら、ダミーのページを用意することを忘れないでください。そうしないと、あ れこれ気にする管理者を混乱させてしまいます。 6.2. このドキュメントの改訂について 必要性を感じて、このドキュメントを書きあげましたが、現状ではこれ以上時 間をさくことができません。そのため、このドキュメントはまだまだ大ざっぱ な内容になっています。改訂を進めるには、このセクションをもっと詳しく、 といったみなさんのアドバイスが必要です。フィードバック、助言、はたまた このドキュメントを私のかわりに更新してくれる方、いずれも歓迎します。 ともかく、まだ多くの問題点が残されています。誰かが見つけた解決方法が、 みなさん(あなたも含めて)のために役立ちます。少々の時間(もしくは人を雇 うお金) を割いていただいて、あなたが書いてみませんか。細かいところを見 ると厄介でトリッキーなのですが、コンセプトは明解ですから。 どうかためらわずに、いろいろな問題を解決するお手伝いをしてください。そ うすれば、このドキュメントがさらによくなると思います。 6.3. とても大切なおことわり の繰り返し --- 本当です!!! このドキュメントの内容について、一切責任は負いません。どんな 障害が生じても、それは私の過失ではありません。このドキュメン トに書かれている手段をとることによって生じるリスクを理解でき ないならば、決して利用しないでください。利用する場合は、あな たの職場のコンピュータが壊れても、業務に支障がでても、また会 社に多額の損害を与えてもかまわない、と腹をくくってください。 私に泣きついたりしないでくださいね。