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

Jue Jun 7 20:05:40 BRT 2007

Hola  a todos estuve leyendo todo lo que ocasiono el NAT...
Recien hace una hora que me engancho a la PC; y veo el comentario de
Jordi que es muy bueno y objetivo...

Pues el habla de la realidad ya  que de lo conceptual... y lo quiero
resumir...

El NAT para algunos bien o mal solución todo depende del escenario, si
no tiene nada que perder implementarlo...

Pero en mucho lugares donde la información es vital, pues no todo es
perímetro, y alli Jordi da  énfasis, un firewall no te  salva la vida,
ya han habido formas de pasar  NAT con firewalling, lean no mas los
números del ya extinguido magazine, mejor dicho e-zine PHRACK...

Por eso mucho se habla en otro idioma el Hardering, ya sea de redes,
sistemas operativos... que también lo indica Jordi muy ambigua, pero
entendible para que el que esta muy atento a la movida de la seguridad y
ve mas allá del común de los mortales...

Rompamos el Mito de los firewalls, si mas no protegen a un porcentaje,
si bien el NAT es una solución por ahorrar direcciones y traducir
direcciones IP a diferentes servicios, no es de agrado de cualquiera
atacante el problema, si mas no vemos ahora, aplicaciones como ya los
BIT torrents que superan el NAT e inclusive el firewalling que existe en
tu red... no se preguntaron como lo hacen.... si una aplicación open
Source lo hace y dispones del código, pues olvidemosnos de todo lo que
se discute, por que no ha como responder... ya entrarías a atacar parte
del problema por otro lado filtrando paquetes y los stateful...

Por eso nadie se explica como se bajan información de empresas que
invierten dinero en tecnología sobre seguridad... mucho entra a tallar
el nivel de personal que tengas y te protegen... Y con todo esto
complemento lo que Jordi dice, al final quienes abren las puertas al NAT
son los mismo usuarios de la red interna, por su curiosidad, y a veces
la curiosidad en todo la historia de la humanidad no se ha podido curar
es nato de todos así que bajo mi criterio la lucha es interninable...

Descartamos las metodologías, buenas practicas, casos de éxito... por
que gracias a estas cosas, aprendemos... No se aun puesto a pensar que
el atacante que llevamos dentro, muy escondido, si supiéramos las
metodologías, las buenas practicas, casos de éxito, y sobe todo el
protocolo mas utilizado por todos el TCP, muestro black hat interno
despierta y la curiosidad nos lleva a resolver problemas...

A todo esto concluyo, que asi discutamos quien es el mejor o no en todo
los NAT que conocemos y que salgan a la luz y las nuevas formas de
diseño del TCP-IP y demás protocolos de aplicación, es mejor enfocar y
aplicar Defense In Depth en los SSI... (Personal, tecnologías,
Operaciones, dícese por este ultimo las políticas reglas de uso de
servicios, administración de la seguridad, recuperación ante incidentes,
etc,,etc)..  Apuesto mas por esto, que preocuparme de confiarme en tal
tecnología o protocolo que me asegura seguridad...

Claro esto esta siendo utilizado y visto por los gobiernos, pero no esta
cercano a por que no entender este paradigma en un empresa, claro tendrá
costos, pero no gastaríamos palabras en ver los pro y cons de las
tecnologías...

Felicito a Jordi Plalet por sus comentarios y espero también la de Uds,
si en caso parezco ser paranoico, o si me equivoco, también los acepto,
inclusive correcciones...

Gracias a todos...  un abrazo desde PERU....

PD. Agradeciendo su comprensión, pido disculpas, si nota Ud. errores de ortografía y gramática en esta misiva. 
-----------------------------------------------------------
 Anatoly Alexei Pedemonte Ku 
 RAGE SYSTEMS S.A.C.
 http://www.ragesys.net
 Av. Juan Pascal Pringles 1225 (ex- La Fontana) - LA MOLINA
 LIMA - PERU
 Nextel: 511.98252347 
 Móvil: 511.97167435 
-----------------------------------------------------------
Este correo y su contenido son confidenciales y exclusivos para su destinatario. Si usted recibe este mensaje por error o no es el destinatario del mismo, por favor sírvase eliminarlo y notificarle a su originador. Así mismo, todas las ideas y reflexiones expresadas en esta comunicación corresponden al originador del correo y NO representa la posición oficial de su empleador.
--------------------------------------------------------------------------------------------------------------------------------------
This email is intended only for the addresse(s) and contains information which may be confidential, legally privileged. If you are not intended recipient please do not save, forward, disclose or copy the content of this email. Please delete it completely from your system and notify originator.Finally, all ideas expressed in this communication are personal comments and NOT represent official position of his employer.
--------------------------------------------------------------------------------------------------------------------------------------

