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

[Fernando Gont]

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