On Monday 08 November 2004 08:27, Foros wrote:

Pero, según tengo entendido, cuando un cliente establece una conexión al puerto 21 tcp de un servidor FTP, éste cambia la conexión del puerto 21 a otro puerto, ¿es esto correcto?.

Pues si estas hablando de como funciona servidores de TCP en general, la respuesta es: Si, pero no te procupes. El firewall sabes eso tambien, y cuando le dises que deje que algien de afuera se connecte con FTP, el deja tambien que la connection se mantega despues del cambio. Pero si estas hablando de como funciona FTP, la respuesta es: hay otros puertos para los datos, de estos puertos exscoje el servidor uno. Esta manera de trabajar presenta muchos problemas para gente que estan atras de un firewall. Por eso hay una option "PASSIV", que le dice al servidor del firewall que no lo haga haci. Yo solo he utilizado el metodo "PASSIV", hacique aqui no te puedo ayudar... Jerry

Hola, On Mon, 8 Nov 2004 14:17:44 +0100, Eloy Mier wrote:

Bueno, ten en cuenta que si el servidor atendiese toda tu petición por el puerto 21 no podria atender a nadie mas, pues a ese puerto no podria conectar.

No me gusta polemizar, pero creo que estás un poco equivocado. Intentaré ser lo más breve posible (me ahorraré detalles). El protocolo FTP es un poco singular porque utiliza dos canales de comunicación, uno para comandos y otro para datos. Cuando un usuario (cliente) se conecta al servidor FTP, lo hace por el canal de comandos (puerto 21 del servidor, puerto > 1024 en el cliente), puerto que se mantiene abierto durante toda la conexión. En el momento en el que el cliente solicita algún dato (ls, put, get, etc.) tienen que ponerse de acuerdo en el nuevo canal a utilizar, lo hacen por el canal de comandos obviamente, aquí existen dos métodos. 1.- Método tradicional (activo): El cliente elige un puerto libre > 1024 e informa al servidor de este puerto para que sea él quien conecte desde su puerto 20 al puerto del cliente que ya lo tiene preparado para recibir datos (OJO puerto e IP) 2.- Método moderno (pasivo): El cliente pide al servidor que elija un puerto y el servidor informa del puerto (> 1024) donde abrirá el canal de datos, ahora es el cliente el que abre un nuevo puerto (>1024) para establecer la conexión el puerto indicado por el servidor. Según usemos un método u otro tendremos que configurar el firewall para que deje pasar los dos canales. El canal de comandos es obvio, pero el de datos genera bastantes problemas. En el método tradicional nos encontramos con el problema del NAT. Si el cliente está conectandose a través de una pasarela NAT resulta que la información que da al servidor FTP es un puerto de una IP privada, con lo que el servidor no llegará a conectar nunca. Por otro lado, el firewall del cliente normalmente no debería aceptar conexiones nuevas desde el "exterior" al "interior". En el método pasivo el firewall tiene que permitir una nueva conexión dinámica desde un puerto alto a otro alto, pero esto permitiría cualquier tipo de tráfico sea FTP o no. Para evitar estos problemas el firewall (en el método 1 el firewall del cliente y en el método 2 el del servidor FTP) debe saber que estas nuevas conexiones están relacionadas con el canal de comandos y para ello linux tiene los módulos ip_conntrack, ip_conntrack_ftp e ip_nat_ftp e 'iptables' tiene la opción RELATED en sus reglas.

On Mon, 8 Nov 2004 18:18:33 +0100, Jesus Gonzalez wrote:

Hola,

On Mon, 8 Nov 2004 14:17:44 +0100, Eloy Mier wrote:

...

Bueno, ten en cuenta que si el servidor atendiese toda tu petición por el puerto 21 no podria atender a nadie mas, pues a ese puerto no podria conectar.

No me gusta polemizar, pero creo que estás un poco equivocado.

Ok, no soy experto en la materia y nunca he estudiado el protocolo ftp, por lo tanto creo lo que dices sin problema.

Intentaré ser lo más breve posible (me ahorraré detalles).

El protocolo FTP es un poco singular porque utiliza dos canales de comunicación, uno para comandos y otro para datos.

Cuando un usuario (cliente) se conecta al servidor FTP, lo hace por el canal de comandos (puerto 21 del servidor, puerto > 1024 en el cliente), puerto que se mantiene abierto durante toda la conexión.

En el momento en el que el cliente solicita algún dato (ls, put, get, etc.) tienen que ponerse de acuerdo en el nuevo canal a utilizar, lo hacen por el canal de comandos obviamente, aquí existen dos métodos.

1.- Método tradicional (activo): El cliente elige un puerto libre > 1024 e informa al servidor de este puerto para que sea él quien conecte desde su puerto 20 al puerto del cliente que ya lo tiene preparado para recibir datos (OJO puerto e IP) 2.- Método moderno (pasivo): El cliente pide al servidor que elija un puerto y el servidor informa del puerto (> 1024) donde abrirá el canal de datos, ahora es el cliente el que abre un nuevo puerto (>1024) para establecer la conexión el puerto indicado por el servidor.

Como puedo apreciar, el puerto 21 queda disponible para nuevas conexiones. No exactamente de la forma que yo habia comentado, pero bueno.

Según usemos un método u otro tendremos que configurar el firewall para que deje pasar los dos canales. El canal de comandos es obvio, pero el de datos genera bastantes problemas.

En el método tradicional nos encontramos con el problema del NAT. Si el cliente está conectandose a través de una pasarela NAT resulta que la información que da al servidor FTP es un puerto de una IP privada, con lo que el servidor no llegará a conectar nunca. Por otro lado, el firewall del cliente normalmente no debería aceptar conexiones nuevas desde el "exterior" al "interior".

En el método pasivo el firewall tiene que permitir una nueva conexión dinámica desde un puerto alto a otro alto, pero esto permitiría cualquier tipo de tráfico sea FTP o no.

Para evitar estos problemas el firewall (en el método 1 el firewall del cliente y en el método 2 el del servidor FTP) debe saber que estas nuevas conexiones están relacionadas con el canal de comandos y para ello linux tiene los módulos ip_conntrack, ip_conntrack_ftp e ip_nat_ftp e 'iptables' tiene la opción RELATED en sus reglas.

--

Un saludo. Eloy

Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com