Hvor VPN-beskyttelsen slutter på vejen til en FTP-server

En VPN beskytter en vej, og en vej har en ende. Når tunnelen slutter ved en virksomhedsgateway, fortsætter filoverførslen derfra under den beskyttelse, dens egen protokol giver. Den forskel afgør, om en overførsel er beskyttet fra ende til anden eller kun indtil gatewayen. Indikatoren Connected siger intet om nogen af delene.

To placeringer, to resterende veje

Tag en bærbar computer, der kobler sig på en virksomheds-VPN og derefter åbner en FTP-session til en separat intern server. Tunnelen stopper ved gatewayen, og strækningen fra gatewayen til den server ligger uden for den.

Almindelig FTP får ikke kryptering, fordi pakkerne er ankommet gennem en tunnel. På den resterende strækning rejser kommandoerne, legitimationsoplysningerne og filindholdet præcis som protokollen definerer det, altså i klartekst. Om det betyder noget afhænger af topologien og af, hvad der ellers beskytter strækningen, og at kalde adressen privat besvarer ikke spørgsmålet. Samme ræsonnement gælder omvendt, når serveren ligger i et cloudnetværk, som gatewayen når via endnu et hop.

Sæt VPN-endepunktet og FTP-tjenesten på én maskine, og der er ingen videre strækning at bekymre sig om. Det er en anden placering og ikke et bevis for, at værtens processer, filer og legitimationsoplysninger er sikre.

Almindelig FTP, FTPS og SFTP er tre beslutninger

Almindelig FTP krypterer intet, heller ikke adgangskoden. FTPS tilføjer TLS til FTP, så kontrolkanalen og, når det forhandles, datakanalen er beskyttet. SFTP er en anden protokol båret inde i SSH, og det er ikke en anden stavemåde for FTPS.

Serveren skal understøtte valget, for en klient kan ikke fremtrylle en lytter, der ikke er der. At vælge SFTP gør ikke en FTP-only tjeneste til et SSH-endepunkt, og at omdøbe et bogmærke eller skifte en port beviser intet om, hvad der blev forhandlet. Bekræft protokollen fra serverens side såvel som fra klientens. En hængelås i en filhåndtering er en påstand om sessionen, ikke om lytteren bag den.

Læs den sidste kolonne, når overførslen betyder noget, for det er der, en uventet identitetsændring dukker op.

Dataforbindelsen er en anden forbindelse

FTP åbner en kontrolforbindelse og derefter separate dataforbindelser til lister og overførsler. Et beskyttet login siger intet om disse senere forbindelser, medmindre udrulningen kræver beskyttelse af dem også.

Med FTPS anmoder klienten om en beskyttet datakanal gennem en bestemt kommando, og en serverpolitik kan afvise det klare alternativ. Bekræft, at politikken kræver det, i stedet for at antage, at klientens standard er nok. Passiv tilstand tilføjer en anden vanskelighed, fordi serveren annoncerer en adresse og port til dataforbindelsen. En firewall eller NAT-enhed, der omskriver eller blokerer den annonce, giver en session, der godkender og derefter hænger på den første liste.

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'

Den anden kommando viser, hvad serveren præsenterer på kontrolkanalen, før nogen fil berøres. Den tredje viser, om der nogensinde blev oprettet en dataforbindelse, hvilket er forskellen mellem en godkendelsesfejl og en passiv-tilstand-fejl.

Identitetskontroller overlever tunnelen

En FTPS-klient validerer en TLS-servers identitet, og en SFTP-klient validerer en SSH-værtsnøgle. Begge kontroller hører til filoverførselsprotokollen, og ingen af dem udføres af VPN’en.

Den adskillelse betyder noget, når noget i midten vil inspicere sessionen. At slå TLS fra, så en netværksenhed kan læse kommandoerne, ændrer beskyttelsesmodellen i stedet for at fuldføre den, og det samme gælder accept af en uforklaret værtsnøgle, fordi tunnelen kom op. Behold den tilsigtede tillidskonfiguration, og hent det korrekte materiale hos operatøren. En tunnel, der godkender, siger intet om serveren i dens fjerne ende.

Materiale med privat nøgle og certifikat til disse protokoller er endnu en tredje hemmelighed, adskilt fra VPN-legitimationsoplysningen.

Skriv ned, hvad du faktisk verificerede

Vælg en uskadelig fil, du har tilladelse til at flytte, og notér fire fakta om forsøget: hvilken protokol der kørte, hvilken modpartidentitet der blev kontrolleret, hvilken vej der var tilsigtet, og om overførslen blev færdig.

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

En mappeliste, et tunnel-login og en afsluttet overførsel er tre separate observationer, og kun den sidste siger, at vejen virker til filer. Hvis designet kun stoler på VPN’en for fortrolighed på det resterende hop, så skriv det ned som den beslutning, det er. Et acceptnotat, der navngiver hoppet og dets tillidsantagelse, er mere værd end et skærmbillede af en tilsluttet klient.