Mudanza
A raiz del gran fallo en los blogs de ya.com que los ha dejado caidos durante un mes y sin avisar de nada he decidido mudarme, podéis encontrar la continuación de mi blog en la siguiente dirección:
http://www.meleagro.es.kz
http://www.meleagro.es.kz
Toy Flippyando
Vuelve uno de sus vacaciones y entra la web oficial de Slackware. Una gran sorpresa, apenas escriben nada que no sean las publicaciones de versiones.
Esto me gusta, me parece conveniente que noticas de este calado se salgan del changelog y salpiquen la web.
KDE 4.1 en la rama testing. Interesante. Muy interesante. Me parece muy acertado ya que así se le concede a la nueva versión del escritorio un caracter oficial, si bien aún no está lo suficientemente maduro y no tiene todas las funcionalidades desarrolladas.
La subrama testing dentro de la rama current me parece una gran opción.
Sin embargo una sensación rara al navegar la web se confirma tras la lectura del segundo parrafo, que cito textualmente:
Also, we recently commissioned Mark from Senile Felines Designs to create a unique new Slackware Logo (that's it there in the upper right), as we were getting a number of bug reports that the old logo could not be read easily while standing on one's head. ;-) We think he did a great job with it! If you like the new logo, we are selling shirts, stickers and other products with it at the Official Slackware CafePress Store, and if the design proves to be popular we'll likely have some of these products mass produced for the main Slackware Store. Meanwhile, you can help support the Slackware project, _and_ be the first on your block to show off the new Slackware "flippy" logo! :-)
El nuevo logo queda tal que así:
Estéticamente cada uno tiene su gusto. A mí personalmente me parece horrible e ilegible, ni boca arriba ni boca abajo. Me recuerda a esos dibujos en tres dimensiones en los que debes desenfocar la vista para poder verlos (las camisetas de Slackware Store con los diseños son aún peores).
Pero si nos salimos de la estética pienso que en lugar de perder el tiempo en estas C H O R R A D A S deberían invertirlo en algo util. Presencia en alguna conferencia, elaboración de newsleters tipo Gentoo para saber en qué está trabajando Slackware y hacia dónde va, dificultades que se encuentra, soporte oficial de pam, actualizar la lista de other sites dando el reconocimiento que las comunicades se merecen, live CD/DVD oficial u otra larga lista.
O al menos presentar el asunto en las listas oficiales para que haya debate.
Si no recuerdo mal hace algún tiempo Gnome dejó de ser oficial porque consumía mucho tiempo su compilación. Que conste que soy KDEero.
Cerrado por vacaciones
Hoy comienzo unas cortas pero intensas vacaciones.
Asique los que habitualmente navegáis por mi blog podéis tomaros un respiro, o mejor aún, utilizar la sindicación para estar informados de cuando escribo (que no es muy a menudo) y de paso elevar mi malerido ego, a no ser que seáis uno de estos 12 valientes:
Yo mientras tanto con las chanclas, bañador, toalla, sombrilla y esta camiseta:
Buen Verano !!
Asique los que habitualmente navegáis por mi blog podéis tomaros un respiro, o mejor aún, utilizar la sindicación para estar informados de cuando escribo (que no es muy a menudo) y de paso elevar mi malerido ego, a no ser que seáis uno de estos 12 valientes:
Yo mientras tanto con las chanclas, bañador, toalla, sombrilla y esta camiseta:
Buen Verano !!
Dan Kaminsky DNS bug
No voy a dedicarme a aprovechar este ya conocido bug para hacer un post que lo explique en detalle y así salvar mi ritmo de publicación de al menos un par de post al mes.
Más interesante que contar lo ya contado y recontado es escribir de manera ordenada los recursos que conozco a día de hoy para detectar este problema, auditarlo e incluso explotarlo, sin pasar por algo recomendaciones y soluciones al mismo. Vamos allá.
Si quieres saber si un servidor es vulnerable:
1. Herramienta web del propio Dan Kaminsky.
2. Script en perl para lanzar contra un servidor DNS.
Para detectar si se está sufriendo un ataque de este tipo hay un par de reglas para Snort muy valiosas que ha publicado recientemente Emerging Threats:
1. DNS Poisoning Signature
2. New DNS Vulnerability
Para explotar esta vulnerabilidad tenemos también dos recursos muy buenos de la mano de los chicos de Computer Academic Underground en forma de exploits para el Metasploit:
1. Kaminsky DNS Cache Poisoning Flaw Exploit.
2. Kaminsky DNS Cache Poisoning Flaw Exploit for Domains.
Para los administradores solo hay una recomendación:
1. ¡¡ Actualiza tus servidores DNS !! Hay parches desde hace días para cualquier servidor DNS.
Para los usuarios hay varias posibles opciones:
1. Comprueba mediante las herramientas comentadas anteriormente que el servidor DNS que utilizas no es vulnerable.
2. En caso de que lo sea te recomiendo migrar a uno que no lo sea, un buen paso sería la migración a OpenDNS. Si no sabes que es OpenDNS te recomiendo darte un paseo por el blog SBD.
ACTUALIZADO 24/07/2008:
Me entero de una nueva herramienta para comprobar si tu servidor DNS es vulnerable. Ha sido desarrollada por Pandalabs y es un ejecutable para Windows.
Más interesante que contar lo ya contado y recontado es escribir de manera ordenada los recursos que conozco a día de hoy para detectar este problema, auditarlo e incluso explotarlo, sin pasar por algo recomendaciones y soluciones al mismo. Vamos allá.
Si quieres saber si un servidor es vulnerable:
1. Herramienta web del propio Dan Kaminsky.
2. Script en perl para lanzar contra un servidor DNS.
Para detectar si se está sufriendo un ataque de este tipo hay un par de reglas para Snort muy valiosas que ha publicado recientemente Emerging Threats:
1. DNS Poisoning Signature
2. New DNS Vulnerability
Para explotar esta vulnerabilidad tenemos también dos recursos muy buenos de la mano de los chicos de Computer Academic Underground en forma de exploits para el Metasploit:
1. Kaminsky DNS Cache Poisoning Flaw Exploit.
2. Kaminsky DNS Cache Poisoning Flaw Exploit for Domains.
Para los administradores solo hay una recomendación:
1. ¡¡ Actualiza tus servidores DNS !! Hay parches desde hace días para cualquier servidor DNS.
Para los usuarios hay varias posibles opciones:
1. Comprueba mediante las herramientas comentadas anteriormente que el servidor DNS que utilizas no es vulnerable.
2. En caso de que lo sea te recomiendo migrar a uno que no lo sea, un buen paso sería la migración a OpenDNS. Si no sabes que es OpenDNS te recomiendo darte un paseo por el blog SBD.
ACTUALIZADO 24/07/2008:
Me entero de una nueva herramienta para comprobar si tu servidor DNS es vulnerable. Ha sido desarrollada por Pandalabs y es un ejecutable para Windows.
OSSEC y CIS
Hace poco comentaba la compra de OSSEC por parte de Third Brigade. Parece que a raiz de esto la aplicación ha recibido un nuevo impulso y en apenas dos semanas han aparecido nuevas e interesantes funcionalidades:
1. El 4 de Julio se hacia publica una nueva versión de OSSEC, la v1.5.1. Leyendo el Changelog se puede apreciar que las correcciones han sido leves. OSSEC se ha caracterizado por no actualizarse muy a menudo pero parece ser que desde la compra esto ha cambiado (había prisa por publicar una nueva release bajo el apadrinamiento Third Brigade).
2. El mismo 4 de Julio en el Blog de Daniel B. Cid (autor de OSSEC) aparecía un interesante artículo en el que se explica como compilar y utilizar la herramienta ossec-logtest, incluida en el IDS y que nos permite la comprobación de las reglas utilizadas por el sensor y, lo que es más importante, nos sirve de depurador para la creación de reglas propias.
3. Cuatro días más tarde se publica un nuevo artículo más interesante aún si cabe que el anterior: OSSEC empieza a desarrollarse para comprobar el cumplimiento con los CIS benchmark tests.
Para quién no sepá qué son estos test una gran referencia es el Blog SDB (Security By Default) que hace poco publicó un interesante artículo al respecto.
Actualmente solo se comprueba la comformidad para sistemas Debian y Ubuntu/Kubuntu/Xubuntu pero la idea es ampliar estos test e incluso cubrir las políticas FDCC, lo cual sería muy pero que muy interesante. Hay que recordar que actualmente a excepción de las herramientas gratuitas de CIS no hay ninguna herramienta OpenSource que compruebe estas políticas ( las reglas DirectFeed de Nessus son de pago ).
1. El 4 de Julio se hacia publica una nueva versión de OSSEC, la v1.5.1. Leyendo el Changelog se puede apreciar que las correcciones han sido leves. OSSEC se ha caracterizado por no actualizarse muy a menudo pero parece ser que desde la compra esto ha cambiado (había prisa por publicar una nueva release bajo el apadrinamiento Third Brigade).
2. El mismo 4 de Julio en el Blog de Daniel B. Cid (autor de OSSEC) aparecía un interesante artículo en el que se explica como compilar y utilizar la herramienta ossec-logtest, incluida en el IDS y que nos permite la comprobación de las reglas utilizadas por el sensor y, lo que es más importante, nos sirve de depurador para la creación de reglas propias.
3. Cuatro días más tarde se publica un nuevo artículo más interesante aún si cabe que el anterior: OSSEC empieza a desarrollarse para comprobar el cumplimiento con los CIS benchmark tests.
Para quién no sepá qué son estos test una gran referencia es el Blog SDB (Security By Default) que hace poco publicó un interesante artículo al respecto.
Actualmente solo se comprueba la comformidad para sistemas Debian y Ubuntu/Kubuntu/Xubuntu pero la idea es ampliar estos test e incluso cubrir las políticas FDCC, lo cual sería muy pero que muy interesante. Hay que recordar que actualmente a excepción de las herramientas gratuitas de CIS no hay ninguna herramienta OpenSource que compruebe estas políticas ( las reglas DirectFeed de Nessus son de pago ).