[LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la lista de NANOG)

Nicolás Ruiz nicolas en ula.ve
Vie Jun 8 15:47:38 BRT 2007


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

JORDI PALET MARTINEZ wrote:
> Hola Ariel, todos,
> 
> No quiero perder mucho tiempo en este tema, pues ya lo hemos perdido en
> cientos de ocasiones en cientos de listas.

Excelente resumen

> Solo comentar algunos aspectos (y seguro que me dejo muchos), que son hechos
> y que cada cual valore por si mismo.
> 
> 1) NAT tiene algo bueno, y es que ha permitido el crecimiento de Internet,
> pero a costa de todo lo demas
> 
> 2) Funciana bien con aplicaciones cliente-servidor
> 
> 3) No funciona bien con aplicaciones peer-to-peer, y por lo tanto bloquea la
> innovacion y el principio fundamental de Internet "end-to-end"
> 
> 4) El coste de desarrollar aplicaciones peer-to-peer para que atraviesen NAT
> supone el 80% del desarrollo y cuando digo el desarrollo, no hablo de unas
> horas, sino de muchos miles de horas. Dicho por gente como Skype, que
> dedican el 80% de sus recursos para que cada vez que sale un nuevo NAT al
> mercado, una nueva version de firmware, tienen que andar comprobando y con
> actualizaciones. Imaginaros una pequeña empresa desarroladora de software,
> que evidentemente no tiene los recursos que tiene Skype.
> 
> 5) NAT no es seguridad, es un concepto erroneo, no protege las redes, no las
> esconde aunque lo parezca. Si un atacante quiere atravesar NAT, lo puede
> hacer, y esta mas que demostrado. Lo que ocurres es que NO les hace falta,
> tienen otros medios y otras maquinas mas faciles de atacar.
> 
> 6) Las funciones de esconder direcciones se llevan a cabo mejor con y de
> forma mas eficaz con proxies y caches
> 
> 7) El 80% de los ataques se producen desde el interior de las redes. NAT es
> inutil para ello, igual que lo son los firewalls perimetrales.
> 
> 8) La mejor proteccion es que cada maquina este auto-protegida. Firewalls en
> los hosts, y de hecho es la tendencia. El firewall perimetral tendera a
> convertirse en un gestor de politicas de seguridad (tengo varios drafts al
> respecto, aunque ahora mismo estan expirados, pero el WG NEA de IETF esta
> trabajando de nuevo en esto).
> 
> 9) NAT tambien tiene costes ocultos, no solo en cuanto a consumo de baterias
> (keep-alives), que por ejemplo son nefastos en aplicaciones celulares (y
> WiFi/portatiles), sino de forma global si calculamos el consumo energetico
> adicional generado. No digo que sea la salvacion para el global warming,
> pero es un pequeño factor adicional, que como todos, impacta. Otro coste
> oculto es el de operación de las redes, gente como AOL ha reconocido
> publicamente, en la reunion de NANOG de hace un par de años en LAX, que el
> soporte de primera linea a un cliente, por problemas de aplicaciones con NAT
> le cuesta en una primera llamada, el beneficio del cliente de todo un año,
> si hay que pasarlo a segunda linea de soporte, el beneficio del cliente para
> toda la vida. Hay muchos otros calculos similares.
> 
> 10) Para la privacidad en el caso de IPv6 hay muchas mejores soluciones que
> NAT, y no solo una (Vista implementa una nueva que ni siquiera tiene RFC y
> es bastante interesante).
> 
> 11) Para evitar el port scanning, si un hacker atraviesa una NAT, no tiene
> problem, mientras que como ya se ha dicho un port scanning de un /64
> necestia 5.3 billones de años.
> 
> 12) Las aplicaciones con NAT no son solo mas costosas, sino ademas,
> ineficaces, el trafico necesita ir a terceros, mas retardo, mas overhead,
> mas energia, mas ancho de banda, etc.. Con IPv6 es peer-to-peer real.
> 
> 13) NAT tiene hasta costes legales en caso de cybercrimen, y el responsable
> legalmente hablando puede llegar a ser el propietario del NAT ! Ya ha habido
> algun caso. No creo que sea nada bueno!
> 
> 14) Si alguien tiene mas dudas, que lea el RFC4864 "Local Network Protection
> for IPv6" (http://tools.ietf.org/html/rfc4864). Es un documento que no tiene
> desperdicio !
> 
> En definitiva, como ha dicho mucha gente NAT es un demonio, puede parecer
> beneficioso, y lo ha sido al principio, nos ha "engañado" y "enganchado",
> pero en realidad ha sido mas perjuicio que otra cosa. Incluso podriamos
> decir que el uso extensivo de NAT ha ralentizado la adopcion de IPv6.
> 
> El futuro es que posiblemente creza NAT con IPv4, dada la escasez de
> direcciones, pero ya no es tan problemático si es piensa en que sigan
> funcionando las aplicaciones existentes, y en cambio las aplicacioens nuevas
> van acompañando al despliegue de IPv6.
> 
> Tambien hay otro documento interesante al respecto del uso de firewalls con
> IPv6 "Application Listener Discovery for IPv6"
> (http://www.ietf.org/internet-drafts/draft-woodyatt-ald-01.txt), que esta
> siendo desarrollado por Apple, que suele hacer cosas muy buenas en este
> campo.
> 
> Saludoss,
> Jordi
> 
> 
> 
> 
> 
> De: Ariel Sabiguero Yawelak <asabigue en fing.edu.uy>
> Responder a: <seguridad en lacnic.net>
> Fecha: Thu, 07 Jun 2007 11:51:24 -0300
> Para: <seguridad en lacnic.net>
> Asunto: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la lista
> de NANOG)
> 
> Hola, espero andes bien.
> 
> Me parece interesante el punto y creo que tenemos que ver algunos puntos
> buenos también del NAT/PAT. Creo que el argumento más sólido para mantener
> el NAT es el de poder ocultar mi red interna a un observador remoto
> (posiblemente hostil).
> Está muy bien el usar firewalls y estoy de acuerdo que la simplicidad no es
> motivo para tomar decisiones de diseño, pero realmente el natting oculta
> muchos aspectos de las redes. Tiene overhead y costo, pero te permite aislar
> tu topología interna y anonimizar al usuario. Sabés de qué empresa es, pero
> no tenés idea de dónde ni quien. Ese factor de privacidad considero que
> debería ser salvado.
> Antes que me manden leer el RFC 3041, les digo que si soy responsable de una
> red y tengo que aplicar la política de "anonimizar" a los usuarios, prefiero
> hacerlo centralmente, a hacerlo desde el cliente.
> Realmente, no me interesa que terceros sepan si conecto 1, 5, 100 o 1000
> dispositivos.
> Si conocen otra forma de lograr esto, bueno, cambio de opinión. Si no, por
> ahora mi voto es + NAT
> 
> Ariel
> 
> Carlos M. Martinez escribió:
>>  
>> Hola a todos,
>>
>> queria compartir con uds un post que hice en la lista de NANOG.
>> Disculpas por que esta en Inglés. Mi interés es motivar la discusión
>> sobre NAT y seguridad, discusión que cobra mucha fuerza con el
>> advenimiento de IPv6
>>
>>   
>>  
>>>  
>>> Hi,
>>>
>>> Valdis.Kletnieks en vt.edu wrote:
>>>     
>>>  
>>>>  
>>>> I think somebody on this list mentioned that due to corporate acquisitions,
>>>> there were legitimate paths between machines that traversed 5 or 6 NATs.
>>>>
>>>>       
>>>>  
>>>  
>>> Not 5 or 6, but in my company I could show you paths with 4 NATs. Many of
>>> them. And no acquisitions, just different Divisions of the same company.
>>>
>>> I once spent three days trying to get the four administrators to talk among
>>> themselves and determine where a SYN flood was coming from.
>>>
>>> Whatever people say, NAT is a hack. NAT was intended to extend IPv4's
>>> lifetime (togher with CIDR they were pretty successful at that) and nothing
>>> else.
>>>
>>> And as someone said it earlier, instead of promoting layer separation NAT it
>>> has promoted "protocol hacking hell".
>>>
>>> Please, even the related PIX commands are named after they hackish nature:
>>>
>>> "fixup protocol dns"
>>> "fixup protocol ftp"
>>>
>>> This completely destroys the end-to-end nature of application protocols! If
>>> someone wants to improve FTP or anything that requires a "fixup", it doesn't
>>> suffice to code a server and a client. No, you need to talk to 1.000sh
>>> firewall manufacturers so they correct their "fixups".
>>>
>>> Which they might or might not do, of course, depending on how they feel that
>>> particular day. Talk about vendor lock-in.
>>>
>>> In my view, this ossifies the whole Internet development cycle.
>>>
>>> And the argument that NAT is easier to administer than a full SI firewall is
>>> pretty thin, even if it was true, about what I have my doubts. Moreover, not
>>> everything in life should be conditioned to the "easier to administer"
>>> argument. 
>>>
>>> Sorry about the rant :-)
>>>
>>> Carlos M.
>>> ANTEL Uruguay
>>>
>>>     
>>>  
>>>>  
>>>> But yeah, "Sure, very easily".  Whatever you say...
>>>>       
>>>>  
>>>  
>>  
>> _______________________________________________
>> Seguridad mailing list
>> Seguridad en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/seguridad
>>
>>
>>   
> 
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Bye 6Bone. Hi, IPv6 !
> http://www.ipv6day.org
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
> 
> 

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
nicolas en ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaaRJmjsZS9ZBxv8RApyYAJ4paGz7mLeqVKXEx2X0QJKTGvk28wCfXKwP
PI9UsHTId1LlempEXk85u+4=
=kVXW
-----END PGP SIGNATURE-----




Más información sobre la lista de distribución Seguridad