Summary

  • FTPは制御接続でコマンドをやり取りし、別のデータ接続でファイルを運んだ。
  • RFC 1579は既存のPASVを使って二本目の接続を開始する側を変えた。クライアント側のフィルタは通りやすくなる一方、サーバー側はデータ用の着信ポートを受け入れる必要があった。

FTPでは「このファイルを送って」という指示を出す接続と、ファイルそのものを運ぶ接続が異なり得た。この分離はプロトコルの設計に含まれていた。そのため、ログインに成功し、RETR に肯定応答が返っても、データが届くとは限らない。FTPが選んだ向きに、もう一本のTCP接続を確立する必要があった。

1985年のRFC 959は、コマンドと応答を扱う制御プロセスと、転送を扱うデータプロセスを分けた。一般的な形では、クライアントがまずサーバーの制御ポート、通常は21番へ接続する。転送前に PORT で自分のアドレスと待受ポートを伝え、サーバーがクライアントへデータ接続を開始する。データ用ソケットは制御用とは別なので、前者を許可するファイアウォールが後者も許すとは限らない。

FTPにはもう一つの方法が当初からあった。PASV を受けると、サーバーのデータプロセスが標準以外のポートで待ち受ける。サーバーはアドレスとポートを返し、クライアントがそこへ接続する。二本目の接続は残り、開始する側だけが変わる。したがって、パッシブモードはファイアウォール対策として推奨されるより何年も前にプロトコルに存在していた。

1994年までに、現場の動きは当初の標準動作と異なる場合があった。Steven Bellovin はRFC 1579で、当時のクライアントが転送ごとに新しいデータ接続を開き、TCPのTIME-WAIT待ちを避けるために新しいポートを選び、PORT で知らせていたと説明した。パケットフィルタから見ると、予測できないポートへの着信である。制御接続で認証済みでも、ファイアウォールが一部の着信サービスだけを許可し、この折り返し接続を拒否することがあった。

RFC 1579は、Gopherのプロキシエージェントを含むFTPクライアントに、PORT ではなく PASV を使うよう勧めた。するとデータ接続はクライアント側からの発信になる。利用者側のファイアウォールでは、ランダムなポートに届く未要求の着信を許可するより、発信した接続を通す方が容易だった。メモはワイヤ上のプロトコル変更を求めていない。必要なコマンドはすでに存在し、どちらの方式でも転送前の準備交換は似ていた。

難しい境界を移しただけで、問題をなくしたわけではない。パッシブモードでは、サーバーが転送用に割り当てたポートで着信を受け入れる。RFC 1579は、サーバー側ファイアウォールにも問題が生じ得ると認めている。作者の論拠は運用上の規模だった。サーバーはクライアントより少なく、運用者がデータ用ポート範囲を絞れるという。これは露出をどこで管理するかの提案であって、すべてのサーバーやファイアウォールが採用した証拠ではない。

規範文書を読むと、実装必須の機能と実際の普及を区別できる。1989年公開のRFC 1123はFTPサーバーに PASV の実装を必須とし、応答の解釈方法を補った一方、応答形式が十分に標準化されていないと記した。RFC 1579は少なくとも二つの独立した改変クライアントの存在を報告した。どちらも、モードを変更したユーザーやサイトの割合は示さない。1994年の記録が裏づけるのは勧告と限られた実装であり、全面移行ではない。

FTPには別々の運用面があった。制御接続は認証情報、コマンド、応答を運び、データ接続は一覧やファイルを運ぶ。「データ接続を開く」という応答はファイルそのものではない。認証成功も転送完了の証拠ではない。障害調査では二つのソケットを追い、どちらの端点がそれぞれを開始する設計なのかを確認する必要がある。

RFC 1579の教訓は「ファイアウォールがFTPを壊した」という話より具体的だ。FTPはデータ接続の開始方向を選べた。フィルタリングがその選択を運用上の決定にした。PASVはクライアント側ファイアウォールが許可しやすい側から接続を始められる一方、サーバー運用者には制限された着信ポート範囲の管理を求める。プロトコルは変わらず、運用負担の位置が移った。

Sources