[LUG.ro] NATted Hosts

[Alejandro Crovetto]

On Tue, 12 Aug 2003 15:20:27 -0300
Walter Castro <W_CASTRO@crm.com.ar> wrote:

WC> Me vino a la mente alguien que pregunto por algo asi en la lista....

Aca dejo otro texto:

  Hispasec - una-al-día                               
  31/07/2003
  Todos los días una noticia de seguridad         
www.hispasec.com

-------------------------------------------------------------------
 
 Contar máquinas detrás de un NAT
 --------------------------------

Aunque teóricamente no es posible hacerlo, un estudio
reciente demuestra la factibilidad de identificar
máquinas y su tráfico asociado situadas tras un NAT, o
pasarela de traducción de direcciones de red.

El estudio publicado por Steve Bellovin, especialista
en seguridad de reconocido prestigio, demuestra cómo
es posible asociar los datagramas vistos en la cara
pública del NAT (típicamente, Internet) con máquinas
individuales en la parte privada (típicamente, una LAN
o red de área local).

Esta identificación permite varias posibilidades, como
el poder contar el número de máquinas situadas tras el
NAT (útil para un ISP que limita el número de
ordenadores que se pueden conectar por una línea) o
identificar tráfico y asociarlo a equipos en concreto.

En un sistema NAT clásico, cuando una máquina interna
envía un datagrama al exterior, el NAT lo reescribe
poniendo su IP "pública" como remitente del mismo, y
un puerto origen arbitrario. Cuando llega un datagrama
de respuesta, se busca el puerto de destino (el puerto
de origen arbitrario de la frase anterior) en una
tabla interna, obteniéndose el puerto original y la IP
interna a la que debe enviarlo.

La tecnología NAT se emplea, fundamentalmente, cuando
es necesario conectar una red LAN a Internet
disponiendo de menos IPs públicas que equipos
internos. El equipo NAT se encarga de multiplexar las
peticiones internas entre las IPs y puertos públicos
externos, permitiendo que toda la LAN acceda a
Internet sin necesitar una IP pública por equipo. Un
NAT puede proporcionar otros servicios, como
cortafuegos o servidor de VPNs.

Tradicionalmente siempre se ha considerado que un NAT
oculta el número, la identidad y las características
de la red LAN interna. Este estudio, sin embargo,
demuestra que no es así; los datagramas "traducidos"
conservan los suficientes rastros sin alterar como
para que se pueda identificar su origen. En concreto,
todos los datagramas IPv4 contienen un campo de 16
bits utilizado en el caso de que sea necesario
fragmentarlo en la ruta hacia su destino. Dicho campo
permite que el receptor identifique los distintos
fragmentos de un datagrama y pueda reensamblarlo de
nuevo.

Aunque lo único que el protocolo IP requiere de dicho
campo es que sea único durante unos minutos, en la
práctica la mayoría de las implementaciones se limitan
a utilizar un contador que se va incrementando con
cada datagrama enviado. Esto unido al hecho de que los
sistemas NAT suelen dejar este campo inalterado, como
demuestra Bellovin, permite asociar cada datagrama a
una máquina interna concreta.

Las medidas a tomar son evidentes una vez que se
identifica el problema: el sistema NAT debe modificar
el campo de identificación de los datagramas que lo
atraviesan (complicado) y, por otro lado, los sistemas
operativos usados en las máquinas internas deben
generar los valores de este campo de forma aleatoria
o, al menos, no predecible para un "escucha" externo
(fácil). Los sistemas operativos "Open Source" OpenBSD
y FreeBSD ya han integrado dicha mejora en su código.

El documento, disponible en formato PDF, es una
lectura llana, amena e interesante. Recomendable.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/1740/comentar

Más Información:

Remotely Counting Machines Behind A NAT Box
http://slashdot.org/article.pl?sid=03/02/05/2129218

El documento en cuestión
http://www.research.att.com/~smb/papers/fnat.pdf

Parche OpenBSD
http://marc.theaimsgroup.com/?l=openbsd-cvs&m=104473518402730&w=2

Slashback: Regalia, Godseye, Undetection
http://slashdot.org/article.pl?sid=03/02/13/0048219


Jesús Cea Avión
jcea@hispasec.com

-- 
Alejandro Crovetto <cabro@ciudad.com.ar>