Es gibt Software, die verschwindet. Und es gibt Software, die sich nur in die Hinterzimmer zurückzieht und dort weiterarbeitet, während die Welt sie längst totgesagt hat.

FTP gehört zur zweiten Sorte.

Über fünfzig Jahre alt, aus den Browsern verbannt, von Sicherheitsfachleuten beargwöhnt. Und trotzdem schiebt es heute Nacht auf Tausenden von Servern Dateien von A nach B. Klaglos. Zuverlässig. Ohne Applaus.

Das File Transfer Protocol (FTP) ist ein Netzwerkprotokoll der Anwendungsschicht, das Dateien zwischen einem Client und einem Server überträgt und verwaltet. Sein Kennzeichen: Es trennt die Steuerung von den Daten in zwei getrennte Verbindungen.

Klingt unscheinbar. Ist aber der Grund, warum FTP bis heute funktioniert und gleichzeitig so viele Firewall-Administratoren in den Wahnsinn treibt.

FTP überträgt Dateien zwischen Client und Server und trennt dabei Steuerbefehle vom eigentlichen Datentransfer.

Woher es kommt, und wofür

FTP wurde in den frühen Tagen des ARPANET gebaut, lange bevor das Web existierte. Die Aufgabe war banal und gewaltig zugleich: Dateien zuverlässig zwischen fremden Rechnern bewegen, ohne dass jemand ein Magnetband durch die Stadt fährt.

In seiner heute gültigen Form steht FTP in RFC 959, verabschiedet 1985. Es sitzt auf der Anwendungsschicht und nutzt darunter TCP, also die Schicht, die sich um verlorene Pakete und richtige Reihenfolge kümmert. Darum muss FTP sich nicht sorgen. Es darf sich aufs Wesentliche konzentrieren: Befehle geben, Dateien schicken.

Eine Sache vorweg, weil sie den ganzen Text grundiert: FTP ohne Zusatzschutz ist unsicher. Nicht ein bisschen. Im Kern. Dazu gleich mehr.

Zwei Türen, eine Mahlzeit: die Architektur

Stellen Sie sich ein gut geführtes Lokal vor.

Vorne steht der Kellner. Er nimmt Ihre Bestellung auf, sagt Ihnen, ob die Küche noch Lachs hat, meldet, wenn es länger dauert. Gesprochen wird viel, getragen wird nichts.

Das Essen kommt durch eine andere Tür. Aus der Küche, über eine eigene Durchreiche, getrennt vom Gespräch am Tisch.

Genau so arbeitet FTP. Zwei TCP-Verbindungen, jede mit ihrer Aufgabe:

• Der Steuerkanal (Control Channel) läuft über Port 21, vom Client zum Server. Hier wandern Befehle und Statuscodes hin und her. Das ist der Kellner: redet, koordiniert, trägt nichts.
• Der Datenkanal (Data Channel) transportiert die eigentlichen Dateien und Verzeichnislisten. In der ursprünglichen Spezifikation nutzt der Server dafür Port 20 oder einen ausgehandelten Port. Das ist die Durchreiche.

Diese Trennung hat einen handfesten Sinn. Während eine große Datei über den Datenkanal kriecht, kann der Steuerkanal längst die nächste Bestellung aufnehmen. Reden und Tragen behindern sich nicht.

Die Sprache am Tresen ist knapp und alt. USER und PASS für die Anmeldung, PWD und CWD fürs Navigieren, LIST, RETR und STOR fürs Auflisten, Holen und Ablegen. Der Server antwortet mit dreistelligen Codes, eine Idee, die HTTP später dankbar übernommen hat. Eine 2xx heißt sinngemäß „passt“, eine 5xx heißt „vergiss es“. Eine Grammatik, die man an einem Nachmittag lernt.

Aktiv oder passiv: Wer klopft bei wem?

Jetzt wird es interessant. Und für viele zum Problem.

Irgendwer muss den Datenkanal aufbauen. Die Frage ist nur: wer klopft an wessen Tür?

Im aktiven Modus sagt der Client dem Server per PORT-Befehl: meine Adresse, mein Port, komm vorbei. Der Server initiiert daraufhin die Verbindung zurück zum Client. Die Küche trägt das Essen ungefragt an den Tisch. Klingt zuvorkommend, scheitert aber regelmäßig: Firewalls und NAT-Router blockieren eingehende Verbindungen von außen. Der Kellner steht vor verschlossener Tür.

Im passiven Modus dreht sich das um. Der Client sendet PASV, der Server öffnet einen Port und teilt mit: hol es dir an Fenster drei ab. Der Client baut die Verbindung selbst auf. Sie holen den Teller an der Durchreiche. Für heutige Netze hinter NAT ist das die verträglichere Variante, und deshalb meist die Voreinstellung.

