Liberar FTP Passivo

Boa tarde...

Amigos, tenho o seguinte ambiente: Servidor FTP com ip válido na eth0. Estou com problemas para criar uma regra para o tráfego de ftp passivo, que está bloqueado. Segue o que já tenho no firewall, em suma:

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 21,80,53,110,143 -j ACCEPT

Resumindo é isso... fazendo conexão ftp passiva não tenho resposta, lembrando que não tenho NAT pois se trata de um servidor com ip válido.

Att.

bom.. o mais provavel é que seja um problema no servidor de FTP.. e nao com o firewall..

pois tanto o FTP ativo como o PASSIVO trabalham da mesma forma.. a diferença é que no PASSIVO sao usadas portas dinamicas para o ftp-data ..

ou seja.. no ativo.. o tunel do ftp-data é sempre pela porta 20 do servidor para o cliente.. passando pelo tunel da porta 21..

no passivo, a porta usada pelo cliente para abrir o tunel na porta 21 é incrementada em n+1 e o servidor FTP usa essa porta do cliente para fazer o tunel na porta 21.

eu uso o vsftpd aqui nos dois modos.. tanto ativo como passivo.. e funciona normal.. so liberando a porta 21 no firewall..

[]'s

Caro,

Hablite o modulo:

modprobe ip_nat_ftp

Falou,

Danilo,

O estranho é que se eu mudo a política da chain INPUT de DROP para ACCEPT (iptables -P INPUT ACCEPT), o modo passivo passa a funcionar. Não acredito que tenho problemas com o servidor ftp (ProFTP).

realmente é estranho...


ou vc esqueceu de liberar algum detalhe no seu iptables,,

pois minha policitca do firewall tb é toda em DROP.. so libero a porta 21.. e funciona os dois modos..

[]'s

Citação:

---

Postado originalmente por estanisgeyer

Boa tarde...

Amigos, tenho o seguinte ambiente: Servidor FTP com ip válido na eth0. Estou com problemas para criar uma regra para o tráfego de ftp passivo, que está bloqueado. Segue o que já tenho no firewall, em suma:

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 21,80,53,110,143 -j ACCEPT

Resumindo é isso... fazendo conexão ftp passiva não tenho resposta, lembrando que não tenho NAT pois se trata de um servidor com ip válido.

Acrescenta um NEW na regra : iptables -A INPUT -m state --state RELATED, ESTABLISHED -j ACCEPT . Entao ela ficara assim:
iptables -A INPUT -m state --state RELATED, NEW, ESTABLISHED -j ACCEPT
e ve no que dá! Depois posta ai o resultado.

Att.

---

dispatcher

Nao sei se é esse o problema...

pois na regra ele de ACCEPT na porta 21 a flag --syn (NEW) ja esta habilitada por default..

o estado de conexao dele é para os pactes da regra que libera o ACCEPT do --syn na porta 21.

a regra de -m state ESTABLISHED,RELATED tb ja garante o fluxo do trafego pelo o NEW que foi aberta pela regra dele de multport

Danilo...

Segui a sugestão do Dispatcher em acrescetar o state NEW, inserindo na primeira posição da chain INPUT para teste:

iptables -I INPUT -m state --state NEW -j ACCEPT

E não é que funcionou? Mas fico pensando... o estado NEW indica que o pacote está criando uma nova conexão e na regra acima estou aceitando, não seria a mesma coisa que fazer:

iptables -I INPUT --dport 0:65325 -j ACCEPT

Altos problemas de segurança

Att.

pois é..

muito estranho..

nao vejo o pq do NEW esta enfluenciando essa conexao passiva..

eu nunca usei isso ... pois a ideia do -m state é justamente vc liberar estados de conexoes para nao ter que ficar criando o retorno dos pacotes para cada regra..

