RFC2577 日本語訳

Network Working Group                                          M. Allman
Request for Comments: 2577                  NASA Glenn/Sterling Software
Category: Informational                                     S. Ostermann
                                                         Ohio University
                                                                May 1999

コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 2577年のNASAのグレン/りっぱなソフトウェアカテゴリ: 情報のS.オステルマンオハイオ大学1999年5月

                      FTP Security Considerations

FTPセキュリティ問題

Status of this Memo

このMemoの状態

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

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   The specification for the File Transfer Protocol (FTP) contains a
   number of mechanisms that can be used to compromise network security.
   The FTP specification allows a client to instruct a server to
   transfer files to a third machine.  This third-party mechanism, known
   as proxy FTP, causes a well known security problem.  The FTP
   specification also allows an unlimited number of attempts at entering
   a user's password.  This allows brute force "password guessing"
   attacks.  This document provides suggestions for system
   administrators and those implementing FTP servers that will decrease
   the security problems associated with FTP.

File Transferプロトコル(FTP)のための仕様はネットワークセキュリティに感染するのに使用できる多くのメカニズムを含んでいます。 FTP仕様で、クライアントは、3分の1に機械加工するファイルを移すようサーバに命令できます。 プロキシFTPとして知られているこの第三者メカニズムはよく知られている警備上の問題を引き起こします。 また、FTP仕様はユーザのパスワードを入力することへの無制限な数の試みを許します。 これは力任せの「パスワード推測」攻撃を許します。 このドキュメントはシステム管理者のための提案を提供します、そして、FTPサーバがそれであると実装する人がFTPに関連している警備上の問題を減少させるでしょう。

1   Introduction

1つの序論

   The File Transfer Protocol specification (FTP) [PR85] provides a
   mechanism that allows a client to establish an FTP control connection
   and transfer a file between two FTP servers.  This "proxy FTP"
   mechanism can be used to decrease the amount of traffic on the
   network; the client instructs one server to transfer a file to
   another server, rather than transferring the file from the first
   server to the client and then from the client to the second server.
   This is particularly useful when the client connects to the network
   using a slow link (e.g., a modem).  While useful, proxy FTP provides
   a security problem known as a "bounce attack" [CERT97:27].  In
   addition to the bounce attack, FTP servers can be used by attackers
   to guess passwords using brute force.

File Transferプロトコル仕様(FTP)[PR85]はクライアントがFTPコントロール接続を確立して、2つのFTPサーバの間にファイルを移すメカニズムを、提供します。 ネットワークでトラフィックの量を減少させるのにこの「プロキシFTP」メカニズムを使用できます。 クライアントは、最初のサーバからクライアントまでそして、クライアントから2番目のサーバまでファイルを移すよりむしろ別のサーバにファイルを移すよう1つのサーバに命令します。クライアントが遅いリンク(例えば、モデム)を使用することでネットワークに接続するとき、これは特に役に立ちます。 役に立ちますが、プロキシFTPは「バウンス攻撃」[CERT97: 27]として知られている警備上の問題を提供します。 バウンス攻撃に加えて、攻撃者は、馬鹿力を使用することでパスワードを推測するのにFTPサーバを使用できます。

Allman & Ostermann           Informational                      [Page 1]

RFC 2577              FTP Security Considerations               May 1999