******** ESP: Esta sección no es virus, sino es la Llave publica de Firma Digital   *********
******** ENG: This section do not a virus, really is the Public Key of Digital Sign   *********

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.3 (MingW32)

mQGiBESAj0sRBACbs6YrxgfA3uYWdrMoJ0Sfq9ZAh+uxWF9mjuNV8CMKmovVQfor
o3KosZ9PzEkYa43WNgTYwPjcI1NkF2W0La0s44GBzJaxzfAojhfV9CgQoViJv+UJ
TFe7TG32wdG+M+E/FqA3vUfMvjoVCu/SY74H+VES7v8h7VJsy6dUDT3jKwCgspkU
oGlOVd9M4h3OiW2BINa/BcMD/ikzpBjrZ0wz0yfIBYgPUAO0yhQpfd0cPxL7lAi9
NGuGQtUdunkomPjzLt/989wCM8kmiEkhsR+mu3vceOLqeAR2mfoEX0vC1UYMlOcB
jitRdx19Wjm8fYVI98vuyIs/i6IGclZnXEoMLoOBvdaIIfj7ZpB59CFOx2WH3ixC
s0O6A/0aO7jE8ugDVVHtSdUayw+sAQes2zELdNAy0u8kOpSzWjaxTo2uJ+5py5/M
uBgifYQMljAnYkTCcBYXD39Din43r330peUpHX3OekRPLYYEOg0Px4sOjJVAf828
rysL1q4uKqUljE6aHVnFM+FkItqUKysAVgemW1wGxyW2UhwuBLQtQW5hdG9seSBB
LiBQZWRlbW9udGUgS3UgPGFuYXRvbHlAcmFnZXN5cy5uZXQ+iGYEExECACYFAkSA
j0sCGwMFCQHhM4AGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBJuebWcCX7tbwi
AJsHXrCU+6dCHf8xUeDdrzJN/NTrlQCgiMjRs7KDAQnu9a0yklQYGlG2W2+5Ag0E
RICPgxAIAIFh8TQuAbWfmj9pez98L6mlNDyQSXyrIUXTFXK3hLMOA0u4oyz6EuCH
zZOIUxveeumspSv98F6vP/W7AQBfX5t6pakvmyRHtBcsdx1dFgOlIWRGHP86tgdl
Ci4s+C9vGrbynXbNDPoV/cCqYZeeKNBbUHbUH3j+hKKTz0mpiHPaFWTsGzmxQpoI
cSHnbGPuIwew9TDC9qnESmGscG8IfZXsB7UjkDMyGUVQNwYd+hqPOof/qMFiR2cG
x2IUs3dGroffjkmncgvoPfBPq0B+7cIqhnEznKCxvjvorZnpT/9uW1Apch8QwXcg
SK/QkHBYwweYWzHYaqzkLzustwJ2dNMAAwYH/RReKPnCUJa45gw3Bv76z9UK0ABr
OLRfVq1nnRnqs1LM+z7xKMpEfzQDIyNoqUlE42pNNYd/N8rz+3PP1pRypcpbP+B/
MNOBEaFhvS7X5El8WfXRIaM19hLpEHVeTPG71cOJaiu/PC6a7KkOarKCIJYa7uU0
JhqVPaAeButljRuQJpR9rjpdPPd2+4sVaWrabtnyhm/oiYQthyMdB8xq2slWreTL
hWFtsenfgVvOlBpt8ZwGpQkzASLBwdGhisMYXQStw1D9dbDFQbb8pqO/9eos9rkL
sflAvD1F3VJl2TmaxjvRRgnAgRzdt3vTWvrYPf2WyesT0C78rriVeWzmuD6ITwQY
EQIADwUCRICPgwIbDAUJAeEzgAAKCRBJuebWcCX7tRdWAKCIlj2g5aMf4CKqwEjx
uAEzo28PuQCfV/U+ptv+7+D0xkMzZ5HG1yxMrhQ=
=GD85
-----END PGP PUBLIC KEY BLOCK-----

JORDI PALET MARTINEZ escribió:
> Hola Ariel, todos,
>
> No quiero perder mucho tiempo en este tema, pues ya lo hemos perdido en
> cientos de ocasiones en cientos de listas.
>
> 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
>
>   
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20070607/2e4e65e3/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20070607/2e4e65e3/attachment.sig>