サイト内関連リンク：
RFC 959 FTP (日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc2577.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
サイト内関連リンク：
RFC 959 FTP (日本語訳)
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 (C) The Internet Society (1999). All Rights Reserved.
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. ファイル転送プロトコル(FTP)のための仕様は、ネットワークセキュリティを低下させる可能性のあるメカニズムを数多く含む。FTP 仕様により、クライアントはサーバーに対し第三のマシンにファイルを転送するように指示することができる。この第三者のメカニズム(プロキシ FTP として知られる)は、よく知られているセキュリティ問題を引き起こす。また FTP 仕様は、ユーザーのパスワード入力を無制限に試行することを許可している。これは総当りの "パスワード推測(password guessing)" 攻撃を許す。本文書は、システム管理者と、FTP に関連するセキュリティ問題を下げる FTP サーバーを実装する人々とに向けての提案を提供する。
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. ファイル転送プロトコル仕様(FTP) [PR85] は、クライアントが FTP コントロール接続を確立し、2 台の FTP サーバー間でファイルを転送することを可能にするメカニズムを提供する。この "プロキシ FTP(proxy FTP)" メカニズムは、ネットワーク上のトラフィック量を減らすために使用することができる。クライアントは、ファイルをあるサーバーからクライアントに転送し、次にクライアントから別のサーバーに転送するのではなく、第一のサーバーに対して第二のサーバーにファイルを転送するように指示する。これはクライアントが低速回線(例えばモデム)を使用してネットワークに接続している場合に特に有用である。プロキシ FTP は有用である一方、"バウンス攻撃(bounce attack)" [CERT97:27] として知られるセキュリティ問題をもたらす。バウンス攻撃に加えて、FTP サーバーは攻撃者が総当たりを使用してパスワードを推測するために使用され得る。
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. 本文書は、IP セキュリティなどの強力なセキュリティプロトコルとともに FTP を使用する場合に付いての議論を含まない。これらのセキュリティ配慮は文書化されるべきだが、本文書の範囲外である。
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 サーバーの実装者とシステム管理者とのための情報を次の通り提供する。セクション 2 では FTP の "バウンス攻撃(bounce attack)" を説明する。セクション 3 はバウンス攻撃を最小限に抑えるための提案を提供する。セクション 4 はネットワークアドレスに基づいてアクセスを制限するサーバーの提案を提供する。セクション 5 はクライアントによる総当たり "パスワード推測(password guessing)" を制限するための推奨事項を提供する。セクション 6 はプライバシーを改善するためのメカニズムの簡単な考察を提供する。セクション 7 はユーザーの身元の推測を防ぐためのメカニズムを提供する。セクション 8 はポートスチールの実践を議論する。最後にセクション 9 は、プロトコル問題ではなくソフトウェアバグに関連する FTP のセキュリティ問題の要約を提供する。
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 の "PORT" コマンドを 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 コマンドを使用することで、クライアントはそのサーバーに第三のマシンの SMTP ポートに接続を開くように指示する。最後に、クライアントはそのサーバーに、SMTP コマンドを含むアップロードしたファイルを第三のマシンへと送信するように指示する。これによりクライアントは、第三のマシンに直接接続することなくメールを偽造することができる。
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, clients have the ability to tell the server to attack a well known service on any machine. オリジナルの FTP 仕様 [PR85] は、トランスミッションコントロールプロトコル(TCP)[Pos81] を使用してデータ接続が行われることを想定している。0 ～ 1023 の範囲の TCP ポート番号は、メールやネットワークニュースや FTP のコントロール接続などのよく知られたサービスのために予約されている。FTP 仕様はデータ接続に使用される TCP ポート番号に制限を設けていない。したがって、クライアントはプロキシ FTP を使用することで、任意のマシン上のよく知られたサービスを攻撃するようにサーバーに伝える能力を持つことになる。
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] において "Command not implemented for that parameter" と定義されている)。それでもなお、非ウェルノウンサーバー(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 コマンドを無効化することの短所はプロキシ FTP を使用する能力を失うことだが、特定の環境ではプロキシ FTP が必要でないかもしれない。
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 not accessible from outside the organization. Whenever possible, secure authentication mechanisms should be used, such as those outlined in [HL97]. ネットワークアドレスに基づくアクセス制限を行っても、FTP サーバーは "なりすまし(spoof)" 攻撃に脆弱なままであることに注意してほしい。なりすまし攻撃では、例えば攻撃者のマシンが組織内の別のマシンのホストアドレスを持つふりをし、組織外からアクセス不可能なファイルをダウンロードする可能性がある。可能な場合には常に、[HL97] で概説されているような安全な認証メカニズムを使用するべきである。
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("Service not available, closing control connection." [PR85])を送信しなければならない。さらに総当り攻撃の効率を下げるために、サーバーが無効な "PASS" コマンドに応答する前に 5 秒の遅延を課すことを推奨する。上記の提案を実装するために利用可能であれば、対象のオペレーティングシステムが提供するメカニズムを使用するべきである。
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. 侵入者はサーバーに対して複数並行してコントロール接続を確立することで、上記のメカニズムを覆すことができる。この複数同時接続に対抗するために、サーバーは可能なコントロール接続の総数を制限するか、セッションをまたがって疑わしい活動を検出することを試み、そのサイトからの追加の接続を拒否することができる。しかしながらこれらのメカニズムは同時に、正当なユーザーによるアクセスを不能にするための攻撃を意図的に行う "サービス不能(denial of service)" 攻撃の機会を生む。
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] は "PASS" コマンドを使用して平文でパスワードを送信する。FTP のクライアントとサーバーは、盗聴の影響を受けにくい別の認証メカニズムを使用することを推奨する(例えば IETF Common Authentication Technology Working Group が開発中のメカニズム [HL97])。
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 が送信する情報のプライバシーを保証するために、可能であれば常に強力な暗号化の仕組みを使用するべきである。そのようなメカニズムのひとつが [HL97] で定義されている。
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 then reject the combination of username and password for an invalid username. 標準 FTP [PR85] は USER コマンドでユーザー名が拒否された場合に 530 応答を規定している。ユーザー名が有効、かつパスワードが必須の場合、FTP は代わりに 331 応答を返す。悪意あるクライアントがサーバー上の有効なユーザー名を判断できないように、サーバーは USER コマンドに常に 331 を返し、不正なユーザーのユーザー名とパスワードとの組み合わせを拒否することを推奨する。
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. 多くのオペレーティングシステムは動的なポート番号を昇順に割り当てる。攻撃者は正当な転送を行うことで、サーバーによって割り当てられる最新のポート番号を観測し、次に使用されるであろう値を "推測(guess)" することができる。攻撃者はそのポートに接続し、それにより他の正当なクライアントによる転送を拒否させることができる。あるいは攻撃者は、正当なユーザーに向けられたファイルを盗むこともできる。さらに攻撃者は、認証されたクライアントから来たと思われるデータストリームに偽造ファイルを挿入することもできる。FTP のクライアントとサーバーとがオペレーティングシステムにランダムなポートを要求するかシステム依存のメカニズムを使用することで、この問題を軽減することができる。
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 の機能は過去に悪用されており、将来の実装者は十分な注意を払うべきであることを指摘しておく：
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 アドバイザリを精査することを推奨する。
Using the above suggestions can decrease the security problems associated with FTP servers without eliminating functionality. 上記の提案を使用することで、FTP サーバーに関連するセキュリティ問題を機能を排することなく減らすことができる。
Security issues are discussed throughout this memo. セキュリティ問題は本文書全体にわたって議論されている。
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. 私たちは Alex Belits, Jim Bound, William Curtin, Robert Elz, Paul Hethmon, Alun Jones, Stephen Tihor による本文書への有益なコメントに感謝する。また、Memphis IETF ミーティングで多くの有益な提案を与えてくれた FTPEXT WG のメンバーにも感謝する。
Mark Allman NASA Glenn Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 EMail: [email protected] Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701 EMail: [email protected]
Copyright (C) The Internet Society (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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society. RFC Editor の活動資金は、現在 Internet Society によって提供されている。