Für IPv6 und sauberere NAT-Kompatibilität kamen später die erweiterten Befehle EPRT und EPSV dazu, die die IPv4-gebundenen PORT und PASV ablösen.

In Unternehmensumgebungen ist passives FTP fast immer gesetzt. Auch, weil sich über den alten PORT-Befehl sogenannte Bounce-Angriffe basteln lassen, bei denen ein Server dazu gebracht wird, Verbindungen an Dritte zu schicken. Die Azure Firewall etwa aktiviert standardmäßig passives FTP und schaltet den aktiven Modus ab, lässt ihn aber auf Wunsch wieder zu.

Ein Tipp aus der Praxis: Legen Sie für den Passivmodus am Server einen festen, engen Portbereich fest und öffnen Sie genau diesen in der Firewall. Sonst rennen Ihre Datenkanäle in Zeitüberschreitungen, und niemand versteht, warum die Verbindung zwar steht, aber nichts ankommt.

Wie die Daten reisen

FTP kennt verschiedene Arten, Inhalte zu verpacken. Zwei muss man kennen: ASCII für reinen Text, Binary für alles andere. Heute ist Binary der Normalfall, weil es Dateien Byte für Byte unverändert überträgt. Wer ein Bild im ASCII-Modus schickt, bekommt am anderen Ende Datenmüll. Ein klassischer Anfängerfehler, der einen halben Arbeitstag fressen kann.

Daneben gibt es Stream-, Block- und Compressed-Mode für unterschiedliche Transferbedürfnisse sowie ein solides Repertoire zur Dateiverwaltung: Verzeichnisse anlegen und löschen (MKD, RMD), umbenennen (RNFR/RNTO), das System abfragen (SYST). Alles in RFC 959 festgeschrieben, alles von gängigen Servern und Clients breit verstanden.

Was über die Jahre dazukam

FTP ist alt, aber nicht stehengeblieben. Die IETF hat das Protokoll an genau den Stellen nachgeschärft, an denen die Praxis es verlangte:

• RFC 3659 brachte SIZE und MDTM (Dateigröße und Zeitstempel), eine erweiterte REST-Funktion zum Wiederaufsetzen abgebrochener Übertragungen und vor allem MLST/MLSD: maschinenlesbare Verzeichnislisten, die das chaotische, von Server zu Server verschiedene LIST ablösen.
• RFC 2428 definierte EPRT/EPSV für IPv6 und bessere Verträglichkeit in gemischten Netzen.
• RFC 2228 legte die Sicherheits- und Authentifizierungs-Erweiterungen fest, auf denen die spätere TLS-Absicherung aufbaut.
• RFC 4217 beschreibt schließlich FTPS, also FTP über TLS.

Vier Dokumente, eine gemeinsame Absicht: ein Protokoll der frühen Jahre fit halten für eine Welt, die es so nie kommen sah.

Sicherheit: Warum Sie Ihr Passwort nicht durch den Raum brüllen sollten

Hier kommt der Teil, der wehtut.

Klassisches FTP überträgt alles im Klartext. Benutzername, Passwort, die Datei selbst, alles unverschlüsselt über die Leitung. Wer im selben Netz mithört, liest mit. Es ist, als würden Sie im vollen Lokal Ihre Bestellung samt Karten-PIN quer durch den Raum rufen.

Das ist kein theoretisches Risiko, sondern ein altbekanntes. Genau deshalb raten Sicherheitsrichtlinien seit Langem von Klartext-FTP ab.

Es gibt zwei Auswege. Und es lohnt sich, sie nicht zu verwechseln.

FTPS ist FTP mit angezogenem Mantel. Es verschlüsselt Steuer- und Datenkanal per TLS und stützt sich auf die Erweiterungen aus RFC 2228; RFC 4217 beschreibt das Verfahren samt Zertifikatsauthentifizierung. In der Praxis gibt es explizites FTPS (Start im Klartext, dann Upgrade per AUTH TLS) und das historische implizite FTPS auf einem eigenen Port. Beide bleiben im Inneren echtes FTP.

SFTP ist etwas völlig anderes, auch wenn der Name das Gegenteil suggeriert. SFTP ist kein FTP. Es ist ein eigenständiges Protokoll aus der SSH-Familie, läuft typischerweise über Port 22, hat eine eigene Befehlssyntax und ein anderes Verbindungsmodell. Historisch war es ein IETF-Entwurf; inzwischen liegt ein neuer Internet-Draft von 2025 vor, der den lange ruhenden Standardisierungsversuch wieder aufnimmt.

Der Merksatz, den Sie sich tätowieren lassen dürfen:

• FTPS = FTP plus TLS, nach RFC 4217.
• SFTP = eigenes Protokoll über SSH, ganz ohne FTP-Semantik.

