Firewall Piercing mini-HOWTO <author>Francois-Rene Rideau, <tt>fare@tunes.org</tt> <date>v0.3b, 27 November 1998 <trans>高橋 聡 <tt>hisai@din.or.jp</tt> <tdate> 4 Sep 1999 <abstract> <!-- Directions for using ppp over telnet to do network stuff transparently through an Internet firewall. --> インターネット接続しているファイアーウォールを意識せずに、各種のネットワーク・ サービスを利用する方法を案内します。telnet プロトコル に PPP プロトコルを 乗せて実現します。 </abstract> <toc> <!-- <sect>Stuff --> <sect>付記 <p> <!-- <sect1>DISCLAIMER --> <sect1>おことわり <p> <!-- <bf>READ THIS IMPORTANT SECTION !!!</bf> --> <bf>大切なことなので、必ず読んでください！！！</bf> </p> <p> <bf> <!-- I hereby disclaim all responsibility for this hack. If it backfires on you in any way whatsoever, that's the breaks. Not my fault. If you don't understand the risks inherent in doing this, don't do it. If you use this hack and it allows vicious vandals to break into your company's computers and costs you your job and your company millions of dollars, well that's just tough nuggies. Don't come crying to me. --> このドキュメントの内容について、一切責任は負いません。どんな障害が生じても、 それは私の過失ではありません。このドキュメントに書かれている手段をとることに よって生じるリスクを理解できないならば、決して利用しないでください。利用する 場合は、あなたの職場のコンピュータが壊れても、業務に支障がでても、また会社に 多額の損害を与えてもかまわない、と腹をくくってください。私に泣きついたりしない でくださいね。 </bf> </p> <!-- <sect1>Legal Blurp --> <sect1>法的なこと <p> Copyright © 1998 by Francois-Rene Rideau. <!-- This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. --> このドキュメントは、フリーソフトウエアです。Free Softweare Foundation が出している GNU General Public License の 第二版もしくはそれ以降の版に 従う限り、この文書を配布または変更できます。 <!-- <sect1>Credits --> <sect1>謝辞 <p> <!-- Even though I rewrote most everything but the disclaimers, I'm indebted to Barak Pearlmutter <URL URL="mailto:bap@cs.unm.edu"> for his Term-Firewall mini-HOWTO: I think there was a necessity for a mini-HOWTO about piercing firewalls, and despite its shortcomings, his mini-HOWTO was a model and an encouragement. --> 「おことわり」以外の部分を大幅に修正しましたが、Term-Firewall mini-HOWTO の 著者である Barak Pearlmutter 氏 <URL URL="mailto:bap@cs.unm.edu"> にはたいへん お世話になりました。 彼の mini-HOWTO はいくつかの欠点があるとはいえ、ファイアーウォールに穴を 開けることについて、必要不可欠な情報を与えてくれました。また、この mini-HOWTO の手本になっただけでなく、書き上げるにあたっての励みにもなりました。 <!-- <sect>Introduction --> <sect>序論 <p> <!-- <sect1>Foreword --> <sect1>はじめに <p> <!-- Because system administrators and users have different constraints and proficiencies, it so happens that a user may find himself behind a firewall, that he may cross, but only in awkward ways. This mini-HOWTO explains a generic and portable way to use standard internet tools seamlessly across such firewalls, by the use of an IP emulator over a telnet session. --> システム管理者とユーザでは、システムを利用するに当たって、制限を受ける事項や システムに対する理解度に差があります。そこでユーザ自身がファイアーウォール の存在に気づいた時に、何とかそれを越えようとしたくても、四苦八苦することに なってしまいます。 このドキュメントでは、ファイアーウォールを気にせずに、インターネットで良く 使われるサービスを利用する方法を説明します。それも特別な手段ではなく、手軽 に行えます。telnet セッション越しに IP エミュレータを動かして実現します。 <!-- It is freely inspired by the Term-Firewall mini-HOWTO by Barak Pearlmutter <URL URL="mailto:bap@cs.unm.edu">, which relies on an ancient and no-more-supported program named Term (yet a great program at its time), as well as on peculiarities of a not-so-standard telnet implementaion, that is, many obsolete and non-portable facts. --> このドキュメントのアイディアは、Barak Pearlmutter 氏 <URL URL="mailto:bap@cs.unm.edu"> が書いた Term-Firewall mini-HOWTO から もらいました。このドキュメントは Term という、あのなつかしい、今ではサポート されていないプログラムを使って書かれています(それでも当時は素晴らしいプログ ラムでした)。Term は、古くさく、移植性のない実装になっています。標準とはいえ ない telnet の実装で見られるような独自さと同様に。 <!-- <sect1>Security problems --> <sect1>セキュリティ上の問題 <p> <!-- Of course, if your sysadm has setup a firewall, s/he might have a good reason, and you may have signed an agreement to not circumvent it. On the other hand, the fact that you can telnet outside (which is a requisite for the presented hacks to work) means that you are allowed to access external systems, and the fact that you can log into a particular external system somehow means you're allowed to do it, too. --> システム管理者がファイアーウォールを立てているのは、もちろん理由があって のことです。したがって、このソフトウエアを使用するに当たっては、管理者から 許可を得た方がよいと思います。一方、あなたが外部に telnet できるという事実 (これはハックキングを行うための必要条件です)は、特定の外部のシステムに アクセスする権利を持っていることを意味します。つまり特定のシステムに何らか のかたちでログインするには、あなたがそのシステムのユーザとして認められている 必要があります。 <!-- So this is all a matter of <em>conveniently</em> using legal holes in a firewall, and allow generic programs to work from there with generic protocols, as opposed to requiring special or modified (and recompiled) programs going through lots of special-purpose proxies that be misconfigured by an uncaring or incompetent sysadm, or to installing lots of special-purpose converters to access each of your usual services (like e-mail) through ways supported by the firewall (like the web). --> セキュリティのことを考えると、ファイアーウォールのすでに開かれている穴を利用 することは、とても <em>お手軽な</em> 方法です。この方式なら、あるプログラム が本来利用しているプロトコルをそのまま使えるからです。逆にこの方法がとれない 場合は、特定の用途のためにプロクシ機能をもつ特別のプログラムが必要になるか、 既存のプログラムの改造(とコンパイル)を行う必要がでてきます。こんなこと をすると、不愛想で無能な管理者が設定ミスをおかすことになるかもしれません。 また、ファイアーウォールによってサポートされているサービス(Web 等)で、普段 使っている通常のサービス(電子メール 等)を利用するためには、あるプロトコルを 許可されたプロトコルに変換するプログラムを必要なプロトコルの分だけ、インス トールするはめになるかもしれません。 <!-- Moreover, the use of a user-level IP emulator such as SLiRP should still prevent external attackers from piercing the firewall back in the other way, unless explicitly permitted by you (or they are clever and wicked, and root or otherwise able to spy you on the remote host). --> その上 SLiRP のようなユーザ・レベルの IP エミュレータを使うことによって、外部 からのファイアーウォールの穴を利用した攻撃を防ぐことができるはずです。 あなたがあえて不正行為を許可しなければ、他の手段を駆使しても、ファイアー ウォールの穴を攻撃できないはずです(ただ、攻撃者はずるがしこく、ルートの権限を 持つ人やそれに類する人は、リモート・ホストからあなたの行為を監視することも できますが)。 <!-- All in all, the presented hack should be <em>relatively</em> safe. However, it all depends on the particular circumstances in which you set things up, and I can give no guarantee about this hack. Lots of things are intrinsically unsafe about any internet connection, be it with this hack or not, so don't you assume anything is safe unless you have good reasons, and/or use some kind of encryption all the way. --> 総合的に判断して、この方法は <em>比較的</em> 安全なはずです。しかしこれは、 あなたが設定した特定の環境に全面的に依存した方法なので、私は何の保証もでき ません。 インターネット経由の接続は、この手段を使おうが使うまいが、本質的に安全なもの ではありません。ですからこの手段に加えて、何らかの暗号化をほどこすといった 対策をあなたが講じていないのなら、安全は保証されている、などという思い込みを 間違ってもしないでください。 <!-- To sum it up, don't use this hack unless you know what you're doing. Re-read the disclaimer above. --> 今までのことをまとめると、あなたが何をしているかを理解していないなら、この 手段を活用しないでください、ということです。再度「おことわり」を読んでください。 <!-- <sect1>Other requirements --> <sect1>他に必要なもの <p> <!-- It is assumed that you know what you're doing; that you know about setting up a network connection; that you have shell accounts on both sides of the firewall; that you can somehow telnet (or ssh, or equivalent) from one account to the other; that you can run an IP emulator on both shell accounts; that you have programs able to use the IP connection emulated on their side. Note that any program can use the connection, in case the local emulator is pppd talking to the Linux kernel; other emulators, like Term, need recompilation and linking to a special library. --> このドキュメントは、あなたが次のことを理解していると仮定して書かれています。 <itemize> <item>ネットワークの設定方法を知っていること。 <item>ファイアーウォールの両側にシェル・アカウントを持っていること。 <item>相手側にも telnet(もしくは ssh(Secure Shell)やそれと同等の機能をもつ もの)が利用できるアカウントを持っていること。 <item>両側にある自分のシェル・アカウントで IP エミュレータを実行できること。 <item>エミュレートされた IP 接続上で動くプログラムを両側に持っていること。 </itemize> どんなプログラムでも、この接続方法を利用できます。ローカルのエミュレータは、 Linux カーネル とやりとりしている pppd か、再コンパイルが必要で、かつ特別な ライブラリをリンクする必要がある Term のようなプログラムが使われます。 <!-- Talking about IP emulators, pppd can be found in any good Linux distribution or ftp site; so can SLiRP. If your remote shell account is user-level only, you can use SLiRP to connect. --> IP エミュレータについては pppd にしても SLiRPにしても、まともな Linux ディス トリビューションであれば付属しているはずですし、ftp サイトでも見つけられます。 もしリモートのシェル・アカウントが一般ユーザのものだけならば、SLiRP で実現して ください。 <!-- <sect1>Downloading software --> <sect1>ソフトウエアのダウンロード <p> <!-- Most described software should be available from your standard distribution, possibly among contrib's; at least all but the two small last ones are available in as rpm packages. In case you want to fetch the latest sources or binaries (after all, one of the ends of the connection may not be running linux), use the addresses below: --> 下記にあげたソフトウエアのほとんどは、標準的なディストリビューションに付属 しているか、場合によっては、そのコントリビューションに含まれているはずです。 少なくとも最後の 2 つを除いて、rpm パッケージで利用できます。 もし最新のバイナリやソースを落してきたいならば、下記のアドレスを利用して ください(結局最後のソフトウエアの内の 1 つは、 Linux では動かないかもしれ ませんが)。 <itemize> <!-- <item><tt>SLiRP</tt> can be found at <URL URL="http://blitzen.canberra.edu.au/slirp"> and/or --> <item><tt>SLiRP</tt> は、 <URL URL="http://blitzen.canberra.edu.au/slirp"> か、 <URL URL="ftp://www.ibc.wustl.edu/pub/slirp_bin/"> に、 <!-- <item><tt>zsh</tt> can be found at --> <item><tt>zsh</tt> は、 <URL URL="http://www.peak.org/zsh/"> に、 <!-- <item><tt>ppp</tt> can be found at --> <item><tt>ppp</tt> は、 <URL URL="ftp://cs.anu.edu.au/pub/software/ppp/"> に、 <!-- <item><tt>fwprc</tt> and <tt>cotty</tt> can be found at --> <item><tt>fwprc</tt> と <tt>cotty</tt> は、 <URL URL="http://www.tunes.org/~fare/files/fwprc/"> にあります。 </itemize> <!-- <sect>Understanding the problem --> <sect>問題点を理解する <p> <!-- Understanding a problem is the first half of the path to solving it. --> 問題点を理解すれば、もう最初の半分を解決したことになります。 <!-- <sect1>Giving names to things --> <sect1>問題点を明確にする <p> <!-- If you want this hack to work for you, you'll have to get an idea of how it works, so that in case anything breaks, you know where to look for. --> もしこの手段を使いたいなら、まずこれがどのように機能するかを考えてみる必要 があります。そうすれば、何かおかしくなった場合に、どこに見当をつけたらよいか がわかります。 <!-- The first step toward understanding the problem is to give a name to relevant concepts. --> 問題点を理解するはじめのステップは、関連した考え方に名前をつけて区別すること です。 <!-- So we'll herein call "local" the machine that initiates the connection, as well as programs and files on that machine; conversely, we'll call "remote" what's on the other side of the connection. --> それではまず、「ローカル」という言葉は、相手に接続を仕掛けるマシンを意味し、 プログラムやファイルもそのマシン上にあることとします。反対に、「リモート」 という言葉は、接続の相手側を意味します。 <!-- <sect1>The problem --> <sect1>問題点 <p> <!-- The goal is to connect the input and output of a local IP emulator to the output and input respectively of a remote IP emulator. --> 最終目標は、ローカルの IP エミュレータ入出力を、それに対応するリモートの IP エミュレータに渡すことです。 <!-- Only the communication channels with which IP emulators interact are either direct devices (in the usual case of pppd), or the "current tty". The previous case obviously does not happen with telnet sessions. The latter is tricky, because when you launch the local emulator from the command line, the "current tty" is linked to the command-line user, not to a remote session; also, should we open a new session (local or remote) on a new terminal, we must synchronize the launching and connection of IP emulators on both sides, least one session's garbage output is going to be executed as commands on the other session, which would recursively produce more garbage. --> IP エミュレータ間のやりとりを行う経路は、直接接続されているデバイス(pppd の 場合)か「現在使用している tty」のどちらかになります。 telnet セッションは前者ではなく、後者に当てはまるのですが、扱いづらい面が あります。 というのも、コマンド・ラインからローカルのエミュレータを実行すると、 「現在使用している tty」は、リモート・セッションではなく、コマンド・ラインを 使っているユーザに接続されてしまうからです。もちろん新たにセッション(ローカル もしくはリモートで)を新規の端末から立ち上げる必要がありますが、両側の IP エミュレータの起動と起動後の接続を同期させなければなりません。あるセッション の不要な出力を、もう一つのセッションのコマンドとして実行してしまうことだけは、 避けなければいけません。そうしないと、繰り返し不要なコマンドが実行されてしまい ます。 <!-- <sect1>Additional difficulty --> <sect1>さらに面倒なこと <p> <!-- To get the best ease of use, the local IP emulator has to provide IP to kernel networking, hence be pppd. However, pppd is dumb enough to only accept having data through /dev or thru the current tty; it must be a tty, not a pair of pipe (which would be the obvious design). This is fine for the remote pppd if any, as it can use the telnet session's tty; but for the local pppd, it sucks, as it can't launch the telnet session to connect to; hence, there must some kind of wrapper around it. --> 最も簡単な方法は、ローカルの IP エミュレータがカーネルのネットワーク 機能である pppd に IPパケットのデータを渡す方法です。しかし pppd は結構まぬけ で、 /dev もしくは、現在使用している tty からしかデータを受け取れません。 受け取るのは tty からで、パイプ経由ではだめなのです(これはいわゆる仕様という やつでしょう)。 つまり、リモートの pppd で telnet セッションの tty を使用する分にはよいと しても、ローカルの pppd では、接続すべき telnet セッションを pppd が横取りして しまうので、具合が悪いことになります。 そのようなわけで、ある種のラッパーが必要になってきます。 <!-- Telnet behaves <em>almost</em> correctly with a pair of pipe, except that it will still insist on doing ioctl's to the current tty, with which it will interfere; using telnet without a tty also causes race conditions, so that the whole connection will fail on "slow" computers (fwprc 0.1 worked perfectly on a P/MMX 233, one time out of 6 on a 6x86-P200+, and never on a 486dx2/66). --> telnet は <em>たいていの場合</em>、パイプをうまく利用できます。ただ、やはり現在 使用している tty デバイスの制御を行うため、動作に支障が生じてしまいます。 また telnet を tty を利用せずに使用すると、データのやりとりが競合状態になって しまいますので、「遅い」コンピュータを使っていると、接続ができなくなるかも しれません(fwprc 0.1 は、Pentium/MMX 233 では問題なく動作しましたが、 6x86-P200+ では 6 回中 1 度だけ動き、486DX2/66 では全く動作しませんでした) <!-- [Note: if I find the sucker (probably a MULTICS guy, though there must have been UNIX people stupid enough to copy the idea) who invented the principle of "tty" devices by which you read and write from a "same" pseudo-file, instead of having clean pairs of pipes, I strangle him!] --> [注: すっきりとしたパイプの対を使わないで、「同じ」仮想ファイルを使ってファ イルを読み書きするという "tty" デバイスの原理を発明した馬鹿野郎 (たぶんそいつは MULTICS 使いだと思うけど、それを真似したバカな UNIX な 人もいるはず)を見つけたらシメてやる! !] <!-- <sect>The solution --> <sect>解決するには <p> <!-- <sect1>Principle --> <sect1>原理 <p> <!-- The firewall-piercing program, <tt>fwprc</tt>, will use a "tty proxy", <tt>cotty</tt>, that opens two pseudo-tty devices, launches some command on each of those devices' slaves, and stubbornly copies every character that one outputs to the tty that serves as input of the other command. One command will be telnet connection to remote site, and the other will be the local pppd. pppd can then open and control the telnet session with a chat script as usual. --> <tt>fwprc</tt>がファイアーウォールに穴を開けるプログラムです。「tty プロクシ」 として機能する<tt>cotty</tt>を利用しています。これは仮想的に 2 つの tty デバイスを開きます。それぞれのデバイス上でコマンドを実行すると、その出力が そのままコピーされて、相手へのコマンドの入力として tty に渡されます。 コマンドは、リモート側へ telnet 接続を通じて渡され、相手側は、ローカルの pppd が受け取ります。そこで pppd は 通常のチャット・スクリプトを扱う場合と同じよう に、telnet セッションを開いて、制御を行えるようになります。 <sect1>fwprc <p> <!-- I wrote a very well self-documented script to pierce firewalls, <tt>fwprc</tt>, available from my site <URL URL="http://www.tunes.org/~fare/files/fwprc/">, together with <tt>cotty</tt> (which is required by <tt>fwprc</tt> 0.2 and later). At the time of my writing these lines, latest versions are <tt>fwprc</tt> 0.3a and <tt>cotty</tt> 0.3a. --> 私が、ファイアーウォルに穴をあけるスクリプト <tt>fwprc</tt> を書きました。 スクリプトのセルフ・ドキュメント化もきちんとしてあります。<tt>cotty</tt> (<tt>fwprc</tt> 0.2 以上のバージョンで必要になります)とあわせて、私のサイト である <URL URL="http://www.tunes.org/~fare/files/fwprc/">から落すことができます。 このドキュメントを書いている時点での最新バージョンは、 <tt>fwprc</tt> 0.3a と <tt>cotty</tt> 0.3a です。 <!-- The name "fwprc" is voluntarily made unreadable and unpronounceable, so that it will confuse the incompetent paranoid sysadm who might be the cause of the firewall that annoys you (of course, there can be legitimate firewalls, too, and even indispensible ones; security is all a matter of <em>correct</em> configuration). If you must read it aloud, choose the worst way you can imagine. --> 「fwprc」という名前はあえて読みづらく、かつ発音しにくくしました。そうすれば ファイアーウォールの件で日頃イライラさせられている、無能で偏執的な管理者を 混乱させることができるからです(もちろん理にかなったファイアーウォールも存在 しますし、それらは無くてはならないものです。 セキュリティは、<em>正当な</em> 環境設定の一部ですから)。 声を出して「fwprc」を読まなければならない時には、思い付く中で一番不快に感じる 読み方を選んでください。 <!-- CONTEST! CONTEST! Send me a <tt>.au</tt> audio file with a digital audio recording of how you pronounce "fwprc". The worst entry will win a free upgrade and his name on the fwprc 1.0 page! --> <bf>コンテスト！</bf> 私に「fwprc」の読み方を <tt>.au</tt> 形式で録音された オーディオ・ファイルにして送ってください。最も不快なものには、フリーでアップ グレードできる権利を差し上げ、fwprc 1.0 のページにお名前を掲載します！ <!-- I tested the program in several settings, by configuring it through resource files. But of course, by Murphy's law, it will break for you. Feel free to contribute enhancements that will make life easier to other people who'll configure it after you. --> いくつかの設定でこのプログラムをテストしました。いずれもリソース・ファイル をいじって設定しました。しかしやはりマーフィーの法則には逆らえず、あなたは 困った状況に陥るかもしれません。そんな時には、ご自由に改良をしていただいて 結構です。 そうすれば、これから設定することになる他のみなさんは、より簡単に利用できる ようになるでしょうから。 <sect1>.fwprcrc <p> <!-- <tt>fwprc</tt> can be customized through a file <tt>.fwprcrc</tt> meant to be the same on both sides of the firewall. Having several alternate configurations to choose from is sure possible (for instance, <em>I</em> do it), and is left as an exercise to the reader. --> <tt>fwprc</tt> は、<tt>.fwprcrc</tt> ファイルを使ってカスタマイズしますので、 ファイアーウォールの両側で同じような設定ファイルを作る必要があります。 異なるいくつかの設定を使い分けることももちろん可能ですが(<em>私は</em> そうしています)、 それは読者の方への宿題としておきましょう。 <p> <!-- To begin with, copy the appropriate section of <tt>fwprc</tt> (the previous to last) into a file named <tt>.fwprcrc</tt> in your home directory. Then replace variable values with stuff that fits your configuration. Finally, copy to the other host, and test. --> まず <tt>fwprc</tt> の該当する部分をコピーして、<tt>.fwprcrc</tt> という名前 のファイルをホーム・ディレクトリに作ってください。 次に、あなたの環境にあった設定になるように、変数の値を変更します。 最後にその設定ファイルを相手側のホストにコピーして、テストしてください。 <p> <!-- Default behavior is to use pppd locally, and slirp remotely. To modify that, you can redefine the appropriate function in your <tt>.fwprcrc</tt> with such a line as: --> デフォルトの設定では、pppd をローカルで使用して、リモートでは slirp を使う ようになっていますので、下記のように適切に再設定してください。 <tscreen> remote_IP_emu () { remote_pppd } </tscreen> <p> <!-- Note that SLiRP is safer than pppd, and easier to have access to, since it does not require being root on the remote machine. Anoter safe feature is that it will drop packets not directly coming from the connected machine (which feature becomes a misfeature if you attempt to route a subnetwork onto it with masquerading). The basic functionality in SLiRP works quite well, but I've found advertised pluses (like run-time controllability) to be deficient; of course, since it is free software, feel free to hack the source so as to actually implement whichever feature you need. --> SLiRP は pppd より安全性が高く、相手側にアクセスする方法も簡単です。なぜなら、 リモート側のマシンで root の権限を必要としないからです。安全な理由はまだあり ます。接続されているマシンから直接くるパケット以外は、まったく受けつけないため です(マスカーレーディングでサブネットのルーティングをするとこのメリットはなく なります)。 SLiRP の基本機能はうまく動きますが、まだまだこれからの機能(例えばランタイムな 制御)もあります。 もちろんフリーソフトですから、ソースをハックして、必要な機能をどんどんインプリ メントしてください。 <p> <!-- <sect>Reverse piercing --> <sect>反対側から穴をあける <p> <!-- <sect1>Rationale --> <sect1>基本的な考え方 <p> <!-- Sometimes, only one side of the firewall can launch telnet sessions into the other side; however, some means of communication is possible (typically, through e-mail). Piercing the firewall is still possible, by triggering with whatever messaging capability is available a telnet connection from the ``right'' side of the firewall to the other. --> telnet がファイアーウォールの片側からしかできない場合があります。 しかしそういう状況でも、いくつかの通信手段を利用することが可能です(電子メール 等)。 その通信手段が用いているメッセージの交換方法がどのように行われていても、 telnet が「許されている」側から、ファイアーウォールの反対側のマシンに接続 できれば、ファイアーウォールを通過してメッセージを伝えることが可能です。 <p> <!-- <tt>fwprc</tt> includes code to trigger such connections from a PGP-authentified e-mail message; all you need is add <tt>fwprc</tt> as a <tt>procmail(1)</tt> filter to messages using the protocol, (instructions included in <tt>fwprc</tt> itself). Note however, that if you are to launch pppd with appropriate priviledges, you might need create your own suid wrapper to become root. Instructions enclosed in <tt>fwprc</tt>. --> <tt>fwprc</tt> は PGP(Pretty Good Privacy)を使って認証された電子メールのような メッセージがくると、自動的に相手に対して接続を行う機能をもっています。 <tt>fwprc</tt> にメッセージを伝えるプロトコルのフィルタとして <tt>procmail(1)</tt> を登録するだけで OK です(具体的な設定方法は <tt>fwprc</tt> に付属しています)。 ただし注意してもらいたいのは、pppd を適切なユーザ権限で実行するためには、 root に setuid するラッパーをつくらなければならないことです。具体的な方法は <tt>fwprc</tt> に付属する解説書を読んでください。 <p> <!-- Also, authentified trigger does not remotely mean secure connection. You should really use ssh (perhaps over telnet) for secure connections. And then, beware of what happens between the triggering of a telnet connection, and ssh taking over that connection. Contribution in that direction welcome. --> また、通信内容が認証されていても、決して接続自体がセキュアなわけではありません。 本当にセキュアな接続をしたいなら ssh(できたら telnet を経由して)を使用すべき です。 このようなわけで telnet 経由の通信で行われていることに対して、注意を払う必要が あります。 また本当にセキュアな通信をしたいなら、ssh を使用してください。これに関連した 情報およびご意見をどしどしお寄せください。 <!-- <sect1>Getting the triggering mail --> <sect1>電子メールのやりとりのしかた <p> <!-- If you are firewalled, your mail may as well be in a central server that doesn't do procmail filtering or allow telnet sessions. No problem! You can use <tt>fetchmail(1)</tt> to run in daemon mode to poll and get mail to your client linux system, and/or add a cron-job to automatically poll for mail every 1-5 minutes. fetchmail will forward mail to a local address through <tt>sendmail(8)</tt>, which itself will have been configured to use <tt>procmail(1)</tt> for delivery. Note that if you run <tt>fetchmail(1)</tt> as a background daemon, it will lock away any other fetchmail that you'd like to run only at other times, like when you open a <tt>fwprc</tt>; of course, if you can also run a fetchmail daemon as a fake user. Too frequent a poll won't be nice to either the server or your host. Too unfrequent a poll means you'll have to wait before the message gets read and the reverse connection gets established. I use two-minute poll frequency. --> あなたが、ファイアーウォールに守られている環境にいるならば、procmail も telnet も許可していないメール・サーバを利用している可能性があります。 でもご心配なく！ <tt>fetchmail(1)</tt> をデーモンとして動かして、クライアント の Linux マシンとやりとりさせれば大丈夫です。さらに cron で 自動的に 1 〜 5 分 間隔でポーリングさせます。fetchmail は、ローカル・アドレス宛のメールを <tt>sendmail(8)</tt> を利用してフォワードすることができます。配送に <tt>procmail(1)</tt> を使うように設定することもできます。 もしバックグラウンドのデーモンとして <tt>fetchmail</tt> を動かすと、 <tt>fwprc</tt> から fetchmail を動かそうとした時に、すでにデーモンとして動いて いる fetchmail がじゃまをして起動できません。 もちろん ダミーのユーザの権限でデーモンの fetchmail を動かすというのも 1 つの 手です。 あまりに頻繁にポーリングすることは、サーバにとっても、自分のクライアント・ マシンにとっても、好ましくありません。反対にポーリングをあまりしないように すると、メッセージが読めるまでに時間がかかり、投稿とのタイミングがずれてしまい ます。 私は 2 分間隔でポーリングしています。 <!-- <sect>Final notes --> <sect>最後の注意点 <p> <!-- <sect1>Other settings --> <sect1>その他の設定 <p> <!-- There are other kinds of firewalls than those that allow for telnet connections. As long as a continuous flow of packets may go through a firewall, and transmit information both ways, it is possible to pierce it; only the price of writing the piercer may be higher or lower. --> telnet を許している他にも、いろいろなポリシーを持つファイアーウォールが存在 しています。 パケットがファイアーウォールを経由して常にやりとりされて情報が行き来している ならば、それを利用してファイアーウォールに穴を開けることは可能です。 要するに、穴を開けるプログラムを書きあげるのが、手間がかかるか、かからないか、 という違いがあるだけです。 <!-- In a very easy case, you can just launch <tt>ssh</tt> over a pty, and do some <tt>pppd</tt> in the slave tty. <tt>cotty</tt> 0.3a should be able to do it, but nobody's modified <tt>fwprc</tt> to take it into account yet. May be tonight's exercise for you. You may even want to do it without an adverse firewall, just so as to build a secure ``VPN'' (Virtual Private Network). See the VPN mini-HOWTO about this. --> 簡単に解決できる場合もあります。pty 越しに <tt>ssh</tt> を動かして そのスレーブの tty で <tt>pppd</tt> を動かす方法です。 <tt>cotty</tt> 0.3a を使って実現できるはずですが、<tt>fwprc</tt> を改造して、 この機能を組み込んでいる人はまだいません。 今晩の練習問題としていかがですか? 面倒くさいファイアーウォールをわきに置いといて、何とかしたいと思われる方 には、セキュアな「VPN(Virtual Private Network)」を構築することをお勧めします。 詳しくは、VPN mini-HOWTO を見てください。 <!-- If you need cross a 7-bit line, you'll want to use SLIP instead of PPP. I never tried, because lines are more or less 8-bit clean these days, but it shouldn't be difficult. --> もし 7 ビットしか通さない回線をまたぐ必要がある場合は、PPP ではなく SLIP を 使う必要があると思います。私は試していませんし、今後も試せないと思います。 というのも、最近はおよそ 8 ビット クリーンな回線がほとんどですから。 <!-- Now, if the only way through the firewall is a WWW proxy (usually, a minimum for an internet-connected network), you might want to write a daemon that buffers data in and out, and sends it during in HTTP connections, achieving some telnet-over-HTTP over which to run fwprc. It might be slow and not very responsive, but still good enough to use <tt>fetchmail(1)</tt>, <tt>suck(1)</tt>, and other non-interactive programs. --> さて、もしファイアーウォールを通過できる手段が WWW プロクシだけなら(普通に インターネット接続しているネットワークの最低条件でしょう)、入出力用のバッファ を持つデーモンを書いて、HTTP 接続を利用してバッファのデータを送り出したいと 思うのではないでしょうか。これは fwprc を動かして、HTTP 越しに telnet を行う ことで実現できます。 速度が遅く、きびきびと反応しないでしょうが、<tt>fetchmail(1)</tt> や <tt>suck(1)</tt> といったバッチ処理系のプログラムで利用する分には、十分です。 <!-- If you want more performance, or if the only thing that goes through unfiltered is some wierder thing even (DNS queries, ICMP packets, whatever), then you're in the very hard case where you'll have to re-hack a wierd IP stack, using (for instance) the Fox project's packet-protocol functors. You'll then achieve some direct IP-over-HTTP, IP-over-DNS, IP-over-ICMP, or such, which requires not only a complex protocol, but also an interface to an OS kernel, both of which are costly to implement. --> これ以上にパフォーマンスを上げたかったり、もっと厄介なプロトコル(DNS クエリー・パケットや ICMP パケット等)を素通ししたい場合は、かなり面倒に なります。たとえば、Fox プロジェクトで行われているように IP スタックを ハックして、パケットやプロトコルの種類に依存しない、統一的にネットワークを 扱える機能を自分で実装する必要がでてきます。 それを行った上ではじめて、HTTP や DNS、ICMP 越しに IP で接続できます。 プロトコルが複雑なだけでなく、カーネルとのインターフェースを作り込む必要がある ので、インプリメントはかなりたいへんな作業になります。<newline> <bf>訳註：</bf>「Fox プロジェクト」については、 <url url="http://www.cs.cmu.edu/afs/cs.cmu.edu/project/fox/mosaic/HomePage.html" name="The Fox Project: Advanced Languages for Systems Software"> を参照して ください。<newline> また このプロジェクトによる ネットワーク・プロトコル・スタックの実装について の資料は、 <url url="http://www.cs.cmu.edu/afs/cs.cmu.edu/project/fox/mosaic/papers.html" name="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」 を見てください。 <!-- By the way, if you use some Firewall-piercing HTTP daemon, don't forget to have it serve fake pages, so as to mislead suspicious adverse firewall administrators. --> ところで、HTTP プロトコルを利用してファイアーウォールに穴を開けるなら、ダミー のページを用意することを忘れないでください。そうしないと、あれこれ気にする 管理者を混乱させてしまいます。 <!-- <sect1>HOWTO maintenance --> <sect1>このドキュメントの改訂について <p> <!-- I felt it was necessary to write it, but I don't have that much time for that, so this mini-HOWTO is very rough. So will it stay, until I get enough feedback so as to know what sections to enhance. Feedback welcome. Help welcome. mini-HOWTO maintenance take-over welcome. --> 必要性を感じて、このドキュメントを書きあげましたが、現状ではこれ以上時間 をさくことができません。そのため、このドキュメントはまだまだ大ざっぱな内容に なっています。改訂を進めるには、このセクションをもっと詳しく、といったみなさん のアドバイスが必要です。フィードバック、助言、はたまたこのドキュメントを私の かわりに更新してくれる方、いずれも歓迎します。 <!-- In any case, the above sections have shown many problems whose solution is just a matter of someone (you?) spending some time (or money, by hiring someone else) to sit down and write it: nothing conceptually complicated, though the details might be burdensome or tricky. --> ともかく、まだ多くの問題点が残されています。誰かが見つけた解決方法が、 みなさん(あなたも含めて)のために役立ちます。少々の時間(もしくは人を雇うお金) を割いていただいて、あなたが書いてみませんか。細かいところを見ると厄介で トリッキーなのですが、コンセプトは明解ですから。 <!-- Do not hesitate to contribute more problems, and hopefully more solutions, to this mini-HOWTO. --> どうかためらわずに、いろいろな問題を解決するお手伝いをしてください。そうすれば、 このドキュメントがさらによくなると思います。 <!-- <sect1>Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!! --> <sect1><bf>とても大切なおことわり</bf>の繰り返し --- <bf>本当です！！！</bf> <p> <quote> <bf> <!-- I hereby disclaim all responsibility for this hack. If it backfires on you in any way whatsoever, that's the breaks. Not my fault. If you don't understand the risks inherent in doing this, don't do it. If you use this hack and it allows vicious vandals to break into your company's computers and costs you your job and your company millions of dollars, well that's just tough nuggies. Don't come crying to me. --> このドキュメントの内容について、一切責任は負いません。どんな障害が生じても、 それは私の過失ではありません。このドキュメントに書かれている手段をとることに よって生じるリスクを理解できないならば、決して利用しないでください。利用する 場合は、あなたの職場のコンピュータが壊れても、業務に支障がでても、また会社に 多額の損害を与えてもかまわない、と腹をくくってください。私に泣きついたりしない でくださいね。 </bf> </quote> </p> </article>