ネットワーク WG
Request for Comments: 2577
分類:情報提供

M. Allman
NASA Glenn/Sterling Software
S. Ostermann
Ohio 大学
1999年 5月

English

FTP セキュリティについての考察
(FTP Security Considerations)

このメモの位置づけ

このメモは、インターネットコミュニティに情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布に制限はありません。

著作権表記

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

要旨

FTP (File Transfer Protocol) の仕様には、ネットワークセキュリティを侵害するのに利用することができる数多くの機構が含まれています。FTP 仕様において、クライアントがサーバーに、第三者のマシンにファイルを転送するように命令することができてしまいます。この第三者機構は、プロキシ FTP として知られていますが、よく知られたセキュリティ問題を引き起こします。また、この FTP 仕様ではユーザのパスワードを回数の制限なく入力することもできてしまいます。これによって、ブルートフォース「パスワード推測」攻撃ができてしまいます。本書は、システム管理者や、FTP に関するセキュリティ問題を減らす FTP サーバーを実装している人のための示唆を提供します。

 

1   はじめに English

FTP (File Transfer Protocol)仕様 [PR85] は、クライアントが FTP コントロールコネクションを確立し、ふたつの FTP サーバー間でファイルを転送することができる機構を提供しています。この「プロキシ FTP」機構は、ネットワーク上のトラフィックの量を減らすために利用できます。; クライアントは、ファイルをまず第 1 のサーバーからクライアントに転送してから、クライアントから第 2 のサーバー宛てに転送するのではなく、一方のサーバーに他方のサーバー宛てにファイルを送るように指示します。これは特に、クライアントが遅いリンクを使ってネットワークに接続しているときに有用です。(例: モデム)有用ではありますが、プロキシ FTP は、「バウンス攻撃」 [CERT97:27] として知られているセキュリティ問題をもたらします。「バウンス攻撃」に加えて、FTP サーバーは、攻撃者によってブルートフォース(力ずく)でパスワードを推測するのに使用される可能性があります。

本書には、FTP を IPsec のような強いセキュリティプロトコルと共に使用した場合の議論は含まれていません。このようなセキュリティの論点は、文書化される必要がありますが、それらは本書の範疇外です。

本論文は、FTP サーバー実装者やシステム管理者に次の情報を提供します。第 2 章においては、FTP「「バウンス(bounce)攻撃」を述べます。第 3 章においては、「バウンス(bounce)攻撃」を最小限に食い止めるための示唆を提供します。第 4 章においては、ネットワークアドレスに基づいてアクセスを制限するサーバーのための示唆を提供します。第 5 章においては、クライアントによるブルートフォース「パスワード推測」を制限するための示唆を提供します。次に、第 6 章においては、プライバシーを改善するための機構についての簡潔な検討を提供いたします。第 7 章においては、ユーザ識別の推測を防ぐ機構を提供いたします。第 8 章においては、ポートスティーリング行為を検討します。最後に、第 9 章においては、プロトコルの論点以外の、ソフトウェアバグに関する他の FTP セキュリティの論点の概観を提供します。

 

2   バウンス(Bounce)攻撃 English

[PR85] 標準で規定されたバージョンの FTP は、よく知られたネットワークサーバーを攻撃する方法を提供してしまっていますが、この加害者を捕まえることは困難です。この攻撃は、ネットワークアドレスと攻撃されるマシンとサービスのポート番号を含んだ FTP "PORT" コマンドを FTP サーバーに送ることによります。このとき、起点となるクライアントは、その FTP サーバーに、攻撃されるサービス宛てにファイルを送信するように指示することができます。そのようなファイルは、攻撃されるサービス( SMTP、NNTP 等)に関連するコマンドを含んでいることでしょう。直接に接続するのではなく、第三者に接続するように指示することによって、その加害者を捕まえることを困難にし、ネットワークアドレスに基づくアクセス制限を迂回することができてしまいます。

