Onde termina a proteção da VPN no caminho para um servidor FTP

Uma VPN protege um caminho, e todo caminho tem um fim. Quando o túnel termina num gateway corporativo, a transferência de ficheiros continua a partir dali sob a proteção que o seu próprio protocolo oferece. Essa distinção decide se uma transferência está protegida de ponta a ponta ou apenas até ao gateway. O indicador Connected não diz nada sobre nenhuma das duas.

Duas colocações, dois caminhos restantes

Pegue num portátil que se junta à VPN corporativa e depois abre uma sessão FTP para um servidor interno separado. O túnel pára no gateway, e o trecho do gateway até esse servidor fica fora dele.

O FTP simples não ganha criptografia por os seus pacotes terem chegado por um túnel. Nesse trecho restante, os comandos, as credenciais e o conteúdo dos ficheiros viajam exatamente como o protocolo define, ou seja, em claro. Se isso importa depende da topologia e do que mais protege o trecho, e chamar privado ao endereço não responde à pergunta. O mesmo raciocínio vale ao contrário quando o servidor está numa rede de nuvem que o gateway alcança por outro salto.

Coloque o ponto final da VPN e o serviço FTP numa só máquina e não há nenhum trecho seguinte com que se preocupar. Essa é outra colocação, não uma prova de que os processos, os ficheiros e as credenciais do anfitrião estão seguros.

FTP simples, FTPS e SFTP são três decisões

O FTP simples não cifra nada, nem a palavra-passe. O FTPS acrescenta TLS ao FTP, pelo que o canal de controlo e, quando negociado, o canal de dados ficam protegidos. O SFTP é um protocolo diferente transportado dentro do SSH, e não é outra grafia de FTPS.

O servidor tem de suportar essa escolha, porque um cliente não pode inventar um ouvinte que não existe. Escolher SFTP não transforma um serviço só FTP num ponto final SSH, e renomear um marcador ou mudar uma porta não prova nada sobre o que foi negociado. Confirme o protocolo tanto do lado do servidor como do lado do cliente. O cadeado de um gestor de ficheiros é uma afirmação sobre a sessão, não sobre o ouvinte por detrás.

Leia a última coluna quando a transferência importar, porque é aí que aparece uma mudança de identidade inesperada.

A ligação de dados é uma segunda ligação

O FTP abre uma ligação de controlo e depois ligações de dados separadas para listagens e transferências. Um início de sessão protegido não diz nada sobre essas ligações posteriores, a menos que a implementação exija proteção também para elas.

Com FTPS, o cliente pede um canal de dados protegido através de um comando específico, e uma política do servidor pode recusar a alternativa em claro. Verifique que a política o exige em vez de assumir que o valor predefinido do cliente basta. O modo passivo acrescenta uma segunda complicação, porque o servidor anuncia um endereço e uma porta para a ligação de dados. Uma firewall ou um dispositivo NAT que reescreva ou bloqueie esse anúncio produz uma sessão que se autentica e depois fica pendurada na primeira listagem.

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'

O segundo comando mostra o que o servidor apresenta no canal de controlo antes de se tocar em qualquer ficheiro. O terceiro mostra se alguma vez se estabeleceu uma ligação de dados, que é a diferença entre uma falha de autenticação e uma falha do modo passivo.

As verificações de identidade sobrevivem ao túnel

Um cliente FTPS valida a identidade de um servidor TLS, e um cliente SFTP valida uma chave de anfitrião SSH. Ambas as verificações pertencem ao protocolo de transferência de ficheiros, e nenhuma é feita pela VPN.

Essa separação importa quando algo no meio quer inspecionar a sessão. Desativar TLS para que um dispositivo de rede possa ler os comandos muda o modelo de proteção em vez de o completar, e o mesmo se aplica a aceitar uma chave de anfitrião sem explicação porque o túnel subiu. Mantenha a configuração de confiança prevista e obtenha o material correto junto do operador. Um túnel que se autentica não diz nada sobre o servidor no seu extremo distante.

O material de chave privada e certificado para estes protocolos é ainda um terceiro segredo, separado da credencial da VPN.

Registe o que realmente verificou

Escolha um ficheiro inofensivo que tenha autorização para mover e registe quatro factos sobre a tentativa: que protocolo correu, que identidade da outra parte foi verificada, que caminho se pretendia e se a transferência terminou.

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

Uma listagem de diretório, um início de sessão no túnel e uma transferência terminada são três observações separadas, e só a última diz que o caminho funciona para ficheiros. Se o desenho confia apenas na VPN para a confidencialidade no salto restante, escreva isso como a decisão que é. Uma nota de aceitação que nomeie o salto e o seu pressuposto de confiança vale mais do que uma captura de ecrã de um cliente ligado.