FTPD mailing list で頂いた意見

Build No.73 at Thu Nov 18 15:33:18 2010

FTP プロトコルの passive mode にまつわる誤解 」(以降、「誤解に関するページ」) について、 ftpd ML で種々のご意見をいただきました。 内容が興味深く、広く世に開示すれば意義があると考え、ここに公開します。

誤解に関するページを作成した動機の1つは、 netnews の fj newsgroups で行われていた議論へ参加するための予備調査をすることでした。 色々な人にこのページを見てもらって意見をもらい、 情報収集にあたろうとしたのです。 そのため、社内で査閲してもらったり、ftpd ML で意見を募ったりしました。 しかし ftpd ML での議論は、古い資料集めの困難さもあって、 私には咀嚼しきれないまま1年以上放置することになります。 それでも、FTP protocol の世界には、 誤解のページを作った当時の私の理解とは違った側面があることがわかってきました。 出元が fj なので、議論を最終的に fj の世界に還したいのですが、 今の私の理解の範囲では、FTP の種々の側面に関する 合理的な説明や主張を与えることはできないでしょう。 そこで、Web で ftpd ML の議論を開示する(そして fj に報告する)ことで、 ひと区切りをつけてみることにしました。

ご意見ご感想等はいつでも歓迎します。

全体・一部に関わらず無断複製を禁じます。 (現在のところ、ftpd MLの記事は一般には公開されていません。 以下の記事はお願いして公開の許可をいただいたものです。) リンクは自由にはって下さい。 個々の記事の先頭にもアンカーを付してあります。 例えば [ftpd 664] という Subject の記事は、

http://katsu.watanabe.name/doc/ftp/responses.html#ftpd-664

という形で参照できます。


[ftpd 664]

From: WATANABE Katsuhiro <katsu@sra.co.jp>
Date: Fri, 31 Mar 2000 02:30:46 +0900
Subject: [ftpd 664] controll and data connections must be separated for 3parties.

はじめまして。渡邊克宏@SRAと申します。
老後のボケ予防にコンピュータネットワークの勉強を始めようとしてる者です。


さて、File Transfer Protocol について、以下のような主張を雑誌あるいは
ネットワークニュースで目にしました。

(a) control connection と data connection を別々に張るのは無駄だ。
    この点で FTP (プロトコル自体)の設計はダサい。
(b) FTP サーバの passive な data transfer connection の存在意義は、
    ファイアウォールの外の FTP サーバからクライアントプログラムに
    接続せず、内側の FTP クライアントの側から接続するように
    できる点にある。

私はこれらは誤解だと考えたので、以下に反論を準備しました。
  http://www.sra.co.jp/people/katsu/doc/ftp/
要旨は、
(A) data を授受する2者を、外から制御する第3の実体がありうることを
    FTP は想定している。この状況では、control connection と data
    connection が分かれていることが本質的に必要。
(B) data 転送に関わる2者の片方が passive だというのは「定義」で、
    近年のファイアウォールの出現とは無関係。
といったところです。

同僚や友達からは何の反応もないのですが、どなたか誤りの指摘やご意見
ご感想をお持ちの方はいらっしゃいませんか?



ちなみに、(a),(b)のネットワークニュース上にみられた具体例として
  http://galaxy.trc.rwcp.or.jp/text/cgi-bin/newsarticle?ng=fj.unix&id=<8978.910863233@rananim.ie.u-ryukyu.ac.jp>&hd=a
  http://galaxy.trc.rwcp.or.jp/text/cgi-bin/newsarticle?ng=fj.unix&id=<75vats$a2r$1@horse.fsinet.or.jp>&hd=a
を挙げておきます。いずれネットニュースの世界で議論したいので、上記の
反論の web ページからこれらへのリンクを張ることはためらっていますが...。

なお、この mailing list の archive がどこかにありましらお教え下さい。
-- 
渡邊克宏@SRA

[ftpd 665]

From: pyramid@tkf.att.ne.jp
Date: Fri, 31 Mar 2000 10:54:37 +0900
Subject: [ftpd 665] Re: controll and data connections must be separatedfor 3 parties.

 はじめまして。

 ウェブ拝見しました「老後のボケ予防」と仰っているわりには読み応えがあり
ましたよ:-)

 FTPに関する誤解については仰るとおりだと納得できる部分が多かったです。
 要は「FTP」をprotocol(ルール)とclient/server(実装)にきちんと分けて
考えるべきなのに、何でもかんでも「FTP」といえば一緒くたに考えてしまって
いることが、この誤解のベースにあるのではないかと思います。
 (いわゆる「最近インターネットしてるんですよ」というトホホなお言葉と
 同じですね(笑))

 ただ、まぁインターネットに接続して、その上で走るprotocolを利用する
