<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br> Para ocultar tus dispositivos solo usa un statefull firewall. Si esta bien configurado no hay forma de que alguien vea tus servicios desde afuera. Solo van a ver lo que tu quieras que se vea, en este caso tus servicios publicos (y solo veran de ellos lo que tu quieres que vean).<br><br>-as<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Ariel Sabiguero Yawelak <asabigue@fing.edu.uy><br>To: seguridad@lacnic.net<br>Sent: Thursday, June 7, 2007 3:51:24 PM<br>Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la lista de NANOG)<br><br>
Hola, espero andes bien.<br>
<br>
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).<br>
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.<br>
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.<br>
Realmente, no me interesa que terceros sepan si conecto 1, 5, 100 o
1000 dispositivos.<br>
Si conocen otra forma de lograr esto, bueno, cambio de opinión. Si no,
por ahora mi voto es + NAT<br>
<br>
Ariel<br>
<br>
Carlos M. Martinez escribió:
<blockquote type="cite">
<pre>Hola a todos,<br><br>queria compartir con uds un post que hice en la lista de NANOG.<br>Disculpas por que esta en Inglés. Mi interés es motivar la discusión<br>sobre NAT y seguridad, discusión que cobra mucha fuerza con el<br>advenimiento de IPv6<br><br> </pre>
<blockquote type="cite">
<pre>Hi,<br><br><a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a> wrote:<br> </pre>
<blockquote type="cite">
<pre>I think somebody on this list mentioned that due to corporate acquisitions,<br>there were legitimate paths between machines that traversed 5 or 6 NATs.<br><br> </pre>
</blockquote>
<pre>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.<br><br>I once spent three days trying to get the four administrators to talk among themselves and determine where a SYN flood was coming from. <br><br>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.<br><br>And as someone said it earlier, instead of promoting layer separation NAT it has promoted "protocol hacking hell". <br><br>Please, even the related PIX commands are named after they hackish nature:<br><br>"fixup protocol dns"<br>"fixup protocol ftp"<br><br>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".<br><br>Which they might or might not do, of course, depending on how they feel that particular day. Talk about vendor lock-in.<br><br>In my view, this ossifies the whole Internet development cycle. <br><br>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. <br><br>Sorry about the rant :-)<br><br>Carlos M.<br>ANTEL Uruguay<br><br> </pre>
<blockquote type="cite">
<pre>But yeah, "Sure, very easily". Whatever you say...<br> </pre>
</blockquote>
</blockquote>
<pre>_______________________________________________<br>Seguridad mailing list<br><a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br><a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br><br><br> </pre>
</blockquote>
<div>_______________________________________________<br>Seguridad mailing list<br>Seguridad@lacnic.net<br><a target="_blank" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br></div></div><br></div></div><br>
<hr size=1>Be a better Globetrotter. <a href="http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545469">Get better travel answers </a>from someone who knows.<br>Yahoo! Answers - Check it out.
</body></html>