[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PROFTPD - esconder serviço em outra porta



Em Sun, Sep 12, 2004 at 01:12:16PM -0400, Julio Lopez escreveu:
> Valeu Caio... o SSH funcionou blz... mas o FTP não.
> O que foi feito:
> 1)Inclui as novas portas 33643 TCP/UDP para o serviço FTP no /etc/services
> (obs.: mantive as portas 20 e 21)
> 2) Implementei as regras p/ o DNAT no script de firewall
> 3) Alterei o proftpd.conf para ouvir na porta 33643
> 
> Beleza...
> Internamente funciona tudo normal...
> Se você tentar acessar da internet o meu FTPserver indicando a nova porta
> (Ex.: FTP 200.xxx.xxx.xxx 33643), o firewall faz o DNAT corretamente para o
> FTPserver interno da rede, conecto nessa máquina normalmente, o PROFTPD pede
> user/passwd, autentica tudo direitinho... Porém ao emitir o comando DIR ou
> LIST ... não retorna nada até dar TIME OUT.
> Repetindo o mesmo processo descrito acima, porém usando a porta padrão 21...
> o DIR retorna o conteúdo do diretório normalmente.
> Será que tem que habilitar mais alguma outra porta para o processo se
> completar?
> Algúem já passou um problema parecido?
> []'s
> Julio Lopez


<chute>

O FTP funciona com duas portas: na porta 20 (dados) e na porta 21
(controle). Se seu firewall está bloqueando a porta 20, e se você não
configurou seu ftpd para escutar em outra porta para os dados, você não
vai conseguir acessar arquivos, listagens de diretórios etc., que vêm
pela porta de dados. Além disso, se você mudar a porta de dados do
default 20 para outra porta, você precisará usar o modo passivo ao
acessar seu servidor (o comando é 'passive' no cliente padrão de FTP),
além de assegurar-se de que conexões para a nova porta são aceitas pelo
firewall.

</chute>
Fiz algo do tipo, para contornar o bloqueio das portas 20 e 21 pela
BrasilTelecom, configurei meu ftp (vsftpd) para escutar nas portas 210
(dados) e 211 (controle), e acesso normalmente via ADSL. Talvez isso
funcione para sua situação específica, também.


Seu problema parece realmente ser o bloqueio da porta de dados, porque
os comandos são passados normalmente.

-- 
José de Paula Rodrigues Neto Assis		Linux User 175920
Brasília - DF - Brasil				counter.li.org



Reply to: