Passive Mode FTP + Iptables

Estou com problemas para conectar o FTP usando o FileZilla, ja tentei de tudo, mas com o firewall levantado não conecta.

iptables -A INPUT -p tcp -s $IP -d $IPDEST --sport 1024:65535 --dport 20 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s $IP -d $IPDEST --sport 1024:65535 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s $IP -d $IPDEST --destination-port 20 -j ACCEPT
iptables -A INPUT -p tcp -s $IP -d $IPDEST --destination-port 21 -j ACCEPT
modprobe ip_conntrack
modprobe ip_conntrack_ftp
iptables -A INPUT -p tcp --syn -j DROP


# SE eu liberar todas as PORTAS para o IP de origem ( como esta abaixo ) conecta, mas se eu limitar as postas acima não conecta.

iptables -A INPUT -p tcp -s $IP -d $IPDEST -j ACCEPT

Obrigado

Olá,

Para entender mais sobre os pacotes que estão sendo descartados é possível utilizar um LOG, no debian vem habilitado por padrão, o rsyslog...
Antes do drop coloque a seguinte regra:
iptables -A INPUT -j LOG --log-prefix [fw-input-drop]

Para verificar o LOG, digite: tailf /var/log/messages|grep fw-input-drop

Se eu não me engano o FTP tem um range de portas altas que é utilizada, precisa verificar no programa qual é, não me recordo de cabeça...
Ou verificar pelo LOG e liberar a porta utilizada conforme explicado acima.

Espero ter ajudado

Para estabelecer uma conexão FTP leve em conta os seguintes aspectos:

- primeiramente,
a) você precisa decidir se o modo do FTP será ativo ou será passivo;

b) você precisa decidir se na transferência FTP você é o cliente ou é o servidor;

= vou presumir que você quer utilizar o modo passivo e que você é o cliente!

- é importante entender a distinção entre Porta de Comandos e Porta de Dados.

- utilizando-se do modo passivo não é necessário aceitar "novas conexões" (NEW) (aliás, é uma falha de segurança aceitá-las).

- é necessário aceitas conexões estabelecidas e conexões relacionadas (ESTABLISHED,RELATED)

- o cliente não recebe dados nas portas baixas (20 ou 21); apenas o servidor;

- o cliente recebe dados nas portas altas (1024:65535);

- A porta 20, por padrão, não é utilizada pelo FTP passivo;

= De maneira resumida, a transferência no FTP passivo ocorre da seguinte maneira:

O cliente faz a solicitação ao servidor (a solicitação sai do cliente em uma porta alta e chega no servidor na porta 21) > o servidor responde ao cliente de uma porta alta para uma porta alta.

Ou seja, a porta 21 é utilizada apenas para chamar o servidor; todo o restante do procedimento é feito de porta alta para porta alta.

a partir do que expus em minha resposta anterior, podemos verificar os seguintes no seu código:



- quatro problemas:

1) o primeiro comando não é necessário -- pois trata-se da porta 20 (além de conter o mesmo erro do problema 2)

2) o segundo comando está permitindo o pacote para a sua porta 21 -- sendo que o cliente nunca recebe pacotes na porta 21.

3) o comando está permitido conexão New -- não é necessário; e é uma falha de segurança (apenas no modo ativo seria preciso).

4) O comando está dando permissão apenas para as conexões ESTABLISHED; é necessário também RELATED.

- sugestões:

1) uma vez que no modo passivo o cliente não precisa aceitar conexões, então, não é necessário verificar a porta de origem -- tendo em vista que necessariamente é advindo de uma conexão demandada pelo cliente na sua negociação com o servidor.

Apenas se fosse o modo ativo pe que seria importante essas verificação: pois estaria sendo criado uma nova conexão no cliente (o que não ocorre no modo passivo)

2) Utilizo apenas o seguinte código:

  iptables -A INPUT -p tcp --dport 32768:61000 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT  #ftp-transf (1024:65535) 

