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

[Nicolás Ruiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eduardo Cota wrote:
> Hola a todos, (hola Carlos!)
> Algunos comentarios respecto a los puntos que Carlos planteó
> originalmente....
> Totalmente de acuerdo en los problemas que ocasiona NAT/PAT para el
> rastreo de problemas.
> Lo que no estoy de acuerdo es que los ALGs, y la "dificultad para
> innovar", sea solamente culpa de NAT.
> El problema de la necesidad de ALGs, del "fixup protocol" como cisco lo
> llama, no desaparece si desaparece NAT. Esta necesidad en mi opinión es
> inherente a los firewalls con estado (al menos en sus implementaciones
> actuales).

No es un problema de los firewalls de estado. Es un problema de aquellos
protocolos que abren otras conexiones adicionales de al conexión inicial
(FTP, H.323).

> Ejemplo sencillo: todos sabemos que NAT causa problemas con el protocolo
> FTP. Pero el mismo problema tenemos si estamos utilizando un firewall,
> aunque se utilicen direcciones públicas en ambos lados del firewall, a
> menos que utilicemos ftp pasivo (de por sí un "workaround" al problema
> de los firewalls y NAT/PAT). ¿por qué? porque, a menos que el firewall
> tenga la inteligencia para observar dentro del protocolo cuales son los
> puertos que el cliente quiere utilizar para la conexión en sentido
> "reverso" (un ALG), la conexión de datos será bloqueada (obviando las
> distintas variantes de ftp). Lo mismo sucede por ejemplo con el p2p.
> Aunque ambos extremos tengan IP públicas, si ambos están detrás de un
> firewall que no permite conexiones entrantes, no podrán conectarse
> directamente.

Efectivamente FTP necesita ser inspeccionado en un firewall de estado
para poder identificar cual es la tupla IP-puerto que se va a utilizar
para la conexión de transferencia de dato.

Pero no es el caso necesariamente con un P2P. Para permitir un nodo P2P
basta con que el firewall permita acceso a una tupla IP-puerto. No es lo
mismo con un NAT, en el cual no tienes forma de saber a cual de las
múltiples IP NATeadas se debe hacer la conexión.

> Hay protocolos intentando paliar el problema (por ejemplo permitiendo al
> cliente indicarle al firewall qué puertos precisa abrir), pero son
> aplicables tanto a NAT/PAT como a los firewalls, no es un problema
> exclusivo de NAT.

No es lo mismo. Si 2 máquinas NATeadas quieren abrir el mismo puerto, el
NAT debe utilizar al menos 2 direcciones IP públicas para poder
distinguir conexiones entrantes a cada una de ellas.

> Como comenta Jordi en otro correo (disculpas si interpreté mal), lo
> único que puede volver a permitir la conectividad total "end to end" es
> alguna arquitectura de red, donde el equipo final tenga el control de
> qué puertos se abren o cierran en la "frontera" (ya sea perímetro, ya
> sea protección en cada host), ya que son las aplicaciones corriendo en
> el host las que saben qué precisan.
> 
> Saludos,
>         Eduardo Cota.
> 
> 
> 
> On Thu, 7 Jun 2007, Carlos M. Martinez wrote:
> 
>> Hola a todos,
>>
>> queria compartir con uds un post que hice en la lista de NANOG.
>> Disculpas por que esta en Inglés. Mi interés es motivar la discusión
>> sobre NAT y seguridad, discusión que cobra mucha fuerza con el
>> advenimiento de IPv6
>>
>>> Hi,
>>>
>>> Valdis.Kletnieks en vt.edu wrote:
>>>>
>>>> I think somebody on this list mentioned that due to corporate
>>>> acquisitions,
>>>> there were legitimate paths between machines that traversed 5 or 6
>>>> NATs.
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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"
>>>
>>> This completely destroys the end-to-end nature of application
>>> protocols! If someone wants to improve FTP or anything that requires
>>> a "fixup", it doesn't suffice to code a server and a client. No, you
>>> need to talk to 1.000sh firewall manufacturers so they correct their
>>> "fixups".
>>>
>>> Which they might or might not do, of course, depending on how they
>>> feel that particular day. Talk about vendor lock-in.
>>>
>>> In my view, this ossifies the whole Internet development cycle.
>>>
>>> And the argument that NAT is easier to administer than a full SI
>>> firewall is pretty thin, even if it was true, about what I have my
>>> doubts. Moreover, not everything in life should be conditioned to the
>>> "easier to administer" argument.
>>>
>>> Sorry about the rant :-)
>>>
>>> Carlos M.
>>> ANTEL Uruguay
>>>
>>>> But yeah, "Sure, very easily".  Whatever you say...
>> _______________________________________________
>> Seguridad mailing list
>> Seguridad en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/seguridad
>>
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
nicolas en ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaaZzmjsZS9ZBxv8RAqKUAJ49BEcOn1Cx9yiVXzEaa3oExGfGwQCfagKW
ZKdZ/s/xvErhVQ4K2YsTtPM=
=gvMK
-----END PGP SIGNATURE-----