[LACNIC/Seguridad] NAT o no NAT esa es la cuestion
Ariel Sabiguero Yawelak
asabigue en fing.edu.uy
Vie Jun 8 09:25:27 BRT 2007
JORDI PALET MARTINEZ escribió:
> Hola Ariel,
>
> Sin animo de crear un nuevo debate,
¿por qué no? Para eso es la lista de seguridad ¿no? :-D
> pero siendo de nuevo imparcial y
> especialmente practico, hay una solucion mas sencilla para no tener que
> hacer todo lo que tu dices:
>
> Usar IPsec extremo a extremo.
>
Si por "extremo a extremo" te referís modo transporte, de todas formas,
estás dejando sin encriptar las direcciones origen y destino. Por otro
lado, en modo tunel si encriptás el paquete completo, pero tenés que
desplegarlo en algun router y no es trivial luego hacer que sea
flexible como para cambiar mi proveedor de correo o cosas del estilo.
Claramente es una herramienta adicional, pero no le veo aplicación a la
navegación, por ejemplo.
> Su uso tiene que extenderse, y salvo que surgan otras alternativas que
> compitan con IPsec, estoy seguro de que asi sera en mayor medida en los
> proximos años, especialmente con el despliegue de IPv6.
>
No quiero hacer demasiado ruido (ni tengo la bola de cristal!), pero no
veo motivo para que se despliegue IPsec más en IPv6 que en IPv4.
A nivel del v6RL se está discutiendo si exigirlo o no para dar el Ready
Logo Phase III, pero claramente no es un requisito actualmente.... por
más que puedas certificarte.
Dudo que algo demasiado distinto vaya a pasar en el mundo IPv6 a lo que
pasa en el IPv4 actualmente. Quienes requieren un tunel lo usan (entre
tantas otras opciones) y el resto, quizás ni saben que existe :-)
> Curiosamente, si utilizas NAT, no puedes hacer IPsec extremo a extremo salvo
> que hagas configuraciones especiales en el NAT.
>
Más simple usar OpenVPN. Está claro que no es lo mismo (transporte vs
red, etc.), pero a los efectos es "NAT-compatible", sirve para hacer
TunnelBrokers de IPv6 y tiene una base de usuarios bastante grande
actualmente.
Cuidate
Ariel
> Saludos,
> Jordi
>
>
>
>
>
>> De: Ariel Sabiguero Yawelak <asabigue en fing.edu.uy>
>> Responder a: <seguridad en lacnic.net>
>> Fecha: Fri, 08 Jun 2007 08:41:26 -0300
>> Para: <nantoniello en antel.net.uy>, <seguridad en lacnic.net>
>> Asunto: Re: [LACNIC/Seguridad] NAT o no NAT esa es la cuestion
>>
>>
>>
>>> Algunos comentarios a modo de fomentar la discusión:
>>>
>>>
>> Bueno, ya estaba fomentada :-D (y en algunos casos un poco exaltada).
>>
>>
>>> seguri >> > Quizás está la imagen de la empresa. Quizás no se quiera saber
>>> que,
>>> seguri >> > desde las máquinas de los directores se accede a sitios
>>> pornográficos o
>>> seguri >> > que no condicen con otros objetivos de mi empresa.
>>> seguri >>
>>> seguri >>Y como puede un ente externo saber que una IP dada pertenece a un
>>> director?
>>> seguri >
>>> seguri >Por ej leyendo el encabezado de un mail enviado por el director.
>>>
>>> El uso de un proxy para WEB no implica que se tenga que utilizar NAT para
>>> todo el resto. Los proxy WEB se justifican, en ciertos casos, por una
>>> serie de motivos mas alla de que se utilice NAT o no. Creo que no se puede
>>> poner al uso de un proxy como argumento a favor del NAT.
>>>
>>>
>> Bueno, en el ejemplo anterior se supo la IP del Director por el
>> encabezado de su e-mail.... tengo que instalar también un SMTP local
>> para anonimizar el e-mail? Tengo que poner un proxy por cada protocolo?
>> También otro para anonimizar los torrents?
>> Ese equipo va a estar complicado de administar... y lleno de
>> vulnerabilidades en el software, pues todos esos proxies realmente van a
>> tener que estar emparchados en cada revisión de software...
>> El ejemplo de WEB era simplemente uno, pero podríamos utilizarlo para
>> "anonimizar" cualquier protocolo X. Si dispongo de NAT/PAT como
>> "servicio" me ahorro de programarlo en mis aplicaciones y no preciso un
>> proxy-X o gateway-X para todo protocolo posible.
>>
>> Mirémoslo como un problema abstracto: no quiero que fuera de mi
>> organización de conozca o individulice el tráfico. Ni si quiera para un
>> ataque, observación pasiva. Sacar la totalidad del tráfico con una única
>> IP es perfecto para eso.
>> Quizás no precisamos tantas direcciones, y quizás por eso aun no se usa
>> IPv6 aun, pero no es culpa del NAT/PAT.
>>
>>> Ademas, si
>>> asumimos que esta bloqueado TODO el trafico indeseable, que me aporta el
>>> nat respecto a la seguridad referente a la alcanzabilidad de mi red?
>>>
>>>
>> Que desde afuera no se conoce cuántas máquinas tengo, qué hace cada una,
>> etc. No podés trivialmente hacer una matríz de orígenes y destinos de
>> mis conexiones, etc. Podés aplicar quizás alguna heurística o inspección
>> más compleja, pero deja de ser trivial. Dejás de poder correlacionar
>> tráficos con usuarios de una manera simple, etc.
>> Me podrán contestar "pero si querés privacidad en el correo, encriptalo"
>> se, el body si, los headers no... podríamos discutirlo protocolo a
>> protocolo. En algunos hay mejores opciones, en otros no tanto... pero la
>> seguridad, concebida como una suma de medidas, creo que es mejor lograda
>> "sumando" lo que cada capa puede darme. Efectivamete creo que si ponés
>> un proxy detrás de un NAT resolvés tanto las cosas proxiables, como
>> todas aquellas que no son proxiables detras de la misma ip.
>>
>> Alguien sugirió seguridad en base a "ocultamiento", pero no es de lo que
>> se trata. Meramente se trata de no divulgar información innecesaria.
>> Muchas veces "menos es más".
>>
>>> Por ultimo, y esto tambien se dijo antes, es falsa la premisa de que el
>>> NAT haga inalcanzables los sistemas desde Internet, pues la proteccion que
>>> pueda dar el NAT se bypasea (siendo un poco simplista) haciendo un
>>> spoofing de IPs, puertos y algo mas.... si bien esto no seria tan facil en
>>> la practica, la proteccion real la estaria dando el firewall y no el NAT.
>>>
>>>
>> Creo que nunca se habló de reemplazar un firewall (realmente no lo
>> recuerdo en la lista) por solamente un "nat device". Creo que se habla
>> solamente de utilizar NAT como algo con valor agregado al resto de las
>> políticas de seguridad.
>>
>>> Por otro lado, también hay que pensar en el uso que se le da al NAT... si
>>> pensamos en tener mas de un servicio (servidores) publico en un red que es
>>> privada (detras de un NAT por ejemplo), creo que ya estamos incurriendo un
>>> error de diseño pues si los servidores son "publicos" no deberian estar
>>> direccionados en forma privada.
>>>
>>>
>> Asumiendo que tenés suficientes direcciones y no estás aplicando NAT
>> porque te faltan, el motivo que se me ocurre (y he usado) para hacer
>> "NAT reverso" es para esconder un poco mi topología en caso de un
>> ataque. Para simplificar la cosa, digamos que "ofrezco" servicios de
>> HTTP y SMTP en una misma IP, y poruq me comí un parche de PHP o porque
>> aun nadie publicó una vulnerabilidad y un cracker muy bueno la explotó y
>> consiguió acceso a mi server HTTP, solamente tiene la mitad de mis
>> servicios, y no la totalidad. Por otra parte, como E.Cota dijo, le va a
>> insumir un tiempo darse cuenta de mi topología. Probablemente poco, pero
>> seguramente algo más le va a llevar. Aumenta mis chances de detectarlo.
>> De todas formas, espero que no pueda esquivar el chroot-jail donde corre
>> el servicio, y además, que mi IDS detecte algo de tráfico "inesperado"
>> en ese equipo, etc.
>>
>>
>>> Ahora bien, si tenemos una red privada desde la que mayormente se
>>> "consume" de Internet (en lugar de "servir" datos), pues no le veo mayores
>>> problemas al NAT (salvando el problema de ciertas aplicaciones ya
>>> mencionadas). Lo que si creo, es que de todas formas, el NAT no sera una
>>> medida de seguridad sino una solucion cuando me dan una unica IP o un
>>> intento (en general fallido) de simplificacion del "control" de acceso a
>>> una red.
>>>
>>>
>> Mirale el valor que tiene a no dar más info de la necesaria. Per se, eso
>> ya es importante.
>> Cuando hacés turismo, ¿te ponés un gorro que dice "turista" y colgás una
>> cámara de fotos bien cara en la mitad del pecho, a la vista de todo el
>> mundo o te mimetizás todo lo que podés para pasar lo más inadvertido
>> posible?
>> Eso también es seguridad y dar la menor información posible ;-)
>>
>> _______________________________________________
>> Seguridad mailing list
>> Seguridad en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/seguridad
>>
>
>
>
>
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
>
> Bye 6Bone. Hi, IPv6 !
> http://www.ipv6day.org
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20070608/f3b57c9d/attachment.html>
Más información sobre la lista de distribución Seguridad