obs: utilizo uma faixa de portas menor porque, anteriormente, configurei esses valores nas configurações de Kernel.

Ainda não esta funcionando.
Fiz o procedimento que o amigo falou para filtrar os logs dos pacotes dropados e inclui a linha:

iptables -A INPUT -p tcp --dport 32768:61000 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Esta dando o log abaixo:


Apr 24 21:21:57 emissor kernel: [118535.996061] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16610 DF PROTO=TCP SPT=63814 DPT=55728 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 24 21:22:00 emissor kernel: [118539.007508] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16612 DF PROTO=TCP SPT=63814 DPT=55728 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 24 21:22:06 emissor kernel: [118545.020759] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16614 DF PROTO=TCP SPT=63814 DPT=55728 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 24 21:22:17 emissor kernel: [118556.273495] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16628 DF PROTO=TCP SPT=63817 DPT=49335 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 24 21:22:20 emissor kernel: [118559.290185] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16630 DF PROTO=TCP SPT=63817 DPT=49335 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 24 21:22:26 emissor kernel: [118565.294258] [fw-input-drop]IN=eth0 OUT= MAC=00:16:3e:2c:b1:09:0c:c4:7a:1e:a3:1e:08:00 SRC=186.227.215.110 DST=187.191.98.16 LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=16632 DF PROTO=TCP SPT=63817 DPT=49335 WINDOW=65535 RES=0x00 SYN URGP=0

Obrigado

o que está bloqueado é a última linha do seu código:

iptables -A INPUT -p tcp --syn -j DROP 

retire essa linha.

"Syn" é a flag de "confirmação da conexão".

para ilustrar

"PROTO=TCP" é o protocolo

"SPT=63814" é a porta de origem (a do servidor)

"DPT=55728" é a porta de destino (a do cliente) (sua máquina)

"SYN" é a flag de "confirmação da conexão".

aliás,... esse código geralmente é utilizado contra um determinado tipo de ataque..

não deveria dar problema..

talvez o problema não seja ele...

- qual erro o filezila mostra?

- conecta mas não lista nada?

- ou sequer consegue conectar?

- posta como ficou o conjunto de suas regras de iptables...

Boa Noite,
Eu não posso retirar essa linha pois é a ultima regra que bloqueia caso não tenha passado pelas regras que libera acima.

iptables -A INPUT -p tcp --syn -j DROP
Retirei o "--syn" mas a regra não funcionou, deu erro de sintax.


A regra ficou assim:
iptables -A INPUT -p tcp --dport 32768:61000 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp -s $CASA -d $MEUIP_01 --destination-port 20 -j ACCEPT
iptables -A INPUT -p tcp -s $CASA -d $MEUIP_01 --destination-port 21 -j ACCEPT
iptables -A INPUT -p tcp -s $CASA -d $MEUIP_01 --dport 20 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s $CASA -d $MEUIP_01 --dport 21 -m state --state RELATED,ESTABLISHED -j ACCEPT

modprobe ip_conntrack_ftp
iptables -A INPUT -p tcp --syn -j DROP

essa linha protege de um ataque em específico. ela não bloqueia os pacotes que não passam pela regra.

pode (e deve) mantê-lo. mas não está cumprindo o papel que você gostaria que cumprisse.

o método correto é setar a política padrão de input como drop e, então, ir liberando o que deseja.

com a política padrão em drop tudo o que não for aceito é automaticamente rejeitado.

  iptables -t filter -P INPUT DROP

  iptables -t filter -P OUTPUT ACCEPT 

isso é para estar entre as primeiras dos códigos

Como tentei explicar antes, essas linhas não tem sentido em um cliente: o cliente não recebe pacote algum nas portas 20 e 21.

você está zerando os códigos antes de setar novos?

as primeiras linhas do código devem ser estas:

iptables -t filter -F  # limpa todas as regras dos chain internos

iptables -t filter -X  # limpa todas as regras dos chain criados pelo usuário

iptables -t filter -Z  # zera os contadores