Bueno, resulta que si desactivo el cortafuegos de Suse el ftp funiona sin problemas, era algo que me quedaba por probar. Si alguien tiene ahora una idea de que puede ser? He iniciado el iptraf, pero con una conexión remota y sin mucho tiempo, asi que lo probaré con mas calma cuando tenga un rato delante de la pantalla... aunque no prometo nada porque no se muy bien como funciona. Otra duda que me ha surgido es donde puedo ver el archivo de log del firewall (o es que no crea un archivo suyo propio¿?), ya que lo encuentro en el Yast -> Miscelanea -> Ver Registro del Sistema, pero mezclada con mas información. Gracias. --- "Carlos E. R." escribió:

El 2006-01-19 a las 10:20 +0100, Marcos Arias Velázquez escribió:

...

Respuesta: 200 Switching to ASCII mode. Comando: PASV Respuesta: 227 Entering Passive Mode (xx,xx,xxx,xxx,xx,xxx) Comando: LIST Error: Transfer channel can't be opened. Reason: Se

Dile que siga en "active mode", por ejemplo.

...

Tengo el puerto 21 abierto en cortafuegos de Suse

y

...

puse también el 20 ya que lei en algun foro que habia que abrirlo,

En el receptor, para modo activo. No en el servidor. En modo pasivo la cosa cambia, se complica en el servidor...

a ver, activa el en servidor el iptraf, y en log del cortafuegos que quieres visualizar todos los paquetes denegados: y a ver que puerto es el que no se abre.

- -- Saludos Carlos Robinson

______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

"Carlos E. R." escribió: El 2006-01-19 a las 17:17 +0100, Marcos Arias Velázquez escribió:

...

Bueno, resulta que si desactivo el cortafuegos de Suse el ftp funiona sin problemas, era algo que me quedaba por probar. Si alguien tiene ahora una idea de que puede ser?

Si, tengo idea, pero no estoy seguro de como se resuelve. El protocolo ftp es puñetero: en modo activo da problemas en el cliente, y en pasivo en el servidor. Elige tu veneno.

*Bueno, creo que el veneno ya lo tengo elegido, el servidor tiene que ser pasivo, para no tener que tocar nada en los clientes

...

He iniciado el iptraf, pero con una conexión remota y sin mucho tiempo, asi que lo probaré con mas calma cuando tenga un rato delante de la pantalla... aunque no prometo nada porque no se muy bien como funciona.

Ves las conexiones que se crean en cada interfase. Si en una de ellas ves un numero de paquetes entrantes, con 0 salientes, ya sabes que no está respondiendo.

Bueno, ya he pasado el iptraf y este es el resultado que obtengo conectandome desde una maquina de la red local y con filtrando solo las conexiones de esta maquina: Con el FileZilla: TCP Connections (Souce Host:Port)---------------Packets-----Bytes Flags Iface ||192.168.1.10:1373 = 16 755 CLOSED eth0 ||192.168.1.200:21 = 20 1114 --A- eth0 ||192.168.1.10:1374 = 3 144 S--- eth0 ||192.168.1.200:40138 = 0 0 ---- eth0 ||192.168.1.200:21 > 1 77 -PA- eth0 ||192.168.1.10:1371 = 1 46 RESET eth0 TCP Connections (Souce Host:Port)---------------Packets-----Bytes Flags Iface ||192.168.1.10:1385 = 15 709 CLOSED eth0 ||192.168.1.200:21 = 20 1114 --A- eth0 ||192.168.1.10:1386 = 3 144 S--- eth0 ||192.168.1.200:58481 = 0 0 ---- eth0 ||192.168.1.200:445 > 1 44 -PA- eth0 ||192.168.1.10:1031 > 1 46 --A- eth0 Con el FireFox: TCP Connections (Souce Host:Port)---------------Packets-----Bytes Flags Iface ||192.168.1.10:1387 = 14 685 -PA- eth0 ||192.168.1.200:21 = 15 1010 --A- eth0 ||192.168.1.10:1388 = 1 48 S--- eth0 ||192.168.1.200:53678 = 0 0 ---- eth0 ||192.168.1.10:1389 = 3 144 S--- eth0 ||192.168.1.200:14024 = 0 0 ---- eth0 Bueno, 192.168.1.200 es el servidor y el 10 el cliente, se puede ver que siempre hay paquetes a los que no se responde, pero no entiendo el porqué. Lo he probado dos veces con el fileZilla y una con el FireFox como clientes. Haber si con esta información tenis alguna idea porque yo no se por donde cogerlo. La última liena que genera el vsftpd en los mensages es siempre la misma: FTP response: Client "192.168.1.10","425 Failed to establish connection"