例えば、あるクライアントが FTP サーバー宛ての SMTP コマンドを含んだファイルをアップロードします。それから、適当な PORT コマンドを使って、そのクライアントはサーバーに、第 3 のマシンの SMTP ポートへのコネクションを開くように指示します。最後にそのクライアントは、そのサーバーに、SMTP コマンドを含んだアップロードされたファイルを、その第 3 のマシンに転送するように指示します。これによって、そのクライアントは、直接接続することなく、第 3 のマシン上でメールを偽造することができてしまいます。これによって攻撃者を捕まえることが困難になります。

 

3   バウンス攻撃に対する防御 English

本来の FTP 仕様 [PR85] では、データコネクションは、TCP(Transmission Control Protocol)[Pos81] を使用して行われると仮定しています。0 から 1023 までの TCP ポート番号は、メール、ネットワークニュース、FTP コントロールコネクション [RP94] のような、よく知られたサービスのために予約されています。FTP 仕様には、データ接続に使用する TCP ポート番号についての制限はありません。それゆえ、プロキシ FTP を使うことによって、クライアントは、そのサーバーに、いかなるマシン上のよく知られたサービスを攻撃するように伝えることができてしまいます。

このような「バウンス攻撃」を避けるためには、サーバーは 1024 より小さい TCP ポートへのデータ コネクションを開かないことが示唆されます。サーバーが 1024 より小さい TCP ポート番号をもった PORT コマンドを受け取った場合には、示唆されるレスポンスは 504 です。( "Command not implemented for that parameter" として [PR85] によって定められています。)このようにしても、( 1023 より大きいポート番号で動作している)よく知られてはいないサーバーがバウンス攻撃に対して脆弱なままとなることを覚えておいてください。

いくつかの提案(例: [AOM98] や [Pis94] )は、TCP 以外のトランスポートプロトコルを使ってデータ コネクションができるようにする機構を提供します。このようなプロトコルを使用する際には、よく知られたサービスを保護するために同様の予防措置をとる必要があります。

この「バウンス攻撃」は、一般に、加害者が FTP サーバーにファイルをアップロードすることができることを要件とし、後でそれを攻撃されるサーバーにダウンロードすることも覚えておいてください。正しいファイル保護機能を使用することによって、この行為を防ぐことができます。しかし攻撃者は、遠隔の FTP サーバーからランダムなデータを送信することによってサービスを攻撃することもでき、これによっていくつかのサービスに問題を引き起こすことがありえます。

PORT コマンドを実行不能にすることもまた、「バウンス攻撃」に対する防御のためのオプションです。大部分のファイル転送は、PASV コマンド [Bel94] を使用するだけでできます。PORT コマンドを実行不能にすることの短所は、プロキシ FTP を使えなくなることですが、プロキシ FTP は、特定の環境においては不要でしょう。

 

4   制限されたアクセス English

FTP サーバーには、ネットワークアドレスに基づいてアクセスを制限することが要求されるものがあります。例えば、あるサーバーが特定の場所からの特定のファイルへのアクセスを制限したいとします。(例: あるファイルは組織体の外部へ転送するしてはならない。)このような状況では、そのサーバーは、制限されたファイルを送信する前に、遠隔ホストのコントロールコネクションとデータコネクションの両方のネットワークアドレスが、組織体の内部であることを検証する必要があります。両方のコネクションをチェックすることによって、サーバーは、コントロールコネクションは信頼できるホストと確立していて、データコネクションはそうでない場合に守られます。同様に、そのクライアントは、そのコネクションが予定されたサーバーによってなされていることを検証するために、リッスンモードで開かれたポートでコネクションを受け入れた後に、遠隔ホストの IP アドレスを検証する必要があります。

ネットワークアドレスに基づいてアクセスを制限することは、FTP サーバーを「スプーフ(spoof:詐称)」攻撃に対して脆弱なままにすることを覚えておいてください。例えば、スプーフ(spoof:詐称)攻撃において攻撃をしかけているマシンは、組織体内部の他のマシンのホストアドレスを装って、組織体の外部からはアクセスすることができないファイルをダウンロードすることができます。可能である限り、[HL97] に記述されているようなセキュアな認証機構を使用する必要があります。

 

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

