Onde remata a protección da VPN camiño dun servidor FTP
Unha VPN cobre o camiño ata a súa pasarela, non o treito posterior. Separe FTP simple, FTPS e SFTP, e despois verifique a canle de datos e a identidade do outro extremo.
Unha VPN protexe un camiño, e todo camiño ten un final. Cando o túnel remata nunha pasarela corporativa, a transferencia de ficheiros continúa desde alí coa protección que ofrece o seu propio protocolo. Esa distinción decide se unha transferencia está protexida de extremo a extremo ou só ata a pasarela. O indicador Connected non di nada sobre ningunha das dúas cousas.
Dous emprazamentos, dous camiños restantes
Colla un portátil que se une á VPN corporativa e despois abre unha sesión FTP cara a un servidor interno separado. O túnel detense na pasarela, e o treito desde a pasarela ata ese servidor queda fóra del.
O FTP simple non adquire cifrado porque os seus paquetes chegasen por un túnel. Nese treito restante, as ordes, as credenciais e o contido dos ficheiros viaxan exactamente como define o protocolo, é dicir, en claro. Se iso importa depende da topoloxía e de que máis protexe o treito, e chamar privada ao enderezo non responde a pregunta. O mesmo razoamento vale á inversa cando o servidor vive nunha rede de nube á que a pasarela chega por outro salto.
Poña o punto final da VPN e o servizo FTP nunha soa máquina e non hai ningún treito posterior que preocupar. Ese é outro emprazamento, non unha proba de que os procesos, os ficheiros e as credenciais do host sexan seguros.
FTP simple, FTPS e SFTP son tres decisións
O FTP simple non cifra nada, nin sequera o contrasinal. FTPS engade TLS a FTP, de xeito que a canle de control e, cando se negocia, a canle de datos quedan protexidas. SFTP é un protocolo distinto transportado dentro de SSH, e non é outra forma de escribir FTPS.
O servidor ten que admitir esa escolla, porque un cliente non pode inventar un escoitador que non está. Escoller SFTP non converte un servizo só FTP nun punto final SSH, e renomear un marcador ou cambiar un porto non demostra nada sobre o que se negociou. Confirme o protocolo tanto desde o lado do servidor como desde o do cliente. O candado dun xestor de ficheiros é unha afirmación sobre a sesión, non sobre o escoitador que hai detrás.
| 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 |
Lea a última columna cando a transferencia importe, porque é onde aparece un cambio de identidade inesperado.
A conexión de datos é unha segunda conexión
FTP abre unha conexión de control e despois conexións de datos separadas para listaxes e transferencias. Un inicio de sesión protexido non di nada sobre esas conexións posteriores, salvo que o despregamento esixa protección tamén para elas.
Con FTPS, o cliente pide unha canle de datos protexida mediante unha orde concreta, e unha política do servidor pode rexeitar a alternativa en claro. Verifique que a política o esixe en lugar de supor que o valor predeterminado do cliente abonda. O modo pasivo engade unha segunda complicación, porque o servidor anuncia un enderezo e un porto para a conexión de datos. Unha devasa ou un dispositivo NAT que reescriba ou bloquee ese anuncio produce unha sesión que se autentica e despois se colga na primeira listaxe.
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'
A segunda orde mostra que presenta o servidor na canle de control antes de tocar ningún ficheiro. A terceira mostra se algunha vez se estableceu unha conexión de datos, que é a diferenza entre un fallo de autenticación e un fallo do modo pasivo.
As comprobacións de identidade sobreviven ao túnel
Un cliente FTPS valida a identidade dun servidor TLS, e un cliente SFTP valida unha chave de host SSH. Ambas as comprobacións pertencen ao protocolo de transferencia de ficheiros, e ningunha a realiza a VPN.
Esa separación importa cando algo no medio quere inspeccionar a sesión. Desactivar TLS para que un dispositivo de rede poida ler as ordes cambia o modelo de protección en lugar de completalo, e o mesmo vale para aceptar unha chave de host sen explicación porque o túnel se levantou. Manteña a configuración de confianza prevista e obteña o material correcto do operador. Un túnel que se autentica non di nada sobre o servidor do seu extremo afastado.
O material de chave privada e certificado para estes protocolos é un terceiro segredo máis, separado da credencial da VPN.
Anote o que verificou realmente
Escolla un ficheiro inofensivo que teña autorización para mover e anote catro feitos sobre o intento: que protocolo se executou, que identidade do outro extremo se comprobou, que camiño se pretendía e se a transferencia rematou.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]
Unha listaxe de directorio, un inicio de sesión no túnel e unha transferencia rematada son tres observacións separadas, e só a última di que o camiño funciona para ficheiros. Se o deseño confía só na VPN para a confidencialidade no salto restante, escriba iso como a decisión que é. Unha nota de aceptación que nomee o salto e a súa suposición de confianza vale máis que unha captura de pantalla dun cliente conectado.