パッシブFTPがデータ接続を反転させた理由

要約

FTPは制御とデータを別接続にした。クライアントが制御接続を始める一方、通常のアクティブ方式ではサーバーがクライアント指定のデータポートへ接続した。
パケットフィルターには、その折り返しが予測不能なポートへの新規着信に見えた。RFC 1579はPASVを勧め、サーバーを待受側、クライアントをデータ接続の開始側にした。
RFC 2428のEPSVは制御接続の相手アドレスを再利用し、返答をポートだけに絞った。だが方向は本人性ではない。FTP bounceとパッシブポートの先取りには別のローカル防御が必要だった。

RFC 959のFTPでは、命令と応答は制御接続を通り、ディレクトリ一覧やファイル本体は別のデータ接続を通る。制御セッションを保ったまま、転送ごとにデータ側を開閉できる構造である。

ここには開始権の非対称があった。制御はクライアントからサーバーへ開く。データは通常、クライアント側が待ち受け、サーバー側のDTPが接続を開始する。PORTを使えば、クライアントは別のホストとポートを指定できた。二台のサーバーを制御して、データを直接渡させる三者転送も設計上の機能だった。

つまり、制御の相手とデータの宛先が同一とは限らない。座標を伝える能力と、その座標を誰が使う権利を持つかは、最初から別問題だった。

RFC 1579が出た1994年には、転送ごとに新しいポートを選んでPORTで通知するクライアントが一般的だった。クライアントを守るフィルターには、外部サーバーが不定の高位ポートへ新規TCP接続を始めるように見える。

FTP自身はログイン済みセッションのデータ路だと知っている。しかし単純なフィルターはその文脈を持たない。多数の着信ポートを常時許せば境界の意味が薄れ、フィルターにFTPの状態機械を背負わせれば中間装置が複雑になる。

衝突したのは二つのローカル規則だった。FTPはクライアントに折り返し先を決めさせる。ファイアウォールは保護領域から始まる新規接続だけを通しやすくする。どちらも単独では理解できるが、組み合わせると転送できない。

PASVはRFC 959に既に存在した。サーバーDTPは非標準のデータポートで待ち受け、その位置を返し、クライアントからの接続を待つ。二本目もクライアント側から始まるため、境界の規則と噛み合う。

RFC 1579は、ファイアウォールの有無にかかわらずクライアントをPASV中心にするよう勧告した。データ形式も二接続構造も変えていない。当時のクライアントはもともと転送前にPORTを送っていたため、必ずしも交換回数が増えたわけでもない。

未対応サーバーはエラーを返し、クライアントは許される環境ならアクティブへ戻れた。古い実装を宣言で排除せず、動く組み合わせが徐々に変わったのである。全転送をパッシブにするAPSV案も触れられたが、既知の実装はなかった。文書の提案と運用上の現実は同じではない。

従来のPORTとPASVはIPv4アドレスとポートを制御メッセージ内に埋め込んだ。IPv6には形式が足りず、NATでは載荷中のアドレスと実際の通信相手が食い違う。変換装置がFTPを解釈し、アプリケーションデータまで書き換える理由になった。

RFC 2428はEPRTとEPSVを定義した。EPRTはアドレスファミリー、ネットワークアドレス、ポートを運び、拡張されたアクティブ方式を保つ。EPSVの返答は待受TCPポートだけで、ネットワーク方式と相手アドレスは制御接続と同じものを使う。

同じ二台の間で転送するなら、どのサーバーかは既に制御接続が実証している。アドレスをもう一度文字列で主張させる必要はない。新しい事実である一時ポートだけを共有すればよい。

EPSV ALLを受け入れたサーバーは、そのセッションでEPRT、PORT、PASVなどを拒否する。後から三者転送が必要になれば新しいFTPセッションを作る。選択は明確だが、その効力は一つのセッションに局在している。

RFC 2577が記録したbounce attackでは、攻撃者がPORTに第三者の機械とサービスを指定し、FTPサーバーにそこへデータを送らせる。接続元をFTPサーバーに見せ、アドレス制限を迂回できる場合があった。

対策には、1024未満のTCPポートへのアクティブ接続を拒む、不要ならPORTを無効にする、ネットワーク位置に基づくアクセスでは制御とデータ双方の相手アドレスを確かめる、といったものがある。

パッシブ側では待受ポートの先取りが起きる。順番に割り当てられるポートを攻撃者が予測して先に接続すれば、正規転送を妨害し、ファイルを盗み、または偽データを注入できる。RFC 2577はローカルデータポートのランダム化を勧めた。

外向きに始まった接続だから安全なのではない。最初に一時ポートへ到着したプロセスが、制御接続で認証された主体だとも限らない。方向は到達性の条件であり、資格証明ではない。

共有部分は、待受を依頼し必要な座標を渡すところまでだった。クライアントがモードを選び、サーバーがポートと許可対象を選び、境界装置が方向規則を選び、両端が二接続を一つのセキュリティ文脈へ結びつける。

そのため導入は段階的に進められた。アクティブが必要な場所は残り、パッシブが必要な境界では切り替わる。EPSVは通常の二者間を薄くし、EPRTは例外能力を残す。互換性は実装と接続結果が示し、中央の承認が生成するものではなかった。

二接続、PORT、PASVはRFC 959、ファイアウォール分析はRFC 1579、IPv6/NAT向け拡張はRFC 2428、bounceとポート先取りはRFC 2577に基づく。

これらは現在の普及率を測らず、あらゆる実装、NAT、プロキシ、ファイアウォールの挙動を保証しない。パッシブFTPが安全になったという証拠でもない。確認できるのは、サーバーからの折り返しが新しい境界と衝突したとき、二本目の開始者を替える小さな拡張が既存の構造を生かした、という歴史である。