FTP サーバーによる、ブルートフォース(力ずく)パスワード推測のリスクを最小限にするためには、正しいパスワードを送信する際に入力することができる回数を サーバーが制限することが示唆されます。数回( 3 〜 5 回)の試みの後、そのサーバーは、クライアントとのコントロールコネクションを閉じる必要があります。コントロールコネクションを閉じる前に、そのサーバーは、リターンコード 421 ("Service not available, closing controlconnection" [PR85] )をクライアントに送らなければなりません。さらに、ブルートフォース(力ずく)攻撃を非効率にするために、サーバーが妥当でない "PASS" コマンドに反応する前に 5 秒間の遅れを入れることが示唆されます。可能であれば、上記の示唆を実装するために、標的となる OS(オぺレーティングシステム)によって既に提供されている機構を利用する必要があります。

侵害者は、サーバーに対して複数の平行的なコントロールコネクションを確立することによって、上記の機構を覆すことができます。複数、同時のコネクションの使用に対抗するためには、そのサーバーは、ありうるコントロールコネクションそ総数を制限することも、セッションにおける怪しい行為を検出し、そのサイトからの以降のコネクションを拒絶するようにすることもできます。しかし、これら双方の機構とも、「サービス妨害」攻撃に対してドアを開けてしまいます。これは、攻撃者が意図的に、妥当なユーザによるアクセスを不能にするための攻撃をしかけるものです。

標準 FTP [PR85] は、パスワードを "PASS" コマンドを使ってクリアテキストで送信します。FTP クライアントとサーバーが(IETF CAT: Common Authentication Technology ワーキンググループによって策定中の機構 [HL97] のような)盗聴できない究極の認証機構を使用することが示唆されます。

 

6   プライバシー English

(パスワードを含む)すべてのデータとコントロール情報は、標準 FTP [PR85] に定められている暗号化されていない形式でネットワーク上を送信されます。FTP 転送における情報のプライバシーを保証するためには、可能な限り強い暗号化スキームが使用される必要があります。そのような機構のひとつとして、[HL97] に定められています。

 

7   ユーザ名を保護する English

標準 FTP [PR85] は、ユーザ名が拒絶された場合、530 を USER コマンドに返すことを指定しています。ユーザ名が妥当で、パスワードが要求される場合には FTP は今度は 331 を返します。悪意あるクライアントがサーバー上の妥当なユーザ名を見つけることを防ぐようにするためには、サーバーは常に USER コマンド 331 を返し、不適格なユーザ名についてのユーザ名とパスワードの組み合わせを拒絶することが示唆されます。

 

8   ポートスティーリング English

多くの OS(オペレーティングシステム)は、昇順にダイナミックポート番号を予約します。正規の転送を行うことによって攻撃者は、サーバーによって確保された現在のポート番号を観察し、次に使用されるポート番号を「推測」することができます。その攻撃者は、このポートにコネクションをつくることができるので、他の正規のクライアントが転送できないようにすることができます。あるいは、その攻撃者は、正規のユーザ向けのファイルを盗むことができます。さらに攻撃者は、認証されたクライアントから来たかのように偽りのファイルをデータストリームの中に挿入することができます。この問題は、FTP クライアントとサーバーがデータコネクションのためにランダムなローカルポート番号を使うようにすることによって鎮静化することができます。これは、OS(オペレーティングシステム)からランダムポートをリクエストしても、システム依存の機構を使ってもかまいません。

 

9    ソフトウェアに基づくセキュリティ問題 English

この文書の重点は、プロトコル関連のセキュリティの論点にあります。下手な実装に起因する、文書化された FTP セキュリティ関連の問題点も数多くあります。この種の問題点の詳細はこの文書の範疇外ですが、下記の FTP 機能が、過去、濫用されてきたので、将来の実装者は十分、慎重に取り扱う必要があることを指摘する必要があります:

