RFC1579 日本語訳

Network Working Group                                        S. Bellovin
Request for Comments: 1579                        AT&T Bell Laboratories
Category: Informational                                    February 1994

Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 大西洋標準時1579とTベル研究所カテゴリ: 情報の1994年2月

                         Firewall-Friendly FTP

ファイアウォールに優しいFTP

Status of this Memo

このMemoの状態

   This document provides information for the Internet community.  This
   document does not specify an Internet standard of any kind.
   Distribution of this document is unlimited.

このドキュメントはインターネットコミュニティのための情報を提供します。 このドキュメントはどんな種類のインターネット標準も指定しません。 このドキュメントの分配は無制限です。

Abstract

要約

   This memo describes a suggested change to the behavior of FTP client
   programs.  No protocol modifications are required, though we outline
   some that might be useful.

このメモはFTPクライアントプログラムの働きに提案された変化を説明します。プロトコル変更は全く必要ではありません、私たちが役に立つかもしれないいくつかについて概説しますが。

Overview and Rational

概要的で合理的です。

   The FTP protocol [1] uses a secondary TCP connection for actual
   transmission of files.  By default, this connection is set up by an
   active open from the FTP server to the FTP client.  However, this
   scheme does not work well with packet filter-based firewalls, which
   in general cannot permit incoming calls to random port numbers.

FTPプロトコル[1]はファイルの実際の伝達にセカンダリTCP接続を使用します。 デフォルトで、この接続はアクティブな戸外によってFTPサーバからFTPクライアントまでセットアップされます。 しかしながら、この体系はパケットのフィルタベースのファイアウォールでうまくいきません。(一般に、ファイアウォールは無作為のポートナンバーにかかってきた電話を可能にすることができません)。

   If, on the other hand, clients use the PASV command, the data channel
   will be an outgoing call through the firewall.  Such calls are more
   easily handled, and present fewer problems.

他方では、クライアントがコマンド、データ・チャンネルが使用するPASVを使用するなら、ファイアウォールを通した発信電話になってください。 そのような呼び出しは、より少ないより容易に扱われて、現在の問題です。

The Gory Details

流血場面の詳しい描写

   The FTP specification says that by default, all data transfers should
   be over a single connection.  An active open is done by the server,
   from its port 20 to the same port on the client machine as was used
   for the control connection.  The client does a passive open.

FTP仕様は、デフォルトで、単独結合の上にすべてのデータ転送があるべきであると言います。 サーバはコントロール接続に使用されたクライアントマシンでポート20から同じポートまでアクティブな戸外をします。 クライアントは受け身の戸外をします。

   For better or worse, most current FTP clients do not behave that way.
   A new connection is used for each transfer; to avoid running afoul of
   TCP's TIMEWAIT state, the client picks a new port number each time
   and sends a PORT command announcing that to the server.

のるかそるか、ほとんどの現在のFTPクライアントはそのように振る舞いません。 新しい接続は各転送に使用されます。 クライアントは、TCPのTIMEWAIT状態と衝突するのを避けるために、その都度、新しいポートナンバーを選んで、PORTコマンドにそれをサーバに示させます。

   Neither scenario is firewall-friendly.  If a packet filter is used
   (as, for example, provided by most modern routers), the data channel
   requests appear as incoming calls to unknown ports.  Most firewalls
   are constructed to allow incoming calls only to certain believed-to-
   be-safe ports, such as SMTP.  The usual compromise is to block only

どちらのシナリオもファイアウォールに優しくはありません。 パケットフィルタが使用されているなら(例えば、ほとんどの現代のルータで提供するように)、入来が未知のポートに呼びかけるのに従って、データ・チャンネル要求は現れます。 ほとんどのファイアウォールが、あるだけ信じられているかかってきた電話を許容するために構成される、-、-、-、安全である、SMTPなどのポート。 ブロックだけには普通の感染があります。

Bellovin                                                        [Page 1]

