Hvor VPN-beskyttelsen slutter på veien til en FTP-server
En VPN dekker veien til gatewayen sin, ikke strekningen etterpå. Skill mellom vanlig FTP, FTPS og SFTP, og verifiser deretter datakanalen og motpartens identitet.
En VPN beskytter en vei, og en vei har en ende. Når tunnelen slutter ved en bedriftsgateway, fortsetter filoverføringen derfra under den beskyttelsen dens egen protokoll gir. Den forskjellen avgjør om en overføring er beskyttet fra ende til annen eller bare frem til gatewayen. Indikatoren Connected sier ingenting om noen av delene.
To plasseringer, to gjenværende veier
Ta en bærbar PC som kobler seg til en bedrifts-VPN og deretter åpner en FTP-økt mot en separat intern server. Tunnelen stopper ved gatewayen, og strekningen fra gatewayen til den serveren ligger utenfor.
Vanlig FTP får ingen kryptering fordi pakkene kom gjennom en tunnel. På den gjenværende strekningen reiser kommandoene, påloggingsdetaljene og filinnholdet nøyaktig slik protokollen definerer, altså i klartekst. Om det betyr noe avhenger av topologien og av hva annet som beskytter strekningen, og å kalle adressen privat besvarer ikke spørsmålet. Samme resonnement gjelder omvendt når serveren ligger i et skynettverk som gatewayen når via ett hopp til.
Sett VPN-endepunktet og FTP-tjenesten på én maskin, og det er ingen videre strekning å bekymre seg for. Det er en annen plassering, ikke et bevis på at vertens prosesser, filer og påloggingsdetaljer er trygge.
Vanlig FTP, FTPS og SFTP er tre beslutninger
Vanlig FTP krypterer ingenting, heller ikke passordet. FTPS legger TLS til FTP, slik at kontrollkanalen og, når det forhandles, datakanalen er beskyttet. SFTP er en annen protokoll båret inne i SSH, og det er ikke en annen stavemåte for FTPS.
Serveren må støtte valget, for en klient kan ikke trylle frem en lytter som ikke finnes. Å velge SFTP gjør ikke en FTP-only tjeneste om til et SSH-endepunkt, og å gi et bokmerke nytt navn eller bytte port beviser ingenting om det som ble forhandlet. Bekreft protokollen fra serversiden så vel som fra klientsiden. En hengelås i en filbehandler er en påstand om økten, ikke om lytteren bak den.
| 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 |
Les den siste kolonnen når overføringen betyr noe, for det er der en uventet identitetsendring dukker opp.
Dataforbindelsen er en andre forbindelse
FTP åpner en kontrollforbindelse og deretter separate dataforbindelser for lister og overføringer. En beskyttet pålogging sier ingenting om disse senere forbindelsene, med mindre utrullingen krever beskyttelse også for dem.
Med FTPS ber klienten om en beskyttet datakanal gjennom en bestemt kommando, og en serverpolicy kan avvise det klare alternativet. Verifiser at policyen krever det i stedet for å anta at klientens standard er nok. Passiv modus legger til en andre vanskelighet, fordi serveren annonserer en adresse og port for dataforbindelsen. En brannmur eller NAT-enhet som skriver om eller blokkerer den annonsen, gir en økt som autentiserer og deretter henger på den første listen.
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 andre kommandoen viser hva serveren presenterer på kontrollkanalen før noen fil berøres. Den tredje viser om det noen gang ble opprettet en dataforbindelse, som er forskjellen mellom en autentiseringsfeil og en feil i passiv modus.
Identitetskontroller overlever tunnelen
En FTPS-klient validerer identiteten til en TLS-server, og en SFTP-klient validerer en SSH-vertsnøkkel. Begge kontrollene hører til filoverføringsprotokollen, og ingen av dem utføres av VPN-en.
Den adskillelsen betyr noe når noe i midten vil inspisere økten. Å slå av TLS slik at en nettverksenhet kan lese kommandoene, endrer beskyttelsesmodellen i stedet for å fullføre den, og det samme gjelder å godta en uforklart vertsnøkkel fordi tunnelen kom opp. Behold den tiltenkte tillitskonfigurasjonen og skaff det riktige materialet fra operatøren. En tunnel som autentiserer sier ingenting om serveren i den fjerne enden.
Materiale for privatnøkkel og sertifikat til disse protokollene er nok en tredje hemmelighet, atskilt fra VPN-påloggingen.
Skriv ned hva du faktisk verifiserte
Velg en uskyldig fil du har tillatelse til å flytte, og noter fire fakta om forsøket: hvilken protokoll som kjørte, hvilken motpartidentitet som ble kontrollert, hvilken vei som var tiltenkt, og om overføringen ble fullført.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]
En mappeliste, en tunnelpålogging og en fullført overføring er tre separate observasjoner, og bare den siste sier at veien fungerer for filer. Hvis designet bare stoler på VPN-en for konfidensialitet på det gjenværende hoppet, skriv det ned som den beslutningen det er. Et akseptnotat som navngir hoppet og tillitsforutsetningen, er verdt mer enn et skjermbilde av en tilkoblet klient.