El 31/08/16 a las 16:28, Hugo Florentino escribió: > On Wed, 31 Aug 2016 11:39:12 -0400, Ulises Gonzalez wrote: >> On 08/31/2016 11:32 AM, Hugo Florentino wrote: >>> En cualquier caso, ¿qué debería hacerse para permitir a los clientes de >>> una red local saliendo mediante NAT el acceso a servicios tipo push? >> >> >> Normalmente en este caso lo que se hace es que se deja abierto el >> puerto en el FW, es lo que siempre hacemos para servidores web, y >> correo smtp, pero huelo a que tienes un caso raro, que te pasa >> exactamente?? > > Es que los servicios no estarían en el servidor de la red local, la idea > es que los clientes de la red local tengan acceso a servicios push > externos. > > Supongamos que tengo paquetes nuevos supuestamente provenientes de > bloques de direcciones de Google desde los puertos udp/53, tcp/80 o > tcp/443 con destino a un puerto no privilegiado en la dirección ip > externa del cortafuegos, en este caso son descartados por una regla que > tengo para todo paquete que venga de un puerto privilegiado con estado > nuevo. Pero en ocasiones Google utiliza servicios push que podrían estar > siendo detenidos por esta regla. > > No obstante, como el cortafuegos en si no navega (excepto para > update/upgrade) y además tiene políticas de denegación por defecto, los > únicos puertos que tiene abiertos son aquellos donde hay servicios o que > el equipo abre puntualmente para establecer conexiones con el exterior, > por lo demás solo reenvía el tráfico entre los clientes y el exterior. > > De modo que estos paquetes provenientes de Google solo podrían estar > destinados a clientes de la red local, que por cierto utiliza > direcciones reservadas de clase C. Lo curioso es que si permito que el > cortafuegos reenvíe hacia la red local cualquier paquete nuevo > proveniente de Google digamos desde los puertos 80 y 443, de todas > maneras los paquetes son descartados porque el rastreo de conexiones no > ha visto tráfico reciente relacionado entre ningun cliente y Google, de > modo que el cortafuegos no sabe a quien reenviarlos. > > Algo parecido sucede con paquetes provenientes desde direcciones de > Yahoo con el puerto de origen tcp/5050, y desde otras direcciones como > las redes de IMO con los puertos de origen tcp/5223 o 5228, etc. > > De modo que si creo una regla que acepte en las cadenas INPUT y FORWARD > cualquier paquete nuevo proveniente de esos puertos, no solo será por > gusto, sino que además estaré creando una vulnerabilidad innecesaria > porque muchas redes maliciosas envían paquetes nuevos desde puertos > privilegiados con la esperanza de encontrar un cortafuegos mal > configurado que permita su paso. > > Todo esto lo digo basado solo en análisis de trazas y deducción, no es > que esté 100% seguro de que es lo que realmente ocurre. > > Saludos, Hugo > ______________________________________________________________________ > Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. > Gutl-l@jovenclub.cu > https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l hugo no te machaques tanto el coco, eso es por gusto, no es posible lo que quieres, en nuestras redes nateadas, con lan privadas, no es posible hacer push a todos los clientes de la lan, con firewall tan celosos de por medio, como los que configuras con iptables. Como tu mismo lo analizas, si no hay un tráfico previamente de salida, que relaciones a tus clientes con conexiones entrantes, no hay forma de que hagas un port forward de todo lo que venga push a dichos clientes, en estas redes eso no es posible. Salu2.
-- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” ______________________________________________________________________ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
