ネットワーク 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によって提供されています。