Resumo

  • O FTP separa comandos e dados. O cliente inicia a conexão de controle, mas no modo ativo tradicional o servidor inicia outra conexão para uma porta indicada pelo cliente.
  • Para o filtro de pacotes, essa chamada de volta parece uma nova entrada em porta imprevisível. O RFC 1579 recomendou PASV: o servidor escuta e o cliente também inicia o canal de dados.
  • O EPSV passou a responder apenas com a porta e a usar o endereço do par de controle, facilitando IPv6 e NAT. A direção, porém, não autenticava o par; bounce e roubo de porta continuavam exigindo controles locais.

Duas conexões compunham uma transferência

No RFC 959, comandos e respostas percorrem a conexão de controle. Listagens e arquivos usam uma conexão de dados separada, que pode nascer e morrer durante a mesma sessão. O usuário vê uma operação; a rede precisa organizar dois encontros.

O cliente abre o controle. No arranjo ativo normal, o lado do usuário escuta para dados e o servidor faz a abertura TCP. Com PORT, o cliente pode apontar outro host e outra porta. A especificação chega a permitir que ele controle dois servidores e mande um transferir diretamente ao outro.

Essa flexibilidade também entregava autoridade: o servidor tratava uma coordenada fornecida no controle como destino operacional. Coordenada não era prova de que o solicitante tinha direito de usar aquele serviço.

A chamada de volta bateu no limite

O RFC 1579, de 1994, observou que clientes escolhiam uma porta nova para cada transferência. O firewall do cliente via então o servidor externo iniciar uma conexão para uma porta alta e variável. Sem a semântica do FTP, parecia tráfego entrante não solicitado.

Liberar todas as portas destruiria a política. Fazer o filtro interpretar cada detalhe do diálogo criaria dependência de um intermediário. O impasse vinha de regras locais diferentes: FTP autorizava o retorno; o firewall esperava que novas conversas fossem iniciadas de dentro.

PASV já fornecia uma composição melhor. O servidor abre uma porta de escuta, informa onde está e aguarda. O cliente realiza a abertura ativa. Controle e dados passam a começar do mesmo lado protegido. Por isso, o RFC 1579 recomendou o modo passivo como comportamento do cliente mesmo fora de firewalls.

A alteração não juntou os canais nem criou um novo motor de transferência. Muitas sessões já enviavam PORT, de modo que trocar o comando não exigia necessariamente mais mensagens. Servidores sem PASV podiam recusar; clientes podiam voltar ao ativo se a rede aceitasse. O documento não desligava o passado: as combinações mudavam por implementação e uso.

A ideia APSV, para tornar toda a sessão passiva, ficou sem implementação conhecida. O fato é instrutivo. Uma possibilidade publicada só vira regra operacional quando participantes a colocam em execução.

EPSV deixou de duplicar o endereço

Os comandos antigos carregavam endereço IPv4 e porta dentro do diálogo. Isso não abrangia IPv6 e obrigava NAT a reconhecer e reescrever um endereço de aplicação que já não correspondia ao caminho externo.

O RFC 2428 definiu EPRT e EPSV. O primeiro preserva o modo ativo com família de rede, endereço e porta. O segundo devolve só a porta TCP de escuta; protocolo e endereço são os mesmos da conexão de controle.

Entre as mesmas duas máquinas, o par já está estabelecido por uma conexão real. Repetir seu endereço como texto cria uma segunda versão sujeita a tradução. O EPSV mantém apenas o dado novo necessário para abrir a via temporária.

EPSV ALL fecha as demais alternativas naquela sessão. Depois de aceitar, o servidor deve rejeitar EPRT, PORT, PASV e outros mecanismos. Uma necessidade posterior de transferência entre três partes exige nova sessão. A escolha tem força, mas não transborda seu âmbito.

Abrir de dentro não prova quem está fora

O RFC 2577 descreve o FTP bounce. Um atacante põe em PORT a máquina e o serviço de um terceiro e ordena que o servidor envie conteúdo preparado. A conexão parece vir do servidor FTP, dificulta a atribuição e pode contornar restrições por endereço.

Entre as defesas propostas estão rejeitar alvos TCP abaixo de 1024, desabilitar PORT quando transferências entre servidores não são necessárias e conferir os pares de controle e dados quando a política depende da origem.

No passivo, o servidor passou a expor uma porta temporária. Se a alocação for previsível, um invasor pode adivinhar a próxima e chegar antes: impede o cliente, recebe arquivo alheio ou injeta dados falsos. O RFC recomenda portas locais aleatórias. Além disso, a implementação precisa ligar o par de dados à identidade já estabelecida no controle.

O PASV resolveu uma direção ruim para o firewall. O EPSV resolveu uma informação ruim para NAT e IPv6. Nenhum cifrou o arquivo ou autenticou automaticamente o primeiro processo que alcançasse a porta.

Um mecanismo pequeno sustentou escolhas diferentes

O cliente decide qual modo pedir. O servidor escolhe a porta e quais destinos ativos permite. O firewall conserva sua política. Os extremos decidem se as duas conexões pertencem à mesma operação. O contrato comum não precisa absorver essas decisões.

Assim, modo ativo e passivo puderam coexistir; EPSV simplificou o caso comum e EPRT manteve a exceção. Compatibilidade apareceu no comando aceito e na conexão realizada, não em uma declaração superior sobre quem podia participar.

Fontes e limites

O RFC 959 define os dois canais, PORT e PASV; o RFC 1579 explica o firewall; o RFC 2428 define as extensões; o RFC 2577 documenta bounce e roubo de porta.

Esses documentos não medem o uso atual e não garantem o comportamento de todo cliente, servidor, proxy, NAT ou firewall. Também não dizem que o FTP passivo é seguro. Sustentam uma história mais exata: uma inversão mínima de iniciativa preservou a arquitetura diante de uma nova fronteira e manteve a confiança sob decisão local.