FTP ist ein Legacy-Dateiübertragungsprotokoll, das separate Steuerungs- und Datenkanäle verwendet. Während moderner Web- und API-Traffic durch Token, TLS, Sitzungsrichtlinien und WAAP-Kontrollen geschützt ist, operiert FTP in den meisten Organisationen immer noch auf der Ebene von "Port öffnen, Benutzername und Passwort prüfen." EDI-Workflows, Batch-Übertragungen, Partner-Dateiaustausch, Mainframe-Bridges und Legacy-Dokumentsysteme laufen daher außerhalb der Sicherheitssichtbarkeit.
Traditionelle Netzwerksicherheit bietet zwei schwache Optionen für FTP. Entweder wird Port 21 geöffnet und niemand kann sehen, welche Befehle durchlaufen, oder FTP wird komplett entfernt und ein monatelanger Integrationsprozess beginnt. Viele Legacy-Systeme können diesen Übergang nicht schnell absorbieren.
FTPS allein zu verwenden reicht ebenfalls nicht aus. Traffic kann verschlüsselt sein, aber die Fragen bleiben: Welcher Benutzer führt welchen Befehl aus, welche Datei wird abgerufen oder gesendet, auf welches Backend wird zugegriffen, kommt die Datenverbindung aus der richtigen Quelle und wie lange ist die Sitzung offen.
Das Protokolldesign von FTP schafft eine spezifische Angriffsfläche. Der PORT-Befehl kann Datenverbindungen zu Drittanbieter-Adressen leiten, FXP-ähnliche Server-zu-Server-Übertragungen können missbraucht werden, und schwache anonyme oder geteilte Konten können für längere Zeiträume offen bleiben. Diese Risiken sind auf der Netzwerkebene schwer zu beobachten; Anwendungsebenen-FTP-Sitzungsbewusstsein ist erforderlich.
Die TR7 WAAP FTP-Sicherheits-Proxy-Schicht betreibt klassische FTP-Dienste — ohne sie zu entfernen — unter Befehlswhitelisting, Pro-User-Richtlinie, Bounce/FXP-Mitigation, Sitzungskontrolle und Forensic-Audit.
TR7 WAAP behandelt FTP nicht als Port-Öffnungsentscheidung, sondern als Anwendungssitzung, die pro Benutzer autorisiert und Befehl für Befehl auditiert wird.
FTP-Befehle wie RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE und MDTM werden auf eine individuelle Allow/Deny-Liste gesetzt. Unbekannte Befehle oder Befehle, die nicht in der Richtlinie enthalten sind, werden standardmäßig abgelehnt.
Der FTP-Benutzername kann als Richtlinienschlüssel verwendet werden. Verschiedene Benutzer, die sich über dieselbe VIP verbinden, können mit verschiedenen Befehlssätzen, verschiedenen Timeouts und verschiedenen Backend-Pools betrieben werden.
Die Quelle der Datenverbindung wird mit der Steuerverbindung korreliert. PORT-Versuche, die auf Drittanbieter-Adressen gerichtet sind, oder Server-zu-Server-Übertragungsverhalten werden standardmäßig blockiert; Ausnahmen werden durch eine explizite Richtlinienentscheidung definiert.
Jede Sitzung, jeder Befehl und jede Dateiübertragung wird in das Audit-Protokoll geschrieben. Monitor-Modus macht den vollständigen Dateipfad sichtbar; Filecopy-Modus kann eine zeitgestempelte Kopie jeder übertragenen Datei speichern.
Der FTP-Sicherheits-Proxy bringt die Befehls-, Benutzer-, Datenkanal-, Sitzungs- und Audit-Schwächen des klassischen FTP-Protokolls unter das WAAP-Richtlinienmodell.
TR7 verwaltet Standard-FTP-Befehle als Allow/Deny-Entscheidungen auf Richtlinienebene. In einer Nur-Lese-Rolle bleiben Befehle wie RETR, LIST, NLST, SIZE, MDTM und STAT offen, während STOR, DELE, RMD oder RNTO abgelehnt werden können. In einer Upload-Rolle werden nur STOR und die notwendigen Verzeichnisbefehle erlaubt. Dies stellt sicher, dass "hat FTP-Zugriff" nicht in unbegrenzte Dateiberechtigungen übersetzt wird.
Der Benutzername wird beim Login gelesen und in die WAAP-Richtlinien-Engine eingespeist. Zwei Benutzer, die sich mit derselben VIP verbinden, können mit verschiedenen Befehlssätzen, verschiedenen Sitzungsdauern, verschiedener Audit-Tiefe und verschiedenen Backend-Pools betrieben werden. Diese Architektur konsolidiert Partner-, Abteilungs- oder tenant-basierte Dateiübertragungen an einem einzigen Eingangspunkt. Betriebsteams definieren Sicherheitsgrenzen pro Benutzer.
Ein Benutzer kann zu einem bestimmten Backend-Pool geleitet werden, während ein anderer zu einem anderen Pool geleitet wird. Das Client-seitige `user@server`-Auswahlmuster kann verwendet werden, oder TR7 kann den Benutzer über eine zentrale Tabelle zum entsprechenden Backend auflösen. Dies eliminiert die Notwendigkeit, viele separate VIPs für B2B-Partner-FTP, Abteilungsfreigabe oder Tenant-Trennung zu öffnen. Kontrolliertes Routing geschieht unter einem einzigen Eingangspunkt.
Aktive und passive FTP-Modi verhalten sich unterschiedlich in Bezug auf die Datenverbindung. TR7 korreliert PORT- und PASV-Flüsse mit der Sitzung, um sicherzustellen, dass der Datenkanal korrekt hergestellt wird. Der passive Port-Bereich kann durch Richtlinie eingeschränkt werden; die Quell-IP in Richtung Backend kann fixiert werden. Dies reduziert Übertragungsfehler bei FTP-Diensten hinter NAT und Firewalls.
Bei FTP-Bounce-Angriffen versucht der PORT-Befehl, Datenverbindungen zu einem dritten Ziel umzuleiten. TR7 kann dieses Verhalten ablehnen, indem die Datenverbindung gegen den echten Endpunkt der Steuerverbindung gematcht wird. Server-zu-Server-Übertragungsverhalten ähnlich wie FXP kann standardmäßig deaktiviert bleiben. Erforderliche Ausnahmen werden explizit definiert; eine Sicherheitslücke ist nie das Standardverhalten.
FTP-Sitzungen können nach Quell-IP, Land, ASN, Zeitfenster oder Benutzerinformationen ausgewertet werden. Verbindungen von außerhalb bestimmter Partner-Länder oder Unternehmens-IP-Bereiche können abgelehnt werden. Dies bringt den auf der Web- und API-Seite verwendeten Zugangskontrollansatz auch zu FTP. Legacy-Dateiübertragungsflüsse werden an moderne Zugriffsrichtlinien gebunden.
FTP-Sitzungen können lange offen bleiben und Sockets am Backend verbrauchen. TR7 kann Limits wie Login-Timeout, Idle-Timeout und Gesamtsitzungsdauer auf Richtlinienebene verwalten. Eine Standard-Sitzungsdauer von 900 Sekunden kann als Ausgangspunkt verwendet und bei Bedarf angepasst werden. Idle-Sitzungen werden geschlossen, ohne das Backend warten zu lassen.
FTP-Clients können Verzeichnisse mit CWD wechseln und dann relative Dateibefehle ausgeben. Monitor-Modus verfolgt das Arbeitsverzeichnis innerhalb der Sitzung und protokolliert Befehle wie `RETR file.csv` mit ihrem vollständigen Dateipfad. Der Audit-Eintrag zeigt daher nicht nur den Befehl, sondern den tatsächlichen Dateispeicherort. Die Nachvorfalluntersuchung klärt genau, welche Datei abgerufen oder gesendet wurde.
Für Compliance- oder forensische Anforderungen kann eine Kopie jeder übertragenen Datei in einen separaten Speicherbereich geschrieben werden. Dateien können in einer datumsbasierten Verzeichnisstruktur aufbewahrt und mit dem Audit-Protokoll korreliert werden. Das bedeutet, dass die Frage "Welche Datei wurde gesendet?" nicht nur mit einem Protokolleintrag, sondern mit der Datei selbst beantwortet werden kann. Audit-Beweise werden in regulierten Branchen gestärkt.
Wenn FTPS im Einsatz ist, ist der Steuerkanal verschlüsselt, aber Befehle müssen verstanden werden, um die Sicherheitsrichtlinie anzuwenden. Die TR7 WAAP FTP-Sicherheits-Proxy-Schicht terminiert die FTPS-Sitzung auf der Sicherheitsebene und kann die Befehle inspizieren. Unter AUTH TLS kann die Weiterleitung zum Backend neu verschlüsselt oder an das interne Netzwerkmodell angepasst werden. Zertifikats- und TLS-Richtlinie werden mit dem zentralen Verwaltungspool ausgerichtet.
Der FTP-Sicherheits-Proxy wird zusammen mit Befehlsverarbeitung, Datenverbindungs-Lebenszyklus, HA-Verhalten, Audit-Streaming, Ressourcenlimits und Compliance-Aufbewahrungsrichtlinien betrieben.
Jeder FTP-Befehl wird vom Steuerkanal empfangen, geparst, gegen die ValidCommands-Liste und die Benutzerrichtlinie ausgewertet. Ein erlaubter Befehl wird an das Backend weitergeleitet. Ein abgelehnter Befehl gibt eine protokollkonforme Fehlerantwort (502 oder 550) zurück; der Client bleibt protokollkonform.
Wenn ein PORT- oder PASV-Befehl gesehen wird, assoziiert TR7 die Datenverbindung mit der Sitzung. Separate Datenverbindungen existieren zwischen Client und TR7, und zwischen TR7 und dem Backend. Diese Struktur ermöglicht es, die Sitzung auf kontrollierte Weise zu schließen, wenn eine Richtlinienverletzung während einer Übertragung erkannt wird.
Neue FTP-Sitzungen öffnen sich auf dem aktiven Knoten mit derselben Richtlinie. Laufende große Datenübertragungen können bei einem Failover-Ereignis aufgrund der Natur des Protokolls unterbrochen werden; wenn der Client Resume unterstützt, kann die Übertragung neu gestartet oder fortgesetzt werden. Kritische Übertragungen sollten daher auf das Client-Verhalten vor der Produktionsbereitstellung getestet werden.
Separate Protokolle können auf Sitzungs-, Befehls- und Übertragungsebene produziert werden. Protokolle können im strukturierten Format an den SIEM-Stream gesendet werden. Monitor-Modus fügt den vollständigen Dateipfad der Protokollzeile hinzu; Filecopy-Modus fügt den Speicherort der gespeicherten Dateikopie hinzu.
Gleichzeitige Sitzungsanzahl, Sitzungen pro Benutzer, Sitzungen pro IP, Dateigröße und Übertragungsrate können alle durch Richtlinie eingeschränkt werden. Dies verhindert, dass ein einzelner Benutzer oder ein sich falsch verhaltender Batch-Job die FTP-Infrastruktur erschöpft. Bandbreite und Timeout sollten für große Dateiübertragungen gemeinsam geplant werden.
Der vollständige Pfad, Zeitstempel, Benutzerinformationen und, falls erforderlich, eine Dateikopie jeder übertragenen Datei können aufbewahrt werden. Die Aufbewahrungsdauer wird gemäß der Compliance-Richtlinie der Organisation festgelegt. Während eines Audits ist FTP-Traffic kein dunkler Bereich mehr.
Ein Finanzinstitut oder eine Behörde tauscht möglicherweise EDI-Dateien mit Partnern über FTP aus. TR7 leitet jeden Partner hinter einer einzigen VIP zu seinem eigenen Backend-Pool, öffnet nur die erlaubten Befehle und stellt jede Übertragung unter Audit.
Wenn eine Legacy-Dokumentenplattform nur FTP-Upload unterstützt, kann TR7 davor platziert werden, ohne das System zu berühren. Die Richtlinie öffnet nur STOR und die notwendigen Verzeichnisbefehle, während Lösch- und Umbenennungsbefehle abgelehnt werden.
Bei Integrationen, die Dateien von einem Mainframe-System abrufen, kann der Benutzer auf Nur-Lese-Befehle wie RETR, LIST und SIZE beschränkt werden. STOR, DELE, RNFR, RNTO, MKD und RMD werden abgelehnt, was das Risiko der Datenmodifikation reduziert.
Wenn ein Gesundheits- oder Forschungsteam Datensätze an externe Partner sendet, kann jede Übertragung mit Filecopy aufbewahrt werden. Dateigrößen-Limits, Pro-User-Richtlinie und SIEM-Log-Streaming machen den Freigabeprozess von Anfang bis Ende prüfbar.
Befehlswhitelisting, Pro-User-Richtlinie, Bounce/FXP-Schutz und Forensic-Audit. Lassen Sie uns ein Live-Setup auf Ihrer eigenen FTP-Infrastruktur durchgehen.