Segurança e Alternativas: SFTP e FTPS

1. Definição

O FTP clássico (RFC 959) foi projetado em 1985 sem qualquer preocupação com segurança: senhas trafegam em texto puro, comandos e dados não têm integridade, e a autenticação é trivialmente interceptável por sniffers. Com a massificação da internet nos anos 1990, tornou-se evidente que o FTP precisava de uma camada de proteção. Surgiram duas soluções concorrentes, frequentemente confundidas:

• FTPS (FTP over SSL/TLS): o mesmo protocolo FTP, com uma camada TLS adicionada. Definido na RFC 4217 (2005) e RFC 2228. Mantém os dois canais TCP (controle + dados) do FTP, mas cifrados.
• SFTP (SSH File Transfer Protocol): protocolo completamente diferente, executado como um subsistema do SSH (RFC 4251-4254). Não tem relação técnica com o FTP além do nome. Usa um único canal TCP na porta 22.

A confusão é comum porque ambos transferem arquivos de forma segura, mas a arquitetura, portas, comandos e casos de uso são distintos.

Comparação Rápida

2. FTP Clássico — Por que não usar

O FTP sem criptografia apresenta vulnerabilidades fundamentais:

1. Senhas em texto puro: comando USER e PASS são legíveis em capturas de pacote. Em redes Wi-Fi públicas ou segmentos compartilhados, qualquer sniffer (Wireshark, tcpdump) captura credenciais instantaneamente.
2. Sem integridade: um atacante na rota pode alterar bytes do arquivo em trânsito (ataque MITM ativo).
3. Sem autenticidade: o cliente não valida a identidade do servidor.
4. Comando BOUNCE: o FTP permite usar PORT para redirecionar a conexão de dados a terceiros, possibilitando relay de port scan (FTP bounce attack, mitigado em servidores modernos).
5. Dados sensíveis em claro: além da senha, o conteúdo dos arquivos é legível.

Por essas razões, o FTP clássico é proibido por compliance PCI-DSS, HIPAA, LGPD e diretrizes de segurança corporativas modernas. Deve ser desativado em favor de FTPS ou SFTP.

3. FTPS — FTP sobre TLS

O FTPS adiciona TLS ao FTP clássico. Há dois modos de operação:

FTPS Explícito (AUTH TLS)

O cliente conecta na porta 21 em texto puro e envia o comando AUTH TLS (RFC 4217) para iniciar o handshake TLS. Após TLS estabelecido, a sessão segue cifrada. Vantagem: a mesma porta 21 atende clientes FTP e FTPS simultaneamente.

C: AUTH TLS
S: 234 Proceed with negotiation.
[handshake TLS]
C: USER joao
S: 331 Password required
C: PASS ****
S: 230 Login successful
C: PBSZ 0
S: 200 PBSZ=0
C: PROT P
S: 200 Protection set to Private

O comando PROT P define que ambos os canais (controle e dados) serão cifrados. PROT C cifra apenas o controle, deixando dados em claro (raro, apenas para economizar CPU).

FTPS Implícito (FTPS na porta 990)

O cliente conecta na porta 990 já esperando TLS — equivalente ao HTTPS na porta 443. Não há negociação; o handshake TLS começa imediatamente. A porta de dados também muda para 989 (modo ativo). É o modelo mais antigo (RFC 2228), hoje em desuso, mas ainda suportado por alguns servidores legados.

Configuração no vsftpd (Explícito)

ssl_enable=YES
allow_anon_ssl=NO
force_local_logins_ssl=YES
force_local_data_ssl=YES
ssl_tlsv1_2=YES
ssl_tlsv1_3=YES
ssl_tlsv1=NO
ssl_tlsv1_1=NO
ssl_sslv3=NO
ssl_sslv2=NO
require_cert=NO
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key

Problemas do FTPS

• Dualidade de canais mantida: a complexidade ativo/passivo persiste, agora com TLS em cima. Firewalls stateful precisam de FTP ALG para inspecionar o canal de controle em TLS — mas se o controle está cifrado, o ALG não enxerga as portas negociadas, quebrando o modo passivo.
• Certificados X.509: exigem gestão de PKI (renovação, CA confiável, CRL/OCSP).
• Portas adicionais: modo implícito usa 990 e 989.
• Maior latência: handshake TLS em cada nova conexão de dados.

