Resumo
- O FTP de 1985 separava comandos e dados, permitindo que um cliente organizasse a transferência direta entre dois servidores e indicasse um destino alternativo com
PORT. - O RFC 2577 explicou, em 1999, como essa escolha podia levar o servidor FTP até um serviço que nada tinha a ver com a transferência.
Se a encomenda está no depósito A e precisa chegar ao depósito B, fazer a carga passar primeiro pela casa do cliente é um capricho caro. Com uma conexão lenta, pior ainda. O FTP resolveu o transporte: o cliente coordenava os dois servidores e a mercadoria seguia direto. Só faltava uma pergunta de balcão. Quem podia escrever o endereço no caminhão que pertencia ao servidor?
O RFC 959, publicado em outubro de 1985, descreveu o FTP com uma conversa de controle separada da conexão que levava os dados. O cliente podia manter duas conversas de controle, uma com cada servidor. Um esperava; o outro se conectava e transferia o arquivo. O comando PORT designava um endereço de dados alternativo. O texto admitia inclusive uma máquina de terceiros ou uma impressora remota. Para quem usava uma linha devagar, tirar o próprio computador do trajeto do arquivo fazia sentido.
O atalho repartia os papéis de um jeito delicado. A escolha do destino vinha do cliente; a conexão saía do servidor. Quando os dois servidores participavam legitimamente da operação, o endereço apontava para o outro depósito. Sem limite para o que o cliente podia indicar, o mesmo servidor podia ser enviado à porta de outro serviço de rede. Esse serviço via uma conexão feita pelo servidor FTP. O autor da instrução permanecia no canal de controle, fora de vista para o destinatário.
O RFC 1579 de Steve Bellovin, de fevereiro de 1994, mostrou por que a direção da conexão já incomodava administradores. No FTP ativo, o servidor ligava de volta para uma porta do cliente; filtros de pacotes tinham dificuldade em admitir chamadas de entrada a portas inesperadas. Bellovin recomendou PASV: o servidor escuta e o cliente abre a conexão para fora. Ele também esboçou APSV, informando que não conhecia implementação à época. A mudança no sentido da ligação ajudava a atravessar firewalls, sem decidir automaticamente quais endereços um servidor deveria aceitar como destino.
Depois vieram endereços que não cabiam na forma antiga. O RFC 2428, de setembro de 1998, apresentou EPRT e EPSV para IPv6 e redes com tradução de endereços. EPRT levava família de rede, endereço e porta TCP. EPSV ALL comprometia a sessão com transferências entre apenas duas partes; para voltar a uma transferência em três pontos, era necessário abrir outra sessão. A ficha de endereçamento ficou mais ampla. O direito de escolher um destino em nome do servidor continuou precisando de regra.
Em maio de 1999, o RFC 2577, FTP Security Considerations, descreveu o ataque de rebote. Um cliente podia escrever no PORT o endereço e a porta de um serviço numa terceira máquina; em seguida mandava o servidor FTP enviar dados para lá. Se os bytes fossem comandos compreensíveis para aquele serviço, o FTP aparecia como visitante involuntário. O exemplo do documento usava um arquivo com comandos SMTP para fazer contato com o serviço de correio de uma terceira máquina. A pessoa que preparara a carga não precisava se conectar diretamente a ela. Pegava carona na posição de rede do servidor.
O RFC apresentou opções concretas, cada uma com uma perda ou um buraco. Sugeriu recusar conexões de dados a portas TCP abaixo de 1024 e responder 504 ao PORT correspondente; serviços em portas mais altas continuavam expostos. Permissões de arquivo podiam bloquear a sequência de enviar conteúdo ao servidor e depois repassá-lo a outro serviço. Desativar PORT eliminava o caminho da transferência entre servidores, junto com essa comodidade. Para a maioria das transferências comuns, diziam os autores, PASV bastava. O operador precisava escolher que serviço queria oferecer e a que destinos entregaria sua máquina.
O FTP não ganhou uma intenção maliciosa em 1999. Seu desenho eficiente permitia que o cliente organizasse o trabalho de dois servidores. A segurança exigiu que o dono do caminhão lesse a ordem de entrega antes de virar a chave. O endereço no papel era uma instrução; não era uma autorização assinada pelo proprietário.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





