como definir as portas altas do FTP utilizadas pelo slackpkg? [RESOLVIDO]

raserafim
(usa Slackware)

Enviado em 26/05/2017 - 17:47h

ryuuaki42, após algumas pesquisas e alguns testes, tenho chegado a algumas conclusões a respeito dos meus últimos questionamentos (no meu último post).

desde já, adianto que esses meus últimos questionamentos (no meu último post) contém algumas pressuposições que estão imprecisas ou mesmo equivocadas.

também desde já, adianto as novas conclusões a que tenho chegado:

- a questão central para a distinção entre o FTP Ativo e o Passivo não diz respeito às portas. o elemento central é se a conexão é estabelecida pelo Cliente (ftp Passivo) ou se é estabelecida pelo Servidor (ftp Ativo).

- tanto no modo Ativo quanto no Passivo as portas configuradas no arquivo /proc/sys/net/ipv4/ip_local_port_range são observadas.


tendo exposto já as conclusões, vamos aos seus detalhamentos...:

quando se tenta (a partir do cliente) baixar um arquivo por meio do FTP Ativo, no processo de negociação da conexão é o servidor que estabelece a conexão de dados com o cliente (a conexão de comando foi o cliente que estabeleceu).

nesse processo de estabelecimento das conexões o ranger de portas (/proc/sys/net/ipv4/ip_local_port_range) é observado tanto o do cliente quanto o do servidor. o ranger de portas que finalmente será utilizado será composto por aquelas portas que estejam presentes tanto no ranger do servidor quanto no do cliente (as portas que formas uma intercessão dos dois ranger's. (como o ranger do servidor tende a ser todo o conjunto de portas altas, então na prática o ranger utilizado é o do cliente). [Editado: esse parágrafo contém um equívoco, que explico quatro tópicos meus à frente]

o complicador do modo FTP Ativo (considerado "padrão', embora atualmente seja pouco utilizado) é que, de certa forma, contraria um princípio da filosofia Cliente-Servidor: neste caso, será o servidor que vai estabelecer uma conexão no cliente.

o complicador é que, em geral, os firewall's bloqueiam conexões que tentam se conectar à um cliente (por que em tese apenas servidores deveriam ser conectados.

já no modo Passivo, as possíveis portas a serem utilizadas são acordadas, igualmente como no modo Ativo, observando as portas configuradas no arquivo /proc/sys/net/ipv4/ip_local_port_range tanto do servidor quanto do cliente.

sendo que neste modo de FTP é o cliente que estabelece a conexão.


fiz os seguintes testes para chegar a essas conclusões...

defini o ranger de portas com um intervalo curto e pouquíssimo usual:

echo 1026 2026 > /proc/sys/net/ipv4/ip_local_port_range 

coloquei estas regras no iptables:

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

iptables -A INPUT -p udp --dport 1:1023 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

iptables -A INPUT -p udp --dport 1024:65535 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 

utilizei o comando wget (que por padrão utiliza o modo Passivo) para baixar um arquivo em um servidor ftp.

tudo funcionou bem: o arquivo foi baixado.

no entanto, utilizando o wget com a opção "--no-passive-ftp", ou seja ativando o seu modo Ativo, o arquivo não foi baixado.

porém, permitindo no iptables o estabelecimento de conexões novas (NEW) nas portas altas, então o arquivo consegue ser baixado.

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

iptables -A INPUT -p udp --dport 1:1023 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp --dport 1024:65535 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p udp --dport 1024:65535 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT 

repeti o teste com um outro método: utilizando o LOG.

iptables -A INPUT -p tcp --dport 1024:65535 -m conntrack --ctstate NEW -j LOG --log-prefix "Input-Dropped: TESTES-NEWalta "

iptables -A INPUT -p udp --dport 1024:65535 -m conntrack --ctstate NEW -j LOG --log-prefix "Input-Dropped: TESTES-NEWalta " 

ao tentar baixar o arquivo com wget (em seu modo Passivo) nada foi registrado no LOG.

mas, ao tentar baixar o arquivo com wget utilizando sua opção "--no-passive-ftp" (portanto, ativando o seu modo Ativo) foi registrado no LOG.

May 26 16:09:12 usertux kernel: [ 1996.958219] Input-Dropped: TESTES-NEWaltaIN=wlan0 OUT= MAC=00:1a:13:bd:92:93:8c:04:ff:da:a8:05:08:00 SRC=200.137.217.134 DST=192.168.0.11 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=53716 DF PROTO=TCP SPT=20 DPT=1177 WINDOW=14600 RES=0x00 SYN URGP=0 

 

e consta a flag SYN , o que significa ser uma constatação adicional! pelo fato de ser uma solicitação de conexão.

raserafim
(usa Slackware)

Enviado em 26/05/2017 - 17:52h

agora, respondendo mais diretamente às minhas próprias perguntas do post que abri novos questionamentos (após a finalização do post):

sim. as possibilidades de um novo intervalo funcionar ou não funcionar são as mesmas para os dois modos.

muitos equívocos nessa pergunta.

como destaquei antes, tanto no modo Ativo quanto no Passivo as possibilidades de portas do cliente são observadas. a distinção do modo Ativo e do modo Passivo se dá mesmo é em quem estabelece a conexão: no modo Ativo o servidor inicia a conexão no cliente; e no modo Passivo é o cliente que inicia a conexão no servidor.

o que faz com que no modo Ativo seja necessário que o cliente aceite novas conexões (--ctstate NEW).

raserafim
(usa Slackware)

Enviado em 26/05/2017 - 23:33h

novamente considero o tópico como resolvido!!

ryuuzaki42
(usa Slackware)

Enviado em 27/05/2017 - 00:35h

Legal, gostei dos seus testes e resultados.
Como dizem, nada melhor do que colocar a mão na massa (y).
Eu estava lendo sobre o FTP Ativo vs Passivo e outras coisas para ter certeza hehe.
Não sei se leu o http://slacksite.com/other/ftp.html, tem uns desenhos bem legais.
Ativo (http://slacksite.com/images/ftp/activeftp.gif) vs Passivo (http://slacksite.com/images/ftp/passiveftp.gif)

Vida longa aos donwloads via wget!

raserafim
(usa Slackware)

Enviado em 29/05/2017 - 14:12h

havia visto sim esse link que você indicou. muito bom!

também me pareceu valer a pena o arquivo que contém a especificação oficial de implementação do FTP:(https://tools.ietf.org/html/rfc959).

essas duas imagens que você mencionou parece que é um clássico da ilustração do modo ativo e do modo passivo! as encontrei em muitos textos na net.

no link que você sugeriu é muito claro a explicação que se faz em torno dessas duas imagens.

o problema é quando, em outros sites, se utiliza as mesmas imagens para explicar outras questões. aí as explicações não correspondem ao que dizem as imagens. um não dialoga com o outro. é uma confusão...

Não sei se nas suas pesquisas você teve a mesma impressão... mas achei muitos artigos confusos e equivocados na net...

teve um que o texto fazia uma explicação sobre o modo ativo e o passivo... e mais à frente no texto dizia “ou seja” (com o intuito de resumir a explicação).. e aí inverteu toda a explicação que havia dado anteriormente...

raserafim
(usa Slackware)

Enviado em 30/05/2017 - 17:23h

essa passagem que escrevi quatro tópicos meus atrás, contém um equívoco.

não há uma "intercessão" de portas como resultado final para o cliente e o servidor.

na verdade, a comunicação FTP é feita por uma porta (ou conjunto de portas) no lado do cliente e uma porta (ou conjunto de portas) do lado do servidor.

o cliente escolhe a sua porta com base no seu port_ranger e o servidor escolhe a sua porta com base no seu port_range.

apenas para ilustrar, vejamos o extrato abaixo. no cliente defini o port_range entre 26500 e 27500, e no servidor (montei um para teste) entre 45000 e 47000. observe que a porta do cliente utilizada está de acordo com o seu port_range e o do servidor de acordo com o seu.

... PROTO=TCP SPT=46644 DPT=26894 WINDOW=229 RES=0x00 ACK URGP=0  

o port_ranger, por sua vez, segundo novos experimentos que fiz, não se constitui necessariamente em um delimitador impositivo. É possível, inclusive, a depender da configuração, que um programa ignore o port_ranger em /proc/sys/net/ipv4/ip_local_port_rang e defina seus próprios padrões...