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

[Eduardo Cota]

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

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.

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.

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