English

ファイアウォールと親和性のある FTP
（Firewall-Friendly FTP）

このメモの位置づけ

本書は、インターネットコミュニティのための情報提供を目的としたものであり、いかなるインターネット標準をも定義するものではありません。本書の配布に制限はありません。

要旨

このメモには、FTPクライアントプログラムの機能に対する変更を提案したものが書かれています。プロトコルの修正は必要ありませんが、何点か有益なヒントなるものをまとめました。

総論と理論 English

FTP プロトコル [1] は、実際のファイル転送時に 2番目のTCP接続を使用します。デフォルトでは、この接続は FTP サーバーから FTP クライアントへのアクティブオープンな接続要求によって確立されます。しかし、この仕様は、通常 、ランダムなポート番号への内向きの接続を許可しないパケットフィルタリングファイアウォールとは、うまく協調しません。

一方で、クライアントが PASV コマンドを使用する場合、データチャネルは、ファイアウォールを通して外向きの接続要求になります。このような接続要求は操作が簡単で、問題も最小限に押えられます。

詳細 English

FTP の仕様によると、全てのデータ転送は、デフォルトでは 1つの接続で完了する必要があります。サーバーの 20番ポートからクライアントの制御用ポートと同じポートに対してアクティブな接続が行われ、クライアントはその接続を受け入れます。

善し悪しは別として、今日使われている多くの FTP クライアントはそのような動作をしません。それぞれの転送毎に、新たな接続を確立します。クライアントは TCP の TIMEWAIT 状態による接続拒否を防ぐために、接続ごとに新たなポートを割り当てて、サーバーにその番号を知らせる PORT コマンドを送信します。

このどちらのシナリオにも属さないのが、ファイアウォールフレンドリーです。パケットフィルタが使用される場合（例えば、最近の殆どのルーターがそうであるように）、データチャネルのは、任意のポートに対する内向きの接続要求を SMTP のような安全と思われるポートだけに通過させます。通常問題となるのは、これがいわゆる“Server"エリア(例： ポート番号が 1024 以下のもの)のみをブロックしているということです。しかし、この方法は、X Window のような危険なサービスが上位のポート番号で提供されているので、少々危険を伴います。

一方で、外向けの要求は、ファイアウォール管理者にとっても、パケットフィルタにとっても、それ程問題にはなりません。ACK ビットセットが立っている TCP パケットは TCP 接続を開始するパケットにはなり得ません。フィルタはそのような接続開始要求パケットを外向けのみに通過するよう設定しています。よって、データチャネルの接続要求を受け入れるために、任意のポートを割り当て、クライアントにそのポート番号を知らせます。 そして、クライアントはそのポートに対し、接続要求を出して、コネクションを確立することができます。

幸い、必要なメカニズムは既に、このプロトコルの中に存在しています。クライアントが PASV コマンドを送信した場合、サーバーは、ランダムなポートをパッシブオープンし、クライアントにそのポート番号を通知します。クライアントは、それからコネクションを確立するためにアクティブオープンします。

PASV コマンドをサポートしていない FTP サーバーは、数限られています。この方法が残念ながら RFC 1123 [2] の STD3 に反してしまうとはいえ、大きな問題とはなりえません。この機能が実装されていない環境では"500 Commando not understood"というメッセージが返されます。このような PASV モードをサポートしていないサイトに対して、ファイアウォールを通して接続することは難しいでしょう。

推奨事項 English

ベンダーには、（ Gopher [3] デーモンのような FTP プロキシを含む)FTP クライアントにおいて、PORT の代わりに PASV を使用することを推奨します。ファイアウォールを介さない転送で PASV を利用しても特に問題はありません。むしろ、利用することにより、ファイアウォール環境におけるクライアントの親和性も高まります。

RFC 1123 の STD 3 では、PASV コマンドへの応答形式が曖昧だと注意されています。そこで、FTP クライアントとサーバーは問題解決のために、この RFC の推奨事項に従うとよいでしょう。

検討 English

今日使われている多く FTP クライアントでは、PASV を使用しても新たなメッセージを送信することはありません。あらゆるケースにおいて、転送操作の初めに、クライアントとサーバ ー間でメッセージの交換が行われます。 また、その交換が PORT コマンドか、PASV コマンドであるかは大して重要にはなりません。

Gopher スタイルのクライアントでは、コントロールチャネルの接続ごとに１つのファイル転送ができるので、PORT コマンドを必要としません。この点を懸念するなら、Gopher プロキシをファイアウォールの外側に設置する必要があります。そうすれば、パケットフィルタ制限でパケットがひっかかることもありません。

クライアント側から常に接続を開始するようにすれば、全体的に余計なメッセージの交換を省くことができ、FTP プロトコルの転送効果を高めることができるかもしれません。手始めとして、クライアントは、新しいコマンドである APSV ("all passive)を送信し、このオプションを実装しているサーバーは常に受動的なオープンを行います。新たな応答コードである 151 は、PORT や PASV ではない全てのファイル転送リクエストに対して発行されます。このメッセージには転送に使用されるポート番号が含まれます。PORT コマンドは前もって APSV を受信したサーバーに送られます。すると、サーバーは次に続くデフォルトの転送機能を無効にします。そして、第 3 者による転送を許可します。

実装状況 English

この機能を実装するために、修正されたクライアントは、少なくとも 2種類存在します。ひとつは、ソースコードがフリーで提供されていますが、知る限りでは、APSV は実装されていません。

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

パケットフィルタは、正しい設定が困難なため、セキュリティホールになりやすいと考える人がいます。確かにその通りとも言えますが、実際には、多くのサイトで使用されています。それ以外にも、外向きの接続を簡単に許してしまうため、ファイアウォールを通して機密データが自由にエクスポートできてしまうことを危惧する人もいます。これを防ぐために、いくつかのファイアウォール においては、帯域幅に制限を設けているものもあります。このアプローチのメリットを論議することは、ここでは控えますが、このような帯域制限を加えるためにはアプリケーションレベルのゲートウェイが必要です。また、そうすることにより、PASV を PORT と同様に容易に扱うことができます。

PASV の使用は、外部の人間が実際の FTP クライアント以前に接続するポートを作成する必要がないので、ゲートウェイマシンのセキュリティを高めます。また、より重要な点は、クライアントホストとファイアウォール間のプロトコルが簡素化されることです。

PASV の使用においての問題点は、この使用によって新たな問題が生まれる可能性があるということです。それは、FTP サーバーがランダムポートへの接続要求を許可しなければならないということで あり、ファイアウォールが同様な問題を抱えることになりかねません。しかし、これらを特に深刻な問題とは受け止めていません。

まず、その理由として、FTP サーバー数はクライアントより圧倒的に少ないからです。重要な役割を持つサーバー（ゲートウェイや構造化された FTP のこと）の数が少ない分、それだけセキュリティ対策をこれ以上複雑にすることはないでしょう。ファイアウォールのフィルタは、これらのマシンだけにアクセスを許可する設定をすれば よいのです。また、他の解決策として、FTP サーバーを修正して、データチャネルが頻繁に使用されるものだけを許可することができます。攻撃されやすいサービスの提供は限られたポート内だけで使用するという確認は、簡単にできます。また、上記のように、これはサーバーの数が限られているからこそ実行可能でもあるのです。

参考文献

[1]	Postel, J., and J. Reynolds, "File Transfer Protocol", STD 1, RFC 959, USC/Information Sciences Institute, 1985年10月.
[2]	Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, 1989年10月.
[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, 1993年 3月.

著者のアドレス

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

電話： (908) 582-5886
EMail： smb＠research.att.com

翻訳者のアドレス

宮川寧夫
情報処理振興事業協会
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

著作権表記全文

Copyright (C) The Internet Society (1994). 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.