[1ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   This document does not contain a discussion of FTP when used in
   conjunction with strong security protocols, such as IP Security.
   These security concerns should be documented, however they are out of
   the scope of this document.

強いセキュリティプロトコルに関連して使用される場合、このドキュメントはFTPの議論を含んでいません、IP Securityなどのように。 これらの安全上の配慮は記録されるべきであり、しかしながら、彼らはこのドキュメントの範囲の外にいます。

   This paper provides information for FTP server implementers and
   system administrators, as follows.  Section 2 describes the FTP
   "bounce attack".  Section 3 provides suggestions for minimizing the
   bounce attack.  Section 4 provides suggestions for servers which
   limit access based on network address.  Section 5 provides
   recommendations for limiting brute force "password guessing" by
   clients.  Next, section 6 provides a brief discussion of mechanisms
   to improve privacy.  Section 7 provides a mechanism to prevent user
   identity guessing.  Section 8 discusses the practice of port
   stealing.  Finally, section 9 provides an overview of other FTP
   security issues related to software bugs rather than protocol issues.

この紙はFTPサーバimplementersと以下のシステム管理者に情報を供給します。 セクション2はFTP「バウンス攻撃」について説明します。 セクション3はバウンス攻撃を最小にするための提案を提供します。 セクション4は限界アクセスがネットワーク・アドレスに基礎づけたサーバのための提案を提供します。 セクション5はクライアントで力任せの「パスワード推測」を制限するための推薦を提供します。 次に、セクション6は、プライバシーを改良するためにメカニズムの簡潔な議論を提供します。 セクション7は、ユーザアイデンティティ推測を防ぐためにメカニズムを提供します。 セクション8はポートが横取りする習慣について論じます。 最終的に、セクション9はプロトコル問題よりむしろソフトウェアのバグに関連する他のFTP安全保障問題の概要を提供します。

2   The Bounce Attack

2 バウンス攻撃

   The version of FTP specified in the standard [PR85] provides a method
   for attacking well known network servers, while making the
   perpetrators difficult to track down.  The attack involves sending an
   FTP "PORT" command to an FTP server containing the network address
   and the port number of the machine and service being attacked.  At
   this point, the original client can instruct the FTP server to send a
   file to the service being attacked.  Such a file would contain
   commands relevant to the service being attacked (SMTP, NNTP, etc.).
   Instructing a third party to connect to the service, rather than
   connecting directly, makes tracking down the perpetrator difficult
   and can circumvent network-address-based access restrictions.

規格[PR85]で指定されたFTPのバージョンは加害者を捜し出すのを難しくしている間、よく知られているネットワークサーバを攻撃するためのメソッドを提供します。 攻撃は、攻撃されるマシンの、そして、サービスのネットワーク・アドレスとポートナンバーを含むFTPサーバにFTP「移植」コマンドを送ることを伴います。 ここに、オリジナルのクライアントは、攻撃されるサービスにファイルを送るようFTPサーバに命令できます。 そのようなファイルは攻撃されるサービス(SMTP、NNTPなど)に関連しているコマンドを含んでいるでしょう。 直接接続するよりむしろサービスに接続するよう第三者に命令するのが、加害者を捜し出すのを難しくして、ネットワークアドレスベースのアクセス制限を回避できます。

   As an example, a client uploads a file containing SMTP commands to an
   FTP server.  Then, using an appropriate PORT command, the client
   instructs the server to open a connection to a third machine's SMTP
   port.  Finally, the client instructs the server to transfer the
   uploaded file containing SMTP commands to the third machine.  This
   may allow the client to forge mail on the third machine without
   making a direct connection.  This makes it difficult to track
   attackers.

例として、クライアントはFTPサーバにSMTPコマンドを含むファイルをアップロードします。次に、適切なPORTコマンドを使用して、クライアントは、3番目のマシンのSMTPポートに接続を開くようサーバに命令します。 最終的に、クライアントは、3番目のマシンにSMTPコマンドを含むアップロードされたファイルを移すようサーバに命令します。 これで、ダイレクト接続を作らないで、クライアントは3番目のマシンにメールを偽造できるかもしれません。 これで、攻撃者を追跡するのは難しくなります。

3   Protecting Against the Bounce Attack

3 バウンス攻撃から守ること。

   The original FTP specification [PR85] assumes that data connections
   will be made using the Transmission Control Protocol (TCP) [Pos81].
   TCP port numbers in the range 0 - 1023 are reserved for well known
   services such as mail, network news and FTP control connections
   [RP94].  The FTP specification makes no restrictions on the TCP port
   number used for the data connection.  Therefore, using proxy FTP,

当初のFTP仕様[PR85]は、データ接続が通信制御プロトコル(TCP)[Pos81]を使用することで作られると仮定します。 範囲0--1023のTCPポートナンバーはメールや、ネットニュースやFTPコントロール接続[RP94]などのよく知られているサービスのために予約されます。 FTP仕様はデータ接続に使用されるTCPポートナンバーで制限を全くしません。 したがって、プロキシFTPを使用すること。

Allman & Ostermann           Informational                      [Page 2]

RFC 2577              FTP Security Considerations               May 1999

[2ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   clients have the ability to tell the server to attack a well known
   service on any machine.

クライアントには、どんなマシンの上でもよく知られているサービスを攻撃するようにサーバに言う能力があります。

   To avoid such bounce attacks, it is suggested that servers not open
   data connections to TCP ports less than 1024.  If a server receives a
   PORT command containing a TCP port number less than 1024, the
   suggested response is 504 (defined as "Command not implemented for
   that parameter" by [PR85]).  Note that this still leaves non-well
   known servers (those running on ports greater than 1023) vulnerable
   to bounce attacks.

そのようなバウンス攻撃を避けるために、サーバが1024未満のTCPポートにデータ接続を開かないことが提案されます。 サーバが1024未満のTCPポートナンバーを含むPORTコマンドを受け取るなら、提案された応答は504([PR85]によって「そのパラメタのために実装されなかったコマンド」と定義される)です。 これがまだ、非よく知られているサーバ(1023以上のポートで走るもの)をバウンス攻撃に被害を受け易い状態でおいていることに注意してください。

   Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism
   that would allow data connections to be made using a transport
   protocol other than TCP.  Similar precautions should be taken to
   protect well known services when using these protocols.

いくつかの提案(例えば、[AOM98]と[Pis94])がデータ接続がTCP以外のトランスポート・プロトコルを使用することで利かせるメカニズムを提供します。 同様の注意は、これらのプロトコルを使用するとき、よく知られているサービスを保護するために払われるべきです。

   Also note that the bounce attack generally requires that a
   perpetrator be able to upload a file to an FTP server and later
   download it to the service being attacked.  Using proper file
   protections will prevent this behavior.  However, attackers can also
   attack services by sending random data from a remote FTP server which
   may cause problems for some services.

また、一般に、バウンス攻撃が、加害者がFTPサーバにファイルをアップロードして、後で攻撃されるサービスにそれをダウンロードできるのを必要とすることに注意してください。 適切なファイル保護を使用すると、この振舞いは防がれるでしょう。 しかしながら、また、攻撃者は、いくつかのサービスのために問題を起こすかもしれないリモートFTPサーバから無作為のデータを送ることによって、サービスを攻撃できます。

   Disabling the PORT command is also an option for protecting against
   the bounce attack.  Most file transfers can be made using only the
   PASV command [Bel94].  The disadvantage of disabling the PORT command
   is that one loses the ability to use proxy FTP, but proxy FTP may not
   be necessary in a particular environment.

また、PORTがコマンドであると無効にするのは、バウンス攻撃から守るためのオプションです。 PASVコマンド[Bel94]だけを使用することでほとんどのファイル転送をすることができます。 PORTがコマンドであると無効にする不都合は1つがプロキシFTPを使用する能力を失うということですが、プロキシFTPは特定の環境で必要でないかもしれません。

4   Restricted Access

4 制限されたアクセス

   For some FTP servers, it is desirable to restrict access based on
   network address.  For example, a server might want to restrict access
   to certain files from certain places (e.g., a certain file should not
   be transferred out of an organization).  In such a situation, the
   server should confirm that the network address of the remote hosts on
   both the control connection and the data connection are within the
   organization before sending a restricted file.  By checking both
   connections, a server is protected against the case when the control
   connection is established with a trusted host and the data connection
   is not.  Likewise, the client should verify the IP address of the
   remote host after accepting a connection on a port opened in listen
   mode to verify that the connection was made by the expected server.

いくつかのFTPサーバに、ネットワーク・アドレスに基づくアクセスを制限するのは望ましいです。 例えば、サーバはある一定の場所からのあるファイルへのアクセスを制限したがっているかもしれません(組織から例えばあるファイルを移すべきではありません)。 そのような状況で、サーバは、制限されたファイルを送る前に、組織の中にコントロール接続とデータ接続の両方のリモートホストのネットワーク・アドレスがあると確認するべきです。 両方の接続をチェックすることによって、コントロール接続が信じられたホストと共に確立されるとき、サーバはケースに対して保護されて、データ接続は保護されません。 同様に、ポートにおける接続が開いた受諾が接続が予想されたサーバによって作られたことを確かめるためにモードを聴いた後にクライアントはリモートホストのIPアドレスについて確かめるべきです。

   Note that restricting access based on network address leaves the FTP
   server vulnerable to "spoof" attacks.  In a spoof attack, for
   example, an attacking machine could assume the host address of
   another machine inside an organization and download files that are

アクセスを制限すると攻撃を「偽造する」ために被害を受け易いFTPサーバがネットワーク・アドレス葉に基づいたことに注意してください。 パロディー攻撃では、例えば、攻撃マシンは、組織の中で別のマシンのホスト・アドレスを仮定して、ファイルをダウンロードするかもしれません。

Allman & Ostermann           Informational                      [Page 3]

RFC 2577              FTP Security Considerations               May 1999

[3ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   not accessible from outside the organization.  Whenever possible,
   secure authentication mechanisms should be used, such as those
   outlined in [HL97].

組織によって、アクセスしやすくはありません。 可能で、安全な認証機構が[HL97]に概説されたものなどのように使用されるべきであるときはいつも。

5   Protecting Passwords

5 パスワードを保護すること。

   To minimize the risk of brute force password guessing through the FTP
   server, it is suggested that servers limit the number of attempts
   that can be made at sending a correct password.  After a small number
   of attempts (3-5), the server should close the control connection
   with the client.  Before closing the control connection the server
   must send a return code of 421 ("Service not available, closing
   control connection." [PR85]) to the client.  In addition, it is
   suggested that the server impose a 5 second delay before replying to
   an invalid "PASS" command to diminish the efficiency of a brute force
   attack.  If available, mechanisms already provided by the target
   operating system should be used to implement the above suggestions.

FTPサーバを通した力任せのパスワード推測の危険を最小にするために、サーバが正しいパスワードを送るようにすることができる試みの数を制限することが提案されます。 少ない数の試み(3-5)の後に、サーバはクライアントとのコントロール接続を終えるべきです。 コントロール接続を終える前に、サーバは421(. 「利用可能でないサービス、閉鎖は接続を監督する」[PR85])の復帰コードをクライアントに送らなければなりません。 さらに、サーバがブルートフォースアタックの効率を減少させる無効の「通過」コマンドに答える前に5 2番目の遅れを課すことが提案されます。 利用可能であるなら、目標オペレーティングシステムで既に提供されたメカニズムは、上の提案を実装するのに使用されるべきです。

   An intruder can subvert the above mechanisms by establishing
   multiple, parallel control connections to a server.  To combat the
   use of multiple concurrent connections, the server could either limit
   the total number of control connections possible or attempt to detect
   suspicious activity across sessions and refuse further connections
   from the site.  However, both of these mechanisms open the door to
   "denial of service" attacks, in which an attacker purposely initiates
   the attack to disable access by a valid user.

侵入者は、複数の、そして、平行なコントロール接続をサーバに確立することによって、上のメカニズムを打倒できます。複数の同時接続の使用と戦うために、サーバは、コントロール接続の可能な総数を制限するか、またはセッションの向こう側に不審な行動を検出して、サイトからさらなる接続を拒否するのを試みるかもしれません。 しかしながら、これらのメカニズムの両方が「サービスの否定」攻撃を可能にします。(そこでは、攻撃者が、正規ユーザーによるアクセスを無効にするためにわざわざ攻撃を開始します)。

   Standard FTP [PR85] sends passwords in clear text using the "PASS"
   command.  It is suggested that FTP clients and servers use alternate
   authentication mechanisms that are not subject to eavesdropping (such
   as the mechanisms being developed by the IETF Common Authentication
   Technology Working Group [HL97]).

標準のFTP[PR85]は、「通過」コマンドを使用することでクリアテキストのパスワードを送ります。 FTPクライアントとサーバが盗聴(IETF Common Authentication Technology作業部会[HL97]によって開発されるメカニズムなどの)を受けることがない代替の認証機構を使用することが提案されます。

6   Privacy

6 プライバシー

   All data and control information (including passwords) is sent across
   the network in unencrypted form by standard FTP [PR85].  To guarantee
   the privacy of the information FTP transmits, a strong encryption
   scheme should be used whenever possible.  One such mechanism is
   defined in [HL97].

(パスワードを含んでいます)が非暗号化されるところのネットワークの向こう側に送られるすべてのデータと制御情報は標準のFTP[PR85]によって形成されます。 情報FTPのプライバシーが伝わるのを保証するために、可能であるときはいつも、強い暗号化体系は使用されるべきです。 そのようなメカニズムの1つは[HL97]で定義されます。

7   Protecting Usernames

7 ユーザ名を保護すること。

   Standard FTP [PR85] specifies a 530 response to the USER command when
   the username is rejected.  If the username is valid and a password is
   required FTP returns a 331 response instead.  In order to prevent a
   malicious client from determining valid usernames on a server, it is
   suggested that a server always return 331 to the USER command and

ユーザ名が拒絶されるとき、標準のFTP[PR85]はUSERコマンドへの530応答を指定します。 ユーザ名が有効であり、パスワードが必要であるなら、FTPは代わりに331応答を返します。 そして悪意があるクライアントがサーバに関する有効なユーザ名を決定するのを防ぐためにサーバがいつもUSERコマンドに331を返すことが提案される。

Allman & Ostermann           Informational                      [Page 4]

RFC 2577              FTP Security Considerations               May 1999

[4ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   then reject the combination of username and password for an invalid
   username.

そして、無効のユーザ名のためにユーザ名とパスワードの組み合わせを拒絶してください。

8   Port Stealing

8 ポート横取り

   Many operating systems assign dynamic port numbers in increasing
   order.  By making a legitimate transfer, an attacker can observe the
   current port number allocated by the server and "guess" the next one
   that will be used.  The attacker can make a connection to this port,
   thus denying another legitimate client the ability to make a
   transfer.  Alternatively, the attacker can steal a file meant for a
   legitimate user.  In addition, an attacker can insert a forged file
   into a data stream thought to come from an authenticated client.
   This problem can be mitigated by making FTP clients and servers use
   random local port numbers for data connections, either by requesting
   random ports from the operating system or using system dependent
   mechanisms.

多くのオペレーティングシステムがオーダーを増強する際にダイナミックなポートナンバーを割り当てます。 正統の振替えるのをすることによって、攻撃者は、サーバによって割り当てられた現在のポートナンバーを観測して、使用される次のものを「推測できます」。 攻撃者はこのポートに接続を作って、その結果、振替えるのをする能力を別の正統のクライアントに対して否定できます。 あるいはまた、攻撃者は正統のユーザのために作られていたファイルを横取りできます。 さらに、攻撃者は認証されたクライアントから来ると考えられたデータ・ストリームの中に偽造ファイルを挿入できます。 FTPクライアントとサーバにデータ接続に無作為の地方のポートナンバーを使用させることによって、この問題を緩和できます、オペレーティングシステムから無作為のポートを要求するか、またはシステム依存性機序を使用することによって。

9   Software-Base Security Problems

9 ソフトウェア基盤警備上の問題

   The emphasis in this document is on protocol-related security issues.
   There are a number of documented FTP security-related problems that
   are due to poor implementation as well.  Although the details of
   these types of problems are beyond the scope of this document, it
   should be pointed out that the following FTP features has been abused
   in the past and should be treated with great care by future
   implementers:

強調がプロトコル関連の安全保障問題に本書ではあります。 また、貧しい実装のためである多くの記録されたFTPセキュリティ関連の問題があります。 これらのタイプの問題の詳細はこのドキュメントの範囲を超えていますが、以下のFTP機能が将来のimplementersによって過去に乱用されて、細心の注意を払って扱われるはずであると指摘されるべきです:

   Anonymous FTP

アノニマス・エフテーピー

      Anonymous FTP refers to the ability of a client to connect to an
      FTP server with minimal authentication and gain access to public
      files.  Security problems arise when such a user can read all
      files on the system or can create files. [CERT92:09] [CERT93:06]

アノニマス・エフテーピーはクライアントが最小量の認証でFTPサーバに接続して、公共のファイルへのアクセスを得る能力について言及します。 そのようなユーザがシステムのすべてのファイルを読むことができるか、またはファイルを作成できるとき、警備上の問題は起こります。 [CERT92: 09][CERT93: 06]

   Remote Command Execution

リモートコマンド実行

      An optional FTP extension, "SITE EXEC", allows clients to execute
      arbitrary commands on the server.  This feature should obviously
      be implemented with great care.  There are several documented
      cases of the FTP "SITE EXEC" command being used to subvert server
      security [CERT94:08] [CERT95:16]

「サイト幹部」という任意のFTP拡大でクライアントはサーバで任意のコマンドを実行できます。この特徴は明らかに細心の注意を払って実装されるべきです。 サーバセキュリティ[CERT94: 08]を打倒するのに使用されるFTP「サイト幹部」コマンドの数個の記録されたケースがあります。[CERT95: 16]

   Debug Code

コードをデバッグしてください。

      Several previous security compromises related to FTP can be
      attributed to software that was installed with debugging features
      enabled [CERT88:01].

FTPに関連する前のいくつかのセキュリティ感染はデバッグ機能が可能にされている状態でインストールされたソフトウェア[CERT88: 01]の結果と考えることができます。

Allman & Ostermann           Informational                      [Page 5]

RFC 2577              FTP Security Considerations               May 1999

[5ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   This document recommends that implementors of FTP servers with these
   capabilities review all of the CERT advisories for attacks on these
   or similar mechanisms before releasing their software.

このドキュメントは、それらのソフトウェアを発表する前にこれらの能力があるFTPサーバの作成者がこれらに対する攻撃か同様のメカニズムのためにCERT勧告のすべてを見直すことを勧めます。

10  Conclusion

10結論

   Using the above suggestions can decrease the security problems
   associated with FTP servers without eliminating functionality.

上の提案を使用するのは機能性を排除しないでFTPサーバに関連している警備上の問題を減少させることができます。

11  Security Considerations

11 セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

Acknowledgments

承認

   We would like to thank Alex Belits, Jim Bound, William Curtin, Robert
   Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful
   comments on this paper.  Also, we thank the FTPEXT WG members who
   gave many useful suggestions at the Memphis IETF meeting.

この紙で彼らの役に立つコメントについてアレックスBelits、ジムBound、ウィリアム・カーティン、ロバートElz、ポール・ヘスマン、アラン・ジョーンズ、およびスティーブンTihorに感謝申し上げます。 また、私たちはメンフィスのIETFミーティングで多くの役に立つ提案を与えたFTPEXT WGメンバーに感謝します。

References

参照

   [AOM98]     Allman, M., Ostermann, S. and C. Metz, "FTP Extensions
               for IPv6 and NATs", RFC 2428, September 1998.

[AOM98] オールマンとM.とオステルマンとS.とC.メス、「IPv6とNATsのためのFTP拡大」、RFC2428、1998年9月。

   [Bel94]     Bellovin. S., "Firewall-Friendly FTP", RFC 1579, February
               1994.

[Bel94]Bellovin。 S.、「ファイアウォールに優しいFTP」、RFC1579、1994年2月。

   [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December,
               1988 ftp://info.cert.org/pub/cert_advisories/

[CERT88: 01]CERT勧告カリフォルニア-88: 01ftpd Vulnerability。 1988年12月の ftp://info.cert.org/pub/cert_advisories/

   [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability.
               April 27, 1992. ftp://info.cert.org/pub/cert_advisories/

[CERT92: 09]CERT勧告カリフォルニア-92: 09。 AIXアノニマス・エフテーピー脆弱性。 1992年4月27日 ftp://info.cert.org/pub/cert_advisories/

   [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability.
               September 19,1997
               ftp://info.cert.org/pub/cert_advisories/

[CERT93: 06]CERT勧告カリフォルニア-93: 06。 Wuarchive ftpd Vulnerability。 1997年9月19日 ftp://info.cert.org/pub/cert_advisories/

   [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September
               23, 1997.  ftp://info.cert.org/pub/cert_advisories/

[CERT94: 08]CERT勧告カリフォルニア-94: 08ftpd Vulnerabilities。 1997年9月23日 ftp://info.cert.org/pub/cert_advisories/

   [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration
               Vulnerability.  September 23, 1997
               ftp://info.cert.org/pub/cert_advisories/

[CERT95: 16]CERT勧告カリフォルニア-95: 16wu-ftpd Misconfiguration Vulnerability。 1997年9月23日 ftp://info.cert.org/pub/cert_advisories/

   [CERT97:27] CERT Advisory CA-97.27. FTP Bounce.  January 8, 1998.
               ftp://info.cert.org/pub/cert_advisories/

[CERT97: 27]CERT勧告カリフォルニア-97.27。 FTP弾み。 1998年1月8日 ftp://info.cert.org/pub/cert_advisories/

Allman & Ostermann           Informational                      [Page 6]

RFC 2577              FTP Security Considerations               May 1999

[6ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

   [HL97]      Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
               2228, October 1997.

[HL97] ホロビッツとM.とS.ラント、「FTPセキュリティ拡大」、RFC2228、1997年10月。

   [Pis94]     Piscitello, D., "FTP Operation Over Big Address Records
               (FOOBAR), RFC 1639, June 1994.

[Pis94] Piscitello、D.、「大きいアドレス記録(FOOBAR)の上のFTP操作、RFC1639、1994年6月。」

   [Pos81]     Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

[Pos81] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [PR85]      Postel, J. and J. Reynolds, "File Transfer Protocol
               (FTP)", STD 9, RFC 959, October 1985.

[PR85] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。

   [RP94]      Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
               RFC 1700, October 1994.  See also:
               http://www.iana.org/numbers.html

[RP94] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html

Authors' Addresses

作者のアドレス

   Mark Allman
   NASA Glenn Research Center/Sterling Software
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135

マークオールマンNASAグレンリサーチセンタ/英貨のソフトウェア21000Brookpark通り MS54-2クリーブランド、OH 44135

   EMail: mallman@grc.nasa.gov

メール: mallman@grc.nasa.gov

   Shawn Ostermann
   School of Electrical Engineering and Computer Science
   Ohio University
   416 Morton Hall
   Athens, OH  45701

電気工学のショーンオステルマン学校とHallアテネ、コンピュータサイエンスオハイオ大学416モートンOH 45701

   EMail: ostermann@cs.ohiou.edu

メール: ostermann@cs.ohiou.edu

Allman & Ostermann           Informational                      [Page 7]

RFC 2577              FTP Security Considerations               May 1999

[7ページ]RFC2577FTPセキュリティ問題1999年5月の情報のオールマンとオステルマン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Allman & Ostermann           Informational                      [Page 8]

オールマンとオステルマンInformationalです。[8ページ]