[LACNIC/Seguridad] [lacnog] Thomas Ptacek: Against DNSSEC

Fernando Gont fgont en si6networks.com
Jue Ene 28 18:39:01 BRST 2016


On 01/27/2016 04:55 PM, Carlos M. Martinez wrote:
>> On 01/27/2016 12:51 PM, Carlos M. Martinez wrote:
>>>>
>>>> Podes describir un escenario de ataque en el cual DNSSEC serviria paa
>>>> mitigar ese riesgo, y para el cual no exista otra variedad de ataque
>>>> igual o mas simple, para lograr lo mismo o algo similar?
>>>
>>> Y cuando logres arreglar esos ataques 'mas simples', ups, derrepente el
>>> agujero del DNS se vuelve es eslabón débil.
>>
>> Los ataques "mas simples" son ataques que realmente no espero que sean
>> mitigados. Por ejemplo, no espero que vaya a autentificarse el trafico
>> ARP ni Neighbor Discovery.
> 
> Dos comentarios: a primera vista parece mucho mas facil y mas 'de guante
> blanco', en el sentido de dejar menos trazas, explotar remotamente un
> cache de DNS que comprometer localmente un switch para poder alterar el
> ARP o el ND.

Aca creo que es crucial describir los escenarios de ataque... sino es
dificil.

Lease: si vos me describis un escenario en que quede en claro que el
atacante puedo lograr su cometido via DNS de manera igual o mas simple
que utilizando otra via, es un buen punto de patida.

Yo no encontre tal escenario. Y tal escenario supone ser el motivador
tecnico de DNSSEC.



> El segundo es que el hecho de que dos problemas nos parezca desde
> nuestro lugar que no van a ser arreglados dificilmente nos excusa de no
> tapar el pequeño agujero que quienes operamos servidores y zonas de DNS
> podemos tapar.

Yo no veo el despliegue de DNSSEC como "tapar un agujero", sino mas bien
como "agregar funcionalidad". Y si voy a agregar funcionalidad, tengo
que tener una motivacion.



> El tercero (perdon, se me ocurrió otro :-) ) es que el hecho de que a
> alguno nos parezca que tal cosa va a ser o no arreglada no deja de ser
> una percepción sobre la que, en realidad, no sabemos. Estamos asumiendo
> un comportamiento de la comunidad y de la industria desde un punto de
> vista muy local.

Como desplegar algo implica dinero, uno falla "del lado barato".


En el caso en que, por ejemplo, un usuario esta navegando desde un
cibercafe, no veo como DNSsec evta que el atacante pueda se victima de
redireccion de trafico hacia el atacante (si el mismo esta en la misma
red) mediante arpcache poisoning o redireccion estilo "via icmp redirects".

COmo atacante, lo que me importa es lograr mi cometido.



>> Lease, se construye el resto sobre la premisa que o bien esos ataques no
>> van a suceder, o si suceden es porque el escenario es tal que mitigar
>> dichos ataques es una perdida de dinero.
> 
> Vuelvo a mi punto anterior. Nadie puede resolver todos los problemas,
> pero participantes individuales de la comunidad podemos tapar los
> agujeros que podemos tapar. No hacerlo, por mas que no me gusten las
> herramientas que tengo para hacerlo, es irresponsable.

Yo veo a DNSSEC como una funcionalidad extra del DNS, y no como el
parcheo de un agujero. De hecho, el DNS por definicion no autentifica nada.


DNSSEC agrega al DNS algo completamente nuevo, que no forma parte del
DNS en si, ni souciona "bugs" de diseño de DNS.


Del mismo modo que IPsec no tapa agujeros de IPv6. Es una funcionalidad
extra vs. e.g. todo el trabajo que yo he hecho sobre IPv6, que *si* se
trata de agujeros de IPv6.



[....]
>>>
>>> La gente no sabe ni el 0.0001% de las cosas que están hechas para su
>>> protección y seguridad.
>>
>> Exacto. Ese es justamente el punto: ningun banco va a ganar prestigio
>> por implementar DNSSEC. AL igual que no va a ganar prestigio de acuerdo
>> a las marcas utilizadas o tipos de proteccion electrica de las
>> instalaciones, ni a la marca del vidrio blindado y demas.
> 
> Cada uno sabe los riesgos que corre y como mitigarlos y que herramientas
> tiene. Los bancos, sobre todo en Estados Unidos, estan a un par de
> buenos juicios de implementar DNSSEC y seguramente, RPKI.