e no caso do ESTABLISHED,RELATED nao tem problemas de segurança, pois o NEW é controlado pela regra que vc da o ACCEPT das portas..., e o retorno disso.. cae nessa regra de estado de conexao.. e como ali so libera o retorno de respostar de pacotes., nao tem problema nenhum..

em uma regra de ACCEPT, se vc nao informar nada.. por default a regra ja considera que a flag --syn esta liberada por default.. ou seja.. a conexao pode ser aberta...

o ESTABLISHED,RELATED seriam para o firewall nao barrar a respostas de pacotes tais como... ACK, etc. para essa conexao --syn que foi solicitada... entao .. muito estranho isso ae... nao deveria precisar do NEW no estado de pacotes...

mais como eu nao analisei seu script de firewall.. nao posso te dizer o que vc tem de errado ae para ter que por o NEW ae nas regras de estado de pacotes... e isso ae acaba se tornando um problema... pois isso diz ao firewall que qualquer conexao nao barrada pela police default ou por regra.. seja aceita a flag --syn ... acaba se tornando um problema de segurança..

eu recomendaria vc re-analisar seu script.. sequencia de regras.. etc..

pois nao precisaria ter o NEW ae na regra para isso funcionar...

Bem... vou passar então as minhas regras, em ordem:

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 21,25,53,80,110,143 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -p icmp --icmp-type 8 -j DROP
iptables -A FORWARD -p tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/s -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT


Era isso.

Abraços

pra quem disse q o -m n existia, boa danilo, detonoooooooooo geralllllllllllllllllllllllllllll ehheheheh

posta tuas regras ae fio, pra gente analizar...

deixa a regra abaixo.. para ser lida como a ultima regra da chain INPUT.

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

e veja o que acontece.

Ainda nada Danilo...

Colocando a regra de estado de conexão no final da chain e apagando ela da posição 2 ainda não consigo fazer o FTP Passivo funcionar... arggggghhhh

Eu tb já fiz essa porcaria funcionar somente com esses estados de conexão, mas com NAT!

bom.. o que eu posso te garantir.. é seja com NAT .. seja SEM.. tem que funcionar..

ja usei nas duas situacoes.. com NAT e sem NAT..

talvez seja algum modulo que vc nao esteja carregando... conntracks etc..

ponha isso aqui no seu script.. e teste..

modprobe ip_conntrack
modprobe ip_conntrack_ftp

qual distro e kernel vc ta usando ?

tiro no escuro, ta faltando alguma porta q ele ta querendo usar e o firewall ta barrando?

acho dificil BRENNO..

meu script de firewall esta totalmente em DROP.. em todas as CHAINS.. e so libero a porta 21.. e funciona normal..

Kernel 2.6.8 compilado em Red Hat 9.
Se não me engano, os módulos estão em built-in do iptables. Vou confirmar isso.

Para vcs confirmarem ae..

esse aqui é o retorno das regras do meu firewall.. que tem ip valido na interface.. como o seu caso..

---------------------------------------------------------------

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 127.0.0.1 127.0.0.1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5
ACCEPT tcp -- 0.0.0.0/0 200.XXX.XXX.XXX tcp dpt:21
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

----------------------------------------------------------------
isso ae sao todas as regras relativas ao meu FTP.. mais nada...

Confirmando...

Tenho as regras iptables em built-in, exceto a Connection Tracking relativo ao NAT/MASQ, mas que no meu caso não é necessário, por esse motivo que está desabilitado. Vou compilar com esse negócio junto para ver se resolve.

putz ehhheheheh

Boa tarde...

Apelei para a recompilação do kernel com o Connection Tracking do MASQ/NAT em built-in e não faço idéia se é por que eu reiniciei a máquina ou pq esse módulo estava ativado que passou a funcionar. Ou ainda pq deu um pau no módulo iptables.... hehehe

Abraços.

putz de novo, ehhehehe é bom que assim muita gente aprende, até eu que já tava sem noção atirando no escuro sem saber oq era.. vlw flw