<!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">
Arturo Servin escribió:
<blockquote cite="mid:572367.80994.qm@web34712.mail.mud.yahoo.com"
 type="cite">
  <style type="text/css"><!-- DIV {margin:0px;} --></style>
  <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>
  </div>
  </div>
</blockquote>
Bueno, pero los servicios no son todo (y asumí que está bloqueado todo
el tráfico que yo no quiero). Un servicio de NAT no reemplaza un
firewall, lo complementa,<br>
Quizás está la imagen de la empresa. Quizás no se quiera saber que,
desde las máquinas de los directores se accede a sitios pornográficos o
que no condicen con otros objetivos de mi empresa. Claramente hay
soluciones para esto, como los proxies, pero proxiar es como natear, en
otra capa :-) {no lo analicen demasiado...} Puedo hacer un tunnel hasta
un anonimizador de navegación, pero si es mi responsabilidad como
sysadmin, igual natearía. Mirá si cambia de computadora, no me entero y
pierdo el trabajo ;-)<br>
<br>
Me estoy esforzando por ser creativo en respuestas, quizás alguna sin
mucha lógica (pero en una facultad conocer si son los alumnos o
docentes los que acceden a cierto contenido ilegal o XXX puede dañar la
imagen....) pero el firewall me va a permitir decidir que tráfico
autorizo o no.<br>
Pero un escucha externo (quizás mi Internet Provider) puede obtener
información mia. Aunque encripte, puede conocer origen y destino de mis
comunicaciones.... y si no es mi ISP, es el carrier más grande.... y si
no, puede ser otro provider, con el que ni tengo relación, en el core.
Quizás no pueda esconder todo, pero cuanto más esconda, más puedo
anonimizar.<br>
<br>
Insisto que NAT es una herramienta. No resuelve todos los problemas y
agrega complicaciones (a veces). En unos casos sirve, en otros no. El
"statefull firewall" también. Es innegable. Juntos pueden resolver más
aspectos de seguridad que por separado.<br>
<br>
Ariel<br>
<br>
<blockquote cite="mid:572367.80994.qm@web34712.mail.mud.yahoo.com"
 type="cite">
  <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>
-as<br>
  <br>
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">-----
Original Message ----<br>
From: Ariel Sabiguero Yawelak <a class="moz-txt-link-rfc2396E" href="mailto:asabigue@fing.edu.uy"><asabigue@fing.edu.uy></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:seguridad@lacnic.net">seguridad@lacnic.net</a><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,

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>Hi,

<a moz-do-not-send="true" rel="nofollow"
 class="moz-txt-link-abbreviated" target="_blank"
 href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a> wrote:
    </pre>
      <blockquote type="cite">
        <pre>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>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>But yeah, "Sure, very easily".  Whatever you say...
      </pre>
      </blockquote>
    </blockquote>
    <pre>_______________________________________________
Seguridad mailing list
<a moz-do-not-send="true" rel="nofollow"
 class="moz-txt-link-abbreviated" target="_blank"
 href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a>
<a moz-do-not-send="true" 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>


  </pre>
  </blockquote>
  <div>_______________________________________________<br>
Seguridad mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br>
  <a moz-do-not-send="true" 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 moz-do-not-send="true"
 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.
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>