RFC 1579                 Firewall-Friendly FTP             February 1994

FTP1994年2月にファイアウォールに優しいBellovin[1ページ]RFC1579

   the "server" area, i.e., port numbers below 1024.  But that strategy
   is risky; dangerous services such as X Windows live at higher-
   numbered ports.

すなわち、「サーバ」領域、1024の下におけるポートナンバー。 しかし、その戦略は危険です。 X-windowsなどの危険なサービスは、より高い番号付のポートに住んでいます。

   Outgoing calls, on the other hand, present fewer problems, either for
   the firewall administrator or for the packet filter.  Any TCP packet
   with the ACK bit set cannot be the packet used to initiate a TCP
   connection; filters can be configured to pass such packets in the
   outbound direction only.  We thus want to change the behavior of FTP
   so that the data channel is implemented as a call from the client to
   the server.

他方では、発信電話はファイアウォール管理者かパケットフィルタのために、より少ない問題を提示します。 ACKビットがセットしたことでのどんなTCPパケットもTCP接続を開始するのに使用されるパケットであることができません。 そのようなパケットを外国行きの方向だけに通過するためにフィルタを構成できます。 その結果、FTPの振舞いを変えたいと思うので、データ・チャンネルはクライアントからサーバまでの呼び出しとして実装されます。

   Fortunately, the necessary mechanisms already exist in the protocol.
   If the client sends a PASV command, the server will do a passive TCP
   open on some random port, and inform the client of the port number.
   The client can then do an active open to establish the connection.

幸い、必要なメカニズムはプロトコルで既に存在しています。 クライアントがPASVコマンドを送ると、サーバは、いくらかの無作為のポートで開いている受け身のTCPをして、ポートナンバーについてクライアントに知らせるでしょう。 そして、クライアントは、接続を証明するためにアクティブな戸外ができます。

   There are a few FTP servers in existence that do not honor the PASV
   command.  While this is unfortunate (and in violation of STD 3, RFC
   1123 [2]), it does not pose a problem.  Non-conforming
   implementations will return a "500 Command not understood" message;
   it is a simple matter to fall back to current behavior.  While it may
   not be possible to talk to such sites through a firewall, that would
   have been the case had PASV not been adopted.

PASVコマンドを光栄に思わない現存するいくつかのFTPサーバがあります。 そして、これが不幸である、(STD3、RFC1123[2])を違反して、それは問題を設定しません。 非の従う実装は「500 Commandは分からなかった」というメッセージを返すでしょう。 現在の振舞いへ後ろへ下がるのは、簡単な事柄です。 ファイアウォールを通してそのようなサイトと話すのが可能でないかもしれない間、PASVが採用されなかったなら、それはそうだったでしょうに。

Recommendation

推薦

   We recommend that vendors convert their FTP client programs
   (including FTP proxy agents such as Gopher [3] daemons) to use PASV
   instead of PORT.  There is no reason not to use it even for non-
   firewall transfers, and adopting it as standard behavior will make
   the client more useful in a firewall environment.

私たちは、ベンダーがPORTの代わりにPASVを使用するために、彼らのFTPクライアントプログラム(ゴーファー[3]デーモンなどのFTPプロキシエージェントを含んでいる)を変換することを勧めます。 非ファイアウォールの転送にさえそれを使用しない理由が全くありません、そして、標準の振舞いとしてそれを採用するのに、クライアントはファイアウォール環境で、より役に立つようになるでしょう。

   STD 3, RFC 1123 notes that the format of the response to a PASV
   command is not well-defined.  We therefore recommend that FTP clients
   and servers follow the recommendations of that RFC for solving this
   problem.

STD3、RFC1123はPASVコマンドへの応答の形式が明確でないことに注意します。 したがって、私たちは、FTPクライアントとサーバがこの問題を解決するためのそのRFCの推薦の後をつけることを勧めます。

Discussion

