O FTP é um protocolo de transferência de arquivo legado que usa canais de controle e dados separados. Enquanto o tráfego web e de API moderno é protegido por tokens, TLS, política de sessão e controles WAAP, o FTP na maioria das organizações ainda opera no nível de "abrir porta, verificar nome de usuário e senha". Fluxos de trabalho EDI, transferências em lote, troca de arquivos com parceiros, pontes de mainframe e sistemas de documentos legados, portanto, rodam fora da visibilidade de segurança.
A segurança de rede tradicional oferece duas opções fracas para FTP. Ou a porta 21 é aberta e ninguém pode ver quais comandos passam por ela, ou o FTP é removido completamente e um projeto de integração de meses começa. Muitos sistemas legados não conseguem absorver essa transição rapidamente.
Usar apenas FTPS também não é suficiente. O tráfego pode ser criptografado, mas as perguntas permanecem: qual usuário está executando qual comando, qual arquivo está sendo recuperado ou enviado, qual backend está sendo acessado, a conexão de dados está vindo da fonte correta e por quanto tempo a sessão está aberta.
O design do protocolo FTP cria uma superfície de ataque específica. O comando PORT pode direcionar conexões de dados para endereços de terceiros, transferências servidor a servidor no estilo FXP podem ser abusadas, e contas anônimas ou compartilhadas fracas podem permanecer abertas por longos períodos. Esses riscos são difíceis de observar na camada de rede; é necessária conscientização de sessão FTP no nível de aplicação.
A camada de proxy de segurança FTP do TR7 WAAP opera serviços FTP clássicos — sem removê-los — sob whitelist de comandos, política por usuário, mitigação bounce/FXP, controle de sessão e auditoria forense.
O TR7 WAAP trata o FTP não como uma decisão de abertura de porta, mas como uma sessão de aplicação que é autorizada por usuário e auditada comando a comando.
Comandos FTP como RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE e MDTM são colocados em uma lista individual de allow/deny. Comandos desconhecidos ou ausentes da política são rejeitados por padrão.
O nome de usuário FTP pode ser usado como chave de política. Usuários diferentes conectando-se pelo mesmo VIP podem operar com conjuntos de comandos diferentes, timeouts diferentes e pools de backend diferentes.
A fonte da conexão de dados é correlacionada com a conexão de controle. Tentativas de PORT direcionadas a endereços de terceiros ou comportamento de transferência servidor a servidor são bloqueados por padrão; exceções são definidas por uma decisão de política explícita.
Cada sessão, comando e transferência de arquivo é gravado no audit log. O modo monitor apresenta o caminho completo do arquivo; o modo filecopy pode armazenar uma cópia com timestamp de cada arquivo transferido.
O Proxy de Segurança FTP coloca as fraquezas de comando, usuário, canal de dados, sessão e auditoria do protocolo FTP clássico sob o modelo de política WAAP.
O TR7 gerencia os comandos FTP padrão como decisões de allow/deny no nível de política. Em um papel somente leitura, comandos como RETR, LIST, NLST, SIZE, MDTM e STAT permanecem abertos enquanto STOR, DELE, RMD ou RNTO podem ser negados. Em um papel de upload, apenas STOR e os comandos de diretório necessários são permitidos. Isso garante que "ter acesso FTP" não se traduza em permissões ilimitadas de arquivo.
O nome de usuário é lido no estágio de login e alimentado no motor de política WAAP. Dois usuários conectando-se ao mesmo VIP podem operar com conjuntos de comandos diferentes, durações de sessão diferentes, profundidade de auditoria diferente e pools de backend diferentes. Essa arquitetura consolida transferências de arquivos baseadas em parceiro, departamento ou tenant em um único ponto de entrada. As equipes de operações definem limites de segurança por usuário.
Um usuário pode ser direcionado para um pool de backend específico enquanto outro é roteado para um pool diferente. O padrão de seleção `user@server` do lado do cliente pode ser usado, ou o TR7 pode resolver o usuário para o backend apropriado por meio de uma tabela central. Isso elimina a necessidade de abrir muitos VIPs separados para FTP de parceiro B2B, compartilhamento departamental ou separação de tenant. O roteamento controlado acontece sob um único ponto de entrada.
Os modos FTP ativo e passivo se comportam de forma diferente em relação à conexão de dados. O TR7 correlaciona os fluxos PORT e PASV com a sessão para garantir que o canal de dados seja estabelecido corretamente. O intervalo de porta passiva pode ser restrito por política; o IP de origem em direção ao backend pode ser fixado. Isso reduz falhas de transferência para serviços FTP atrás de NAT e firewalls.
Em ataques FTP bounce, o comando PORT tenta direcionar conexões de dados para um terceiro destino. O TR7 pode rejeitar esse comportamento correspondendo a conexão de dados ao endpoint real da conexão de controle. O comportamento de transferência servidor a servidor similar a FXP pode ser mantido desabilitado por padrão. As exceções necessárias são definidas explicitamente; uma lacuna de segurança nunca é o comportamento padrão.
As sessões FTP podem ser avaliadas por IP de origem, país, ASN, janela de tempo ou informações de usuário. Conexões de fora de países de parceiros específicos ou intervalos de IP corporativos podem ser rejeitadas. Isso traz a abordagem de controle de acesso usada no lado web e de API para o FTP também. Os fluxos de transferência de arquivo legados são vinculados à política de acesso moderna.
As sessões FTP podem ficar abertas por longos períodos e consumir sockets no backend. O TR7 pode gerenciar limites como timeout de login, timeout de idle e duração total da sessão no nível de política. Uma duração de sessão padrão de 900 segundos pode ser usada como baseline e ajustada conforme necessário. As sessões ociosas são fechadas sem manter o backend aguardando.
Os clientes FTP podem mudar de diretório com CWD e depois emitir comandos de arquivo relativos. O modo monitor rastreia o diretório de trabalho dentro da sessão e registra comandos como `RETR file.csv` com seu caminho de arquivo completo. O registro de auditoria, portanto, mostra não apenas o comando, mas a localização real do arquivo. A investigação pós-incidente esclarece exatamente qual arquivo foi recuperado ou enviado.
Para necessidades de conformidade ou forenses, uma cópia de cada arquivo transferido pode ser gravada em uma área de armazenamento separada. Os arquivos podem ser mantidos em uma estrutura de diretórios baseada em data e correlacionados com o audit log. Isso significa que a pergunta "qual arquivo foi enviado?" pode ser respondida não apenas com uma entrada de log, mas com o próprio arquivo. A evidência de auditoria é fortalecida em setores regulados.
Quando FTPS está em uso, o canal de controle é criptografado, mas os comandos devem ser entendidos para aplicar a política de segurança. A camada de proxy de segurança FTP do TR7 WAAP termina a sessão FTPS na camada de segurança e pode inspecionar os comandos. Sob AUTH TLS, o encaminhamento para o backend pode ser re-criptografado ou adaptado ao modelo de rede interno. O certificado e a política TLS se alinham com o pool de gerenciamento central.
O Proxy de Segurança FTP é operado em conjunto com processamento de comandos, ciclo de vida de conexão de dados, comportamento HA, streaming de auditoria, limites de recursos e políticas de retenção de conformidade.
Cada comando FTP é recebido do canal de controle, analisado, avaliado contra a lista ValidCommands e a política de usuário. Um comando permitido é encaminhado para o backend. Um comando rejeitado retorna uma resposta de erro compatível com o protocolo (502 ou 550); o cliente permanece compatível com o protocolo.
Quando um comando PORT ou PASV é visto, o TR7 associa a conexão de dados à sessão. Conexões de dados separadas existem entre o cliente e o TR7, e entre o TR7 e o backend. Essa estrutura torna possível fechar a sessão de forma controlada se uma violação de política for detectada durante uma transferência.
Novas sessões FTP são abertas no nó ativo com a mesma política. Transferências de dados grandes em andamento podem ser interrompidas em um evento de failover devido à natureza do protocolo; se o cliente suportar retomada, a transferência pode ser reiniciada ou continuada. Transferências críticas devem, portanto, ter o comportamento do cliente testado antes da implantação em produção.
Logs separados podem ser produzidos nos níveis de sessão, comando e transferência. Os logs podem ser enviados para o stream SIEM em formato estruturado. O modo monitor acrescenta o caminho completo do arquivo à linha de log; o modo filecopy acrescenta a localização da cópia do arquivo armazenado.
Número de sessões simultâneas, sessões por usuário, sessões por IP, tamanho de arquivo e taxa de transferência podem ser todos restritos por política. Isso evita que um único usuário ou um job em lote com mau comportamento esgote a infraestrutura FTP. A largura de banda e o timeout devem ser planejados juntos para transferências de arquivos grandes.
O caminho completo, o timestamp, as informações de usuário e, se necessário, uma cópia do arquivo de cada arquivo transferido podem ser retidos. A duração da retenção é definida de acordo com a política de conformidade da organização. Durante uma auditoria, o tráfego FTP não é mais uma área obscura.
Uma instituição financeira ou agência governamental pode trocar arquivos EDI com parceiros via FTP. O TR7 roteia cada parceiro atrás de um único VIP para seu próprio pool de backend, abre apenas os comandos permitidos e coloca cada transferência sob auditoria.
Se uma plataforma de documentos legada suporta apenas upload FTP, o TR7 pode ser colocado na frente sem tocar no sistema. A política abre apenas STOR e os comandos de diretório necessários enquanto rejeita os comandos de exclusão e renomeação.
Em integrações que recuperam arquivos de um sistema mainframe, o usuário pode ser limitado a comandos somente leitura como RETR, LIST e SIZE. STOR, DELE, RNFR, RNTO, MKD e RMD são rejeitados, reduzindo o risco de modificação de dados.
Quando uma equipe de saúde ou pesquisa envia datasets para parceiros externos, cada transferência pode ser retida com filecopy. Limites de tamanho de arquivo, política por usuário e streaming de log para SIEM tornam o processo de compartilhamento auditável de ponta a ponta.
Whitelist de comandos, política por usuário, proteção bounce/FXP e auditoria forense. Deixe-nos guiá-lo por uma configuração ao vivo na sua própria infraestrutura FTP.