...

Otra duda que me ha surgido es donde puedo ver el archivo de log del firewall (o es que no crea un archivo suyo propio¿?), ya que lo encuentro en el Yast -> Miscelanea -> Ver Registro del Sistema, pero mezclada con mas información.

Si, está mezclado. Suele ser o /var/log/messages o .../warn o ..../kernel. Se puede separar en el suyo propio si usas syslog-ng. Tendrás que activar en el cortafuegos:

FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="yes" para ver todo lo que rechaza.

OK, veo todo lo que rechaza en /var/log/warm pero tras un intento de conexión no muestra ningun mensage, es decir, es como si el cortafuegos no rechace nada. ¿Alguna idea con esta información? Yo no entiendo mucho de administración y ya estoy un poco perdido. Gracias. --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

El 21/01/06, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

[...]

Si, ya veo el problema. Me lo sospechaba, pero no estaba seguro.

Tienes una conexión entrante (y aleatoria) en los puertos altos, y no puedes saber en que puerto va a entrar a priori, porque el número de puerto se negocia en la conexión de control que va en el 21.

el ftp, utiliza 2 puertos (20 y 21) uno para la conexcion (21) y otros para los datos (20)... y en esto esta el problema para los cortafuegos !!!!

En el cortafuegos tienes la opción de dejar abiertos todos los puertos altos (¡BUFF!),

uacala.

o ver si hay alguna historia para que el cortafuegos siga el estado de las conexiones ftp y sepa que puerto tiene que abrir.

¿Existe eso? Supongo... pero no se como se hace. Creo que eso lo lleva el módulo "ftp conntrack".

si existe, el modulo se llama ip_conntrack_ftp para activarlo: modprobe ip_conntrack_ftp tambien, tiene el ip_conntrack_irc para servidores de irc.. que presentan el mismo inconveniente.

A ver si alguno de los que están por aquí que saben de iptables lo sabe.

salu2. -- -- Victor Hugo dos Santos Linux Counter #224399

El 21/01/06, jose maria escribió:

El Sábado, 21 de Enero de 2006 18:59, Victor Hugo dos Santos escribió:

...

el ftp, utiliza 2 puertos (20 y 21) uno para la conexcion (21) y otros para los datos (20)... y en esto esta el problema para los cortafuegos !!!!

* El problema para los cortafuegos es que usa otro par de ellos mas aleatorios.

yo tengo abierto, solamente los que mencione mas arriba.. y funciona.. el kernel, es lo bastante inteligente para manejar las conexciones que ya fueron estabelecidas !!!!

...

...

¿Existe eso? Supongo... pero no se como se hace. Creo que eso lo lleva el módulo "ftp conntrack".

si existe, el modulo se llama ip_conntrack_ftp

para activarlo: modprobe ip_conntrack_ftp

tambien, tiene el ip_conntrack_irc para servidores de irc.. que presentan el mismo inconveniente.

* E ip_nat_ftp, pero los modulos de seguimiento de conexiones establecidas o relacionadas para ftp, son ñapas que no solucionan el problema principal, que es que el protocolo ftp es de otros tiempos.

yo tengo instalado un ftp anonimo detras de un cortafuegos y por aca, con el modulo que mencione antes, funciona sin mayores problemas.... de verdad, nunca use este modulo que mencionas "ip_nat_ftp" y no podria mencionar nada sobre el !!!!

* La solucion decente es instalar un proxy ftp, es decir proxyficar el protocolo, software como proxy-suite por ejemplo.

estamos hablando del mismo ??? un servidor ftp, a los cuales los clientes externos van bajar/subir archivos en mi servidor ???

* La solucion buena es no usar ftp.

hehehe... pienso el mismo !!!! scp seria una opcion !!!! salu2. -- -- Victor Hugo dos Santos Linux Counter #224399

