Zusammenfassung

  • FTP trennt Befehle und Dateien. Der Client öffnete die Steuerverbindung, doch im normalen aktiven Muster begann der Server eine zweite Verbindung zu einem vom Client genannten Datenport.
  • Für einen Paketfilter sah dieser Rückruf wie ein neuer Eingang zu einem unvorhersehbaren Port aus. RFC 1579 empfahl PASV: Der Server lauscht, und der Client eröffnet auch die Datenverbindung.
  • EPSV antwortete später nur mit dem Port und übernahm die Peer-Adresse der Steuerverbindung. Das vereinfachte IPv6 und NAT, löste aber nicht die Identitätsfrage hinter Bounce-Angriff und passivem Portdiebstahl.

Zwei Leitungen hinter einer Sitzung

RFC 959 legt Befehle und Antworten auf eine Steuerverbindung, Verzeichnislisten und Dateien auf eine gesonderte Datenverbindung. Letztere kann für jeden Transfer neu entstehen, während die Sitzung weiterläuft.

Die Rollen waren ungleich verteilt. Der Client begann die Steuerung. Für Daten lauschte normalerweise seine Seite, und der Server-DTP stellte die Verbindung her. Mit PORT durfte der Client einen anderen Host und Port nennen. So konnte er sogar zwei Server steuern und die Datei direkt zwischen ihnen bewegen lassen.

Die Koordinate war eine Handlungsanweisung, kein Berechtigungsnachweis. Solange Hosts eingehende Verbindungen einfach akzeptierten, blieb diese Trennung wenig sichtbar.

Am Rand wirkte der Rückruf fremd

RFC 1579 beschrieb 1994 Clients, die für jeden Transfer einen neuen Port wählten. Der Filter vor dem Client sah deshalb einen externen Server, der eine frische TCP-Verbindung zu einer wechselnden hohen Portnummer begann.

Die Anwendung kannte den Zusammenhang mit der Anmeldung; der Paketfilter nicht unbedingt. Alle Ports zu öffnen hätte die Grenze entwertet. Den Filter zum vollständigen FTP-Interpreter zu machen, hätte Protokollzustand in ein Zwischenstück verlagert. FTP und Firewall teilten Initiative unterschiedlich zu und scheiterten erst in der Kombination.

PASV drehte genau diesen Punkt um. Der Server lauscht auf einem nicht standardmäßigen Datenport und meldet ihn. Der Client führt die aktive Öffnung aus. Steuer- und Datenverbindung beginnen nun auf der geschützten Seite. RFC 1579 empfahl diese Nutzung auch ohne Firewall.

Weder wurden beide Kanäle vereinigt noch zusätzliche Dateioperationen erfunden. Weil Clients ohnehin meist PORT sendeten, musste die Zahl der Nachrichten nicht wachsen. Ein alter Server konnte PASV ablehnen; der Client konnte dort zum aktiven Modus zurückkehren, wo das Netz den Rückruf zuließ. Tatsächliche Einführung bestand aus laufenden Defaults und Implementierungen.

Ein vorgeschlagenes APSV für durchgehend passiven Betrieb blieb ohne bekannte Implementierung. Veröffentlichung allein stellte keine Betriebswirklichkeit her.

EPSV ließ die Adresse weg

Klassisches PORT und PASV betteten IPv4-Adresse und Port in den Steuertext ein. Für IPv6 reichte das Format nicht. Bei NAT konnte die eingebettete Adresse zudem von der sichtbaren Verbindung abweichen, sodass der Übersetzer Anwendungsdaten verstehen und verändern musste.

RFC 2428 führte EPRT und EPSV ein. EPRT trägt Adressfamilie, Netzadresse und Port für den aktiven Fall. EPSV liefert nur den TCP-Port; Netzprotokoll und Gegenadresse werden aus der Steuerverbindung übernommen.

Für einen Transfer zwischen denselben Maschinen hatte die laufende Verbindung den Gegenüber bereits bestimmt. Eine zweite textuelle Adresse war nicht nur überflüssig, sondern konnte falsch sein. Die Erweiterung übermittelte nur die neue Tatsache: den vorübergehenden Listener.

Nach akzeptiertem EPSV ALL muss der Server in dieser Sitzung EPRT, PORT, PASV und andere Alternativen zurückweisen. Wird später eine Drei-Parteien-Übertragung benötigt, ist eine neue Sitzung nötig. Die Wahl bleibt stark, aber örtlich begrenzt.

Richtung war keine Identität

RFC 2577 dokumentiert den Bounce-Angriff. Ein Angreifer konnte mit PORT einen fremden Rechner und Dienst angeben und den FTP-Server veranlassen, vorbereitete Daten dorthin zu senden. Das erschwerte die Zuordnung und konnte adressbasierte Sperren umgehen.

Als Gegenmaßnahmen wurden unter anderem das Ablehnen aktiver Ziele unter TCP-Port 1024, das Abschalten von PORT ohne Bedarf an Server-zu-Server-Transfers und die Prüfung beider Peer-Adressen empfohlen.

Im passiven Modus öffnete nun der Server einen flüchtigen Port. Bei vorhersehbarer Vergabe konnte ein Angreifer den nächsten Port erraten und zuerst erscheinen: Transfer blockieren, Datei abfangen oder gefälschte Daten einspeisen. Zufällige lokale Datenports vermindern das Risiko. Zusätzlich muss die Implementierung den Datenpeer mit dem Steuerkontext verbinden.

PASV machte den Weg firewallfreundlich; EPSV machte die Koordinate übersetzungsfreundlich. Weder verschlüsselte noch authentisierte damit den separaten Datenstrom.

Minimale gemeinsame Regeln, lokale Verantwortung

Der Client wählt seine Modusanfrage. Der Server wählt Listener und erlaubte aktive Ziele. Die Firewall behält ihre Richtungsregel. Die Endpunkte prüfen, ob beide Verbindungen zu derselben Operation gehören. Gerade weil das Protokoll diese Entscheidungen nicht an sich zog, konnten aktiver und passiver Betrieb schrittweise koexistieren.

EPSV machte den gewöhnlichen Zwei-Parteien-Fall schlanker; EPRT bewahrte die Ausnahme. Akzeptierte Befehle und zustande gekommene Verbindungen zeigten Kompatibilität. Keine fortdauernde Stelle musste sie verleihen.

Quellen und Grenzen

RFC 959 definiert Verbindungen, PORT und PASV. RFC 1579 analysiert Paketfilter. RFC 2428 spezifiziert die Erweiterungen. RFC 2577 behandelt Bounce und Portdiebstahl.

Die Dokumente messen keine heutige Verbreitung und garantieren kein Verhalten aller Clients, Server, Proxys, NATs oder Firewalls. Passives FTP wird dadurch nicht zu einem sicheren Transport. Belegt ist die engere Geschichte: Eine kleine Umkehr der Initiative erhielt die Architektur an einer neuen Grenze und ließ Vertrauen bei den laufenden Systemen.