Kvar VPN-vernet sluttar på vegen til ein FTP-tenar
Ein VPN dekkjer vegen til gatewayen sin, ikkje strekninga etterpå. Skil mellom vanleg FTP, FTPS og SFTP, og stadfest deretter datakanalen og identiteten til motparten.
Eit VPN vernar ein veg, og ein veg har ein ende. Når tunnelen sluttar ved ein bedriftsgateway, held filoverføringa fram derfrå under det vernet som den eigne protokollen gir. Den skilnaden avgjer om ei overføring er verna frå ende til annan eller berre fram til gatewayen. Indikatoren Connected seier ingenting om nokon av delane.
To plasseringar, to attverande vegar
Ta ein berbar PC som koplar seg til eit bedrifts-VPN og deretter opnar ei FTP-økt mot ein separat intern tenar. Tunnelen stoppar ved gatewayen, og strekninga frå gatewayen til den tenaren ligg utanfor.
Vanleg FTP får inga kryptering fordi pakkane kom gjennom ein tunnel. På den attverande strekninga fer kommandoane, påloggingsdetaljane og filinnhaldet nøyaktig slik protokollen definerer, altså i klartekst. Om det spelar noko rolle, kjem an på topologien og på kva anna som vernar strekninga, og å kalle adressa privat svarar ikkje på spørsmålet. Same resonnementet gjeld omvendt når tenaren ligg i eit skynettverk som gatewayen når via eitt hopp til.
Set VPN-endepunktet og FTP-tenesta på éin maskin, og det er inga vidare strekning å uroa seg for. Det er ei anna plassering, ikkje eit prov på at prosessane, filene og påloggingsdetaljane til verten er trygge.
Vanleg FTP, FTPS og SFTP er tre avgjerder
Vanleg FTP krypterer ingenting, heller ikkje passordet. FTPS legg TLS til FTP, slik at kontrollkanalen og, når det vert forhandla, datakanalen er verna. SFTP er ein annan protokoll som vert boren inne i SSH, og det er ikkje ein annan stavemåte for FTPS.
Tenaren må støtte valet, for ein klient kan ikkje trylle fram ein lyttar som ikkje finst. Å velje SFTP gjer ikkje ei teneste med berre FTP om til eit SSH-endepunkt, og å gje eit bokmerke nytt namn eller byte port provar ingenting om det som vart forhandla. Stadfest protokollen frå tenarsida så vel som frå klientsida. Ein hengelås i ein filhandsamar er ein påstand om økta, ikkje om lyttaren bak henne.
| 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øringa betyr noko, for det er der ei uventa identitetsendring dukkar opp.
Dataforbindinga er ei andre forbinning
FTP opnar ei kontrollforbinding og deretter separate dataforbindingar for lister og overføringar. Ei verna pålogging seier ingenting om desse seinare forbinningane, med mindre utrullinga krev vern også for dei.
Med FTPS ber klienten om ein verna datakanal gjennom ein bestemt kommando, og ein tenarpolicy kan avvise det klare alternativet. Stadfest at policyen krev det i staden for å tru at standarden til klienten er nok. Passiv modus legg til ei andre vanske, fordi tenaren annonserer ei adresse og ein port for dataforbindinga. Ein brannmur eller NAT-eining som skriv om eller blokkerer den annonsen, gir ei økt som autentiserer og deretter heng på den første lista.
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 kva tenaren presenterer på kontrollkanalen før noka fil vert rørt. Den tredje viser om det nokon gong vart oppretta ei dataforbinding, som er skilnaden mellom ein autentiseringsfeil og ein feil i passiv modus.
Identitetskontrollar overlever tunnelen
Ein FTPS-klient validerer identiteten til ein TLS-tenar, og ein SFTP-klient validerer ein SSH-vertsnøkkel. Båe kontrollane høyrer til filoverføringsprotokollen, og ingen av dei vert utførte av VPN-et.
Den skilnaden betyr noko når noko i midten vil inspisere økta. Å slå av TLS slik at ei nettverksining kan lese kommandoane, endrar vernemodellen i staden for å fullføre han, og det same gjeld å godta ein uforklart vertsnøkkel fordi tunnelen kom opp. Hald den tiltenkte tillitskonfigurasjonen og skaff det rette materialet frå operatøren. Ein tunnel som autentiserer seier ingenting om tenaren i den fjerne enden.
Materiale for privatnøkkel og sertifikat til desse protokollane er nok ei tredje løyndom, skild frå VPN-pålogginga.
Skriv ned kva du faktisk stadfesta
Vel ei uskuldig fil du har løyve til å flytte, og noter fire fakta om forsøket: kva protokoll som køyrde, kva motpartidentitet som vart kontrollert, kva veg som var tiltenkt, og om overføringa vart fullført.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]
Ei mappeliste, ei tunnelpålogging og ei fullført overføring er tre separate observasjonar, og berre den siste seier at vegen fungerer for filer. Viss designet berre stolar på VPN-et for konfidensialitet på det attverande hoppet, skriv det ned som den avgjerda det er. Eit akseptnotat som namngir hoppet og tillitsføresetnaden, er verdt meir enn eit skjermbilete av ein tilkopla klient.