El Domingo, 22 de Enero de 2006 00:26, Victor Hugo dos Santos escribió:

...

...

el ftp, utiliza 2 puertos (20 y 21) uno para la conexcion (21) y otros para los datos (20)... y en esto esta el problema para los cortafuegos !!!!

* El problema para los cortafuegos es que usa otro par de ellos mas aleatorios.

yo tengo abierto, solamente los que mencione mas arriba.. y funciona.. el kernel, es lo bastante inteligente para manejar las conexciones que ya fueron estabelecidas !!!!

* El kernel no dispone de inteligencia que se sepa, los modulos de iptables para seguimiento de conexiones ftp estan cargados por defecto, tienes una politica por defecto accept y se pueden establecer conexiones a los puertos altos, que es lo que hace el modulo (una ñapa). * ftp hace lo siguiente: * El cliente inicia desde cualquier puerto (puerto X) una peticion hacia el puerto 21 del servidor. Una vez que está establecida la conexión, se envía el comando PORT al servidor, para especificar el número de puerto que debe utilizar el servidor para crear la conexión de datos (puerto Y). Para ciertas operaciones, es necesario realizar el envío de un fichero, por lo que se crea el canal de datos. Para ello el servidor crea una conexión física desde su puerto 20 hasta un número de puerto del cliente. Este número de puerto fue el que indicó el cliente a través del comando PORT (puerto Y). De este modo, el servidor establece el canal de datos por el que se transmite la información. * El anterior esquema es el modo activo, porque es el servidor el que activamente crea el canal de datos. * modo pasivo: * El cliente arranca e intenta conectarse contra el servidor. Para ello crea un canal de control estableciendo una conexión física a la dirección IP (o nombre de dominio) del servidor, y desde cualquier puerto del cliente (puerto X) hacia el puerto 21 del servidor. (este punto es igual que en el modo activo). * El cliente envía el comando PASV para activar el modo pasivo. Como respuesta a este comando, el servidor retorna un número de puerto que tenga disponible (puerto Z). * Para ciertas operaciones, es necesario realizar el envío de un fichero, por lo que se crea el canal de datos. Para ello el cliente crea una conexión física desde uno de sus puerto (puerto Y) hasta un número de puerto del servidor. * Este número de puerto fue el que indicó el servidor como respuesta del comando PASV (puerto Z). De este modo, el cliente establece el canal de datos por el que se transmite la información. * La principal diferencia es que en el modo pasivo es el cliente el que inicia las conexiones y nunca el servidor. * Supongamos que nuestra conexión a internet utiliza un cortafuegos. * El principal cometido del cortafuegos es cerrar los puertos para conexiones entrantes, es decir: que sobre ciertos puertos sea imposible realizar una conexión remota. * Si el cliente FTP utiliza un cortafuegos, y se utiliza el modo activo de conexión, tendremos muchas posibilidades de que no funcione correctamente, ya que cuando el servidor necesite abrir el canal de datos, se podría utilizar uno de los puertos que el cortafuegos del cliente mantiene cerrado. * Sin embargo, en el modo pasivo, un cortafuegos no supone ningún problema en el cliente, ya que las conexiónes siempre las inicia el cliente, y el servidor nunca intentará abrir una conexión con el cliente, traspasandose el problema de seguridad al servidor (o no poderse establecer la conexion) por que los puertos pedidos estan filtrados en el servidor. * Si a esto le añades que hay que definir modos de transmision (ascii o binario) estamos en un protocolo de otros tiempos, es preferible un servidor web para las descargas anonimas, si no se pretenden otras funcionalidades no hace falta poner apache, boa por ejemplo, hay servidores web minimos implementados hasta en bash.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-21 a las 17:50 +0100, Jordi Espasa Clofent escribió:

En el vsftpd no sé, pero en Pure-FTPd existe la opción -p / --passiveportrange que precisamente se usa para solventar (o, al menos, aliviar, esta problemática).

También lo tiene: pasv_max_port y pasv_min_port. En cuanto lo he mirado en el manual lo he encontrado. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD0t61tTMYHG2NR9URApxtAJ0di3+RERuBG+0jm0Kux8gz3bJbeQCfY/dZ mqQy9i+/0CtXlVIeV6F+gBs= =eXfT -----END PGP SIGNATURE-----