evitar mapeos de red
Aldrin Martoq escribió: On Fri, 2008-09-19 at 14:01 -0400, Sebastian Veloso Varas wrote: Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: A veces, por muy sobreevaluadas, se nota la diferencia y efectividad entre ellas. No creo que haya tanta. Salvo que tengas una red de Giga, un tarro de lo mas picante se la puede sin problemas corriendo un Linux configurado como la gente. Me refería a las tecnologias de filtrado y seguridad de las competencias, mas que sobreevaluado en prestaciones o throughput. Cada propietario de productos de seguridad tiene sus mecanismos personalizados en el mercado para entregar seguridad en nuestras redes y servicios. Te puedo contar una historia cortita: yo antes solia tener antiviruses; ah, y por supuesto utilizar el ad-aware no se cuantito y cuanto producto que existiara en el mercado, porque o si no supuestamente estaria re-jodido y estaria infectado y los mil demonios me llegarian. Eso porque tenia windows 2000 o windows xp. Todo eso cuando la solucion es resencilla: trabajar de verdad en Linux por ejemplo (o incluso MacOS). Aca no existen los viruses o mas bien dicho, las posibilidades de infeccion son ridiculamente bajas... No sabes la cantidad de horas que recupere des-preocupandome de este problemita. Actualmente sigo ocupando Windows XP, no se si tendra virus o algo, pero jamas lo uso para cosas importantes... Fue curioso darse cuenta que si eliminas la fuente del problema no necesitas ninguna solucion ya que no hay problema! La moraleja de esta historia? Que la necesidad de seguridad es mayormente inventada. Ninguna soluciona el problema de fondo, sino que lo parchan. Y lo peor, es que el parche es excesivamente caro... Ahora, mi pega de sysadmin fue hace unos 8-10 an~os.. en ese entonces, podias contactar a [EMAIL PROTECTED] ... Las cosas han cambiado mucho, y claramente la cantidad y complejidad de los problemas han aumentado; pero siempre he seguido la misma politica: utilizar un producto que venga bien configurado o que tenga alguna politica de seguridad buena... un caso notable es Debian por ejemplo. Hay montones de cosas mas que influyen, por ejemplo que tan complejo es el sistema... Pero la idea basica es no parchar, sino usar cosas de calidad y/o que respondan rapida y facilmente a los problemas. Lamentablemente, como administrador me toca liar con Windows ..y en toda su palabra !! desde escritorio hasta servidores y no por cuestiones mias, es muy complicado (aún) imponer en la mayoria de las empresas sistemas libres (por lo menos en servidores si) , puesto que hay necesidades puntuales de trabajo que te forzan a usar Windows. En mi caso personal, uso los 2 ambientes, no voy a entrar en polémicas de Win vs Linux pero claramente (hasta por forma de trabajo) me adapto mejor a un Linux. Lo mismo pasa con soluciones de seguridada pesar de que uno puede porfiar y hasta demostrar que un firewall sea Linux, BSD (mis preferidos este ultimo), no confian mucha gente ... y prefieren gastar millonadas de plata (pasa mucho en empresas grandes!) Estoy muy de acuerdo en lo que dices tu, el mercado se preocupa de parchar las plataformas en vez de cortar de raíz el tema. Somos una especie culpables-victimas del mercado, no crees? Yo he tenido la oportunidad de montar sistemas completos en entornos libres y en entornos completamente en Microsoft ... y sabes por que? Por que hay gente que te lo pide! y como dicen ... el cliente tiene la razónuna opinión mas basada en lo que es el mercado. Mi filosofia? Ojala fuera todo Unix/Linux!!! =) -- Sebastián Veloso Varas Seguridad y Comunicaciones E-Mail : [EMAIL PROTECTED] Móvil : 9-4968717 WebSite : http://www.sevelv.cl
evitar mapeos de red
Sebastian Veloso Varas wrote: Aldrin Martoq escribió: On Fri, 2008-09-19 at 14:01 -0400, Sebastian Veloso Varas wrote: Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: A veces, por muy sobreevaluadas, se nota la diferencia y efectividad entre ellas. No creo que haya tanta. Salvo que tengas una red de Giga, un tarro de lo mas picante se la puede sin problemas corriendo un Linux configurado como la gente. Me refería a las tecnologias de filtrado y seguridad de las competencias, mas que sobreevaluado en prestaciones o throughput. Cada propietario de productos de seguridad tiene sus mecanismos personalizados en el mercado para entregar seguridad en nuestras redes y servicios. Te puedo contar una historia cortita: yo antes solia tener antiviruses; ah, y por supuesto utilizar el ad-aware no se cuantito y cuanto producto que existiara en el mercado, porque o si no supuestamente estaria re-jodido y estaria infectado y los mil demonios me llegarian. Eso porque tenia windows 2000 o windows xp. Todo eso cuando la solucion es resencilla: trabajar de verdad en Linux por ejemplo (o incluso MacOS). Aca no existen los viruses o mas bien dicho, las posibilidades de infeccion son ridiculamente bajas... No sabes la cantidad de horas que recupere des-preocupandome de este problemita. Actualmente sigo ocupando Windows XP, no se si tendra virus o algo, pero jamas lo uso para cosas importantes... Fue curioso darse cuenta que si eliminas la fuente del problema no necesitas ninguna solucion ya que no hay problema! La moraleja de esta historia? Que la necesidad de seguridad es mayormente inventada. Ninguna soluciona el problema de fondo, sino que lo parchan. Y lo peor, es que el parche es excesivamente caro... Ahora, mi pega de sysadmin fue hace unos 8-10 an~os.. en ese entonces, podias contactar a [EMAIL PROTECTED] ... Las cosas han cambiado mucho, y claramente la cantidad y complejidad de los problemas han aumentado; pero siempre he seguido la misma politica: utilizar un producto que venga bien configurado o que tenga alguna politica de seguridad buena... un caso notable es Debian por ejemplo. Hay montones de cosas mas que influyen, por ejemplo que tan complejo es el sistema... Pero la idea basica es no parchar, sino usar cosas de calidad y/o que respondan rapida y facilmente a los problemas. Lamentablemente, como administrador me toca liar con Windows ..y en toda su palabra !! desde escritorio hasta servidores y no por cuestiones mias, es muy complicado (aún) imponer en la mayoria de las empresas sistemas libres (por lo menos en servidores si) , puesto que hay necesidades puntuales de trabajo que te forzan a usar Windows. En mi caso personal, uso los 2 ambientes, no voy a entrar en polémicas de Win vs Linux pero claramente (hasta por forma de trabajo) me adapto mejor a un Linux. Esa es una realidad de muchos, sino algunos qué comeriamos? Lo mismo pasa con soluciones de seguridada pesar de que uno puede porfiar y hasta demostrar que un firewall sea Linux, BSD (mis preferidos este ultimo), no confian mucha gente ... y prefieren gastar millonadas de plata (pasa mucho en empresas grandes!) En las empresas grandes no les importa gastar burradas de plata si es que va en pro de la seguridad, aunque sea sólo una falsa sensación. Lamentablemente ellos ven un appliance (por ejemplo) más seguro por muy mal comportamiento que tenga a futuro. Estoy muy de acuerdo en lo que dices tu, el mercado se preocupa de parchar las plataformas en vez de cortar de raíz el tema. Somos una especie culpables-victimas del mercado, no crees? Yo he tenido la oportunidad de montar sistemas completos en entornos libres y en entornos completamente en Microsoft ... y sabes por que? Por que hay gente que te lo pide! y como dicen ... el cliente tiene la razónuna opinión mas basada en lo que es el mercado. Mi filosofia? Ojala fuera todo Unix/Linux!!! =) Una utopía, aunque tambien me gusta Linux ¿que pasaría si no exisitesen otras alternativas?...¿todavía usariamos Windows?...bueno, creo que esto esta un poco off-topic Saludos
evitar mapeos de red
On Thu, 18 Sep 2008 22:04:58 -0400, Horst H. von Brand [EMAIL PROTECTED] wrote: Jorge Luis Rodriguez [EMAIL PROTECTED] wrote: les cuento mi problema, resulta que tenemos una red clase A con el rango de ip 10.0.0.xxx, con salida a internet y algunos servicios para la red interna, dentro de esta red instales un servidor con debian, ese servidor tiene la eth0 con ip 10.0.0.150, y una eth1 con ip 192.168.1.1. Resulta que con el scrips que posteso mas abajo funciona perfecto, pero no logro evitar que desde la red interna se pueda mapear la red de clase A (10.0.0.xxx), probe con nmap, languard, y en ambos caso si mapeo el rango de ip 10.0.0.1-10.0.0.250 estando en la red de clase C (192.168.1.1) puedo ver todas las pc que estan en la red 10.0.0.xxx. Eh buscado y leido mucho, quizas la solucion sea una tontera, pero bueno, lo cierto es que no logro ver la socucion entre todo lo que ley y busque. basicamente lo que deseo es que desde la red 192.168.1.xxx no se puedan hacer scaneos de red hacia la red 10.0.0.xxx [Resumen] Amigo aunque medio off-topic, supongo que si tiene una red de ese tipo , también tendra switch's administrables que soporten VLAN. Yo dejaría a la red 10.0.0.0/8 en una VLAN y la 192.168.1.0/24 en otra. Se supone que el servidor tendría 2 interfaces de red por lo que fisicamente la puedes conectar en puertos diferentes y asignarles una VLAN a cada uno. Con eso te evitas los scaneos a esa red e incluso ahorras el trafico tipo broadcast que le pueda llegar de la red clase C. En definitiva nunca se verían excepto por el equipo conectado a las 2 VLAN (que en el fondo hace de router ya que esta directamente conectado a las vlan pero que en este caso puedes borrar la ruta desde la red clase C hacia la red 10.0.0.0/8). Sinceramente no veo mucho el sentido de aplicar más reglas o considerar appliance's. (Eso si tienes los switch que necesitas). Saludos. -- Informatica Bio-Bio Comunicaciones S.A Administrador de Redes Fono : 09-1523359
evitar mapeos de red
On Fri, 2008-09-19 at 23:50 -0400, Sebastian Veloso Varas wrote: Lamentablemente, como administrador me toca liar con Windows ..y en toda su palabra !! desde escritorio hasta servidores y no por cuestiones mias, es muy complicado (aún) imponer en la mayoria de las empresas sistemas libres (por lo menos en servidores si) , puesto que hay necesidades puntuales de trabajo que te forzan a usar Windows. En mi caso personal, uso los 2 ambientes, no voy a entrar en polémicas de Win vs Linux pero claramente (hasta por forma de trabajo) me adapto mejor a un Linux. Lo mismo pasa con soluciones de seguridada pesar de que uno puede porfiar y hasta demostrar que un firewall sea Linux, BSD (mis preferidos este ultimo), no confian mucha gente ... y prefieren gastar millonadas de plata (pasa mucho en empresas grandes!) Estoy muy de acuerdo en lo que dices tu, el mercado se preocupa de parchar las plataformas en vez de cortar de raíz el tema. Somos una especie culpables-victimas del mercado, no crees? Yo he tenido la oportunidad de montar sistemas completos en entornos libres y en entornos completamente en Microsoft ... y sabes por que? Por que hay gente que te lo pide! y como dicen ... el cliente tiene la razónuna opinión mas basada en lo que es el mercado. Mi filosofia? Ojala fuera todo Unix/Linux!!! =) Ojo que aca tambien hay cosas malas. PHPNuke se me viene a la memoria y estoy seguro que hay mas y peores. Y tambien hay cosas buenas en otros lados, el ejemplo de los viruses era algo cotidiano; pero no se trata de que nosotros somos los buenos y el resto los malos... -- Aldrin Martoq [EMAIL PROTECTED] http://aldrinvideopodcast.podshow.com/
evitar mapeos de red
Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: [...] Primero que todo, que tipo de scans estas realizando por nmap u otra herramienta hacia la red 10? Yo sugiero que controles los tipos de ataques con PortScan Attack Detector psad (http://cipherdyne.org/psad/). Una de las debilidades de Iptables es esta. Cual debilidad? Si el port esta disponible, esta disponible. Y por muy creativo que te pongas en ocultarlo a usuarios ilegitimos, cualquiera se puede hacer pasar por usuario legitimo facilmente y pasar igual. Ocultar ports disponibles para scans de nada sirve, por lo demas: Supongo que habran visto el incesante martilleo a SSH, incluso a maquinas que no tienen SSH. Para un atacante con suficientes recursos a la mano (botnet) es mas rentable simplemente tirarse en picada contra todo lo que tenga direccion IP que darse el trabajo de revisar antes. No me refiero a los ports abiertos, mas bien me refiero evitar el ataque en si. La idea de un firewall aparte de la publicacion segura de servicios, es mantener un mecanismo capaz de repeler ataques a dichas maquinas; los fabricantes de firewalls implementan distintas formas de hacerlo, mediante reglas de control de conexiones para evitar ataques indebidos o tecnologias propietarias que realicen esta funcion. Un mecanismo mas eficaz de seguridad medianamente eficaz siempre, a mi parecer, debe ser un arquitectura de denegacion de acceso indebidos (firewall) y un mecanismo de prevención de ataques y riesgos de las redes (IDS/IPS). -- Sebastián Veloso Varas Seguridad y Comunicaciones E-Mail : [EMAIL PROTECTED] Móvil : 9-4968717 WebSite : http://www.sevelv.cl
evitar mapeos de red
Sebastian Veloso Varas [EMAIL PROTECTED] wrote: Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: [...] Primero que todo, que tipo de scans estas realizando por nmap u otra herramienta hacia la red 10? Yo sugiero que controles los tipos de ataques con PortScan Attack Detector psad (http://cipherdyne.org/psad/). Una de las debilidades de Iptables es esta. Cual debilidad? Si el port esta disponible, esta disponible. Y por muy creativo que te pongas en ocultarlo a usuarios ilegitimos, cualquiera se puede hacer pasar por usuario legitimo facilmente y pasar igual. Ocultar ports disponibles para scans de nada sirve, por lo demas: Supongo que habran visto el incesante martilleo a SSH, incluso a maquinas que no tienen SSH. Para un atacante con suficientes recursos a la mano (botnet) es mas rentable simplemente tirarse en picada contra todo lo que tenga direccion IP que darse el trabajo de revisar antes. No me refiero a los ports abiertos, mas bien me refiero evitar el ataque en si. Bloquea acceso al port. Asegurate que los programas que dan a la red sean solo los necesarios, esten al dia, bien configurados. Cualquier otra cosa es falsa sensacion de seguridad (si, es bastante facil que se te cuele un malandrin a la red local; despues de eso, toda la proteccion contra el frio e impersonal mundo de Internet vale hongo). Sin contar que (segun a que estadistica quieras creer) entre un 85 y 95% de los ataques tienen alguna componente interna... La idea de un firewall aparte de la publicacion segura de servicios, es mantener un mecanismo capaz de repeler ataques a dichas maquinas; los fabricantes de firewalls implementan distintas formas de hacerlo, mediante reglas de control de conexiones para evitar ataques indebidos o tecnologias propietarias que realicen esta funcion. No. /Cobran/ por eso, lo usan como justificacion para que les compres sus (sobrevaluadas) soluciones, y lo usan como herramienta para mantener cautivos a los clientes. De pocazo sirve, en la practica. Un mecanismo mas eficaz de seguridad medianamente eficaz siempre, a mi parecer, debe ser un arquitectura de denegacion de acceso indebidos (firewall) No. La mejor manera de impedir accesos no debidos es que /no existan/ los accesos. Cualquier otra cosa es (cuando mucho) una mitigacion (mas o menos debil) del problema. Ver los comentarios arriba. y un mecanismo de prevención de ataques y riesgos de las redes (IDS/IPS). Prevencion de ataques conocidos? Corregir lo atacado. Prevenir ataques desconocidos? Auditoria del codigo, pruebas, configuracion cuidadosa, monitoreo. IPS? Puedes meterte en lios legales si inicias accion defensiva... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 From [EMAIL PROTECTED] Fri Sep 19 00:56:42 2008 From: [EMAIL PROTECTED] (Sebastian Veloso Varas) Date: Fri Sep 19 00:56:39 2008 Subject: evitar mapeos de red In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: [...] Primero que todo, que tipo de scans estas realizando por nmap u otra herramienta hacia la red 10? Yo sugiero que controles los tipos de ataques con PortScan Attack Detector psad (http://cipherdyne.org/psad/). Una de las debilidades de Iptables es esta. Cual debilidad? Si el port esta disponible, esta disponible. Y por muy creativo que te pongas en ocultarlo a usuarios ilegitimos, cualquiera se puede hacer pasar por usuario legitimo facilmente y pasar igual. Ocultar ports disponibles para scans de nada sirve, por lo demas: Supongo que habran visto el incesante martilleo a SSH, incluso a maquinas que no tienen SSH. Para un atacante con suficientes recursos a la mano (botnet) es mas rentable simplemente tirarse en picada contra todo lo que tenga direccion IP que darse el trabajo de revisar antes. No me refiero a los ports abiertos, mas bien me refiero evitar el ataque en si. Bloquea acceso al port. Asegurate que los programas que dan a la red sean solo los necesarios, esten al dia, bien configurados. Cualquier otra cosa es falsa sensacion de seguridad (si, es bastante facil que se te cuele un malandrin a la red local; despues de eso, toda la proteccion contra el frio e impersonal mundo de Internet vale hongo). Sin contar que (segun a que estadistica quieras creer) entre un 85 y 95% de los ataques tienen alguna componente interna... Si pero
evitar mapeos de red
2008/9/19 Sebastian Veloso Varas [EMAIL PROTECTED]: Pienso que si mientras mas obstaculos le pones al individuo que quiere acceder de la forma que sea a un sistema, menos riesgos se corre; Mientras más código ay sí, Más cosas pueden fallar, Y espérate que te cuento, que Murphy se va a presentar Se presenta ay sí, y siempre de la peor forma. y tu jefe te hará encontrar, el zapato de tu horma. (Mish, no sabía que era payador) Si intentas poner soluciones de seguridad en tu ecuación, intenta que sean lo suficientemente separadas como para prescindir de ellas sin que el resto deje de funcionar. Si pones demasiado esfuerzo por asegurar una cosa, deberías cuestionarte sobre algunas cosas. Al tratar de acordarme de los ejemplos, me acordé de puras cosas que no vienen muy al caso, así que escribí los cuestionamientos en mi blog, aprovechando de que ya hace como cinco o seis días que no escribía nada. http://www.thecodekeeper.net/blog/archivos/2008/09/19/50-Que-tan-seguro-debe-ser-un-sistema.html Saludos, -- Rodrigo Fuentealba http://www.thecodekeeper.net/
evitar mapeos de red
Rodrigo Fuentealba escribió: 2008/9/19 Sebastian Veloso Varas [EMAIL PROTECTED]: Pienso que si mientras mas obstaculos le pones al individuo que quiere acceder de la forma que sea a un sistema, menos riesgos se corre; Mientras más código ay sí, Más cosas pueden fallar, Y espérate que te cuento, que Murphy se va a presentar Se presenta ay sí, y siempre de la peor forma. y tu jefe te hará encontrar, el zapato de tu horma. (Mish, no sabía que era payador) Si intentas poner soluciones de seguridad en tu ecuación, intenta que sean lo suficientemente separadas como para prescindir de ellas sin que el resto deje de funcionar. Si pones demasiado esfuerzo por asegurar una cosa, deberías cuestionarte sobre algunas cosas. Al tratar de acordarme de los ejemplos, me acordé de puras cosas que no vienen muy al caso, así que escribí los cuestionamientos en mi blog, aprovechando de que ya hace como cinco o seis días que no escribía nada. http://www.thecodekeeper.net/blog/archivos/2008/09/19/50-Que-tan-seguro-debe-ser-un-sistema.html Saludos, Creo que el mundo de la seguridad tiene un espectro muy amplio, siempre sujeto a probabilidades de errores, por eso hay que ser constante y bien ordenado en todo, evitar dejar cosas que se te escapen. -- Sebastián Veloso Varas Seguridad y Comunicaciones E-Mail : [EMAIL PROTECTED] Móvil : 9-4968717 WebSite : http://www.sevelv.cl
evitar mapeos de red
algo al respecto. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 From [EMAIL PROTECTED] Fri Sep 19 14:01:20 2008 From: [EMAIL PROTECTED] (Sebastian Veloso Varas) Date: Fri Sep 19 14:01:13 2008 Subject: evitar mapeos de red In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: Horst H. von Brand escribió: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: Horst H. von Brand escribiÃ?³: Sebastian Veloso Varas [EMAIL PROTECTED] wrote: [...] Primero que todo, que tipo de scans estas realizando por nmap u otra herramienta hacia la red 10? Yo sugiero que controles los tipos de ataques con PortScan Attack Detector psad (http://cipherdyne.org/psad/). Una de las debilidades de Iptables es esta. Cual debilidad? Si el port esta disponible, esta disponible. Y por muy creativo que te pongas en ocultarlo a usuarios ilegitimos, cualquiera se puede hacer pasar por usuario legitimo facilmente y pasar igual. Ocultar ports disponibles para scans de nada sirve, por lo demas: Supongo que habran visto el incesante martilleo a SSH, incluso a maquinas que no tienen SSH. Para un atacante con suficientes recursos a la mano (botnet) es mas rentable simplemente tirarse en picada contra todo lo que tenga direccion IP que darse el trabajo de revisar antes. No me refiero a los ports abiertos, mas bien me refiero evitar el ataque en si. Bloquea acceso al port. Asegurate que los programas que dan a la red sean solo los necesarios, esten al dia, bien configurados. Cualquier otra cosa es falsa sensacion de seguridad (si, es bastante facil que se te cuele un malandrin a la red local; despues de eso, toda la proteccion contra el frio e impersonal mundo de Internet vale hongo). Sin contar que (segun a que estadistica quieras creer) entre un 85 y 95% de los ataques tienen alguna componente interna... Si pero creo que lo estas enfocando mas a la solucion de red, Solucion de red no hay. Si estas en red, eres alcanzable (esa es la idea de la red!); si lo alcanzable es vulnerable, estas matriculado (o lo estaras pronto). Solo es valido en el (improbable) caso en que tienes estricto control sobre la red desde la cual es alcanzable. y no tan aplicativa (aunque esa tarea me dirás, debe ser corregida en el servicio publicado y no en el firewall =) ). Bingo! Muchos errores y vulnerabilidades las explotan por fallas de aplicacion, por ende, obviamente a parte de mantener los servicios publicados lo mas seguros. No muchos, todos! Salvo los casos de configuracion idiota, que no son tan infrecuentes tampoco... La idea de un firewall aparte de la publicacion segura de servicios, es mantener un mecanismo capaz de repeler ataques a dichas maquinas; los fabricantes de firewalls implementan distintas formas de hacerlo, mediante reglas de control de conexiones para evitar ataques indebidos o tecnologias propietarias que realicen esta funcion. No. /Cobran/ por eso, lo usan como justificacion para que les compres sus (sobrevaluadas) soluciones, y lo usan como herramienta para mantener cautivos a los clientes. De pocazo sirve, en la practica. A veces, por muy sobreevaluadas, se nota la diferencia y efectividad entre ellas. No creo que haya tanta. Salvo que tengas una red de Giga, un tarro de lo mas picante se la puede sin problemas corriendo un Linux configurado como la gente. Me refería a las tecnologias de filtrado y seguridad de las competencias, mas que sobreevaluado en prestaciones o throughput. Cada propietario de productos de seguridad tiene sus mecanismos personalizados en el mercado para entregar seguridad en nuestras redes y servicios. Un mecanismo mas eficaz de seguridad medianamente eficaz siempre, a mi parecer, debe ser un arquitectura de denegacion de acceso indebidos (firewall) No. La mejor manera de impedir accesos no debidos es que /no existan/ los accesos. Cualquier otra cosa es (cuando mucho) una mitigacion (mas o menos debil) del problema. Ver los comentarios arriba. y un mecanismo de prevenciÃ?³n de ataques y riesgos de las redes (IDS/IPS). Prevencion de ataques conocidos? Corregir lo atacado. Prevenir ataques
evitar mapeos de red
Jorge Luis Rodriguez [EMAIL PROTECTED] wrote: les cuento mi problema, resulta que tenemos una red clase A con el rango de ip 10.0.0.xxx, con salida a internet y algunos servicios para la red interna, dentro de esta red instales un servidor con debian, ese servidor tiene la eth0 con ip 10.0.0.150, y una eth1 con ip 192.168.1.1. Puras redes privadas. OK (supongo). Este servidor debe brindar nada mas que internet a la subred de clase C con ip 192.168.1.xxx. No tengo idea de que hablas. Configuracion de la red? Algo como: +--- 192.168.1.0/24 | Internet -- Maquina | + 10.0.0.0/8 Otra cosa? Que hay en las redes del caso? Exactamente que trafico quieres que pase/no pase entre las tres zonas? Resulta que con el scrips que posteso mas abajo funciona perfecto, pero no logro evitar que desde la red interna se pueda mapear la red de clase A (10.0.0.xxx), probe con nmap, languard, y en ambos caso si mapeo el rango de ip 10.0.0.1-10.0.0.250 estando en la red de clase C (192.168.1.1) puedo ver todas las pc que estan en la red 10.0.0.xxx. Eh buscado y leido mucho, quizas la solucion sea una tontera, pero bueno, lo cierto es que no logro ver la socucion entre todo lo que ley y busque. internet-=|Router-1|10.0.0.1=---10.0.0.150-=|Router-2|=-192.168.1.1 Oh! OK, claro que desde la red interna se ve la red 10.0.0.0/8 El trafico /pasa/ por ella! #!/bin/bash #Firewall con politicas por defecto DROP! Malisima idea. REJECT, como ya dije un par de docenas de veces aca. route add default gw 10.0.0.1 IPTABLES=`which iptables` IPLOCAL=192.168.1.1 EXTIF=eth0 INTIF=eth1 echo Interface Externa: $EXTIF echo Interface Interna: $INTIF echo Path a iptables : $IPTABLES echo IP de local: $IPLOCAL #cargamos los modulos /sbin/modprobe ip_tables /sbin/modprobe ip_conntrack /sbin/modprobe ip_conntrack_ftp /sbin/modprobe iptable_nat /sbin/modprobe ip_nat_ftp /sbin/modprobe iptable_filter /sbin/modprobe ipt_LOG /sbin/modprobe ipt_REJECT /sbin/modprobe ipt_state /sbin/modprobe ipt_MASQUERADE #bit necesarios en el kernel echo 1 /proc/sys/net/ipv4/ip_forward echo 1 /proc/sys/net/ipv4/ip_dynaddr #borramos Reglas Preestablecidas $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F #establecemos las politicas por defecto $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP #habilitar el enmascarado $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE #Se permiten pasar solo las conecciones establecidas $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT $IPTABLES -A FORWARD -j LOG $IPTABLES -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -o $EXTIF -j ACCEPT #permitimos entrar y salir al loopback $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT #solo mi ip puede entrar al SSH $IPTABLES -A INPUT -i $INTIF -p tcp --dport 22 -s 192.168.1.9 -j ACCEPT $IPTABLES -A OUTPUT -o $INTIF -p tcp --sport 22 -d 192.168.1.9 -j ACCEPT $IPTABLES -A INPUT -i $INTIF -p udp --dport 53 -j ACCEPT $IPTABLES -A OUTPUT -o $INTIF -p udp --sport 53 -j ACCEPT #Permitiendo ingresar al DHCP $IPTABLES -A INPUT -i $INTIF -p tcp --sport 68 --dport 67:68 -j ACCEPT $IPTABLES -A INPUT -i $INTIF -p udp --sport 68 --dport 67:68 -j ACCEPT $IPTABLES -A OUTPUT -p tcp --sport 67 --dport 67:68 -j ACCEPT $IPTABLES -A OUTPUT -p udp --sport 67 --dport 67:68 -j ACCEPT #Habilitar pings $IPTABLES -A INPUT -p icmp -i $INTIF -j ACCEPT $IPTABLES -A OUTPUT -p icmp -o $INTIF -j ACCEPT #$IPT -L basicamente lo que deseo es que desde la red 192.168.1.xxx no se puedan hacer scaneos de red hacia la red 10.0.0.xxx Entonces debieras parar /todo/ trafico que no vaya hacia afuera o al router-1 en router-2. Algo como dejar pasar 10.0.0.1, y luego frenar todo 10.0.0.0/8. Aunque para que quieres hacer tal cosa, se me escapa... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 From [EMAIL PROTECTED] Thu Sep 18 22:09:28 2008 From: [EMAIL PROTECTED] (Horst H. von Brand) Date: Thu Sep 18 22:09:31 2008 Subject: evitar mapeos de red In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Sebastian Veloso Varas [EMAIL PROTECTED] wrote: [...] Primero que todo, que tipo de scans estas realizando por nmap u otra herramienta hacia la red 10? Yo sugiero que controles los tipos de ataques con PortScan Attack Detector psad (http://cipherdyne.org/psad/). Una de
evitar mapeos de red
basicamente lo que deseo es que desde la red 192.168.1.xxx no se puedan hacer scaneos de red hacia la red 10.0.0.xxx Muchas gracias a todos. Ricardo! Hola: Tal vez debas ser mas específico con el filtro icmp y/o probar con parches para netfilter que permitan detener escaneos por umbrales de tiempo, date una vuelta por patch-o-matic, puedes encontrar algo que te ayude Saludos From [EMAIL PROTECTED] Sat Sep 13 06:07:00 2008 From: [EMAIL PROTECTED] (Miguel Oyarzo O.) Date: Sat Sep 13 12:07:12 2008 Subject: evitar mapeos de red Message-ID: [EMAIL PROTECTED] At 15:49 12/09/2008, Jorge Luis Rodriguez wrote: Hola comunidad! les cuento mi problema, resulta que tenemos una red clase A con el rango de ip 10.0.0.xxx, con salida a internet y algunos servicios para la red interna, dentro de esta red instales un servidor con debian, ese servidor tiene la eth0 con ip 10.0.0.150, y una eth1 con ip 192.168.1.1. Este servidor debe brindar nada mas que internet a la subred de clase C con ip 192.168.1.xxx. Resulta que con el scrips que posteso mas abajo funciona perfecto, pero no logro evitar que desde la red interna se pueda mapear la red de clase A (10.0.0.xxx), probe con nmap, languard, y en ambos caso si mapeo el rango de ip 10.0.0.1-10.0.0.250 estando en la red de clase C (192.168.1.1) puedo ver todas las pc que estan en la red 10.0.0.xxx. Eh buscado y leido mucho, quizas la solucion sea una tontera, pero bueno, lo cierto es que no logro ver la socucion entre todo lo que ley y busque. internet-=|Router-1|10.0.0.1=---10.0.0.150-=|Router-2|=-192.168.1.1 #!/bin/bash #Firewall con politicas por defecto DROP! route add default gw 10.0.0.1 IPTABLES=`which iptables` IPLOCAL=192.168.1.1 EXTIF=eth0 INTIF=eth1 echo Interface Externa: $EXTIF echo Interface Interna: $INTIF echo Path a iptables : $IPTABLES echo IP de local: $IPLOCAL #cargamos los modulos /sbin/modprobe ip_tables /sbin/modprobe ip_conntrack /sbin/modprobe ip_conntrack_ftp /sbin/modprobe iptable_nat /sbin/modprobe ip_nat_ftp /sbin/modprobe iptable_filter /sbin/modprobe ipt_LOG /sbin/modprobe ipt_REJECT /sbin/modprobe ipt_state /sbin/modprobe ipt_MASQUERADE #bit necesarios en el kernel echo 1 /proc/sys/net/ipv4/ip_forward echo 1 /proc/sys/net/ipv4/ip_dynaddr #borramos Reglas Preestablecidas $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F #establecemos las politicas por defecto $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP #habilitar el enmascarado $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE #Se permiten pasar solo las conecciones establecidas $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT $IPTABLES -A FORWARD -j LOG $IPTABLES -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -o $EXTIF -j ACCEPT #permitimos entrar y salir al loopback $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT #solo mi ip puede entrar al SSH $IPTABLES -A INPUT -i $INTIF -p tcp --dport 22 -s 192.168.1.9 -j ACCEPT $IPTABLES -A OUTPUT -o $INTIF -p tcp --sport 22 -d 192.168.1.9 -j ACCEPT $IPTABLES -A INPUT -i $INTIF -p udp --dport 53 -j ACCEPT $IPTABLES -A OUTPUT -o $INTIF -p udp --sport 53 -j ACCEPT #Permitiendo ingresar al DHCP $IPTABLES -A INPUT -i $INTIF -p tcp --sport 68 --dport 67:68 -j ACCEPT $IPTABLES -A INPUT -i $INTIF -p udp --sport 68 --dport 67:68 -j ACCEPT $IPTABLES -A OUTPUT -p tcp --sport 67 --dport 67:68 -j ACCEPT $IPTABLES -A OUTPUT -p udp --sport 67 --dport 67:68 -j ACCEPT #Habilitar pings $IPTABLES -A INPUT -p icmp -i $INTIF -j ACCEPT $IPTABLES -A OUTPUT -p icmp -o $INTIF -j ACCEPT #$IPT -L basicamente lo que deseo es que desde la red 192.168.1.xxx no se puedan hacer scaneos de red hacia la red 10.0.0.xxx Muchas gracias a todos. Ricardo! Esto es absolutamente inutil: 1) $IPTABLES -P FORWARD DROP 2) $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE 3) $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT por una parte le dices a tu firewall ACEPTA TODO LO QUE ATRAVIESE LA MAQUINA (3), sino BLOQUEA EL TRAFICO (1) (incoherente.. equivale a que tengas una policy $IPTABLES -P FORWARD ACCEPT) Debes modificar esa regla FORWARD (3) y decir exactamente los puertos que deseas que atraviesen la maquina (varias lineas quizas). Ademas, para solucionar tu malestar por los escaneos desde 192.168 hacia 10.0 puedes agregar a tu regla FORWARD un ! 10.0.0.0/24 ej: $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -p tcp --dport 80 -d ! 10.0.0.24 -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -p tcp --dport 443 -d ! 10.0.0.24 -j ACCEPT Con eso evitaras conexiones hacia esa red, (solo saldran hacia Internet en tu caso) Saludos, Miguel Oyarzo O, Austro Internet S.A. Punta Arenas