議論

   Given the behavior of most current FTP clients, the use of PASV does
   not cause any additional messages to be sent.  In all cases, a
   transfer operation is preceded by an extra exchange between the
   client and the server; it does not matter if that exchange involves a
   PORT command or a PASV command.

ほとんどの現在のFTPクライアントの振舞いを考えて、PASVの使用はどんな送られるべき追加メッセージも引き起こしません。 すべての場合では、クライアントとサーバの間の付加的な交換で転送操作に先行しています。 その交換がPORTコマンドかPASVコマンドにかかわるかどうかは重要ではありません。

   There is some extra overhead with Gopher-style clients; since they
   transfer exactly one file per control channel connection, they do not

ゴーファースタイルクライアントがいる何らかの付加的なオーバーヘッドがあります。 彼らがまさにコントロールチャンネル接続あたり1個のファイルを移すので、それらは移しません。

Bellovin                                                        [Page 2]

RFC 1579                 Firewall-Friendly FTP             February 1994

FTP1994年2月にファイアウォールに優しいBellovin[2ページ]RFC1579

   need to use PORT commands.  If this is a serious concern, the Gopher
   proxy should be located on the outside of the firewall, so that it is
   not hampered by the packet filter's restrictions.

PORTを使用する必要性は命令します。 これが真剣な関心であるなら、ゴーファープロキシはファイアウォールの外部に見つけられるべきです、それがパケットフィルタの制限で妨げられないように。

   If we accept that clients should always perform active opens, it
   might be worthwhile enhancing the FTP protocol to eliminate the extra
   exchange entirely.  At startup time, the client could send a new
   command APSV ("all passive"); a server that implements this option
   would always do a passive open.  A new reply code 151 would be issued
   in response to all file transfer requests not preceded by a PORT or
   PASV command; this message would contain the port number to use for
   that transfer.  A PORT command could still be sent to a server that
   had previously received APSV; that would override the default
   behavior for the next transfer operation, thus permitting third-party
   transfers.

私たちが、クライアントがいつも働くべきであると受け入れるなら、能動態は開いて、付加的な交換を完全に排除するためにFTPプロトコルを高める価値があるかもしれません。 始動時に、クライアントは新しいコマンドAPSV(「すべての受動態」)を送ることができました。 このオプションを実装するサーバはいつも受け身の戸外をするでしょう。 PORTによって先行されたというわけではないすべてのファイル転送要求かPASVコマンドに対応して新しい回答コード151を発行するでしょう。 このメッセージはその転送に使用するポートナンバーを含んでいるでしょう。 まだ以前にAPSVを受けたサーバにPORTコマンドを送ることができました。 それは次の転送操作のためのデフォルトの振舞いをくつがえして、その結果、転送を第三者に可能にするでしょう。

Implementation Status

実装状態

   At least two independent implementations of the modified clients
   exist.  Source code to one is freely available.  To our knowledge,
   APSV has not been implemented.

変更されたクライアントの少なくとも2つの独立している実装が存在しています。 1つへのソースコードは自由に利用可能です。 私たちが知っている限り、APSVは実装されていません。

Security Considerations

セキュリティ問題

   Some people feel that packet filters are dangerous, since they are
   very hard to configure properly.  We agree.  But they are quite
   popular.  Another common complaint is that permitting arbitrary
   outgoing calls is dangerous, since it allows free export of sensitive
   data through a firewall.  Some firewalls impose artificial bandwidth
   limits to discourage this.  While a discussion of the merits of this
   approach is beyond the scope of this memo, we note that the sort of
   application-level gateway necessary to implement a bandwidth limiter
   could be implemented just as easily using PASV as with PORT.

それらは適切に非常に構成しにくくてパケットフィルタが危険であることを感じる人々もいます。 私たちは同意します。 しかし、それらはかなりポピュラーです。 別の一般的な苦情は任意の発信電話を可能にするのが危険であるということです、極秘データの無為替輸出のファイアウォールに通ることを許すので。 いくつかのファイアウォールが、これをがっかりさせるように人工の帯域幅限界を課します。 このアプローチの長所の議論がこのメモの範囲を超えている間、私たちは、ちょうどPORTのように容易にPASVを使用するとして帯域幅リミタを実装するのに必要なアプリケーションレベルゲートウェイの種類を実装することができたことに注意します。

   Using PASV does enhances the security of gateway machines, since they
   no longer need to create ports that an outsider might connect to
   before the real FTP client.  More importantly, the protocol between
   the client host and the firewall can be simplified, if there is no
   need to specify a "create" operation.

PASVを使用すると、ゲートウェイマシンのセキュリティは機能アップにします、もう、部外者が本当のFTPクライアントの前で接続するかもしれないポートを作成する必要はないので。 より重要に、クライアントホストとファイアウォールの間のプロトコルを簡素化できます、「作成」操作を指定する必要は全くなければ。

   Concerns have been expressed that this use of PASV just trades one
   problem for another.  With it, the FTP server must accept calls to
   random ports, which could pose an equal problem for its firewall.  We
   believe that this is not a serious issue, for several reasons.

関心は述べられました。PASVのこの使用は別のもののためにただ1つの問題を取り引きします。 それで、FTPサーバは無作為のポートに呼び出しを受け入れなければなりません。(ポートは等しい問題をファイアウォールに引き起こすことができました)。 私たちは、いくつかの理由でこれが重大な問題でないと信じています。

   First, there are many fewer FTP servers than there are clients.  It
   is possible to secure a small number of special-purpose machines,
   such as gateways and organizational FTP servers.  The firewall's

まず最初に、多くのクライアントがいるより少ないFTPサーバがあります。 ゲートウェイや組織的なFTPサーバなどの少ない数の専用マシンを固定するのは可能です。 ファイアウォールのもの

Bellovin                                                        [Page 3]

RFC 1579                 Firewall-Friendly FTP             February 1994

FTP1994年2月にファイアウォールに優しいBellovin[3ページ]RFC1579

   filters can be configured to allow access to just these machines.
   Further precautions can be taken by modifying the FTP server so that
   it only uses very high-numbered ports for the data channel.  It is
   comparatively easy to ensure that no dangerous services live in a
   given port range.  Again, this is feasible because of the small
   number of servers.

まさしくこれらのマシンへのアクセスを許すためにフィルタを構成できます。 さらに、それは、FTPサーバを変更することによって注意できるので、データ・チャンネルにまさしくその高く番号付のポートを使用するだけです。 どんな危険なサービスも与えられたポート範囲に住んでいないのを保証するのは比較的簡単です。 一方、これはサーバの少ない数のために可能です。

References

参照

   [1] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 1, RFC
       959, USC/Information Sciences Institute, October 1985.

[1] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、STD1、RFC959、科学が1985年10月に設けるUSC/情報。

   [2] Braden, R., Editor, "Requirements for Internet Hosts -
       Application and Support", STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.

[2] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)

   [3] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
       D., and B. Alberti, "The Internet Gopher Protocol (a distributed
       document search and retrieval protocol)", RFC 1436, University of
       Minnesota, March 1993.

[3]Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、トーリー、D.、およびB.アルベルティ、「インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)」、RFC1436、ミネソタ大学(1993年3月)。

Author's Address

作者のアドレス

       Steven M. Bellovin
       AT&T Bell Laboratories
       600 Mountain Avenue
       Murray Hill, NJ  07974

マリー・ヒル、スティーブンM.Bellovin AT&Tベル研究所600山のAvenueニュージャージー 07974

       Phone: (908) 582-5886
       EMail: smb@research.att.com

以下に電話をしてください。 (908) 582-5886 メールしてください: smb@research.att.com

Bellovin                                                        [Page 4]

Bellovin[4ページ]