[LACNIC/Seguridad] NAT o no NAT esa es la cuestion
Nicolás Antoniello
nicolas en antel.net.uy
Vie Jun 8 09:37:33 BRT 2007
Algunos comentarios a modo de fomentar la discusión:
seguri >> > Quizás está la imagen de la empresa. Quizás no se quiera saber que,
seguri >> > desde las máquinas de los directores se accede a sitios pornográficos o
seguri >> > que no condicen con otros objetivos de mi empresa.
seguri >>
seguri >>Y como puede un ente externo saber que una IP dada pertenece a un director?
seguri >
seguri >Por ej leyendo el encabezado de un mail enviado por el director.
El uso de un proxy para WEB no implica que se tenga que utilizar NAT para
todo el resto. Los proxy WEB se justifican, en ciertos casos, por una
serie de motivos mas alla de que se utilice NAT o no. Creo que no se puede
poner al uso de un proxy como argumento a favor del NAT.
seguri >> > Bueno, pero los servicios no son todo (y asumí que está bloqueado todo
seguri >> > el tráfico que yo no quiero). Un servicio de NAT no reemplaza un
seguri >> > firewall, lo complementa,
seguri >>
seguri >>Podrías explicar como lo complementa (excluyendo el aspecto de proveer
seguri >>más direcciones IP internas)?
seguri >
seguri >Hace que los sistemas sean inalcanzables desde la Internet.
Nuevamente en desacuerdo... una cosa es un Firewall y otra es NAT. Creo
que depende de lo que quiera hacer (como se dijo antes en esta discusion)
el NAT puede incluso ser muy desfavorable y hasta en varios casos afectar
el funcionamiento de los protocolos (ftp, sip, etc...) en los que es
necesario meterse en la capa de aplicacion (como los fixup de cisco,
etc...) para resolver los problemas que ocaciona el NAT o que ocaciono la
combinacion del diseño del propio protocolo con el NAT (si bien, creo que
es un tanto acertado el comentario de que algunos protocolos "violan"
ampliamente la buena praxis de la separacion de capas). Ademas, si
asumimos que esta bloqueado TODO el trafico indeseable, que me aporta el
nat respecto a la seguridad referente a la alcanzabilidad de mi red?
Por ultimo, y esto tambien se dijo antes, es falsa la premisa de que el
NAT haga inalcanzables los sistemas desde Internet, pues la proteccion que
pueda dar el NAT se bypasea (siendo un poco simplista) haciendo un
spoofing de IPs, puertos y algo mas.... si bien esto no seria tan facil en
la practica, la proteccion real la estaria dando el firewall y no el NAT.
Por otro lado, también hay que pensar en el uso que se le da al NAT... si
pensamos en tener mas de un servicio (servidores) publico en un red que es
privada (detras de un NAT por ejemplo), creo que ya estamos incurriendo un
error de diseño pues si los servidores son "publicos" no deberian estar
direccionados en forma privada.
Ahora bien, si tenemos una red privada desde la que mayormente se
"consume" de Internet (en lugar de "servir" datos), pues no le veo mayores
problemas al NAT (salvando el problema de ciertas aplicaciones ya
mencionadas). Lo que si creo, es que de todas formas, el NAT no sera una
medida de seguridad sino una solucion cuando me dan una unica IP o un
intento (en general fallido) de simplificacion del "control" de acceso a
una red.
Comentarios?
Saludos,
Nicolas.
On Fri, 8 Jun 2007 seguridad-request en lacnic.net wrote:
seguri >Envíe los mensajes para la lista Seguridad a
seguri > seguridad en lacnic.net
seguri >
seguri >Para subscribirse o anular su subscripción a través de la WEB
seguri > https://mail.lacnic.net/mailman/listinfo/seguridad
seguri >
seguri >O por correo electrónico, enviando un mensaje con el texto "help" en
seguri >el asunto (subject) o en el cuerpo a:
seguri > seguridad-request en lacnic.net
seguri >
seguri >Puede contactar con el responsable de la lista escribiendo a:
seguri > seguridad-owner en lacnic.net
seguri >
seguri >Si responde a algún contenido de este mensaje, por favor, edite la
seguri >linea del asunto (subject) para que el texto sea mas especifico que:
seguri >"Re: Contents of Seguridad digest...". Además, por favor, incluya en
seguri >la respuesta sólo aquellas partes del mensaje a las que está
seguri >respondiendo.
seguri >
seguri >
seguri >Asuntos del día:
seguri >
seguri > 1. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Fernando Gont)
seguri > 2. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Fernando Gont)
seguri > 3. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Fernando Gont)
seguri > 4. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Carlos Quevedo)
seguri > 5. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Fernando Gont)
seguri > 6. Re: El NAT y la seguridad (Cross-post de la lista de NANOG)
seguri > (Anatoly A. Pedemonte Ku)
seguri >
seguri >
seguri >----------------------------------------------------------------------
seguri >
seguri >Message: 1
seguri >Date: Fri, 08 Jun 2007 00:39:54 -0300
seguri >From: Fernando Gont <fernando en gont.com.ar>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <200706080340.l583eIv0023981 en venus.xmundo.net>
seguri >Content-Type: text/plain; charset="iso-8859-1"; format=flowed
seguri >
seguri >At 04:01 p.m. 07/06/2007, you wrote:
seguri >
seguri >> > Bueno, pero los servicios no son todo (y asumí que está bloqueado todo
seguri >> > el tráfico que yo no quiero). Un servicio de NAT no reemplaza un
seguri >> > firewall, lo complementa,
seguri >>
seguri >>Podrías explicar como lo complementa (excluyendo el aspecto de proveer
seguri >>más direcciones IP internas)?
seguri >
seguri >Hace que los sistemas sean inalcanzables desde la Internet.
seguri >
seguri >
seguri >
seguri >> > Quizás está la imagen de la empresa. Quizás no se quiera saber que,
seguri >> > desde las máquinas de los directores se accede a sitios pornográficos o
seguri >> > que no condicen con otros objetivos de mi empresa.
seguri >>
seguri >>Y como puede un ente externo saber que una IP dada pertenece a un director?
seguri >
seguri >Por ej leyendo el encabezado de un mail enviado por el director.
seguri >
seguri >Saludos,
seguri >
seguri >--
seguri >Fernando Gont
seguri >e-mail: fernando en gont.com.ar || fgont en acm.org
seguri >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >------------------------------
seguri >
seguri >Message: 2
seguri >Date: Fri, 08 Jun 2007 00:33:42 -0300
seguri >From: Fernando Gont <fernando en gont.com.ar>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <200706080340.l583eIuw023981 en venus.xmundo.net>
seguri >Content-Type: text/plain; charset="iso-8859-1"; format=flowed
seguri >
seguri >Carlos,
seguri >
seguri >Mis respuestas/comentarios van entre lineas....
seguri >
seguri >
seguri >> > Not 5 or 6, but in my company I could show
seguri >> you paths with 4 NATs. Many of them. And no
seguri >> acquisitions, just different Divisions of the same company.
seguri >> >
seguri >> > I once spent three days trying to get the
seguri >> four administrators to talk among themselves
seguri >> and determine where a SYN flood was coming from.
seguri >
seguri >Cuando se aplica con alguna motivacion de
seguri >seguridad, el NAT justamente apunta a "ocultar"
seguri >los sistemas que estan detras del NAT. Ese esa
seguri >propia caracteristica la que, en escenarios como
seguri >el que describis, puede dificultar el rastreo de ataques.
seguri >
seguri >Nosotros (en UTN/FRH) haciamos NAT+stateful
seguri >filtering. Por ello, ataques como el SYN flood
seguri >podian ser evitados simplemente limitando las
seguri >conexiones activas que un sistema podia mantener.
seguri >Tambien es de notar que el NAT lo haciamos justo
seguri >antes de salir a Internet. Tanto la red interna,
seguri >como el acceso de nuestros clientes a los
seguri >servidores publicos, se realizaba utilizando direcciones privadas.
seguri >
seguri >
seguri >
seguri >> > Whatever people say, NAT is a hack. NAT was
seguri >> intended to extend IPv4's lifetime (togher with
seguri >> CIDR they were pretty successful at that) and nothing else.
seguri >
seguri >TCP/IP es un hack en si... por donde lo mires.
seguri >
seguri >Por ej., en IP el esquema de direccionamiento
seguri >esta incompleto (tanto en v4, como en v6).
seguri >
seguri >En TCP, se agrego control de congestion (!)
seguri >cuando Internet colapso a mitad de los 80. SACK
seguri >es un parche para ackear paquetes. El
seguri >pseudoheader de TCP es algo poco limpio. :-)
seguri >
seguri >Los well-known ports (por ej., "el puerto 80 es
seguri >la web") no es mas que un hack ante la carencia de un servicio de directorio.
seguri >
seguri >etc., etc., etc.
seguri >
seguri >
seguri >
seguri >> > And as someone said it earlier, instead of
seguri >> promoting layer separation NAT it has promoted "protocol hacking hell".
seguri >> >
seguri >> > Please, even the related PIX commands are named after they hackish nature:
seguri >> >
seguri >> > "fixup protocol dns"
seguri >> > "fixup protocol ftp"
seguri >
seguri >Yo discrepo con esta observacion. En la gran
seguri >mayoria de los casos, NAT simplemente hizo
seguri >evidente que numerosos protocolos estan mal diseñados.
seguri >
seguri >Pensa el caso de FTP. De donde proviene la
seguri >dificulta principal de usar FTP a traves de
seguri >NATs/middle-boxes? - Basicamente, el problema
seguri >radica que en el protocolo de *aplicacion* TCP se
seguri >transfieren direcciones IP y numeros de puerto
seguri >TCP. Y esta clarisimo que un protocolo de
seguri >aplicacion no tendria que trabajar con tales objetos de tan bajo nivel.
seguri >
seguri >(Como puede ser que haya que modificar FTP para que pueda andar con v6?????)
seguri >
seguri >La gente pro-v6 usa como uno de sus argumentos de
seguri >marketing que todos los sistemas que accedan a
seguri >Internet tienen que ser directamente
seguri >direccionables ("end to end argument"). Esto es
seguri >un error. El hecho de que un sistema quiera
seguri >acceder a Internet no tiene porque implicar,
seguri >desde un punto de vista teorico
seguri >(direccionamiento) que tenga un punto de conexion
seguri >(direccion IP, en este caso) publico.
seguri >
seguri >El problema aca es que la arquitectura de
seguri >direccionamiento de Internet esta incompleta. No
seguri >hay direcciones de "nodos". Entocnes las
seguri >direcciones IP tienen doble significado: tanto
seguri >"punto de conexion", como "nodo". Y eso es loq ue
seguri >usualmente motiva a pensar que todo el mundo (es
seguri >decir, cada nodo) tendria que tener una direccion IP propia.
seguri >
seguri >Saludos,
seguri >
seguri >--
seguri >Fernando Gont
seguri >e-mail: fernando en gont.com.ar || fgont en acm.org
seguri >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >------------------------------
seguri >
seguri >Message: 3
seguri >Date: Fri, 08 Jun 2007 00:43:04 -0300
seguri >From: Fernando Gont <fernando en gont.com.ar>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <200706080343.l583h9vN028428 en venus.xmundo.net>
seguri >Content-Type: text/plain; charset="iso-8859-1"; format=flowed
seguri >
seguri >At 08:15 p.m. 07/06/2007, you wrote:
seguri >
seguri >> > Creo que ocultar tu red es parte de la seguridad basica. No anuncies lo
seguri >> > innecesario.
seguri >>
seguri >>FALSO !
seguri >>
seguri >>eso no es seguridad básica, es una falsa sensación de seguridad
seguri >>que los admin TI tienen...
seguri >>
seguri >>"ocultar" tu red no es seguridad....lamentablemente, sino sería
seguri >>muy fácil ;)
seguri >
seguri >Todo suma. Por que habria de hacer publicamente
seguri >accesible a un sistema que no necesita estarlo?
seguri >
seguri >
seguri >--
seguri >Fernando Gont
seguri >e-mail: fernando en gont.com.ar || fgont en acm.org
seguri >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >------------------------------
seguri >
seguri >Message: 4
seguri >Date: Fri, 08 Jun 2007 02:41:33 -0500
seguri >From: Carlos Quevedo <tecnica en ccit.org.co>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <001e01c7a9a0$7003b0a0$0a00a8c0 en amd16>
seguri >Content-Type: text/plain; format=flowed; charset=iso-8859-1;
seguri > reply-type=original
seguri >
seguri >No concuerdo con lo de hack por todos lados, TCP/IP es una familia de
seguri >protocolos y como tal tiene virtudes y defectos en mi opinion.
seguri >
seguri >No se si exista un protocolo publico al que nunca le hayan encontrado fallas
seguri >de seguridad, pero me extrañaría mucho que existiese uno de esas
seguri >características por el simple hecho de que los protocolos son diseñados
seguri >pensando en un conjunto predeterminado de situaciones, o es que se puede
seguri >diseñar un protocolo teniendo en cuenta todas las situaciones posibles?
seguri >
seguri >En particular usar el término hack sobre el protocolo TCP/IP me parece
seguri >demasiado despectivo y hasta irrespetuoso con quienes lo diseñaron, aunque
seguri >pueda ser que se sientan halagados por el hecho de ser considerados
seguri >"hackers".
seguri >
seguri >Que una opinion de un sector de las telecomunicaciones sea que el
seguri >direccionamiento de nodos es indispensable y que no deben todos los
seguri >elementos de una red contar con una direccion publica es hasta donde llega
seguri >mi conocimiento: una opinion. O existe una demostración matemática de que
seguri >así debe ser?
seguri >
seguri >(nota al margen:Podria una persona independiente unirse a una red donde el
seguri >direccionamiento de nodos existiese y compartir sus bases de conocimiento
seguri >con cualquier persona del mundo a un costo muy bajo?)
seguri >
seguri >NAT nació para suplir la escasez de direcciones IPv4, por lo que la
seguri >afirmación de que gracias a NAT se ha descubierto que tan mal estaban
seguri >diseñados los protocolos me hace ver que no conozco literatura que sustente
seguri >dichas afirmaciones y que obviamente me gustaría leer.
seguri >
seguri >Por ahora mejor me despido viendo como los bits de este mensaje son
seguri >"hackeados" para llegar a su destino.
seguri >
seguri >Carlos Quevedo
seguri >Asesor Técnico CCIT
seguri >
seguri >----- Original Message -----
seguri >From: "Fernando Gont" <fernando en gont.com.ar>
seguri >To: <seguridad en lacnic.net>
seguri >Sent: Thursday, June 07, 2007 10:33 PM
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la
seguri >lista de NANOG)
seguri >
seguri >
seguri >Carlos,
seguri >
seguri >Mis respuestas/comentarios van entre lineas....
seguri >
seguri >
seguri >> > Not 5 or 6, but in my company I could show
seguri >> you paths with 4 NATs. Many of them. And no
seguri >> acquisitions, just different Divisions of the same company.
seguri >> >
seguri >> > I once spent three days trying to get the
seguri >> four administrators to talk among themselves
seguri >> and determine where a SYN flood was coming from.
seguri >
seguri >Cuando se aplica con alguna motivacion de
seguri >seguridad, el NAT justamente apunta a "ocultar"
seguri >los sistemas que estan detras del NAT. Ese esa
seguri >propia caracteristica la que, en escenarios como
seguri >el que describis, puede dificultar el rastreo de ataques.
seguri >
seguri >Nosotros (en UTN/FRH) haciamos NAT+stateful
seguri >filtering. Por ello, ataques como el SYN flood
seguri >podian ser evitados simplemente limitando las
seguri >conexiones activas que un sistema podia mantener.
seguri >Tambien es de notar que el NAT lo haciamos justo
seguri >antes de salir a Internet. Tanto la red interna,
seguri >como el acceso de nuestros clientes a los
seguri >servidores publicos, se realizaba utilizando direcciones privadas.
seguri >
seguri >
seguri >
seguri >> > Whatever people say, NAT is a hack. NAT was
seguri >> intended to extend IPv4's lifetime (togher with
seguri >> CIDR they were pretty successful at that) and nothing else.
seguri >
seguri >TCP/IP es un hack en si... por donde lo mires.
seguri >
seguri >Por ej., en IP el esquema de direccionamiento
seguri >esta incompleto (tanto en v4, como en v6).
seguri >
seguri >En TCP, se agrego control de congestion (!)
seguri >cuando Internet colapso a mitad de los 80. SACK
seguri >es un parche para ackear paquetes. El
seguri >pseudoheader de TCP es algo poco limpio. :-)
seguri >
seguri >Los well-known ports (por ej., "el puerto 80 es
seguri >la web") no es mas que un hack ante la carencia de un servicio de
seguri >directorio.
seguri >
seguri >etc., etc., etc.
seguri >
seguri >
seguri >
seguri >> > And as someone said it earlier, instead of
seguri >> promoting layer separation NAT it has promoted "protocol hacking hell".
seguri >> >
seguri >> > Please, even the related PIX commands are named after they hackish
seguri >> > nature:
seguri >> >
seguri >> > "fixup protocol dns"
seguri >> > "fixup protocol ftp"
seguri >
seguri >Yo discrepo con esta observacion. En la gran
seguri >mayoria de los casos, NAT simplemente hizo
seguri >evidente que numerosos protocolos estan mal diseñados.
seguri >
seguri >Pensa el caso de FTP. De donde proviene la
seguri >dificulta principal de usar FTP a traves de
seguri >NATs/middle-boxes? - Basicamente, el problema
seguri >radica que en el protocolo de *aplicacion* TCP se
seguri >transfieren direcciones IP y numeros de puerto
seguri >TCP. Y esta clarisimo que un protocolo de
seguri >aplicacion no tendria que trabajar con tales objetos de tan bajo nivel.
seguri >
seguri >(Como puede ser que haya que modificar FTP para que pueda andar con v6?????)
seguri >
seguri >La gente pro-v6 usa como uno de sus argumentos de
seguri >marketing que todos los sistemas que accedan a
seguri >Internet tienen que ser directamente
seguri >direccionables ("end to end argument"). Esto es
seguri >un error. El hecho de que un sistema quiera
seguri >acceder a Internet no tiene porque implicar,
seguri >desde un punto de vista teorico
seguri >(direccionamiento) que tenga un punto de conexion
seguri >(direccion IP, en este caso) publico.
seguri >
seguri >El problema aca es que la arquitectura de
seguri >direccionamiento de Internet esta incompleta. No
seguri >hay direcciones de "nodos". Entocnes las
seguri >direcciones IP tienen doble significado: tanto
seguri >"punto de conexion", como "nodo". Y eso es loq ue
seguri >usualmente motiva a pensar que todo el mundo (es
seguri >decir, cada nodo) tendria que tener una direccion IP propia.
seguri >
seguri >Saludos,
seguri >
seguri >--
seguri >Fernando Gont
seguri >e-mail: fernando en gont.com.ar || fgont en acm.org
seguri >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
seguri >
seguri >
seguri >
seguri >
seguri >_______________________________________________
seguri >Seguridad mailing list
seguri >Seguridad en lacnic.net
seguri >https://mail.lacnic.net/mailman/listinfo/seguridad
seguri >
seguri >
seguri >------------------------------
seguri >
seguri >Message: 5
seguri >Date: Fri, 08 Jun 2007 05:26:20 -0300
seguri >From: Fernando Gont <fernando en gont.com.ar>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <200706080826.l588QPjq006236 en venus.xmundo.net>
seguri >Content-Type: text/plain; charset="iso-8859-1"; format=flowed
seguri >
seguri >Carlos,
seguri >
seguri >>En particular usar el término hack sobre el protocolo TCP/IP me parece
seguri >>demasiado despectivo y hasta irrespetuoso con quienes lo diseñaron, aunque
seguri >>pueda ser que se sientan halagados por el hecho de ser considerados
seguri >>"hackers".
seguri >
seguri >Para nada es despectivo. O al menos, no intenta serlo.
seguri >
seguri >Los protocolos TCP e IP vienen dando vuelta desde
seguri >hace mas de 25 años. Me parece que es bastante
seguri >obvio que en estos ultimos 25 años "algo" se a
seguri >aprendido en el campo de las redes. Y siendo que
seguri >mantenemos los mismos protocolos, dichos
seguri >"avances" o tecnicas se han volcado a los protocolos existentes como hacks.
seguri >
seguri >SACK (en TCP) es un ejemplo. Agrega la capacidad
seguri >de ACKear paquetes (a la practica) a TCP. El tema
seguri >de ACKear bytes era valido hace veinte años
seguri >atras, cuando el hardware tenia mucha menor
seguri >capacidad que el actual, y habia gran trafico de
seguri >telnet. Pero no hoy en dia. SACK "emparcha" eso, por ejemplo.
seguri >
seguri >En lo que respecta al merito de los diseñadores
seguri >de los protocolos, es simple: revolucionaron la
seguri >forma en que la gente se comunica, y la vida
seguri >diaria de una gran cantidad de personas. Esto es
seguri >indiscutible, e imposible de opacar por cualquier
seguri >comentario tecnico acerca de los protocolos.
seguri >
seguri >
seguri >
seguri >>Que una opinion de un sector de las telecomunicaciones sea que el
seguri >>direccionamiento de nodos es indispensable y que no deben todos los
seguri >>elementos de una red contar con una direccion publica es hasta donde llega
seguri >>mi conocimiento: una opinion.
seguri >
seguri >Una opinion, y un esquema mas flexible.
seguri >
seguri >
seguri >
seguri >>O existe una demostración matemática de que
seguri >>así debe ser?
seguri >
seguri >Podes leer los papers (de mas de 20 años de
seguri >antigüedad) de Saltzer, por ejemplo.
seguri >
seguri >
seguri >
seguri >>(nota al margen:Podria una persona independiente unirse a una red donde el
seguri >>direccionamiento de nodos existiese y compartir sus bases de conocimiento
seguri >>con cualquier persona del mundo a un costo muy bajo?)
seguri >
seguri >No entiendo tu pregunta.
seguri >
seguri >
seguri >
seguri >>NAT nació para suplir la escasez de direcciones IPv4, por lo que la
seguri >>afirmación de que gracias a NAT se ha descubierto que tan mal estaban
seguri >>diseñados los protocolos me hace ver que no conozco literatura que sustente
seguri >>dichas afirmaciones y que obviamente me gustaría leer.
seguri >
seguri >A ver... a vos te parece correcto que un
seguri >protocolo de aplicacion para transferencia de
seguri >archivos maneje como objetos direcciones de
seguri >interfaz de red? Te parece justificable que el
seguri >cambio de un protocolo de red (v4 -> v6) implique
seguri >la modificacion de un protocolo de aplicacion para transferencia de archivos?
seguri >
seguri >Por si vale la aclaracion, nuevamente: FTP tiene
seguri >mas de 30 años de antiguedad. Originalmente, era
seguri >el protocolo que se utilizaba para el envio de
seguri >correo electronico. Y se diseño en un momento en
seguri >que las redes eran un simple experimento de
seguri >laboratorio. Por ello, sea cual sea su diseño, el
seguri >mismo no mancha la reputacion de los creadores.
seguri >Sin embargo, de ahi a decir que el diseño es
seguri >correcto... mm... hay un largo trecho.
seguri >
seguri >En cuanto a la literatura....si esperas leer
seguri >estas cosas de libros, creo que vas muerto (dudo que lo vayas a encontrar).
seguri >
seguri >
seguri >
seguri >>Por ahora mejor me despido viendo como los bits de este mensaje son
seguri >>"hackeados" para llegar a su destino.
seguri >
seguri >Si. Convengamos que es mas simple aceptar lo
seguri >usual como correcto, que intentar abstraerse e
seguri >intentar imaginar de que otra manera podrian
seguri >hacerse las cosas. (cuando lo unico que tienes a
seguri >mano es un martillo, todo te parece un clavo).
seguri >
seguri >"Free your mind, Neo."
seguri >
seguri >Saludos,
seguri >
seguri >--
seguri >Fernando Gont
seguri >e-mail: fernando en gont.com.ar || fgont en acm.org
seguri >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >
seguri >------------------------------
seguri >
seguri >Message: 6
seguri >Date: Fri, 08 Jun 2007 03:36:57 -0500
seguri >From: "Anatoly A. Pedemonte Ku" <apedemonte en gmail.com>
seguri >Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de
seguri > la lista de NANOG)
seguri >To: seguridad en lacnic.net
seguri >Message-ID: <46691529.9030407 en gmail.com>
seguri >Content-Type: text/plain; charset="iso-8859-1"
seguri >
seguri >Hola a todos, discutir sobre el NAT, tenemos para rato, creo que seguro
seguri >para todo no es, todo depende del escenario y que cosa deseas hacer...
seguri >hay muchas soluciones para utilizar dichas opciones de ocultar,
seguri >restringir, privar, asegurar, etc, etc una red o un segmente de red...
seguri >
seguri >Utilizar dicho feature del protocolo esta dado según el impacto que
seguri >deseen dentro de tu infraestructura tecnológica de comunicaciones, ya
seguri >sea para data, voz, etc,etc...
seguri >
seguri >Pero saliéndome del tema del NAT, y complementado los comentarios de por
seguri >que el TCP trae sorpresas....
seguri >
seguri >Bueno también hay que entender que las cosas nunca se hacen o se
seguri >inventan para las situaciones de una época a futuro no se sabe a cierta
seguri >medida quien inventa algo para que en 10 años, funcione o cumpla las
seguri >necesidades al futuro... no hay desarrollo alguno que a futuro sea 95%
seguri >perfecto...
seguri >
seguri >Solo sucede en la teorías... Pero nos damos cuenta que tal como se
seguri >predijo que las direcciones IP nunca se acabarían, se están acabando,
seguri >por que son una parte esencial en las redes...
seguri >
seguri >Muchos predijeron que las PC y los sistemas operativos de punto flotante
seguri >tenían un final, en esta década que viene, pero vemos que así como va
seguri >seguirá sobreviviviendo con el TCP-IP, de lado y como eje central en las
seguri >comunicaciones, y gracias a internet también, del cual depende
seguri >
seguri >Sabemos que muchas arquitecturas de hardware, como i386, AMD, PowerPC,
seguri >SPARC, DEC, apostaron por TCP-IP, y las plataformas informaticas, Mac,
seguri >MSX, Spectrum, etc, se ajustaron a TCP-IP, inclusive vemos celulares,
seguri >PDA, consolas de juego apostando por TCP-IP... Quizas veamos Microwave,
seguri >neveras, televisores, con TCP-IP
seguri >
seguri >Entonces no se puede decir que TCP-IP es la maldición por ponernos estas
seguri >piedritas en el camino... Pues inventar la pólvora o hacer todo el
seguri >conjunto de protocolos, es una cosa de locos.. pues creo que las
seguri >experiencias como los protocoles propietarios, que en paz descansen no
seguri >pudieron con el TCP-IP...
seguri >
seguri >Mientras exista TCP-IP, estaremos desarrollando mas tecnología, y
seguri >desarrollando mas dispositivos inimaginables, creo que hablar mal de
seguri >TCP-IP en este momento es como estar insultando a la columna vertebral
seguri >de las comunicaciones, y que por ahora con sus problemas hay que
seguri >convivir,.... a no ser que google haga la ingeniería al protocolo.... O
seguri >que la plataforma informática mas utilizada en el mundo, osea las
seguri >IBM-PC, sean desplazados por las Mac, que sinceramente esta tan cercana
seguri >esta afirmación... si no veamos no más como windows se parece e innova
seguri >con respecto a Mac por ser propietario con respecto a GNU/Linux que
seguri >tampoco se queda atrás en el rubro y además soportas varias
seguri >arquitecturas, por que si seguía con sus ventanas toscas, y sabiendo que
seguri >Apple se pasaba a la fila del arquitectura i386, perdía terreno....
seguri >
seguri >Un saludos a todos
seguri >
seguri >PD. Agradeciendo su comprensión, pido disculpas, si nota Ud. errores de ortografía y gramática en esta misiva.
seguri >-----------------------------------------------------------
seguri > Anatoly Alexei Pedemonte Ku
seguri > RAGE SYSTEMS S.A.C.
seguri > http://www.ragesys.net
seguri > Av. Juan Pascal Pringles 1225 (ex- La Fontana) - LA MOLINA
seguri > LIMA - PERU
seguri > Nextel: 511.98252347
seguri > Móvil: 511.97167435
seguri >-----------------------------------------------------------
seguri >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.
seguri >--------------------------------------------------------------------------------------------------------------------------------------
seguri >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.
seguri >--------------------------------------------------------------------------------------------------------------------------------------
seguri >
seguri >******** ESP: Esta sección no es virus, sino es la Llave publica de Firma Digital *********
seguri >******** ENG: This section do not a virus, really is the Public Key of Digital Sign *********
seguri >
seguri >-----BEGIN PGP PUBLIC KEY BLOCK-----
seguri >Version: GnuPG v1.4.3 (MingW32)
seguri >
seguri >mQGiBESAj0sRBACbs6YrxgfA3uYWdrMoJ0Sfq9ZAh+uxWF9mjuNV8CMKmovVQfor
seguri >o3KosZ9PzEkYa43WNgTYwPjcI1NkF2W0La0s44GBzJaxzfAojhfV9CgQoViJv+UJ
seguri >TFe7TG32wdG+M+E/FqA3vUfMvjoVCu/SY74H+VES7v8h7VJsy6dUDT3jKwCgspkU
seguri >oGlOVd9M4h3OiW2BINa/BcMD/ikzpBjrZ0wz0yfIBYgPUAO0yhQpfd0cPxL7lAi9
seguri >NGuGQtUdunkomPjzLt/989wCM8kmiEkhsR+mu3vceOLqeAR2mfoEX0vC1UYMlOcB
seguri >jitRdx19Wjm8fYVI98vuyIs/i6IGclZnXEoMLoOBvdaIIfj7ZpB59CFOx2WH3ixC
seguri >s0O6A/0aO7jE8ugDVVHtSdUayw+sAQes2zELdNAy0u8kOpSzWjaxTo2uJ+5py5/M
seguri >uBgifYQMljAnYkTCcBYXD39Din43r330peUpHX3OekRPLYYEOg0Px4sOjJVAf828
seguri >rysL1q4uKqUljE6aHVnFM+FkItqUKysAVgemW1wGxyW2UhwuBLQtQW5hdG9seSBB
seguri >LiBQZWRlbW9udGUgS3UgPGFuYXRvbHlAcmFnZXN5cy5uZXQ+iGYEExECACYFAkSA
seguri >j0sCGwMFCQHhM4AGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBJuebWcCX7tbwi
seguri >AJsHXrCU+6dCHf8xUeDdrzJN/NTrlQCgiMjRs7KDAQnu9a0yklQYGlG2W2+5Ag0E
seguri >RICPgxAIAIFh8TQuAbWfmj9pez98L6mlNDyQSXyrIUXTFXK3hLMOA0u4oyz6EuCH
seguri >zZOIUxveeumspSv98F6vP/W7AQBfX5t6pakvmyRHtBcsdx1dFgOlIWRGHP86tgdl
seguri >Ci4s+C9vGrbynXbNDPoV/cCqYZeeKNBbUHbUH3j+hKKTz0mpiHPaFWTsGzmxQpoI
seguri >cSHnbGPuIwew9TDC9qnESmGscG8IfZXsB7UjkDMyGUVQNwYd+hqPOof/qMFiR2cG
seguri >x2IUs3dGroffjkmncgvoPfBPq0B+7cIqhnEznKCxvjvorZnpT/9uW1Apch8QwXcg
seguri >SK/QkHBYwweYWzHYaqzkLzustwJ2dNMAAwYH/RReKPnCUJa45gw3Bv76z9UK0ABr
seguri >OLRfVq1nnRnqs1LM+z7xKMpEfzQDIyNoqUlE42pNNYd/N8rz+3PP1pRypcpbP+B/
seguri >MNOBEaFhvS7X5El8WfXRIaM19hLpEHVeTPG71cOJaiu/PC6a7KkOarKCIJYa7uU0
seguri >JhqVPaAeButljRuQJpR9rjpdPPd2+4sVaWrabtnyhm/oiYQthyMdB8xq2slWreTL
seguri >hWFtsenfgVvOlBpt8ZwGpQkzASLBwdGhisMYXQStw1D9dbDFQbb8pqO/9eos9rkL
seguri >sflAvD1F3VJl2TmaxjvRRgnAgRzdt3vTWvrYPf2WyesT0C78rriVeWzmuD6ITwQY
seguri >EQIADwUCRICPgwIbDAUJAeEzgAAKCRBJuebWcCX7tRdWAKCIlj2g5aMf4CKqwEjx
seguri >uAEzo28PuQCfV/U+ptv+7+D0xkMzZ5HG1yxMrhQ=
seguri >=GD85
seguri >-----END PGP PUBLIC KEY BLOCK-----
seguri >
seguri >
seguri >
seguri >Carlos Quevedo escribió:
seguri >> No concuerdo con lo de hack por todos lados, TCP/IP es una familia de
seguri >> protocolos y como tal tiene virtudes y defectos en mi opinion.
seguri >>
seguri >> No se si exista un protocolo publico al que nunca le hayan encontrado fallas
seguri >> de seguridad, pero me extrañaría mucho que existiese uno de esas
seguri >> características por el simple hecho de que los protocolos son diseñados
seguri >> pensando en un conjunto predeterminado de situaciones, o es que se puede
seguri >> diseñar un protocolo teniendo en cuenta todas las situaciones posibles?
seguri >>
seguri >> En particular usar el término hack sobre el protocolo TCP/IP me parece
seguri >> demasiado despectivo y hasta irrespetuoso con quienes lo diseñaron, aunque
seguri >> pueda ser que se sientan halagados por el hecho de ser considerados
seguri >> "hackers".
seguri >>
seguri >> Que una opinion de un sector de las telecomunicaciones sea que el
seguri >> direccionamiento de nodos es indispensable y que no deben todos los
seguri >> elementos de una red contar con una direccion publica es hasta donde llega
seguri >> mi conocimiento: una opinion. O existe una demostración matemática de que
seguri >> así debe ser?
seguri >>
seguri >> (nota al margen:Podria una persona independiente unirse a una red donde el
seguri >> direccionamiento de nodos existiese y compartir sus bases de conocimiento
seguri >> con cualquier persona del mundo a un costo muy bajo?)
seguri >>
seguri >> NAT nació para suplir la escasez de direcciones IPv4, por lo que la
seguri >> afirmación de que gracias a NAT se ha descubierto que tan mal estaban
seguri >> diseñados los protocolos me hace ver que no conozco literatura que sustente
seguri >> dichas afirmaciones y que obviamente me gustaría leer.
seguri >>
seguri >> Por ahora mejor me despido viendo como los bits de este mensaje son
seguri >> "hackeados" para llegar a su destino.
seguri >>
seguri >> Carlos Quevedo
seguri >> Asesor Técnico CCIT
seguri >>
seguri >> ----- Original Message -----
seguri >> From: "Fernando Gont" <fernando en gont.com.ar>
seguri >> To: <seguridad en lacnic.net>
seguri >> Sent: Thursday, June 07, 2007 10:33 PM
seguri >> Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la
seguri >> lista de NANOG)
seguri >>
seguri >>
seguri >> Carlos,
seguri >>
seguri >> Mis respuestas/comentarios van entre lineas....
seguri >>
seguri >>
seguri >>
seguri >>>> Not 5 or 6, but in my company I could show
seguri >>>>
seguri >>> you paths with 4 NATs. Many of them. And no
seguri >>> acquisitions, just different Divisions of the same company.
seguri >>>
seguri >>>> I once spent three days trying to get the
seguri >>>>
seguri >>> four administrators to talk among themselves
seguri >>> and determine where a SYN flood was coming from.
seguri >>>
seguri >>
seguri >> Cuando se aplica con alguna motivacion de
seguri >> seguridad, el NAT justamente apunta a "ocultar"
seguri >> los sistemas que estan detras del NAT. Ese esa
seguri >> propia caracteristica la que, en escenarios como
seguri >> el que describis, puede dificultar el rastreo de ataques.
seguri >>
seguri >> Nosotros (en UTN/FRH) haciamos NAT+stateful
seguri >> filtering. Por ello, ataques como el SYN flood
seguri >> podian ser evitados simplemente limitando las
seguri >> conexiones activas que un sistema podia mantener.
seguri >> Tambien es de notar que el NAT lo haciamos justo
seguri >> antes de salir a Internet. Tanto la red interna,
seguri >> como el acceso de nuestros clientes a los
seguri >> servidores publicos, se realizaba utilizando direcciones privadas.
seguri >>
seguri >>
seguri >>
seguri >>
seguri >>>> Whatever people say, NAT is a hack. NAT was
seguri >>>>
seguri >>> intended to extend IPv4's lifetime (togher with
seguri >>> CIDR they were pretty successful at that) and nothing else.
seguri >>>
seguri >>
seguri >> TCP/IP es un hack en si... por donde lo mires.
seguri >>
seguri >> Por ej., en IP el esquema de direccionamiento
seguri >> esta incompleto (tanto en v4, como en v6).
seguri >>
seguri >> En TCP, se agrego control de congestion (!)
seguri >> cuando Internet colapso a mitad de los 80. SACK
seguri >> es un parche para ackear paquetes. El
seguri >> pseudoheader de TCP es algo poco limpio. :-)
seguri >>
seguri >> Los well-known ports (por ej., "el puerto 80 es
seguri >> la web") no es mas que un hack ante la carencia de un servicio de
seguri >> directorio.
seguri >>
seguri >> etc., etc., etc.
seguri >>
seguri >>
seguri >>
seguri >>
seguri >>>> And as someone said it earlier, instead of
seguri >>>>
seguri >>> promoting layer separation NAT it has promoted "protocol hacking hell".
seguri >>>
seguri >>>> Please, even the related PIX commands are named after they hackish
seguri >>>> nature:
seguri >>>>
seguri >>>> "fixup protocol dns"
seguri >>>> "fixup protocol ftp"
seguri >>>>
seguri >>
seguri >> Yo discrepo con esta observacion. En la gran
seguri >> mayoria de los casos, NAT simplemente hizo
seguri >> evidente que numerosos protocolos estan mal diseñados.
seguri >>
seguri >> Pensa el caso de FTP. De donde proviene la
seguri >> dificulta principal de usar FTP a traves de
seguri >> NATs/middle-boxes? - Basicamente, el problema
seguri >> radica que en el protocolo de *aplicacion* TCP se
seguri >> transfieren direcciones IP y numeros de puerto
seguri >> TCP. Y esta clarisimo que un protocolo de
seguri >> aplicacion no tendria que trabajar con tales objetos de tan bajo nivel.
seguri >>
seguri >> (Como puede ser que haya que modificar FTP para que pueda andar con v6?????)
seguri >>
seguri >> La gente pro-v6 usa como uno de sus argumentos de
seguri >> marketing que todos los sistemas que accedan a
seguri >> Internet tienen que ser directamente
seguri >> direccionables ("end to end argument"). Esto es
seguri >> un error. El hecho de que un sistema quiera
seguri >> acceder a Internet no tiene porque implicar,
seguri >> desde un punto de vista teorico
seguri >> (direccionamiento) que tenga un punto de conexion
seguri >> (direccion IP, en este caso) publico.
seguri >>
seguri >> El problema aca es que la arquitectura de
seguri >> direccionamiento de Internet esta incompleta. No
seguri >> hay direcciones de "nodos". Entocnes las
seguri >> direcciones IP tienen doble significado: tanto
seguri >> "punto de conexion", como "nodo". Y eso es loq ue
seguri >> usualmente motiva a pensar que todo el mundo (es
seguri >> decir, cada nodo) tendria que tener una direccion IP propia.
seguri >>
seguri >> Saludos,
seguri >>
seguri >>
seguri >------------ próxima parte ------------
seguri >Se ha borrado un adjunto en formato HTML...
seguri >URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20070608/679eeb24/attachment.htm
seguri >------------ próxima parte ------------
seguri >Se ha borrado un mensaje que no está en formato texto plano...
seguri >Nombre : signature.asc
seguri >Tipo : application/pgp-signature
seguri >Tamaño : 187 bytes
seguri >Descripción: OpenPGP digital signature
seguri >Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20070608/679eeb24/attachment.pgp
seguri >
seguri >------------------------------
seguri >
seguri >_______________________________________________
seguri >Seguridad mailing list
seguri >Seguridad en lacnic.net
seguri >https://mail.lacnic.net/mailman/listinfo/seguridad
seguri >
seguri >
seguri >Fin de Resumen de Seguridad, Vol 14, Envío 11
seguri >*********************************************
seguri >
Más información sobre la lista de distribución Seguridad