Wer beides in einen Topf wirft, konfiguriert irgendwann die falsche Firewall-Regel und sucht den Fehler dann an der falschen Stelle.

Die Browser haben den Stecker gezogen

Eine Weile konnte man ftp:// einfach in die Adresszeile tippen. Diese Zeit ist vorbei.

Firefox hat FTP ab Version 88 standardmäßig abgeschaltet und in Version 90 endgültig entfernt. Chrome ging denselben Weg: erst deaktiviert, dann mit Version 95 den Code komplett herausoperiert. Der Grund ist derselbe wie überall in diesem Text: zu wenig Nutzen, zu viel Klartext-Risiko, auf einem Weg zu einem Web, das nur noch verschlüsselt sprechen will.

Für einfache Downloads übernehmen heute HTTPS oder WebDAV. Wer wirklich FTP braucht, greift zu einem eigenen Client.

Wo FTP heute noch lebt

Totgesagte arbeiten länger. FTP findet man heute vor allem an drei Orten:

• In Altsystemen, die FTP sprechen und sich nicht über Nacht migrieren lassen. Maschinensteuerungen, betagte Schnittstellen, Software, deren Hersteller man nicht mehr erreicht.
• In kontrollierten Netzen, in denen Kompatibilität vorgeht und der Transport anderweitig abgesichert ist, etwa durch einen Tunnel.
• In der Massenverteilung großer Dateien, vereinzelt noch bei Mirror-Servern, wo allerdings längst HTTPS den Ton angibt.

Sobald es etwas zu schützen gibt, führt der Weg zu FTPS oder SFTP. In der Cloud oft auch zu S3 über HTTPS oder zu einer Managed-File-Transfer-Lösung.

Best Practices für den Betrieb

Wenn FTP bleiben muss, dann richtig:

1. Passiv fahren. Setzen Sie EPSV/EPRT ein, definieren Sie einen engen Passiv-Portbereich und öffnen Sie nur diesen. Robuster hinter NAT, schlankeres Regelwerk.
2. Verschlüsselung erzwingen. Kein Klartext-FTP. Für bestehende Workflows FTPS mit soliden Cipher Suites und echter Zertifikatsvalidierung. Wo möglich, langfristig auf SFTP umziehen.
3. Maschinenlesbar auflisten. MLSD/MLST statt LIST, damit Verzeichnisdaten zuverlässig parsebar bleiben.
4. Integrität absichern. Wiederaufsetzen per REST, dazu SIZE und MDTM. Und Prüfsummen auf Anwendungsebene, denn FTP selbst garantiert keine Ende-zu-Ende-Integrität.
5. Den Server härten. Anonyme Logins aus, Server-zu-Server-Transfers (FXP) aus, sofern nicht zwingend gebraucht. Benutzer in ihr Verzeichnis sperren (Chroot), dazu Rate Limits, Logging und ein wachsames Auge auf Bounce-Angriffe.

Fünf Regeln, die nach Bürokratie klingen. In Wahrheit sind es die paar Handgriffe, die zwischen „läuft seit Jahren störungsfrei“ und „warum steht plötzlich alles“ liegen.

Drei Irrtümer, die sich hartnäckig halten

Zum Schluss drei Sätze, die man oft hört und die so nicht stimmen.

„SFTP ist einfach das sichere FTP.“
Nein. SFTP ist kein FTP, sondern ein eigenes Protokoll über SSH. Sicheres FTP im Wortsinn heißt FTPS.

„Für FTP reichen Port 21 und 20.“
Nur halb. Im Passivmodus kommen wechselnde Ephemeral-Ports ins Spiel, die Sie in der Firewall gezielt freigeben müssen. Wer das übersieht, sucht stundenlang am falschen Ende.

„FTP im Browser ist noch Alltag.“
Nicht mehr. Chrome und Firefox haben es ausgebaut. Heute übernimmt ein FTP-Client oder ein Weg über HTTPS.

Was bleibt

FTP ist ein Werkzeug aus einer anderen Zeit. Funktional ausgereift, klar gebaut, mit dieser eleganten Trennung von Reden und Tragen, die HTTP auf seine Art geerbt hat. Was ihm fehlt, ist der Schutzmantel, den die heutige Welt verlangt.

Die ehrliche Frage ist deshalb selten „Wie richte ich FTP ein?“. Sondern: Brauche ich überhaupt noch FTP, oder halte ich nur aus Gewohnheit am alten Lokal fest?

Wird die FTP-Semantik wirklich gebraucht, dann mit TLS, dann als FTPS. Sonst der saubere Umzug auf SFTP oder HTTPS. Und in jedem Fall ein Blick auf die Firewall-Regeln für den Passivmodus, bevor die nächste Übertragung still ins Leere läuft.

Manche Protokolle sterben nicht. Man sollte nur wissen, warum man sie noch am Leben hält.