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

[Carlos Quevedo]

No concuerdo con lo de hack por todos lados, TCP/IP es una familia de 
protocolos y como tal tiene virtudes y defectos en mi opinion.

No se si exista un protocolo publico al que nunca le hayan encontrado fallas 
de seguridad, pero me extrañaría mucho que existiese uno de esas 
características por el simple hecho de que los protocolos son diseñados 
pensando en un conjunto predeterminado de situaciones, o es que se puede 
diseñar un protocolo teniendo en cuenta todas las situaciones posibles?

En particular usar el término hack sobre el protocolo TCP/IP me parece 
demasiado despectivo y hasta irrespetuoso con quienes lo diseñaron, aunque 
pueda ser que se sientan halagados por el hecho de ser considerados 
"hackers".

Que una opinion de un sector de las telecomunicaciones sea que el 
direccionamiento de nodos es indispensable y que no deben todos los 
elementos de una red contar con una direccion publica es hasta donde llega 
mi conocimiento: una opinion.  O existe una demostración matemática de que 
así debe ser?

(nota al margen:Podria una persona independiente unirse a una red donde el 
direccionamiento de nodos existiese y compartir sus bases de conocimiento 
con cualquier persona del mundo a un costo muy bajo?)

NAT nació para suplir la escasez de direcciones IPv4, por lo que la 
afirmación de que gracias a NAT se ha descubierto que tan mal estaban 
diseñados los protocolos me hace ver que no conozco literatura que sustente 
dichas afirmaciones y que obviamente me gustaría leer.

Por ahora mejor me despido viendo como los bits de este mensaje son 
"hackeados" para llegar a su destino.

Carlos Quevedo
Asesor Técnico CCIT

----- Original Message ----- 
From: "Fernando Gont" <fernando en gont.com.ar>
To: <seguridad en lacnic.net>
Sent: Thursday, June 07, 2007 10:33 PM
Subject: Re: [LACNIC/Seguridad] El NAT y la seguridad (Cross-post de la 
lista de NANOG)


Carlos,

Mis respuestas/comentarios van entre lineas....


> > 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.

Cuando se aplica con alguna motivacion de
seguridad, el NAT justamente apunta a "ocultar"
los sistemas que estan detras del NAT. Ese esa
propia caracteristica la que, en escenarios como
el que describis, puede dificultar el rastreo de ataques.

Nosotros (en UTN/FRH) haciamos NAT+stateful
filtering. Por ello, ataques como el SYN flood
podian ser evitados simplemente limitando las
conexiones activas que un sistema podia mantener.
Tambien es de notar que el NAT lo haciamos justo
antes de salir a Internet. Tanto la red interna,
como el acceso de nuestros clientes a los
servidores publicos, se realizaba utilizando direcciones privadas.



> > 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.

TCP/IP es un hack en si... por donde lo mires.

Por ej., en IP el esquema de direccionamiento
esta incompleto (tanto en v4, como en v6).

En TCP, se agrego control de congestion (!)
cuando Internet colapso a mitad de los 80. SACK
es un parche para ackear paquetes. El
pseudoheader de TCP es algo poco limpio. :-)

Los well-known ports (por ej., "el puerto 80 es
la web") no es mas que un hack ante la carencia de un servicio de 
directorio.

etc., etc., etc.



> > 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"

Yo discrepo con esta observacion. En la gran
mayoria de los casos, NAT simplemente hizo
evidente que numerosos protocolos estan mal diseñados.

Pensa el caso de FTP. De donde proviene la
dificulta principal de usar FTP a traves de
NATs/middle-boxes? - Basicamente, el problema
radica que en el protocolo de *aplicacion* TCP se
transfieren direcciones IP y numeros de puerto
TCP. Y esta clarisimo que un protocolo de
aplicacion no tendria que trabajar con tales objetos de tan bajo nivel.

(Como puede ser que haya que modificar FTP para que pueda andar con v6?????)

La gente pro-v6 usa como uno de sus argumentos de
marketing que todos los sistemas que accedan a
Internet tienen que ser directamente
direccionables ("end to end argument"). Esto es
un error. El hecho de que un sistema quiera
acceder a Internet no tiene porque implicar,
desde un punto de vista teorico
(direccionamiento) que tenga un punto de conexion
(direccion IP, en este caso) publico.

El problema aca es que la arquitectura de
direccionamiento de Internet esta incompleta. No
hay direcciones de "nodos". Entocnes las
direcciones IP tienen doble significado: tanto
"punto de conexion", como "nodo". Y eso es loq ue
usualmente motiva a pensar que todo el mundo (es
decir, cada nodo) tendria que tener una direccion IP propia.

Saludos,

-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
https://mail.lacnic.net/mailman/listinfo/seguridad