Las cuestiones legales tienen en general poco que ver con lo tecnico.

Tengamos en cuenta que ahi en USA es donde forzaron a las empresas a
poner un cartelito de "el cafe esta caliente" en los vasitos, porque
alguno se lo volco y se quemo...

(escuche del rumor de "ud no puede secar su gato en el microondas"
(wtf!?), pero la verdad que no lo chequie).



> ¿Porque les resuelven todos los problemas? No, sino por el concepto de
> 'due dilligence': si no hiciste todo lo que estaba a tu alcance, por mas
> que fuera una mitigación y no una solución completa, sos negligente y
> sos co-responsable en caso de que algo malo pase.

Pero eso es una motivacion legal o politica, no una motivacion tecnica.




>> Yo justamente desde hace varios posts pedi que alguien me describa un
>> escenario de ataque que DNSSEC prevenga, y que sea lo suficientemente
>> valedero como para justificar la inversion de dinero en desplegar IPv6.
>> -- Pero nadie hizo el aporte en cuestión, todavia.
> 
> Yo te puedo aportar que la inversión en dinero es marginal, y además no
> hemos tenido mayores incidencias ni outages que antes. Yo gasté menos de
> 5.000 dolares. Por eso no hacerlo, es negligente, por mas que proteja de
> pocas cosas (cosa en la que difiero, pero igual)

En una infinidad de casos, esa "negligencia por no implementar dns"
sería la panacea.




>> Personalmente, no tengo nada contra DNSSEC per-se.
> 

(aca me referia, en particular, a que "no sufri su proceso de
estandarizacion", etc.)



> Yo tengo mis críticas para con DNSSEC. También las tengo con BGP, RPKI,
> IPv4, IPv6 (porque carajo el /64 es una frontera dura? porque no puedo
> configurar el largo de prefijo en mi servidor de RA? :-) )

Por que es una frontera dura? -- SImple: copiaron el diseño de un
protocolo anerior, en donde la autoconfiguracion se basaba en poner una
direccion mac. Incialmente, las subnets eran un /96. Luego esto se llevo
a /64 para los EUI-64.

La realidad es que nunca deberias haber metido una mac address ahi.
RFC7217 no depende en si de ningun tamaño de subred en particular, por
ejemplo.




>> Volviendo al tema de DNSSEC, entiendo que, por ejemplo, politicamente
>> lacnic tengar que firmar sus zonas, etc. Del mismo modo que entiendo que
>> NICs de distintos paises "tengan" que hacer lo mismo. Al igual que creo
>> que ambos tipos de organizaciones deben poseer recursos capacitados en
>> el tema, experiencia, y demas (algo que tambien alguien podri argumentar
>> que se obtiene desplegandolo para los recursos que les competen).  -- Lo
>> que digo es que dichos organismos tienen motivaciones que son dificiles
>> de replicar en empresas u otro tipo de organizaciones. Y cuando uno
>> analiza las motivaciones tecnicas, personalmente creo que son cuestionables.
> 
> Como dijo Luis Carlos, cada uno gestiona sus riesgos. En el caso
> nuestro, políticamente no tenemos que hacer nada. Lamento que sea una
> desilución a los que tienen por ahi el tema de las teorías conspirativas.
> 
> Nosotros firmamos las zonas porque consideramos que es lo correcto, es
> parte de nuestros deberes de 'due dilligence' y porque, a diferencia de
> lo que se ha dicho equivocadamente en este thread, si se puede hacer de
> manera económica y sin mayor estress.

Yo no tengo teoria conspirativa (lease, no tengo ideas estilo "la mafia
X amenazo a Y para que despliegue Z") en casos locales.

Lo que argumento es que si uno se limita a argumentos tecnicos, el
despliegue no es facil de justificar.

Pero considerando l posibilidad de estar equivocado, por eso pedi que
alguien plantee escenarios en donde DNSSEC me pueda aportar una
difeencia concreta y substancial que haga evidente la motivacion de su
despliegue.

Soy de la idea que si tal escenario fuera tan obvio, la discusion seria
mucho mas breve.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







Más información sobre la lista de distribución Seguridad