Re: sobre vsftp y firewall
Ah, ok, ya tenemos algo mas conciso entonces.
(escibe a la lista, mejor, o te mando la factura :)
> Yo creo que es el firewall, porque en la red interna donde mi servidor
> tiene dos ips una que es 192.168.0.1 y otra que es 24.232.212.155
> Si desde una maquina de la red interna conecto al ftp
> ftp 192.168.0.1 10021
> me pide usuario, contraseña y anda perfecto.
ok, coincido, el ftpd se ve bien.
> ahora si desde el exterior intento conectarme
> 24.232.212.155 sale para autenticar, pero no ingresa.
A ver, entiendo que tienes una conexion a internet con una IP real, y la
estas
compartiendo con una red local con un NAT (enmascarador) que a su vez
la hace de firewall (en este caso es dificil separar estas funciones),
correcto?
Y tu servidor FTP esta en una maquina en la red local, o esta en el mismo
ruteador?
> yo creo que viene por el lado de las conexiones pasivas, o algo asi
> hay algo en los puertos. Por esto le atribuyo la culpa al firewall.
En efecto, el FTP es un protocolo algo "tricky". En modo activo (default) el
cliente inicializa una conexion "de comandos" hacia el servidor, y cada que
hace
falta el servidor inicializa una conexion "de datos" hacia el cliente, para
eso el
cliente le dice en que IP y en que puerto va a escuchar. En modo pasivo
ambas
conexiones se originan por iniciativa del cliente. Si tu servidor y/o tu
cliente esta
atras de un NAT, se vuele un tanto dificil, ya que alguno de los dos no es
contactable
directamente por tener una IP privada. Se la pueden comunicar a la otra
parte, pero
no le sirve de nada, ya que no se rutea. La conexion de datos se usa no solo
para
transferir archivos como tal, sino al desplegar el listado de directorios, y
creo que
para otras cosas tambien. El hecho es que si no es posible establecer
conexion de datos,
no puedes hacer nada con el servidor ftp, salvo exploitearlo en algunos
casos :)
Afortunadamente, existen modulos para el kernel para "reescribir" estos
datos.
Son ip_nat_ftp y ip_conntrack_ftp (asegurate de compilarlos y hacer
referencia
a ellos en /etc/modules o en tu script de firewall, de preferencia lo
primero)
Asi cuando se manda info sobre a que IP y a que puerto se debe de mandar la
conexion
de datos, si es nesesario (dependiendo del mode de ftp) el ruteador
sustituye la IP por
la suya, y escucha en el puerto apropiado para pasarle el trafico al cliente
FTP (o servidor,
si se usa modo pasivo).
Muy util el asunto.
Ahora al grano:
$IPTABLES -A INPUT -p tcp --dport 10019:11000 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 10019:11000 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
No se que tan funcional sea esto si se trata de un ftpd en la misma maquina
(es mas, de donde sacaste esas reglas?), en tal caso basta que aceptes y
dejes salir
conexiones en el rano de puertos deseado, pero si el servidor esta en la LAN
y quieres accesarlo desde afuera, lo conveniente es incertar en el kernel
los modulos
mencionados y hacer una sola regla de tipo:
iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 21 -j DNAT --to
10.10.1.20
donde la ppp0 es la interfase que ve al mundo y tiene una IP real y
10.10.1.20 es
la IP destino en la red local.
El numero del puerto de la maquina en la LAN por default es el mismo que el
original,
si quieres especificar explicitamente un puerto de la maquina
en la LAN, puedes hacerlo por anotacion estandar: 10.10.1.20:10021.
Hacer referencia a la interface externa (no a la IP externa) es
particularmente
util si se trata de una conexion con IP dinamica.
Ahora, debes tener algo de consideraicon en cuanto a las demas reglas, de
tal forma
que dejes pasar las conexiones de datos. La regla general, es no poner
ninguna regla
cuyo significado, nesecidad y funcionamiento no te sean claros.
Por lo general, no nesecitas nada adicional a las reglas que enmascaran y
hacen el forward
en un firewall, la simple naturaleza del NAT protege tus maquinas, salvo que
no solo
quieras proteger a tus usuarios del mundo, sino al mundo de tus usuarios
(bloqueando ciertas
conexiones salientes, a reconocidos servidores porno, por ejemplo, o a
smtp's esternos si hay
uno interno y no quieres que tus usuarios envien virus o spameen). Solo
cuida de no hablitar
hacia afuera ningun servicio que no desees dar (pop, smpt, etc.). Es mas
sano hacer que los
demonios dejen de escuchar en la interface externa, que bloquearlos
explicitamente por
un firewall (que tal si pasa algo y tu script de firewall no se corre?).
Calro, una solucion
burda en efeco es bloquear todo y dejar entrar solo lo que nesecitas, pero
quieremos hacer
algo elegante, no?
> Ademas, acabo de probarlo yo mismo, y si no deshabilito el firewall ni
> veo la autenticacion... (el que hacia la prueba desde otro lado me dijo
> cualquier cosa).
O sea, dejas de enmascarar y hacer forward, supongo. Bueno, es el sintoma
mas logico.
Tambien toma en cuenta, que usando la manera de exponer servicios que te he
sugerido, no pordras
accederlos desde la LAN usando la IP externa, no se porque, no me he tomado
la molestia de
averiguarlo a falta de nesecidad. :)
Tal vez si en la regla en vez de decir "todo lo que venda en esta interface"
dices
"todo lo que venga a esta IP", podras hacerlo, falta que lo nesecites y
pruebes, la
sintaxis te la dejo de tarea.
> Te agradeceria cualquier ayuda
np.
Reply to: