[opensuse-es] [OT] Actualización de seguridad para Bind
Hola, Cuando un problema de este tipo sale en las noticias, es que debe ser gordo :-P Ayer escuché en varios medios de comunicación un fallo en el protocolo dns y por lo poco que entendí (decían muchas vaguedades, pero nada claro) parecía un error generalizado. Buscando más datos sobre el tema, encuentro los informes: Multiple Vendors DNS Spoofing Vulnerability http://isc.dshield.org/diary.html?storyid=4687 CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 Pero no he visto de momento ninguna actualización para suse :-? P.S. Parece que los fallos de "flojera entrópica" no sólo afectan a Debian... ¿a quién "sacrificamos" ahora? >:-) (es broma) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-10 a las 11:20 +0200, Camaleón escribió:
Hola,
Cuando un problema de este tipo sale en las noticias, es que debe ser gordo :-P
Ayer escuché en varios medios de comunicación un fallo en el protocolo dns y por lo poco que entendí (decían muchas vaguedades, pero nada claro) parecía un error generalizado. Buscando más datos sobre el tema, encuentro los informes:
Multiple Vendors DNS Spoofing Vulnerability http://isc.dshield.org/diary.html?storyid=4687
No lo pillo.
CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
Está en estado "candidate" desde marzo (Assigned (20080321)). No lo han tomado en serio - si es que leo correctamente lo que pone.
Pero no he visto de momento ninguna actualización para suse :-?
P.S. Parece que los fallos de "flojera entrópica" no sólo afectan a Debian... ¿a quién "sacrificamos" ahora? >:-) (es broma)
Lo que entiendo quieren decir es que alguien puede pasar respuestas haciendose pasar por el DNS al que has preguntado, para lo cual tienen primero que saber a qué DNS le has preguntado, o sea, debe estar en la linea, o tirar a boleo. Pero lo mismo que pueden atacar el DNS podrían atacar cualquier otro protocolo que use UDP. El DNS es un poco más fácil, porque cada respuesta ocupa un sólo paquete. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIddz5tTMYHG2NR9URAnZsAJ4mFDPHIsuCPoaNlR+RGTFSHvQwbgCfcfhK OebLvbQLTbPhMTs07yZKecc= =jh9/ -----END PGP SIGNATURE-----
2008/7/10 Camaleón
Hola,
Cuando un problema de este tipo sale en las noticias, es que debe ser gordo :-P
Ayer escuché en varios medios de comunicación un fallo en el protocolo dns y por lo poco que entendí (decían muchas vaguedades, pero nada claro) parecía un error generalizado. Buscando más datos sobre el tema, encuentro los informes:
Multiple Vendors DNS Spoofing Vulnerability http://isc.dshield.org/diary.html?storyid=4687
CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
Pero no he visto de momento ninguna actualización para suse :-?
P.S. Parece que los fallos de "flojera entrópica" no sólo afectan a Debian... ¿a quién "sacrificamos" ahora? >:-) (es broma)
Saludos,
-- Camaleón
El usuario no tiene que hacer nada, el problema lo tienen los servidores de nombres, los grandes directorios de internet.... Además, por lo visto el problema no afecta a todos los gordos, sino a bastantes de los EEUU, aquellos que implementaban una funcionalidad que permitía redirigir a algunas páginas de ISPs en el caso de dirección errónea o inexistente. Lo cachondo del tema, es que aún sabiendo que existe el bug, y mientras se saca el parche y se soluciona ... el servicio afectado sigue funcionando (los cabrones estos no quieren dejar de ganar un céntimo mientras puedan) ... estaría guapísimo que x ejemplo mañana, no funcionase ningun DNS de los gordos, y las webs fueran TODAS inaccesibles ... xD Bueno, esto es lo que yo he podído leer y entender a lo largo del dia de ayer. -- SkavenXXI @ www.Alvaroncho.es Habla del mundo libre! [ http://www.Linuzeros.org ] Un gran foro con gran gente! [ http://www.ElBarDeAlktodostemen.net ] Un sistema operativo diferente! [ http://www.OpenSuSE.org ]
El 10/07/08, SkavenXXI escribió:
El usuario no tiene que hacer nada, el problema lo tienen los servidores de nombres, los grandes directorios de internet....
El Hispasec lo explican mejor: 09/07/2008 Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad en la implementación del protocolo que "sustenta" Internet http://www.hispasec.com/unaaldia/3546 Lo que me "escama" es lo que dicen en ese artículo: *** Hasta ahora, Cisco, Microsoft, BIND y otras muchas distribuciones Linux han publicado sus respectivas actualizaciones, en un esfuerzo sincronizado y secretismo coordinado no vistos hasta la fecha. Dan Kaminsky (que al parecer se topó con el problema de forma casual) pretende dar los detalles en la conferencia Black Hat de agosto. En cualquier caso, y aunque el fallo sea importante, también es cierto que hace años, cuando los ataques de este tipo eran más sencillos y factibles que hoy en día, nunca se ha observado que hayan sido llevados a la práctica de forma masiva o generalizada por atacantes. Se recomienda a todos los administradores que parcheen sus sistemas cuanto antes. *** Estoy viendo parches de bind para slackware, fedora, solaris, debian... por eso preguntaba :-? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 10/07/08, Camaleón escribió:
Estoy viendo parches de bind para slackware, fedora, solaris, debian... por eso preguntaba :-?
Ya lo tenemos :-) SUSE Security Announcement: bind (SUSE-SA:2008:033) http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-11 a las 12:34 +0200, Camaleón escribió:
Ya lo tenemos :-)
Llegó ayer noche.
SUSE Security Announcement: bind (SUSE-SA:2008:033) http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html
Me "encanta" esta frase: If you use the UDP source-port number of the DNS server in your firewall configuration, for example to let DNS queries through your packetfilter, then you have to take steps to adapt your filter rules to the new behavior of the DNS server. Vale, y... ¿eso como se hace? Tiene narices la cosa. El puerto cambia aleatoriamente y el cortafuegos lo tiene que saber. ¿Mande? ¿Como hago eso? Con el susefirewall. No es mi caso, que yo sepa. Ahora, están todos los routers de adsl por ahí con dns, como el mio. ¿Publicará Telefónica el parche, para el mio y todos los routers que ha vendido? ¿Prontamente? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIdzuMtTMYHG2NR9URAsIkAJ46P26oWAwViUaNx4IEWUwVk86z0QCglm+2 ZN5mxk7XvogzMVI6sjiitlk= =WtP8 -----END PGP SIGNATURE-----
El 11/07/08, Carlos E. R. escribió:
Llegó ayer noche.
Grrr. Lo he visto esta mañana... Sigo con los problemas en Gmail :-}
Me "encanta" esta frase:
If you use the UDP source-port number of the DNS server in your firewall configuration, for example to let DNS queries through your packetfilter, then you have to take steps to adapt your filter rules to the new behavior of the DNS server.
Vale, y... ¿eso como se hace? Tiene narices la cosa. El puerto cambia aleatoriamente y el cortafuegos lo tiene que saber. ¿Mande? ¿Como hago eso? Con el susefirewall.
FW_SERVICES_EXT_UDP="random(n)" :-P Tendrán que "relajar" las reglas del cortafuegos para permitir un rango mayor de puertos o darle vía libre a bind :-?
No es mi caso, que yo sepa.
Ahora, están todos los routers de adsl por ahí con dns, como el mio. ¿Publicará Telefónica el parche, para el mio y todos los routers que ha vendido? ¿Prontamente?
¿Telefónica... publicar... parches? :-) Si no lo usas, mejor desactivarlo. Mira, esto de un router SpeedStream del año de la parrala, configurado en ese mismo año O:-): *** DNS Server on router Disabled DHCP Server on router Disabled NAPT Mode Enabled RIP Mode Disabled IP Filter Mode Enabled *** Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-11 a las 15:23 +0200, Camaleón escribió:
FW_SERVICES_EXT_UDP="random(n)"
:-P
:-)
Tendrán que "relajar" las reglas del cortafuegos para permitir un rango mayor de puertos o darle vía libre a bind :-?
La verdad, que no no me afecta, no me he parado a pensarlo.
No es mi caso, que yo sepa.
Ahora, están todos los routers de adsl por ahí con dns, como el mio. ¿Publicará Telefónica el parche, para el mio y todos los routers que ha vendido? ¿Prontamente?
¿Telefónica... publicar... parches? :-) Si no lo usas, mejor desactivarlo.
Mira, esto de un router SpeedStream del año de la parrala, configurado en ese mismo año O:-):
*** DNS Server on router Disabled DHCP Server on router Disabled NAPT Mode Enabled RIP Mode Disabled IP Filter Mode Enabled ***
Normalmente no uso el dns del router. Pero cuando estoy con una live o instalando algo, que no tengo la máquina principal funcionando, en vez de poner los dns del proveedor pongo el del router, que es más fácil de recordar. Eso lo ha puesto tesa porque les ahorra tráfico a sus servidores dns. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFId7I+tTMYHG2NR9URAgSlAJ9uVdm7ZL9ZgYkyOeTgrI/wx9jmowCePGrK EVt64s5l4ywnwYdB5JQjbjY= =QpOO -----END PGP SIGNATURE-----
2008/7/11 Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-07-11 a las 12:34 +0200, Camaleón escribió:
Ya lo tenemos :-)
Llegó ayer noche.
SUSE Security Announcement: bind (SUSE-SA:2008:033)
http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html
Me "encanta" esta frase:
If you use the UDP source-port number of the DNS server in your firewall configuration, for example to let DNS queries through your packetfilter, then you have to take steps to adapt your filter rules to the new behavior of the DNS server.
Vale, y... ¿eso como se hace? Tiene narices la cosa. El puerto cambia aleatoriamente y el cortafuegos lo tiene que saber. ¿Mande? ¿Como hago eso? Con el susefirewall.
mmmm. aver.. esto se aplica, caso tengas confiurado en el cortafuegos (muy restrictivo) el puerto de origen y destino para las consultas.. por ejemplo: iptables -A FORWARD -p tcp --dport 53 --sport 53 -s 192.168.0.0/24 -j ACCEPT se podria cambiar a algo como: iptables -A FORWARD -p tcp --dport 53 -s 192.168.0.0/24 -j ACCEPT lo mismo pasa con varios protocolos.. donde generalmente se configura los cortafuegos, pensando solamente en los puertos de destino y no se configura los puertos de origen !!! pero ojo, por defecto (al menos en bind) los puertos de consultas, vienen configurados para ser aleatorio.. a no ser que tengas configurado el parametro "query-source 53" en tu configuracion. [...]
Ahora, están todos los routers de adsl por ahí con dns, como el mio. ¿Publicará Telefónica el parche, para el mio y todos los routers que ha vendido? ¿Prontamente?
mmm. sinceramente, creo que no !!! hasta que tengan problemas que afecten a directamente a ellos. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-11 a las 13:50 -0400, Victor Hugo dos Santos escribió:
esto se aplica, caso tengas confiurado en el cortafuegos (muy restrictivo) el puerto de origen y destino para las consultas.. por ejemplo: iptables -A FORWARD -p tcp --dport 53 --sport 53 -s 192.168.0.0/24 -j ACCEPT
se podria cambiar a algo como: iptables -A FORWARD -p tcp --dport 53 -s 192.168.0.0/24 -j ACCEPT
lo mismo pasa con varios protocolos.. donde generalmente se configura los cortafuegos, pensando solamente en los puertos de destino y no se configura los puertos de origen !!!
pero ojo, por defecto (al menos en bind) los puertos de consultas, vienen configurados para ser aleatorio.. a no ser que tengas configurado el parametro "query-source 53" en tu configuracion.
Bueno... aquí no me afecta. Era curiosidad.
[...]
Ahora, están todos los routers de adsl por ahí con dns, como el mio. ¿Publicará Telefónica el parche, para el mio y todos los routers que ha vendido? ¿Prontamente?
mmm. sinceramente, creo que no !!! hasta que tengan problemas que afecten a directamente a ellos.
Eso pienso yo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFId7GitTMYHG2NR9URAj7HAJ4sX7ZQYY1Rf44pYoLSq4k5kCeHtQCgjSd1 WVwjUBOezH0kDgjNFgdPtrM= =SKpq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 10/07/08, SkavenXXI escribió:
El usuario no tiene que hacer nada, el problema lo tienen los servidores de nombres, los grandes directorios de internet....
Por lo que he leido el problema lo tiene cualquiera, salvo que no merece la pena atacar un servidor particular.
El Hispasec lo explican mejor:
09/07/2008 Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad en la implementación del protocolo que "sustenta" Internet
Bueno, algo es algo. Pero no dicen nada de en qué consiste el ataque. ...
Se recomienda a todos los administradores que parcheen sus sistemas cuanto antes. ***
Estoy viendo parches de bind para slackware, fedora, solaris, debian... por eso preguntaba :-?
Hubo uno de bind hace unos dias, pero no recuerdo que mencionasen nada de esto. [...] Finalmente pusieron el parche en suse, pero tampoco dicen cual es el problema, ni siquiera ellos lo saben (marcado con '*' abajo en el extracto del anuncio ofical): ] 1) Problem Description and Brief Discussion ] ] The bind daemon is responsible for resolving hostnames in IP addresses ] and vice versa. ] The new version of bind uses a random transaction-ID (TRXID) and a ] random UDP source-port for DNS queries to address DNS cache poisoning ] attacks possible because of the "birthday paradox" and an attack ] * discovered by Dan Kaminsky. Unfortunately we do not have details about ] * Kaminsky's attack and have to trust the statement that a random UDP ] * source-port is sufficient to stop it. ] DNS servers that do not support recursive queries or do not use a ] cache (authoritative only servers) are not vulnerable too. ] ] Update packages of bind9 for SLES8 will be available soon. ] ] The glibc stub resolver is known to be vulnerable too and we will ] publish updates as soon as possible. ] ] Note, a local attacker can always sniff DNS queries and generate ] spoofed responses easily. ] ] If you use the UDP source-port number of the DNS server in your ] firewall configuration, for example to let DNS queries through your ] packetfilter, then you have to take steps to adapt your filter rules ] to the new behavior of the DNS server. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIe0eNtTMYHG2NR9URAn4NAJ91j55WxsTwppTihXu9wI4GQmlhHQCffTqX HSJq63HVfmyYzQrqLgjjOMw= =F/k/ -----END PGP SIGNATURE-----
El 14/07/08, Carlos E. R. escribió:
El 2008-07-10 a las 14:04 +0200, Camaleón escribió:
El Hispasec lo explican mejor:
09/07/2008 Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad en la implementación del protocolo que "sustenta" Internet
Bueno, algo es algo. Pero no dicen nada de en qué consiste el ataque.
Hum... Carlos, ¿estás hablando en serio? :-?
Hubo uno de bind hace unos dias, pero no recuerdo que mencionasen nada de esto.
O Gmail me está jugando una mala pasada y estoy teniendo un "dejà vu" ("Tanke, dame una salida...") o me estás dejando a cuadros 8-). Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Bueno, algo es algo. Pero no dicen nada de en qué consiste el ataque.
Hum... Carlos, ¿estás hablando en serio? :-?
La explicación completa y detallada del agujero y posible ataque no está. Leí que lo explicarían en una conferencia del tipo que lo descubrió, prevista para agosto.
Hubo uno de bind hace unos dias, pero no recuerdo que mencionasen nada de esto.
O Gmail me está jugando una mala pasada y estoy teniendo un "dejà vu" ("Tanke, dame una salida...") o me estás dejando a cuadros 8-).
¿Mande? ¿Y eso? Lo único que se me ocurre es que este correo se me quedó sin salir varios dias, y por eso lo ves hoy. ¿Te refieres a eso? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIe5eGtTMYHG2NR9URAg+cAKCL1CQx608tip+0VePDh6uFZfVEZQCcCBC9 w0Y0Wj61rXK0vUOgNjZfwxg= =qTKo -----END PGP SIGNATURE-----
El 14/07/08, Carlos E. R. escribió:
La explicación completa y detallada del agujero y posible ataque no está. Leí que lo explicarían en una conferencia del tipo que lo descubrió, prevista para agosto.
En agosto dirán cómo explotarlo, sí, en la conferencia "Black Hat," creo. Pero el fallo dicen que es antiguo e inherente al protocolo dns, que se solucionaría utilizando cifrado para distinguir entre una petición auténtica o falsa (dnssec).
¿Mande? ¿Y eso? Lo único que se me ocurre es que este correo se me quedó sin salir varios dias, y por eso lo ves hoy. ¿Te refieres a eso?
Eso será :-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 14/07/08, Carlos E. R. escribió:
La explicación completa y detallada del agujero y posible ataque no está. Leí que lo explicarían en una conferencia del tipo que lo descubrió, prevista para agosto.
En agosto dirán cómo explotarlo, sí, en la conferencia "Black Hat," creo.
Es que fijate la frase: ] Unfortunately we do not have details about ] Kaminsky's attack and have to trust the statement that a random UDP ] source-port is sufficient to stop it. No conocen los detalles del ataque ni de la solución.
Pero el fallo dicen que es antiguo e inherente al protocolo dns, que se solucionaría utilizando cifrado para distinguir entre una petición auténtica o falsa (dnssec).
Sí, pero exige activar cifrado en todas las consultas de los grandes servidores de dns (los de los proveedores con caché, no los raiz) hacia todos los posibles servidores a los que preguntan, incluyendo todas las empresas y particulares con dominio y servidor dns de tal dominio. ¿Es viable eso? Tendrías que automatizar un proceso para intercambio de claves fiablemente, y eso creo que sólo es posible con una entidad de manejo de llaves como las que se usan para servidores de correo o web (ssl?), y esas llaves tienen un coste elevado. Dicho sea sin conocer como funciona dnssec, o sea, que puedo estar metiendo la pata hasta el fondo :-)
¿Mande? ¿Y eso? Lo único que se me ocurre es que este correo se me quedó sin salir varios dias, y por eso lo ves hoy. ¿Te refieres a eso?
Eso será :-)
Ah, vale :-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIe6JbtTMYHG2NR9URAlBXAJ4oI7nCoNuawWNyZovvI7lld24ffQCfXBZO vUlFq3K4zmDxpxw+cEuneoY= =QJ2a -----END PGP SIGNATURE-----
El 14/07/08, Carlos E. R. escribió:
Es que fijate la frase:
] Unfortunately we do not have details about ] Kaminsky's attack and have to trust the statement that a random UDP ] source-port is sufficient to stop it.
No conocen los detalles del ataque ni de la solución.
Pero eso lo dicen en la nota del parche de suse ¿no? En el primero de los enlaces que puse, confirman: *** UPDATE: The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable. "Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation" *** Si saben qué es lo que lo hace vulnerable y dicen que aplicando mayor entropía se soluciona... yo me fío O:-)
Sí, pero exige activar cifrado en todas las consultas de los grandes servidores de dns (los de los proveedores con caché, no los raiz) hacia todos los posibles servidores a los que preguntan, incluyendo todas las empresas y particulares con dominio y servidor dns de tal dominio. ¿Es viable eso? Tendrías que automatizar un proceso para intercambio de claves fiablemente, y eso creo que sólo es posible con una entidad de manejo de llaves como las que se usan para servidores de correo o web (ssl?), y esas llaves tienen un coste elevado.
Dicho sea sin conocer como funciona dnssec, o sea, que puedo estar metiendo la pata hasta el fondo :-)
"My 2 cents" de que es viable. Pero ahora no existe O:-): *** Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works). *** Es más, en un futuro la mayoría del tráfico que circule por la web estará cifrado y todos estaremos identificados y si no, no nos permirtán el acceso... eso del anonimato tendrá los días contados y sólo unos cuantos locos vagarán por la red quebrantando las reglas
:-)
Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-14 a las 21:18 +0200, Camaleón escribió:
El 14/07/08, Carlos E. R. escribió:
Es que fijate la frase:
] Unfortunately we do not have details about ] Kaminsky's attack and have to trust the statement that a random UDP ] source-port is sufficient to stop it.
No conocen los detalles del ataque ni de la solución.
Pero eso lo dicen en la nota del parche de suse ¿no?
Lo que he puesto yo es la nota del parche de suse, y de la cual se deduce que ellos no lo tienen claro.
En el primero de los enlaces que puse, confirman:
*** UPDATE:
The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable.
"Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation" ***
Si saben qué es lo que lo hace vulnerable y dicen que aplicando mayor entropía se soluciona... yo me fío O:-)
Los de suse dicen que se tienen que fiar de lo que les dicen.
Sí, pero exige activar cifrado en todas las consultas de los grandes servidores de dns (los de los proveedores con caché, no los raiz) hacia todos los posibles servidores a los que preguntan, incluyendo todas las empresas y particulares con dominio y servidor dns de tal dominio. ¿Es viable eso? Tendrías que automatizar un proceso para intercambio de claves fiablemente, y eso creo que sólo es posible con una entidad de manejo de llaves como las que se usan para servidores de correo o web (ssl?), y esas llaves tienen un coste elevado.
Dicho sea sin conocer como funciona dnssec, o sea, que puedo estar metiendo la pata hasta el fondo :-)
"My 2 cents" de que es viable. Pero ahora no existe O:-):
*** Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works). ***
O sea, que he acertado bastante.
Es más, en un futuro la mayoría del tráfico que circule por la web estará cifrado y todos estaremos identificados y si no, no nos permirtán el acceso... eso del anonimato tendrá los días contados y sólo unos cuantos locos vagarán por la red quebrantando las reglas
:-)
En cuanto entre IPv6. Te asignan una IP igual al numero de DNI o pasaportem, y listo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIe6mrtTMYHG2NR9URAuj1AJ49HO2CeawYc6OFZkaNqiYhuXz71gCbBIGr EQNCWHFJ8nhL+ScvdGhqYes= =jD3h -----END PGP SIGNATURE-----
El 14/07/08, Carlos E. R. escribió:
Lo que he puesto yo es la nota del parche de suse, y de la cual se deduce que ellos no lo tienen claro.
Cómo explotarlo, no. Pero sí saben cómo y por qué se origina y cómo evitarlo, de lo contrario no habría parche para bind :-P
Los de suse dicen que se tienen que fiar de lo que les dicen.
Están en su papel. Aunque lo supieran, tampoco creo que lo dirían. Además del tal Kaminsky ya habrá más gente que sepa cómo utilizarlo. De todas formas, del concepto a la explotación real, va un trecho. Veremos que dicen en la Black Hat.
O sea, que he acertado bastante.
Sí, pero oye, que tampoco es un imposible, y hay términos medios :-): ISC's DLV Registry https://secure.isc.org/index.pl?/ops/dlv/ Habrá empresas que ya lo estén utilizando en sus zonas. Sólo falta que se generalice y que se implante la infraestructura necesaria :-P. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 14/07/08, Carlos E. R. escribió:
Lo que he puesto yo es la nota del parche de suse, y de la cual se deduce que ellos no lo tienen claro.
Cómo explotarlo, no.
Pero sí saben cómo y por qué se origina y cómo evitarlo, de lo contrario no habría parche para bind :-P
Los de suse dicen que se tienen que fiar de lo que les dicen.
Están en su papel. Aunque lo supieran, tampoco creo que lo dirían.
Que no. Los de bind lo saben y han hecho el parche, pero el asunto no lo han explicado; los de suse dicen que se fían de que está resuelto, pero no conocen cual es el problema, no tienen detalles; y por tanto no han podido analizar si el parche resuelve realmente el problema. Fíjate bien otra vez en lo que dicen, leelo una docena de veces, es muy sutil: ] Unfortunately we do not have details about ] Kaminsky's attack and have to trust the statement that a random UDP ] source-port is sufficient to stop it. «Desfortunadamente no tenemos detalles del ataque de Kaminsky y tenemos que fiarnos de que digan que un puerto de origen UDP aleatorio es suficiente para detenerlo.» No conocen el problema y no certifican que esté resuelto. Recuerda lo del "not mature", el inglés de ésta gente significa más cosas del "face value".
Además del tal Kaminsky ya habrá más gente que sepa cómo utilizarlo. De todas formas, del concepto a la explotación real, va un trecho. Veremos que dicen en la Black Hat.
Por lo menos después de eso tendremos los comentarios legibles.
O sea, que he acertado bastante.
Sí, pero oye, que tampoco es un imposible, y hay términos medios :-):
ISC's DLV Registry https://secure.isc.org/index.pl?/ops/dlv/
Habrá empresas que ya lo estén utilizando en sus zonas. Sólo falta que se generalice y que se implante la infraestructura necesaria :-P.
Si, ya, ad calendas graecas. Aunque peor lo tiene el correo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIe+PjtTMYHG2NR9URArLGAJ9sIHMlLDvxumkZAqydDYnTUr3WwgCgmHVQ 0lDh0IettIpleGuhtAB67xA= =YPok -----END PGP SIGNATURE-----
El 15/07/08, Carlos E. R. escribió:
Que no. Los de bind lo saben y han hecho el parche, pero el asunto no lo han explicado; los de suse dicen que se fían de que está resuelto, pero no conocen cual es el problema, no tienen detalles; y por tanto no han podido analizar si el parche resuelve realmente el problema.
Disponen de la misma información que la mayoría de las empresas: - No han explicado los detalles de cómo explotarlo "fácilmente" - El problema es conocido (no es nuevo) y consiste en que se puede predecir puerto e identificador y por tanto, suplantar la respuesta del servidor original y devolver datos falsos - El parche sólo añade dificultad en predecir esos datos
No conocen el problema y no certifican que esté resuelto. Recuerda lo del "not mature", el inglés de ésta gente significa más cosas del "face value".
No pueden certificar que lo esté hasta que no se sepa cómo aprovechar el fallo de manera sencilla (y ni aún así... seguro que cuando den los detalles aparece otro "agujero" tamaño cráter :-P). Lo que dicen es normal: "más vale prevenir, actualiza".
Por lo menos después de eso tendremos los comentarios legibles.
Y los intentos de "envenenamiento" a los dns por doquier :-). Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-07-15 a las 09:28 +0200, Camaleón escribió:
El 15/07/08, Carlos E. R. escribió:
Que no. Los de bind lo saben y han hecho el parche, pero el asunto no lo han explicado; los de suse dicen que se fían de que está resuelto, pero no conocen cual es el problema, no tienen detalles; y por tanto no han podido analizar si el parche resuelve realmente el problema.
Disponen de la misma información que la mayoría de las empresas:
- No han explicado los detalles de cómo explotarlo "fácilmente" - El problema es conocido (no es nuevo) y consiste en que se puede predecir puerto e identificador y por tanto, suplantar la respuesta del servidor original y devolver datos falsos - El parche sólo añade dificultad en predecir esos datos
Lo que sabe todo el mundo.
No conocen el problema y no certifican que esté resuelto. Recuerda lo del "not mature", el inglés de ésta gente significa más cosas del "face value".
No pueden certificar que lo esté hasta que no se sepa cómo aprovechar el fallo de manera sencilla (y ni aún así... seguro que cuando den los detalles aparece otro "agujero" tamaño cráter :-P). Lo que dicen es normal: "más vale prevenir, actualiza".
Obviamente, se actualiza.
Por lo menos después de eso tendremos los comentarios legibles.
Y los intentos de "envenenamiento" a los dns por doquier :-).
Esos llegarán antes. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIfPQOtTMYHG2NR9URArQpAKCDqnMPkENhi8n4J/SkqBa19cP/IACfT7g8 DsMabm4YJmBuFmWRsZeBg9Y= =Ge7h -----END PGP SIGNATURE-----
participants (4)
-
Camaleón
-
Carlos E. R.
-
SkavenXXI
-
Victor Hugo dos Santos