Wo der VPN-Schutz auf dem Weg zu einem FTP-Server endet
Ein VPN deckt den Weg bis zu seinem Gateway ab, nicht den Abschnitt dahinter. Unterscheiden Sie reines FTP, FTPS und SFTP und prüfen Sie dann den Datenkanal und die Identität der Gegenstelle.
Ein VPN schützt einen Weg, und ein Weg hat ein Ende. Endet der Tunnel an einem Unternehmens-Gateway, setzt sich die Dateiübertragung von dort aus mit dem Schutz fort, den ihr eigenes Protokoll bietet. Diese Unterscheidung entscheidet, ob eine Übertragung durchgehend geschützt ist oder nur bis zum Gateway. Die Anzeige Connected sagt über beides nichts aus.
Zwei Platzierungen, zwei verbleibende Wege
Nehmen Sie ein Notebook, das sich mit einem Unternehmens-VPN verbindet und dann eine FTP-Sitzung zu einem separaten internen Server öffnet. Der Tunnel endet am Gateway, und der Abschnitt vom Gateway zu diesem Server liegt außerhalb davon.
Reines FTP erhält keine Verschlüsselung, nur weil seine Pakete durch einen Tunnel angekommen sind. Auf dem verbleibenden Abschnitt reisen die Befehle, die Anmeldedaten und der Dateiinhalt genau so, wie das Protokoll es definiert, also im Klartext. Ob das eine Rolle spielt, hängt von der Topologie und davon ab, was den Abschnitt sonst noch schützt, und eine Adresse privat zu nennen beantwortet die Frage nicht. Dieselbe Überlegung gilt umgekehrt, wenn der Server in einem Cloud-Netzwerk liegt, das das Gateway über einen weiteren Sprung erreicht.
Setzen Sie den VPN-Endpunkt und den FTP-Dienst auf eine Maschine, und es gibt keinen weiteren Abschnitt, um den man sich sorgen müsste. Das ist eine andere Platzierung und kein Beweis dafür, dass die Prozesse, Dateien und Anmeldedaten des Hosts sicher sind.
Reines FTP, FTPS und SFTP sind drei Entscheidungen
Reines FTP verschlüsselt nichts, auch nicht das Passwort. FTPS ergänzt TLS um FTP, sodass der Steuerkanal und, wenn ausgehandelt, der Datenkanal geschützt sind. SFTP ist ein anderes Protokoll, das innerhalb von SSH übertragen wird, und keine andere Schreibweise für FTPS.
Der Server muss die Wahl unterstützen, denn ein Client kann keinen Listener herbeizaubern, der nicht da ist. SFTP auszuwählen macht aus einem reinen FTP-Dienst keinen SSH-Endpunkt, und ein Lesezeichen umzubenennen oder einen Port zu ändern beweist nichts über das Ausgehandelte. Bestätigen Sie das Protokoll sowohl auf der Serverseite als auch auf der Clientseite. Ein Schloss in einem Dateimanager ist eine Aussage über die Sitzung, nicht über den Listener dahinter.
| Protocol | Usual port | What it protects | Identity check |
|---|---|---|---|
| FTP | 21 | Nothing on the wire | None beyond the login |
| FTPS | 21 or 990 | Control channel, data channel when required | TLS server certificate |
| SFTP | 22 | The whole session inside SSH | SSH host key |
Lesen Sie die letzte Spalte, wenn die Übertragung wichtig ist, denn dort zeigt sich eine unerwartete Identitätsänderung.
Die Datenverbindung ist eine zweite Verbindung
FTP öffnet eine Steuerverbindung und dann separate Datenverbindungen für Listen und Übertragungen. Eine geschützte Anmeldung sagt nichts über diese späteren Verbindungen, es sei denn, die Bereitstellung verlangt auch für sie Schutz.
Bei FTPS fordert der Client über einen bestimmten Befehl einen geschützten Datenkanal an, und eine Serverrichtlinie kann die ungeschützte Alternative ablehnen. Prüfen Sie, dass die Richtlinie es verlangt, statt anzunehmen, die Standardeinstellung des Clients genüge. Der passive Modus bringt eine zweite Schwierigkeit mit sich, weil der Server eine Adresse und einen Port für die Datenverbindung bekannt gibt. Eine Firewall oder ein NAT-Gerät, das diese Bekanntgabe umschreibt oder blockiert, erzeugt eine Sitzung, die sich authentifiziert und dann beim ersten Listing hängen bleibt.
curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'Der zweite Befehl zeigt, was der Server auf dem Steuerkanal präsentiert, bevor eine Datei berührt wird. Der dritte zeigt, ob überhaupt eine Datenverbindung aufgebaut wurde, was der Unterschied zwischen einem Authentifizierungsfehler und einem Fehler im passiven Modus ist.
Identitätsprüfungen überleben den Tunnel
Ein FTPS-Client validiert die Identität eines TLS-Servers, und ein SFTP-Client validiert einen SSH-Hostschlüssel. Beide Prüfungen gehören zum Dateiübertragungsprotokoll, und keine davon führt das VPN durch.
Diese Trennung zählt, wenn etwas in der Mitte die Sitzung inspizieren will. TLS abzuschalten, damit ein Netzwerkgerät die Befehle lesen kann, ändert das Schutzmodell, statt es zu vervollständigen, und dasselbe gilt für die Annahme eines unerklärten Hostschlüssels, weil der Tunnel hochkam. Behalten Sie die vorgesehene Vertrauenskonfiguration und holen Sie das richtige Material beim Betreiber. Ein Tunnel, der sich authentifiziert, sagt nichts über den Server an seinem fernen Ende.
Material für privaten Schlüssel und Zertifikat ist für diese Protokolle ein drittes Geheimnis, getrennt von den VPN-Anmeldedaten.
Halten Sie fest, was Sie tatsächlich geprüft haben
Wählen Sie eine harmlose Datei, die Sie bewegen dürfen, und notieren Sie vier Fakten zum Versuch: welches Protokoll lief, welche Identität der Gegenstelle geprüft wurde, welcher Weg beabsichtigt war und ob die Übertragung abgeschlossen wurde.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]Eine Verzeichnisliste, eine Tunnel-Anmeldung und eine abgeschlossene Übertragung sind drei getrennte Beobachtungen, und nur die letzte sagt, dass der Weg für Dateien funktioniert. Wenn das Design für die Vertraulichkeit auf dem verbleibenden Sprung allein auf das VPN setzt, schreiben Sie das als die Entscheidung auf, die es ist. Eine Abnahmenotiz, die den Sprung und seine Vertrauensannahme nennt, ist mehr wert als ein Screenshot eines verbundenen Clients.