Anonymous FTP

Anonymous FTP とは、クライアントが FTP サーバーに最小限の認証で接続し、パブリックなファイルへのアクセスを得ることができることをいいます。そのシステム上のすべてのファイルを読むことができたり、もしくは、ファイルを作成することができる場合にセキュリティ問題が起きます。[CERT92:09] [CERT93:06]

遠隔コマンド実行

オプションの FTP 実行である "SITE EXEC" は、クライアントがサーバー上で勝手なコマンドを実行できるようにしてしまいます。この機能は、明らかに非常に注意深く実装される必要があります。いくつか FTP "SITE EXEC" コマンドがサーバーセキュリティを覆すのに使用されたことについての文書化された事例があります。[CERT94:08] [CERT95:16]

デバッグコード

いくつかの以前の FTP に関するセキュリティ侵害は、デバッグ機能を実行可能にしたままインストールされたソフトウェアに原因があるといえます。[CERT88:01]

本書においては、このような機能をもった FTP サーバーの実装者は、自身のソフトウェアをリリースする前に、これら、もしくは同様の機構への攻撃について、すべての CERT アドバイザリを見直すことをお薦めします。

 

10  結論 English

上記の示唆を使うことによって、機能性を奪うことなく FTP サーバーに関連するセキュリティ問題を低減することができます。

 

11  セキュリティについての考慮事項 English

セキュリティの論点が、このメモを通じて検討されています。

 

謝辞

我々は、本論文について有用なコメントをしてくださった Alex Belits 氏、Jim Bound 氏、William Curtin 氏、Robert Elz 氏、Paul Hethmon 氏、Alun Jones 氏、そして Stephen Tihor 氏に感謝します。また、メンフィスで行われた IETF ミーティングで多くの有用な示唆を与えてくださった FTPEXT WG メンバーにも感謝します。

 

参考文献

[AOM98] Allman, M., Ostermann, S. and C. Metz,
"FTP Extensions for IPv6 and NATs",
RFC 2428, 1998年 9月.
 
[Bel94] Bellovin. S.,
「ファイアウォールと親和性のある FTP(Firewall-Friendly FTP)」,
RFC 1579, 1994年 2月.
 
[CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. 1988年 12月.
ftp://info.cert.org/pub/cert_advisories/
 
[CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability. 1992年 4月 27日.
ftp://info.cert.org/pub/cert_advisories/
 
[CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability. 1997年 9月19日.
ftp://info.cert.org/pub/cert_advisories/
 
[CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. 1997年 9月 23日. 
ftp://info.cert.org/pub/cert_advisories/
 
[CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration Vulnerability.  1997年 9月 23日.
ftp://info.cert.org/pub/cert_advisories/
 
[CERT97:27] CERT Advisory CA-97.27. FTP Bounce.  1998年 1月 8日.
ftp://info.cert.org/pub/cert_advisories/
 
[HL97] Horowitz, M. and S. Lunt,
"FTP Security Extensions",
RFC 2228, 1997年10月.
 
[Pis94] Piscitello, D.,
"FTP Operation Over Big Address Records (FOOBAR),
RFC 1639, 1994年 6月.
 
[Pos81] Postel, J.,
"Transmission Control Protocol",
STD 7, RFC 793, 1981年 9月.
 
[PR85] Postel, J. and J. Reynolds,
"File Transfer Protocol (FTP)",
STD 9, RFC 959, 1985年10月.
 
[RP94] Reynolds, J. and J. Postel,
"Assigned Numbers",
STD 2, RFC 1700, 1994年10月. 
次も見よ: http://www.iana.org/numbers.html

 

著者のアドレス

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

EMail: mallman@grc.nasa.gov

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

EMail: ostermann@cs.ohiou.edu

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

Email: miyakawa@ipa.go.jp

 

著作権表記全文

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.

謝辞

RFC 編集者のための資金は現在、Internet Society によって提供されています。