Kie finiĝas la VPN-protektado survoje al FTP-servilo

VPN protektas vojon, kaj vojo havas finon. Kiam la tunelo finiĝas ĉe entreprena enirejo, la dosiera transigo daŭras de tie sub la protekto, kiun donas ĝia propra protokolo. Tiu distingo decidas, ĉu transigo estas protektita de unu fino ĝis la alia aŭ nur ĝis la enirejo. La indikilo Connected diras nenion pri iu el la du.

Du lokigoj, du restantaj vojoj

Prenu tekkomputilon, kiu aliĝas al entreprena VPN kaj poste malfermas FTP-sesion al aparta interna servilo. La tunelo haltas ĉe la enirejo, kaj la sekcio de la enirejo ĝis tiu servilo restas ekster ĝi.

Simpla FTP ne akiras ĉifradon nur ĉar ĝiaj pakaĵoj alvenis tra tunelo. Sur tiu restanta sekcio la komandoj, la legitimiloj kaj la dosiera enhavo vojaĝas precize tiel, kiel la protokolo difinas, do malkaŝe. Ĉu tio gravas dependas de la topologio kaj de tio, kio alie gardas la sekcion, kaj nomi la adreson privata ne respondas la demandon. La sama rezonado validas inverse, kiam la servilo troviĝas en nuba reto, kiun la enirejo atingas per plia salto.

Metu la VPN-finpunkton kaj la FTP-servon sur unu maŝinon, kaj ne restas plua sekcio pri kiu zorgi. Tio estas alia lokigo, ne pruvo, ke la procezoj, dosieroj kaj legitimiloj de la gastiganto estas sekuraj.

Simpla FTP, FTPS kaj SFTP estas tri decidoj

Simpla FTP ĉifras nenion, eĉ ne la pasvorton. FTPS aldonas TLS al FTP, do la stirkanalo kaj, kiam oni interkonsentas, la datuma kanalo estas protektitaj. SFTP estas alia protokolo portata ene de SSH, kaj ĝi ne estas alia literumo de FTPS.

La servilo devas subteni tiun elekton, ĉar kliento ne povas elpensi aŭskultanton, kiu ne ekzistas. Elekti SFTP ne transformas servon nur-FTP en SSH-finpunkton, kaj renomi legosignon aŭ ŝanĝi pordon pruvas nenion pri tio, kio estis interkonsentita. Konfirmu la protokolon kaj de la flanko de la servilo kaj de la flanko de la kliento. Seruro en dosieradministrilo estas aserto pri la sesio, ne pri la aŭskultanto malantaŭ ĝi.

Legu la lastan kolumnon, kiam la transigo gravas, ĉar tie aperas neatendita ŝanĝo de identeco.

La datuma konekto estas dua konekto

FTP malfermas stirkanalon kaj poste apartajn datumajn konektojn por listoj kaj transigoj. Protektita ensaluto diras nenion pri tiuj postaj konektoj, se la deplojo ne postulas protekton ankaŭ por ili.

Ĉe FTPS la kliento petas protektitan datuman kanalon per specifa komando, kaj servila politiko povas rifuzi la malkaŝan alternativon. Kontrolu, ke la politiko tion postulas, anstataŭ supozi, ke la apriora agordo de la kliento sufiĉas. Pasiva reĝimo aldonas duan komplikaĵon, ĉar la servilo anoncas adreson kaj pordon por la datuma konekto. Fajroŝirmilo aŭ NAT-aparato, kiu reskribas aŭ blokas tiun anoncon, produktas sesion, kiu aŭtentikigas kaj poste pendas ĉe la unua listo.

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'

La dua komando montras, kion la servilo prezentas en la stirkanalo antaŭ ol oni tuŝas ajnan dosieron. La tria montras, ĉu datuma konekto iam estis starigita, kio estas la diferenco inter aŭtentikiga malsukceso kaj pasiva-reĝima malsukceso.

Identecaj kontroloj postvivas la tunelon

FTPS-kliento kontrolas la identecon de TLS-servilo, kaj SFTP-kliento kontrolas SSH-gastigan ŝlosilon. Ambaŭ kontroloj apartenas al la dosiera transiga protokolo, kaj neniun el ili faras la VPN.

Tiu apartigo gravas, kiam io en la mezo volas inspekti la sesion. Malŝalti TLS, por ke reta aparato povu legi la komandojn, ŝanĝas la protektan modelon anstataŭ kompletigi ĝin, kaj same validas akcepti neklarigitan gastigan ŝlosilon ĉar la tunelo ekfunkciis. Konservu la celitan fidan agordon kaj akiru la ĝustan materialon de la operatoro. Tunelo, kiu aŭtentikigas, diras nenion pri la servilo ĉe sia malproksima fino.

Materialo de privata ŝlosilo kaj atestilo por tiuj protokoloj estas ankoraŭ tria sekreto, aparta de la VPN-legitimilo.

Notu, kion vi efektive kontrolis

Elektu sendanĝeran dosieron, kiun vi rajtas movi, kaj notu kvar faktojn pri la provo: kiu protokolo funkciis, kiu identeco de la kontraŭparto estis kontrolita, kiu vojo estis intencita, kaj ĉu la transigo finiĝis.

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

Dosieruja listo, tunela ensaluto kaj finita transigo estas tri apartaj observoj, kaj nur la lasta diras, ke la vojo funkcias por dosieroj. Se la dezajno fidas nur la VPN por konfidenceco sur la restanta salto, skribu tion kiel la decidon, kiu ĝi estas. Akcepta noto, kiu nomas la salton kaj ĝian fidon-supozon, valoras pli ol ekrankopio de konektita kliento.