<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Verdana">Hola a todos estuve leyendo todo lo que ocasiono
el NAT...<br>
Recien hace una hora que me engancho a la PC; y veo el comentario de
Jordi que es muy bueno y objetivo...<br>
<br>
Pues el habla de la realidad ya que de lo conceptual... y lo quiero
resumir...<br>
<br>
El NAT para algunos bien o mal solución todo depende del escenario, si
no tiene nada que perder implementarlo...<br>
<br>
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...<br>
<br>
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...<br>
<br>
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...<br>
<br>
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... <br>
<br>
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...<br>
<br>
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 </font><font
face="Verdana">reglas de uso de servicios</font><font face="Verdana">,
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...<br>
<br>
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...<br>
<br>
<br>
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...<br>
<br>
Gracias a todos... un abrazo desde PERU....<br>
</font>
<pre class="moz-signature" cols="72">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.
<a class="moz-txt-link-freetext" href="http://www.ragesys.net">http://www.ragesys.net</a>
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-----
</pre>
<br>
<br>
JORDI PALET MARTINEZ escribió:
<blockquote cite="mid:C28E499C.19D47D%25jordi.palet@consulintel.es"
type="cite">
<pre wrap="">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" (<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc4864">http://tools.ietf.org/html/rfc4864</a>). 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"
(<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-woodyatt-ald-01.txt">http://www.ietf.org/internet-drafts/draft-woodyatt-ald-01.txt</a>), que esta
siendo desarrollado por Apple, que suele hacer cosas muy buenas en este
campo.
Saludoss,
Jordi
De: Ariel Sabiguero Yawelak <a class="moz-txt-link-rfc2396E" href="mailto:asabigue@fing.edu.uy"><asabigue@fing.edu.uy></a>
Responder a: <a class="moz-txt-link-rfc2396E" href="mailto:seguridad@lacnic.net"><seguridad@lacnic.net></a>
Fecha: Thu, 07 Jun 2007 11:51:24 -0300
Para: <a class="moz-txt-link-rfc2396E" href="mailto:seguridad@lacnic.net"><seguridad@lacnic.net></a>
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ó:
</pre>
<blockquote type="cite">
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">
Hi,
<a class="moz-txt-link-abbreviated" href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
I think somebody on this list mentioned that due to corporate acquisitions,
there were legitimate paths between machines that traversed 5 or 6 NATs.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">
But yeah, "Sure, very easily". Whatever you say...
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Seguridad mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Seguridad mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a>
**********************************************
The IPv6 Portal: <a class="moz-txt-link-freetext" href="http://www.ipv6tf.org">http://www.ipv6tf.org</a>
Bye 6Bone. Hi, IPv6 !
<a class="moz-txt-link-freetext" href="http://www.ipv6day.org">http://www.ipv6day.org</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a>
</pre>
</blockquote>
</body>
</html>