ユーザが増加するにつれて、ご指摘の1対1でのファイル転送のみしかサポート
されていないclientのような、protocolで規定された能力を全てサポート
しないものが一般的になっていくという政治的、経済的な状況が下敷きに
なっているのではないかという気もします。

 利用者の増加による、商業的な要求でWebに対するサービス統合(または
何でもWebに放り込む、ともいいますが:-p)がはげしくて、元来Newsgroupで
行われていた掲示板やIRCなどで行われているChat、さらにはSMTP/POPによる
電子メールまで、WEB(HTTP)上で擬似的に利用できるようなサービスが現れて
いる現状だからこそ、ご指摘のようなprotocolまで掘り下げた議論は必要なの
ではないかと感想をもちました。

 それでは。
Exitus patet-------------------------------------+---------------------
                                                pyramid@tkf.att.ne.jp
                                        A6 1D 87 D0 0D 96 BC FE 4D 6A
                                        76 1A 81 28 8D 39 21 04 DC 73

[ftpd 666]

FTP serverから認証なしに3rd partyへ直接ファイルを転送しようという試みは、 FTP bounce attack と呼ばれている。 つまり、今日ではこれはもはやattackととらえられており、一般には機能という理解のされかたではない。

From: kjm@rins.ryukoku.ac.jp (KOJIMA Hajime /小島肇)
Date: Fri, 31 Mar 2000 11:08:35 +0900
Subject: [ftpd 666] Re: controll and data connections must be separatedfor 3 parties.

<20000331023046V.katsu@sra.co.jp>において
WATANABE Katsuhiro さんがおっしゃるには:
| さて、File Transfer Protocol について、以下のような主張を雑誌あるいは
| ネットワークニュースで目にしました。
| 
| (a) control connection と data connection を別々に張るのは無駄だ。
|     この点で FTP (プロトコル自体)の設計はダサい。
……
| 私はこれらは誤解だと考えたので、以下に反論を準備しました。
|   http://www.sra.co.jp/people/katsu/doc/ftp/
| 要旨は、
| (A) data を授受する2者を、外から制御する第3の実体がありうることを
|     FTP は想定している。この状況では、control connection と data
|     connection が分かれていることが本質的に必要。

; 以下 http://www.sra.co.jp/people/katsu/doc/ftp/ にある図を参照しなが
; らの意見

  個人的には、認証なしに A-B 間での直接ファイル転送を許可する「機能」
  が必要だとは思いません (不要だと思います) から、control connection
  と data connection を分ける必要性も認識できません。wu-ftpd の 

>Changes in 2.4.2-BETA-18-VR14: Released 15 February, 1999
……
> o  Disallow PASV connections from IP addresses different than the control
>    connection.  This is not a complete fix, but it will stop connection
>    theft where the attacker is on a different machine than the victim-
>    client.

  もそういうことだと認識しています。

----
// 木下是雄「理科系の作文技術」中公新書 624 を読もう!!

小島 肇 - KOJIMA Hajime
[Office] kjm@rins.ryukoku.ac.jp, http://www.st.ryukoku.ac.jp/~kjm/
         Phone: 077-543-7414  Fax: 077-543-0706

[ftpd 667]

From: Koga Youichirou <y-koga@mms.mt.nec.co.jp>
Date: Fri, 31 Mar 2000 12:48:36 +0900 (JST)
Subject: [ftpd 667] Re: controll and data connections must be separatedfor 3 parties.

渡邊さん:
> さて、File Transfer Protocol について、以下のような主張を雑誌あるいは
> ネットワークニュースで目にしました。
> 
> (a) control connection と data connection を別々に張るのは無駄だ。
>     この点で FTP (プロトコル自体)の設計はダサい。

>   http://galaxy.trc.rwcp.or.jp/text/cgi-bin/newsarticle?ng=fj.unix&id=<8978.910863233@rananim.ie.u-ryukyu.ac.jp>&hd=a

> (A) data を授受する2者を、外から制御する第3の実体がありうることを
>     FTP は想定している。この状況では、control connection と data
>     connection が分かれていることが本質的に必要。

例としてあげられたこのニュース記事に限って言えば、乱暴な議論展開をして
変な結論が出ていますけれど (データ転送部分のプロトコルがださいのであっ
て、記事で主張されていることと制御とデータが分かれていることとは無関
係)、無駄ということを言っているのではないと思います。

> (b) FTP サーバの passive な data transfer connection の存在意義は、
>     ファイアウォールの外の FTP サーバからクライアントプログラムに
>     接続せず、内側の FTP クライアントの側から接続するように
>     できる点にある。

>   http://galaxy.trc.rwcp.or.jp/text/cgi-bin/newsarticle?ng=fj.unix&id=<75vats$a2r$1@horse.fsinet.or.jp>&hd=a

> (B) data 転送に関わる2者の片方が passive だというのは「定義」で、
>     近年のファイアウォールの出現とは無関係。

