FTP e NAT
Era um pacato dia de inverno na TI da empresa onde presto serviços quando eu estava fazendo a migração do firewall em linux para uma máquina nova(Sun X4100) com FreeBSD.
Havia instalado o squid com autenticação ntlm no AD windows, nessus para dar uma conferida na segurança e estava migrando as regras de firewall de iptables para PF. Quase tudo pronto. Quase! pois havia ainda o velho e conhecido problema em acessar servidores ftp estando atrás de um firewall com NAT.
Segundo consta na documentação do próprio PF é bastante simples ter a solução para o problema de acesso a servidores ftp, principalmente os que trabalham em modo ativo, onde o problema de acesso é do cliente.
Teoricamente usa-se um proxy ftp(ftp-proxy) as conexões dos clientes são redirecionadas para esse proxy, normalmente escuta na porta 8021 através do inetd, faz a requisição para o servidor ftp que o cliente solicitou e retorna os dados para o cliente, enfim.. ele faz o meio campo, o papel de um proxy.
O ftp-proxy também cria regras necessárias no firewall, rodando, para permitir o tráfego para o cliente que solicitou, através de âncoras. Hipoteticamente quando uma sessão ftp é estabelecida deveria ser possível ver as regras que o nosso amigo ftp-proxy criou com o comando:
Mas, porém, contudo, entretanto, todavia seguia as instruções, busquei por ajuda em fóruns e não obtive sucesso.
Fiquei um pouco decepcionado pois o que parecia ser simples me roubou um dia inteiro e no final das contas não funcionava em servidores em modo ativo, somente passivo.
Costumo testar no ftp da pucpr:
logo-me como anonymous e quando dou um ls ele entra em modo ativo e é ai que a porca torce o rabo. Para saber mais sobre o funcionamento do protocolo e serviço ftp eu recomendo essa leitura: http://pintday.org/whitepapers/ftp-review.shtml
Buscando por uma solução em alguma lista de discussão encontrei várias pessoas com o mesmo problema e uma das soluções citadas era de usar o pftpx. Um softwarezinho que, olhando pelo manual dele aparenta ser a mesma coisa que o ftp-proxy, também escuta na mesma porta(8021). Faz uso de âncoras também e nesse me parece que funciona.
Pois bem, no firewall foi necessário apenas inserir o seguinte:
no /etc/rc.conf adicionei o seguinte:
OU
OU
"After making the necessary changes to the /etc/* file you should send a SIGHUP (hangup) signal to the init process to force it to re-read its configuration file. For example:"
Porém o comando acima, re-lê, mas não finaliza os serviços que já estão rodando.
Vejamos se o pftpx foi iniciado com sucesso:
proxy pftpx 4378 3 tcp4 127.0.0.1:8021 *:*
Bom se foram inseridas as regras e âncoras no firewall e o serviço está iniciado tudo indica que os clientes da sua rede já podem acessar servidores FTP sem problemas. Teste.
No momento que estabelecer um conexão, a partir de um cliente, execute o seguinte comando no firewall:
pfctl -s Anchors -v
Serão exibidas todas as âncoras. Haverá uma chamada pftpx e outra como pftpx/pid.x.
Onde pid é o número do processo pftpx e x eu não sei. Mas deve ser algo como instância.
execute então:
pfctl -a "pftpx/pid.x" -s rules
pfctl -a "pftpx/pid.x" -s nat
Serão exibidas as regras criadas para essa conexão ftp. Essa âncora pftpx/pid.x só será criada no momento que o ftp estiver em modo ativo.
Proonto!!!!!
Havia instalado o squid com autenticação ntlm no AD windows, nessus para dar uma conferida na segurança e estava migrando as regras de firewall de iptables para PF. Quase tudo pronto. Quase! pois havia ainda o velho e conhecido problema em acessar servidores ftp estando atrás de um firewall com NAT.
Segundo consta na documentação do próprio PF é bastante simples ter a solução para o problema de acesso a servidores ftp, principalmente os que trabalham em modo ativo, onde o problema de acesso é do cliente.
Teoricamente usa-se um proxy ftp(ftp-proxy) as conexões dos clientes são redirecionadas para esse proxy, normalmente escuta na porta 8021 através do inetd, faz a requisição para o servidor ftp que o cliente solicitou e retorna os dados para o cliente, enfim.. ele faz o meio campo, o papel de um proxy.
O ftp-proxy também cria regras necessárias no firewall, rodando, para permitir o tráfego para o cliente que solicitou, através de âncoras. Hipoteticamente quando uma sessão ftp é estabelecida deveria ser possível ver as regras que o nosso amigo ftp-proxy criou com o comando:
pfctl -a ftp-proxy -s rulesMas eu nunca consegui ver(talvez eu esteja fazendo algo errado)... cheguei até a pensar que o tal do ftp-proxy não tava trabalhando, porque por sinal ele não loga nada e não faz debug também. Mas descobri que ele estava funcionado quando parei o serviço inetd. Aí não conectou mais no server ftp.
Mas, porém, contudo, entretanto, todavia seguia as instruções, busquei por ajuda em fóruns e não obtive sucesso.
Fiquei um pouco decepcionado pois o que parecia ser simples me roubou um dia inteiro e no final das contas não funcionava em servidores em modo ativo, somente passivo.
Costumo testar no ftp da pucpr:
ftp ftp.pucpr.br
logo-me como anonymous e quando dou um ls ele entra em modo ativo e é ai que a porca torce o rabo. Para saber mais sobre o funcionamento do protocolo e serviço ftp eu recomendo essa leitura: http://pintday.org/whitepapers/ftp-review.shtml
Buscando por uma solução em alguma lista de discussão encontrei várias pessoas com o mesmo problema e uma das soluções citadas era de usar o pftpx. Um softwarezinho que, olhando pelo manual dele aparenta ser a mesma coisa que o ftp-proxy, também escuta na mesma porta(8021). Faz uso de âncoras também e nesse me parece que funciona.
Pois bem, no firewall foi necessário apenas inserir o seguinte:
In the NAT section:Bloco acima retirado do próprio manual.
nat-anchor "pftpx/*"
rdr-anchor "pftpx/*"
rdr pass on $int_if proto tcp from $lan to any port 21 -> 127.0.0.1 port 8021
In the rule section:
anchor "pftpx/*"
no /etc/rc.conf adicionei o seguinte:
#proxy ftpIsso irá carregar o pftpx na inicialização do FreeBSD. Aliás, para se reiniciar os serviços sem reinicializar o freebsd pode-se usar o seguinte:
pftpx_enable="YES"
Dica acima retirada daqui.
# shutdown now
(Nota: sem -r ou -h)
# return
# exit
OU
#sh /etc/rc
OU
"After making the necessary changes to the /etc/* file you should send a SIGHUP (hangup) signal to the init process to force it to re-read its configuration file. For example:"
# kill -HUP 1
Porém o comando acima, re-lê, mas não finaliza os serviços que já estão rodando.
Vejamos se o pftpx foi iniciado com sucesso:
sockstat -l4 | grep 8021tem que aparecer algo como:
proxy pftpx 4378 3 tcp4 127.0.0.1:8021 *:*
Bom se foram inseridas as regras e âncoras no firewall e o serviço está iniciado tudo indica que os clientes da sua rede já podem acessar servidores FTP sem problemas. Teste.
No momento que estabelecer um conexão, a partir de um cliente, execute o seguinte comando no firewall:
pfctl -s Anchors -v
Serão exibidas todas as âncoras. Haverá uma chamada pftpx e outra como pftpx/pid.x.
Onde pid é o número do processo pftpx e x eu não sei. Mas deve ser algo como instância.
execute então:
pfctl -a "pftpx/pid.x" -s rules
pfctl -a "pftpx/pid.x" -s nat
Serão exibidas as regras criadas para essa conexão ftp. Essa âncora pftpx/pid.x só será criada no momento que o ftp estiver em modo ativo.
Proonto!!!!!
1 Comentários:
Parabéns pelo artigo!!Tive exatamente o mesmo problema!! Obrigado!!
By Junior Pisetta, at 28/08/2007, 17:13
Postar um comentário
<< Home