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

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