Var VPN-skyddet slutar på vägen till en FTP-server

Ett VPN skyddar en väg, och en väg har ett slut. När tunneln slutar vid en företagsgateway fortsätter filöverföringen därifrån under det skydd som dess eget protokoll erbjuder. Den skillnaden avgör om en överföring är skyddad från ände till ände eller bara fram till gatewayen. Indikatorn Connected säger ingenting om något av dem.

Två placeringar, två återstående vägar

Ta en bärbar dator som ansluter till ett företags-VPN och sedan öppnar en FTP-session mot en separat intern server. Tunneln stannar vid gatewayen, och sträckan från gatewayen till den servern ligger utanför.

Vanlig FTP får ingen kryptering för att paketen kom genom en tunnel. På den återstående sträckan färdas kommandona, inloggningsuppgifterna och filinnehållet exakt som protokollet definierar, det vill säga i klartext. Om det spelar någon roll beror på topologin och på vad annat som skyddar sträckan, och att kalla adressen privat besvarar inte frågan. Samma resonemang gäller omvänt när servern ligger i ett molnnätverk som gatewayen når via ett hopp till.

Sätt VPN-slutpunkten och FTP-tjänsten på en och samma maskin, och det finns ingen ytterligare sträcka att oroa sig för. Det är en annan placering, inte ett bevis på att värdens processer, filer och inloggningsuppgifter är säkra.

Vanlig FTP, FTPS och SFTP är tre beslut

Vanlig FTP krypterar ingenting, inte ens lösenordet. FTPS lägger till TLS på FTP, så kontrollkanalen och, när det förhandlas, datakanalen är skyddade. SFTP är ett annat protokoll som bärs inuti SSH, och det är inte en annan stavning av FTPS.

Servern måste stödja valet, för en klient kan inte trolla fram en lyssnare som inte finns. Att välja SFTP gör inte en FTP-only tjänst till en SSH-slutpunkt, och att byta namn på ett bokmärke eller ändra en port bevisar ingenting om vad som förhandlades. Bekräfta protokollet från serversidan såväl som från klientsidan. Ett hänglås i en filhanterare är ett påstående om sessionen, inte om lyssnaren bakom den.

Läs den sista kolumnen när överföringen spelar roll, för det är där en oväntad identitetsändring dyker upp.

Dataförbindelsen är en andra förbindelse

FTP öppnar en kontrollförbindelse och sedan separata dataförbindelser för listningar och överföringar. En skyddad inloggning säger ingenting om dessa senare förbindelser, om inte utrullningen kräver skydd även för dem.

Med FTPS begär klienten en skyddad datakanal genom ett särskilt kommando, och en serverpolicy kan avvisa det klara alternativet. Verifiera att policyn kräver det i stället för att anta att klientens standardinställning räcker. Passivt läge lägger till en andra komplikation, eftersom servern annonserar en adress och port för dataförbindelsen. En brandvägg eller NAT-enhet som skriver om eller blockerar den annonsen ger en session som autentiserar och sedan hänger på den första listningen.

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'

Det andra kommandot visar vad servern presenterar på kontrollkanalen innan någon fil rörs. Det tredje visar om en dataförbindelse någonsin upprättades, vilket är skillnaden mellan ett autentiseringsfel och ett fel i passivt läge.

Identitetskontroller överlever tunneln

En FTPS-klient validerar identiteten hos en TLS-server, och en SFTP-klient validerar en SSH-värdnyckel. Båda kontrollerna hör till filöverföringsprotokollet, och ingen av dem utförs av VPN:et.

Den åtskillnaden spelar roll när något i mitten vill inspektera sessionen. Att stänga av TLS så att en nätverksenhet kan läsa kommandona ändrar skyddsmodellen i stället för att fullborda den, och detsamma gäller att acceptera en oförklarad värdnyckel för att tunneln kom upp. Behåll den avsedda förtroendekonfigurationen och hämta rätt material från operatören. En tunnel som autentiserar säger ingenting om servern i dess bortre ände.

Material för privat nyckel och certifikat till dessa protokoll är ännu en tredje hemlighet, skild från VPN-inloggningen.

Skriv ned vad du faktiskt verifierade

Välj en ofarlig fil som du har tillstånd att flytta, och notera fyra fakta om försöket: vilket protokoll som kördes, vilken motpartsidentitet som kontrollerades, vilken väg som var avsedd, och om överföringen slutfördes.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

En kataloglista, en inloggning i tunneln och en slutförd överföring är tre separata observationer, och bara den sista säger att vägen fungerar för filer. Om designen bara förlitar sig på VPN:et för konfidentialitet på det återstående hoppet, skriv ned det som det beslut det är. En acceptnotering som namnger hoppet och dess förtroendeantagande är värd mer än en skärmbild av en ansluten klient.