4. SFTP — SSH File Transfer Protocol

O SFTP é um subsistema do SSH, não uma versão segura do FTP. É definido na RFC 4251 (arquitetura SSH), RFC 4252 (autenticação), RFC 4253 (transporte) e RFC 4254 (conexões), com o protocolo de transferência em si no Internet-Draft draft-ietf-secsh-filexfer. É executado como Subsystem sftp /usr/lib/openssh/sftp-server no sshd_config.

Características

• Canal único: uma única conexão TCP na porta 22, multiplexando múltiplas requisições (read, write, opendir, readdir) em canais SSH.
• Sem dualidade ativo/passivo: a porta 22 é tudo; não há conexão de dados separada. Resolve todos os problemas de NAT/firewall do FTP.
• Operações ricas: além de get/put, suporta rename, mkdir, rmdir, stat, setstat, symlink, readlink, fstatvfs — equivalente a um sistema de arquivos remoto.
• Preserva atributos: permissões Unix, timestamps (atime, mtime), ownership (uid, gid), ACLs estendidas.
• Reinício de transferência: comando read/write com offset permite retomar transferências interrompidas.
• Autenticação SSH: chave pública RSA/Ed25519/ECDSA, com ou sem passphrase, ou senha (em texto puro dentro do canal cifrado).

Configuração no OpenSSH

# /etc/ssh/sshd_config
Subsystem sftp /usr/lib/openssh/sftp-server
# Ou internal-sftp (mais seguro, sem binário externo):
# Subsystem sftp internal-sftp

# Chroot para usuarios SFTP-only
Match Group sftpusers
    ChrootDirectory /home/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Cliente SFTP

# Conexao interativa
sftp user@servidor.com

# Upload direto
sftp user@host:/remoto/arquivo.txt /local/

# Com lftp (mais recursos: mirror, paralelismo)
lftp sftp://user@host -e "mirror /remoto /local; quit"

# Com curl
curl -u user: --key ~/.ssh/id_rsa sftp://host/remoto/arquivo -o /local/

5. Comparativo Profundo FTPS vs SFTP

6. Quando Usar Cada

• SFTP: caso padrão. Simples, seguro, nativo em servidores Linux. Ideal para automação (scripts bash, CI/CD), transferências B2B, acesso a servidores na nuvem.
• FTPS explícito: quando há requisito contratual ou legado de compatibilidade com clientes Windows mainframes, AS/400 ou parceiros que só falam FTP. Comum em integrações EDI (B2B) e sistemas bancários legados.
• FTP clássico: somente em redes isoladas sem acesso externo (ex.: laboratório, rede de gerenciamento out-of-band), para distribuição pública de arquivos não sensíveis (espelhos de software).

7. Diagnóstico

# Testar FTPS explicito
lftp -d -u user,pass ftps://servidor -e "ls; quit"
openssl s_client -connect servidor:21 -starttls ftp

# Testar FTPS implicito (porta 990)
openssl s_client -connect servidor:990

# Testar SFTP com debug
sftp -vvv user@servidor
ssh -v user@servidor  # equivalente (mesma porta)

# Verificar certificado FTPS
openssl s_client -connect servidor:21 -starttls ftp -showcerts

8. Boas Práticas de Hardening

9. Conclusão

FTP clássico é inaceitável em qualquer ambiente com dados sensíveis. Entre as alternativas, SFTP é a escolha preferencial pela simplicidade de arquitetura (canal único SSH), compatibilidade universal com servidores Unix, ausência de problemas de NAT/firewall e riqueza de operações. FTPS deve ser reservado para cenários de compatibilidade legada com clientes que só suportam FTP, mantendo as mesmas fraquezas arquiteteturais do FTP original (dois canais, ALG, complexidade de portas passivas). Em novos projetos, sempre escolha SFTP; use FTPS apenas como ponte de transição enquanto migra parceiros e sistemas legados.