想像ですが、もともとは利用するサイトでさまざまなポリシがある、というこ
とが背景にあって、データポートをサーバ側でもクライアント側でも用意でき
る仕様にしたんだと思います (そうでなかったらこんなアクロバティックとも
言える仕様は不要でしょう)。当時はファイアウォールと名づけられた概念は
ありませんでしたが、考え方として近いものがもととなったんじゃないかと思
います。
----
こがよういちろう

[ftpd 668]

参考文献

From: "Hisayuki Nomura" <hnomura@fa2.so-net.ne.jp>
Date: Fri, 31 Mar 2000 13:57:41 +0900
Subject: [ftpd 668] Re: controll and data connections must be separatedfor 3 parties.

MLに投稿するのは初めてなので、マナー違反などあればご指摘ください。

> 老後のボケ予防にコンピュータネットワークの勉強を始めようとしてる者です。
コンピュータをやって、老後を迎える前にボケてしまいそうな
(あるいは既にボケている)野村と申します。

> (A) data を授受する2者を、外から制御する第3の実体がありうることを
>     FTP は想定している。この状況では、control connection と data
>     connection が分かれていることが本質的に必要。
要旨は、「data を授受する2者を、外から制御する第3の実体がありうることを
FTP は想定している。」
というより、
(1) もともと、データ転送と、ファイル転送という別の二つのものであった、
 という歴史的経緯
(2) dataを授受する2者を、第三者が外から制御するものがFTPの原型だった
 (ニュアンスの違いを判っていただけるでしょうか)
のほうがよいのではないかということです。

以下、その時代を知っているわけではないので、すべて推測です。
もともと、現在FTPと呼ばれているものは二つのプロトコルを一緒くたにした
ものです。ファイルとデータが異なるものであることに注意してお読みください

(1) と考える理由
Data-Transfer-Protocl (RFC264)は、データを転送するときのプロトコルで、
ファイルの内容であるデータと、そのデータ転送を制御するためのコード
(終端コード等)以外はデータラインを流れません
で、FTPは、このData-Transfer-Protocolを利用して、データのまとまりで
ある「ファイル」を送受信し、かつユーザー制御可能な形にするためのプロ
トコルとして誕生しました。
その後、RFC354でFTPでは、Telnetプロトコルのサブセットを使用して、
DTPを起動することによってファイルの送受信を行うように定義されました。
RFC354ではData-Transfer-ProtocolとFile-Transfer-Protocolがまとめ
て定義されていますが、基本的に二つのプロトコルを使って一つの目的を
達成するということには変わりありません。RFC354では他に大きな変更
が加えられていますが、「プロトコル二つ」の部分に大きな変更がなされな
かった理由はわかりません。
つまり、FTPで制御リンクとデータリンクが分かれているのは、もともと別の
ものだったからであり、それ以上でもそれ以下でもないと思います。

(2)と考える理由
過去のRFCにおいては、「FTPの操作機器」は、ダム端末装置のよう
にファイルシステムを持たない機器でも操作可能であることを考慮していま
すので、「サーバー間転送もできる」のではなく、「サーバー間転送が基本」
であったことが想像できます。

以上、かなり推測が入っていますが、誤りなどあれば、ご指摘いただけれ
ば幸いです。

--------------------------------------------
野村 久之   hnomura@fa2.so-net.ne.jp
--------------------------------------------

[ftpd 784]

dqAeRFCA[JCuTCgQB

From: WATANABE Katsuhiro <katsu@sra.co.jp>
Date: Wed, 27 Jun 2001 15:08:55 +0900
Subject: [ftpd 784] Re: controll and data connections must be separatedfor 3 parties.

私の書いた http://www.sra.co.jp/people/katsu/doc/ftp/responses.html で:

> RFC264: "The Data Transfer Protocol"; A. Bhushan, B. Braden, W. Crowther,
>  E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White ;
> Jan-04-1972. 本家IETFのrepositoryを含め、The Internet 上のどこにもみつからな
> い。理由は謎。

これに対して、
"Nomura, Hisayuki" <hnomura@fa2.so-net.ne.jp> さんいはく [ftpd 783]

> とのことでしたが、以前、RFC959を邦訳したときには確かに見つかったの
> ですが、ちょっとWebで探した範囲では見つかりませんでした。むぅ・・・

RFC264 は typewriter で打たれたそうです。電子テキスト版は存在せず、
著者のうちのまだ生きている方に連絡をとってコピーを入手するぐらいしか
入手方法はないそうです。

野村さん、翻訳に使った電子テキスト版をなんとか発掘できないでしょうか?
貴重なものだと思われます。          

-- 
渡邊克宏@SRA Linux サポートグループ
June Bride の言い伝え「6月の花嫁は幸せになれる」
June Programmer の言い伝え「6月にプログラミングすると幸せになれる」

ご意見ご感想や誤りの指摘、関連する情報を歓迎します。

渡邊克宏

katsu@watanabe.name