Summary

  • O FTP negociava comandos em uma conexão de controle e enviava arquivos por outra conexão, dedicada aos dados.
  • A RFC 1579 reutilizou o comando PASV para inverter quem iniciava essa segunda conexão: o filtro do lado cliente ficava mais simples, enquanto o servidor precisava aceitar portas de dados de entrada.

Uma sessão FTP podia dizer “envie este arquivo” sem levar o próprio arquivo pela conexão usada para o comando. Essa separação fazia parte do projeto do protocolo. Na prática, entrar no servidor e receber uma resposta positiva a RETR não garantia a chegada dos bytes: ainda era preciso estabelecer uma segunda conexão TCP no sentido escolhido pelo FTP.

A especificação de 1985, RFC 959, separava um processo de controle para comandos e respostas e processos de dados para transferências. No arranjo comum, o cliente abria a conexão de controle para o servidor, normalmente na porta 21. Antes da transferência, podia enviar PORT com seu endereço e uma porta de escuta. O servidor então iniciava a conexão de dados de volta para o cliente. Como esse socket era distinto do canal de comandos, um firewall que liberava o primeiro não precisava liberar o segundo.

O protocolo já oferecia outro arranjo. Com PASV, o cliente pedia que o processo de dados do servidor escutasse em uma porta não padrão. O servidor devolvia endereço e porta; o cliente então abria a conexão de dados até ele. O arquivo continuava usando uma segunda conexão; só mudava quem a iniciava. Portanto, o modo passivo já existia muito antes de ser recomendado como resposta a filtros de pacotes.

Em 1994, a prática nem sempre seguia o padrão original. Steven Bellovin escreveu na RFC 1579 que os clientes da época costumavam abrir uma nova conexão de dados para cada transferência, escolher uma nova porta para evitar a espera TCP TIME-WAIT e anunciá-la com PORT. Para um filtro de pacotes, isso parecia uma chamada de entrada para uma porta imprevisível. Firewalls frequentemente aceitavam alguns serviços de entrada e rejeitavam essas conexões, mesmo depois da autenticação pelo canal de controle.

A RFC 1579 recomendou que fornecedores mudassem clientes FTP, inclusive agentes proxy do Gopher, para usar PASV em vez de PORT. Assim, a conexão de dados passava a ser iniciada de dentro da rede do cliente. Para o firewall do usuário, permitir uma conexão de saída iniciada pelo cliente era mais simples do que aceitar uma chamada não solicitada a uma porta aleatória. A nota não propôs alterar o protocolo: o comando já existia e os dois modos exigiam uma troca de preparação semelhante antes da transferência.

A solução deslocou a fronteira difícil, em vez de eliminá-la. Em modo passivo, o servidor precisava aceitar chamadas de entrada nas portas escolhidas para as transferências. A RFC 1579 reconheceu que isso poderia criar um problema de firewall do lado do servidor. Seu argumento era operacional: havia menos servidores que clientes, e o operador poderia limitar a faixa de portas de dados. Era uma proposta sobre onde administrar a exposição, não prova de adoção geral.

Os documentos normativos ajudam a separar capacidade obrigatória de comportamento difundido. A RFC 1123, publicada em 1989, exigiu que servidores FTP implementassem PASV e esclareceu a interpretação da resposta, embora observasse que o formato ainda era pouco padronizado. Mais tarde, a RFC 1579 informou que existiam ao menos dois clientes independentes modificados. Nenhuma dessas informações mede quantos usuários ou sites mudaram de modo. O registro de 1994 sustenta uma recomendação e algumas implementações, não uma migração universal.

O FTP tinha duas superfícies operacionais. A conexão de controle carregava credenciais, comandos e respostas; a conexão de dados levava listagens ou arquivos. Uma resposta como “abrindo conexão de dados” não era o arquivo, e autenticação bem-sucedida não provava que a transferência terminou. A investigação precisava acompanhar os dois sockets e identificar qual ponta deveria iniciar cada conexão.

A lição da RFC 1579 é mais específica do que “os firewalls quebraram o FTP”. O protocolo já oferecia uma escolha sobre a direção da conexão de dados. O filtro tornou essa escolha operacionalmente importante. PASV permitia iniciar pelo lado em que o firewall do cliente tinha mais chance de autorizar, mas atribuía ao operador do servidor a gestão de uma faixa limitada de portas de entrada. O protocolo não mudou; o peso operacional mudou de lugar.

Sources