0xCAFE x-press

El software libre es para todos (y todas, claro ;))

noreply@blogger.com (Knaverit) — Sun, 25 Apr 2010 02:12:00 +0000

Es un hecho: el ambiente universitario es un buen escenario para un festival como FLISOL. Hoy tuvimos la fiesta de instalación de GNU/Linux, además de las ponencias que ya se han vuelto una tradición aquí. Como lo dije, la sede nuevamente fue la Universidad Regiomontana y me dio mucho gusto haber estado esta mañana para compartir mi charla relativa a Software Libre. El título de mi charla fue: "El Software Libre es para todos (y todas, claro ;)). El ABC del Software Libre". Sí, ya sé que el título suena muy "básico", pero fue el título que me pareció más adecuado, además de que fue lo mejor que se me ocurrió en los 5 minutos que me dieron de plazo para elegirlo. La intención fue hablar acerca de algunos conceptos fundamentales sobre Software Libre y Código Abierto, que si bien no son lo mismo, están relacionados de alguna manera para representar la libertad que debiera tener un programador de modificar un programa para adecuarlo a sus necesidades y mejorarlo para bien de la comunidad. Creo que vale la pena darle un vistazo a la presentación y ¡al video! Ahora sí está publicado y pueden verlo en:

http://www.justin.tv/flisolmty/b/262704058

Pueden adelantarle al minuto 0:54, que es donde yo comienzo, y termino en el 1:57 ;)... una hora de sano entretenimiento :D, o ir directo a la siguiente liga:

http://es.justin.tv/knaverit/b/262779679

De lo que me gustaría rescatar de esta plática fue la participación de los asistentes; hice algunas preguntas "expertas" (así les llamé) sobre aspectos del software libre, y me sorprendió que había algunos que sí se supieron la mayoría (la que no se supieron fue la pregunta de la cerveza, si ven el video se darán cuenta; por cierto, ¿sabían que existen cervezas "open source"? Cualquiera puede tener la receta, fabricarla y venderla, y si mejora la receta la tiene que compartir... yo no tomo cerveza ni otras bebidas alcohólicas, pero es interesante hasta dónde puede llegar un modelo así. No es por hacer promoción, pero si tienen curiosidad, pueden googlear "free beer open source", y encontrarán una cerveza que no es gratis, pero sí es libre... qué raro). Otra nota curiosa es que la presentación se llama "Software libre para todos (y todas)", pero al iniciar no había ni una sola mujer; poco después llegó una muchacha, la única asistente a mi charla, y por ella el título mereció quedarse como está; no se me ocurrió, pero debieron regalarle una playera del evento a ella, por ser la única. :D (si eres esa muchacha y lees esto, ponte en contacto conmigo y te la consigo ;), en serio).

La nota de promoción del evento salió también publicada en un periódico local de Monterrey periódico local de Monterrey, en la sección dedicada a tecnología.

Y también tuve una entrevista con mis amigos de AppCAST:
http://appgtp.blogspot.com/
(Posiblemente la entrevista se escuche en el podcast a partir de este lunes 26 de abril, yo les aviso).

Y para los interesados en tener una copia libre de la presentación, se las comparto con mucho gusto, con la intención de que ayude a promover la cultura del software libre. Viene en dos formatos, para que descarguen el que más les convenga:

Presentación para PowerPoint
Presentación para OpenOffice

Esta presentación se distribuye bajo la licencia de Creative-Commons Atribución-Licenciamiento Recíproco 2.5 México, con la que eres libre de copiar, distribuir y comunicar públicamente la obra, así como hacer obras derivadas, siempre y cuando reconozcas la autoría de la obra en los términos especificados por el autor [o sea, por mi], y si alteras, transformas o creas una obra a partir de esta obra, sólo podrás distribuir la obra resultante bajo una licencia igual a ésta.
http://creativecommons.org/licenses/by-sa/2.5/mx/

Gracias a los que pudieron asistir; de verdad es muy importante la participación de todos para la difusión del software libre, especialmente de la comunidad universitaria que siempre está deseosa de aprender cosas nuevas.

¡Nos vemos en FLISOL 2011! (O antes, si es posible). Síganme en Twitter, yo soy @knaverit, y pueden buscarme en Google.

Ah, casi lo olvidaba: Si alguien tomó alguna fotografía donde salga su servidor (o sea yo, no su server de GNU/Linux), les agradeceré que me la manden a romeo dot sanchez at amsi dot org dot mx, para publicarla aquí. Sus comentarios también son bienvenidos, aquí en el blog o por e-mail. Gracias

:wq!

El tema sigue y seguirá siendo libre

noreply@blogger.com (Knaverit) — Mon, 12 Apr 2010 17:37:00 +0000

Ha transcurrido ya un año desde nuestro último Festival Latinoamericano de Instalación de SOftware Libre, mejor conocido como El FLISOL. El de Monterrey 2009 se puso bueno, y el de 2010 promete estar mejor, pues el Grupo de Usuarios de Linux de la Universidad Regiomontana (GULUR) vuelve a la carga con la organización del evento y, en honor a la verdad, debo decir que son unos expertos en estos menesteres.

En esta ocasión he tenido el honor de haber sido invitado nuevamente para compartir con la comunidad una ponencia (que en mi caso es como dejar a un farmacodependiente a cuidar una farmacia, por todo lo que yo disfruto dando una conferencia, seminario, curso, charla, o similares). El tema es tan libre, que todavía no lo decido...:D quiero decir que tengo dos o tres temas de los que podría hablar (todos muy interesantes, por cierto), pero estoy esperando la iluminación para elegir el adecuado para ese día, considerando que (por si fuera poco) la ponencia de apertura es la mía (¡a madrugar!). El año pasado hablé sobre NetBeans, pero como todavía estoy de luto por la compra de Sun Microsystems, no voy a abordar el tema porque no quiero que me vean llorar, y más sabiendo que James Gosling (el padre de Java) ya renunció a Oracle, el nuevo dueño de Sun. Si me preguntan, en este momento no sé qué pasará con los proyectos de Open Source que patrocinaba Sun Microsystems (como NetBeans, OpenSolaris, MySQL, el mismo Java y OpenOffice, entre otros), y Oracle no se ha pronunciado al respecto con alguna postura definida, pero mientras me repongo de la aflicción seguiré preparando mi ponencia, pues el tema sigue y seguirá siendo libre.

Les recomiendo a todos los que puedan ir que hagan el esfuerzo y vayan. Yo sé que es sábado y nos gusta levantarnos tarde (¿o seré el único?), pero es una vez al año, y escuchar las ponencias o asistir a talleres siempre es enriquecedor (¿mencioné que la entrada es libre?). Sólo tienen que visitar el sitio de FLISOL Monterrey 2010 en http://www.flisolmty.org y registrarse (es gratis); si alguien no alcanza a registrarse y quiere asistir, puede hacerlo, nos dará mucho gusto recibirlos. Si quieren comenzar a usar Linux y tienen una computadora que quieran "revivir", llévenla al InstallFest, y saldrá estrenando Linux Ubuntu.

Por cierto, para los fans de las redes sociales, pueden seguir a FLISOL Monterrey en Twitter y FaceBook.

Nos vemos en el FLISOL, no falten. Como siempre, si van, me saludan.

:wq!

Elegía de un Proceso Distribuido

noreply@blogger.com (Knaverit) — Fri, 19 Mar 2010 05:15:00 +0000

[Basado en una historia real de punto flotante.]

Advertencia: La historia descrita a continuación contiene texto computacional explícito. Se recomienda leerlo en compañía de un sysadmin experimentado.

(¡es broma! léanlo, por favor) :D

por: Romeo Sánchez

Él era un proceso como cualquier otro; bueno, no como cualquiera, sino uno de alta prioridad, privilegiado, siempre sirviendo a los demás. Ella era un proceso más sencillo que luego se convertiría en su cliente. Cuando la conoció, desde el primer handshake de TCP, fue amor a primera vista. Comenzaron a tratarse, aunque al principio el scheduler no los hacía coincidir (el de alta prioridad casi siempre estaba ocupado), así que decidieron citarse (válgame la redundancia) por rendezvous, es decir, en cada encuentro uno esperaba pacientemente hasta que el otro llegara. Su relación se dio, como todas las relaciones, con cambios de contexto entre el modo kernel y el modo usuario que rompían la monotonía. De vez en cuando uno sorprendía al otro con alguna llamada síncrona inesperada que le alegraba el día, o incluso algún mensaje asíncrono, aunque también tenían sus interrupciones de I/O como toda pareja de procesos.

Con el tiempo decidieron tener un subproceso. Era uno pequeño, ligero, nacido a partir de un fork() en un nuevo shell. Siempre fue tímido y con dificultad lo mostraba un ps -a, aunque en ocasiones se rebelaba y acaparaba al procesador, consiguiendo llamar la atención no sólo de su proceso padre, sino hasta del mismo root. Aún así tenía sus ratos buenos, y hacía todas sus tareas con múltiples hilos de ejecución, escuchando atentamente.

Sin embargo, a pesar de sus emotivos encuentros por rendezvous, comenzaron a tener problemas y a contender, discutir, por el uso de los recursos. Las interrupciones eran cada vez más frecuentes, y la competencia por ser el primero en tener acceso al recurso derivó en una race condition insoportable ya para ambos, al grado de llegar a cuestionar incluso a root, diciéndole: "¿por qué me permites ejecutarme? un `kill -9` sería lo mejor, ya no quiero vivir así". Esa era su elegía de día y de noche, pero sólo otros daemons como cron lo escuchaban en silencio sin poder hacer nada. Quizá si el programador, recordando el caso de la cena de filósofos o del barbero dormilón, hubiera establecido una exclusión mutua (un mutex, pues) en las secciones críticas, el problema se habría resuelto, pero al final, después de una larga lucha de contención por recursos, quedaron atrapados en un deadlock, un bloqueo mutuo, cada quien esperando que el otro cediera, pero sin ceder él mismo, arruinando la relación, la comunicación, la ejecución y la interacción.

El desenlace fue triste: un solo `kill -9` fulminante bastó para terminar con su sufrimiento. El nuevo problema es que el proceso hijo ahora es huérfano, y dada su rebeldía, ni siquiera init, el más sabio de todos los procesos, ha podido hacer algo por él. Es ahora un alma en pena, un zombie, condenado a pagar por los errores de sus padres y por los errores del programador llevando para siempre (o al menos hasta el próximo reboot) un estigma en cada ps -a: la vergüenza de ser <DEFUNCT>.

:wq!

Conferencia: ¿Seguro que está seguro?

noreply@blogger.com (Knaverit) — Wed, 02 Dec 2009 07:09:00 +0000

El pasado 21 de noviembre de 2009 (sí, ya sé, hace mucho que no escribo) se llevó a cabo el Primer Simposio de Seguridad de la Información AMSI '09, que organizó la Asociación Mexicana de Seguridad de la Información (AMSI), y que tuvo su sede en la Universidad Regiomontana, en Monterrey, N.L. Yo no pude estar desde el inicio del evento, pues me encontraba dando un curso de Java Programming, pero llegué justo a tiempo para el final... porque me tocó la ponencia final (para variar, igual que en Flisol'09, cuando ya se fueron la mitad de los asistentes a ver el futbol). A pesar de haber sido la última ponencia, hubo muy buena participación y yo me divertí mucho.

El enfoque de mi charla fue el de aclarar algunos mitos en torno a la seguridad de las aplicaciones web, tratando de darle un toque de ingenio y usando una metáfora que se me ocurrió, al comparar a Spiderman con un desarrollador Web (Web developer... "el que fabrica la telaraña", suena lógico, ¿no? :D), y explicando la importancia de implementar la seguridad desde la programación, antes de pensar en controles como firewalls y cosas así. Hubo buenos comentarios al final respecto al Simposio, así que creo que se logró el cometido y ya nos estamos preparando para los de este año, porque pretendemos hacer dos, uno nuevamente en la Universidad Regiomontana que nos ha abierto incondicionalmente sus puertas, y posiblmente otro en la Universidad Autónoma de Nuevo León ("La Uni"), pero nada está escrito aún, yo les aviso.

Es posible que ahora sí me faciliten el video que grabaron durante mi plática, y si es así, lo voy a publicar para que tengan oportunidad de verlo aquellos que no pudieron asistir, y tal vez se interesen en mejorar la seguridad de sus aplicaciones.

La nota chusca de mi sesión fue cuando me presentaron, porque mi reseña dice que tengo más de 20 años de experiencia en IT, y todo mundo se imagina a alguien mucho mayor (en realidad no soy tan viejo, ese día era la víspera de mi cumpleaños 34). Tuve que explicarles, mientras abría mi presentación para proyectarla, que la verdad es que comencé desde muy chavito a interesarme en las cuestiones de la computación (en ese tiempo no era como ahora, que todos los niños saben de todo, como los míos que se la pasan buscando de todo en Google, o jugando en un mundito virtual de pingüinos), y siempre he leído mucho, siempre estoy tratando de aprender algo nuevo y leyendo cuanto libro llegue a mis manos (o al dispositivo de almacenamiento correspondiente). Estoy convencido de que es la única manera de mantenerse vigente en esta profesión que cada día está más inmersa en la vida cotidiana de la gente, aún de la que no es alfabeta en bits y bytes.

En conclusión, espero que con eventos de este tipo más profesionales adquieran consciencia de la importancia de la seguridad de la información, en un mundo cada vez dependiente de la informática, pero también cada vez más confiado.

Los dejo con la frase con la que abrí mi charla: "Creer que se tiene seguridad sin realmente tenerla, es peor que saberse inseguro.” (Romeo Sánchez, 2009). No sé si alguien más ya había dicho algo así, pero al menos con estas palabras exactas, esta frase es mía ;).

Se me olvidaba... si quieren ver la presentación en línea, pueden hacerlo en esta dirección:

http://docs.google.com/present/view?id=ddb3stqf_45fsrwdrp9&interval=10&loop=true

Hasta la próxima.

:wq!

0x22 años, el día 22 del mes 22/2

noreply@blogger.com (Knaverit) — Sun, 22 Nov 2009 04:10:00 +0000

0x22 años, el día 22 del mes 22/2.

No podía faltar. Nuevamente surge una curiosa relación entre los números del día de mi cumpleaños que me obligan (es un decir) a escribir una reflexión sobre los guarismos. En esta ocasión, la cifra es dos.

Dos (2) es es el único número primo que es par, una rareza, y cualquier número se considera par si puede dividirse por 2; además, si sumas 2+2, multiplicas (2)(2), elevas 2 a la potencia 2 (2²), o calculas el factorial de 2 (2!), el resultado es el mismo. Mejor aún es que el 2 es la base de las computadoras, pues en computación todo lo expresamos en potencias de 2.

0x22 es un número hexadecimal que representa el 34 en decimal. Por si no lo han notado todavía, estoy cumpliendo 34 vueltas al sol, el día 22 del mes 22/2, o sea, el mes 11 (noviembre, 22 entre 2=11). Este sábado di una conferencia, y comentaba precisamente que tengo 22 años de experiencia en tecnologías de información; sí, tenía sólo 12 años cuando comencé a programar, y el aprendizaje también es experiencia. Otra referencia más al 2 es que mi hermana Julieta (la número 2 en orden de aparición) también cumple años este mismo día. Somos 2 los que festejamos simultáneamente. Feliz cumpleaños también para ti.

Tampoco hoy tengo un gran comentario, y para muchos es trivial lo que dije; pero no importa, es mi cumpleaños y estoy doblemente feliz de vivir.

:wq!

El Cazador de Virus: La Obscuridad de la Venganza

noreply@blogger.com (Knaverit) — Mon, 04 May 2009 03:10:00 +0000

4564 6469 6520 6C69 7665 732E Eddie lives.

2E2E 736F 6D65 7768 6572 6520 ..somewhere.

696E 2074 696D 6521 0000 0000 in time!....

Cuando leí esto en mi editor hexadecimal, supe que lo había encontrado. Varias horas después de buscar a ese virus por todo el disco duro, por fin lo encontré. Ya antes había tratado con otros virus: Stoned, Ping-Pong, pero nada como Dark Avenger, hasta entonces. Y es que buscar a un virus polimórfico tiene su complejidad, y es tanto un arte como una carrera contra el tiempo; hay que encontrarlo antes de que destruya los datos del disco, pues después de varias ejecuciones del programa infectado, el virus escribe caracteres basura en el disco y lo deja inservible, desde el punto de vista de los datos y la información, y permanece en guardia, residente en la memoria, esperando que otro inocente ejecutable se cargara en la memoria para ser infectado por él.

La epidemia mundial de Dark Avenger era una realidad, y la ignorancia era generalizada como ocurre casi siempre en estos casos. No faltaba el irresponsable que decía que no pasaba nada o que ese nuevo virus era una mentira para sacar dinero, y que era comparable con una simple gripa, que sola desaparece. Pero la realidad era que el virus pasaba de una computadora a otra, de un diskette a otro, infectando archivos *.com y *.exe indiscriminadamente en cada copia, causando que en poco tiempo, en 1991, se diagnosticara la epidemia. Los brotes de Dark Avenger en las empresas crecerían del 10% al 60% en menos de un año (eso decían las revistas de computación de esa época, aunque en realidad no me consta), y se reportaron pérdidas millonarias atribuidas a ese virus creado en Bulgaria tan sólo dos años antes, en 1989. Si la gente se hubiera abstenido de copiar discos, quizá la epidemia se habría controlado o al menos retardado, pero la facilidad de introducir un diskette (o ahora, una memoria flash para USB, o pen-drive) en una computadora, luego en otra y luego en otra, donde a su vez han hecho lo mismo otros (no puedo resistirme a usar aquí la palabra "promiscuidad", so pena de ser bloqueado por algún filtro de contenido o por el mismísimo WebSense :D), propicia que la infección se propague más rápidamente.

Pero fue precisamente en 1991 cuando me tocó cazar a ese virus (tenía yo 16 años, y ya trabajaba: lo recuerdo porque no podía cobrar los cheques de mi sueldo, por no tener identificación oficial; tuve que hacerme amigo de la cajera del banco mientras convencía a la empresa de que me pagaran en efectivo :D). Volviendo a la cacería: Un antivirus en ese tiempo no era tan eficaz, pues el motor de mutación (mutation engine) de un virus polimórfico hace que el virus cambie su forma y, por consiguiente, su rastreo y erradicación sea más difícil. Así que la manera de localizarlo era identificando archivos ejecutables que hubieran aumentado de tamaño y buscando ciertas cadenas específicas en ellos, usando las herramientas de las que disponíamos en ese entonces, como Norton Utilities para MS-DOS (el primer Sistema Operativo que usé), o PC-Tools, entre otros. Para terror de algunos de mis lectores, en ese tiempo no teníamos conexiones a Internet como en la actualidad, sólo libros, así que ni pensar siquiera en googlear cualquier cosa. Todo era artesanal, como yo le llamo. El mayor artesano que conocí en ese tiempo fue Don Nico (así le llamábamos, era un señor como de 70 años, pianista, con coleta, mezclilla y chamarra de cuero, que viajaba en motocicleta y llevaba siempre sus diskettes en una bolsa de plástico, 'para no llamar la atención de los ladrones', me decía) y de él aprendí muchas de las técnicas ancestrales de seguridad computacional y administración de sistemas que todavía hoy conozco. Ese hombre sabía de todo y me inspiró mucho cuando me dijo una vez: "yo tengo mucha confianza en ti, porque a diferencia de los demás, a ti te gusta estudiar". Con esa frase me convertí en su padawan (no se rían, es en serio :D), en su aprendiz, y me dediqué a aprender y estudiar con él muchas técnicas de manipulación de archivos y direcciones de memoria, configuraciones avanzadas del Sistema Operativo, y muchas otras cosas que si las contara posiblemente perdería más de la mitad de mis lectores por su alto contenido técnico :D.

Dark Avenger, el Vengador Obscuro, no fue el único virus con el que tuve que lidiar en aquellos tiempos en que la ignorancia y la falta de información, aunados al descuido e irresponsabilidad, hacían de las suyas en el terreno de las infecciones virales de archivos de computadora. Después hubo muchos más, pero los softwares anti-virus comenzaron a ser cada vez más eficaces (aunque no necesariamente más eficientes), y poco a poco el arte del cazador de virus se fue olvidando (¿cuántos todavía recuerdan cómo rastrear cadenas en un mar de dígitos hexadecimales? Sin duda eran buenos tiempos). Algo que siempre me inquietó fue saber si el programador de Dark Avenger usaba una computadora como la mía, si él también tenía esos 256 Megabytes en RAM que yo tenía en mi 8088 a finales de los 80s.

La motivación de los programadores de virus siempre ha sido tema de debate: existen aquellos que justifican sus virus diciendo que es una forma de contrarrestar la piratería de software (el que copia ilegalmente un software, podría llevarse inadvertidamente algún virus), los que quieren vengarse de alguien o de la empresa que los despidió, o los que quieren obtener fama y reconocimiento a expensas de la destrucción de datos ajenos, e incluso los que no tienen ni la más remota idea de lo que están haciendo (script kiddies), y también los que lo hacen por diversión o por adquirir mayor conocimiento; lo malo de estos dos últimos es que muchas veces sus experimentos e investigaciones se les salen de control, y terminan "in the wild" (es decir, fuera del laboratorio) ocasionando desastres mayores.

Seguramente aún quedamos algunos que todavía conservamos algún trofeo de aquellas cacerías colgado en la pared. Yo, por ejemplo, aún tengo una reliquia: mi primer disco duro de 10 Megabytes (sí, leyó Ud. bien: 10 Megabytes, 10 MB) de 5¼", que guarda la única copia de Dark Avenger que conservo (eso quiere decir que no está erradicado :D). Hay veces, cuando me siento melancólico, que miro aquél viejo disco y recuerdo que aún hay mucho por aprender y experimentar en materia de seguridad y que he sido afortunado al haber tenido experiencias como aquélla con Dark Avenger y otros virus no menos peligrosos, pues me hicieron dar mis primeros pasos en la arena de la seguridad computacional; y, por supuesto, también me recuerda a Don Nico (Don Nicolás Flores), que siempre tenía algo qué enseñar a quien estuviera dispuesto a aprender y escuchar sus explicaciones sobre cómo y por qué hacía las cosas; sin duda, uno de mis mejores maestros.

¿"Eddie lives...somewhere in time!"? ...sí, en la obscuridad de mi viejo disco duro.

:wq!

Conferencia sobre NetBeans en FLISOL 2009 Monterrey

noreply@blogger.com (Knaverit) — Sun, 26 Apr 2009 04:18:00 +0000

Este sábado fue el Festival Latinoamericano de Instalación de Software Libre 2009, y el evento en Monterrey fue todo un éxito. Debo reconocer en primer lugar el esfuerzo en la organización; en verdad fue un evento bien realizado, con una buena asistencia. Como comenté anteriormente, el anfitrión fue la Universidad Regiomontana (UR), en la Facultad de Ingeniería y Arquitectura (FACIYA). Yo tenía toda la intención de llegar desde temprano, pero en la mañana me conecté y entré al sitio de Flisol Monterrey, y descubrí que estaban haciendo un broadcasting, es decir, una transmisión en vivo del evento. Así que estuve siguiendo la primera parte del evento desde mi casa. Esa transmisión fue lo que llaman "la cereza del pastel", aunque como a mi no me gustan los pasteles, lo llamaría... no sé, mejor lo dejaré como un bonus ;-)

Las conferencias fueron muy buenas, y a pesar de recibir (indirectamente, nada personal) críticas hacia las certificaciones de seguridad (¿por qué medio mundo critica a alguien que se certifica?, ¿acaso no les gusta hacer exámenes?), el contenido fue de gran calidad. En cuanto a mi presentación, hablé sobre NetBeans y el crecimiento que ha tenido desde su primera aparición en Praga hasta nuestros días, y sobre todo, traté de hacer énfasis en la importancia de los desarrolladores en la aportación a la comunidad Open Source, pues quienes programan son precisamente los que mantienen vivo el crecimiento, por eso es que necesitamos que más se incorporen a la red de colaboradores del Open Source, especialmente los jóvenes universitarios que, con su entusiasmo y deseos de libertad, aportan mucho.

Para mi presentación instalé Linux Ubuntu en una memoria flash (pen-drive) USB, con OpenOffice 3.0, pues no tendría el descaro de presentarme al FLISOL con un Windows o con PowerPoint, ni Dios lo quiera ;). Lo único que lamento es no haber tenido tiempo suficiente para hacer una demostración con NetBeans IDE, para que vieran lo fácil que es programar con él. Es posible que el video de la conferencia esté disponible en los próximos días en YouTube, y si es así, pondré el enlace aquí mismo. La presentación pueden verla directamente al inicio de esta entrada.

Durante la conferencia me comprometí a iniciar un blog para hablar específicamente sobre NetBeans y Java, así que espérenlo muy pronto. El propósito es, como siempre, compartir un poco con la comunidad de quien también he aprendido.

En resumen, fue una buena experiencia compartir con la comunidad (principalmente universitaria) este sábado, y espero que esta experiencia se vuelva a repetir. Por cierto, gracias a quienes asistieron y permanecieron hasta mi conferencia, que fue la última del día (los agarré cansados, no pudieron correr :D).

Hasta luego.

:wq!

Hoy el tema es "libre"

noreply@blogger.com (Knaverit) — Tue, 21 Apr 2009 00:08:00 +0000

Qué día. Aún estoy recuperándome del shock recibido esta mañana con la noticia de la adquisición de Sun Microsystems por Oracle, aunque muy en el fondo de mi corazón me parece bien que haya sido Oracle y no IBM. Me dá curiosidad ver qué hace Oracle con MySQL después de haber completado (commit;) la transacción (por decirlo en términos de bases de datos). La realidad es que Oracle había estado trabajando muchísimo con Sun desde hace varios años y sus productos se habían integrado muy bien en los ambientes de Sun (Oracle ejecutándose en Solaris, por ejemplo, o Java Stored Procedures), por lo que la integración de ambas compañías se vuelve, hasta cierto punto, natural. La verdad es que el shock fue porque he trabajado muy de cerca con tecnologías de Sun Microsystems desde hace 10 años (administrando, desarrollando, configurando, enseñando, investigando, etc.), y traigo (todavía) puesta la camiseta de Stanford University Network (SUN), por lo que cambiar de "color" de morado a rojo no será tan sencillo. Mientras tanto, una de las grandes preocupaciones de la comunidad será referente al código abierto de Sun (Java, OpenSolaris, NetBeans, MySQL, GlassFish, OpenOffice,...), que todos esperamos siga abierto y libre. Que así sea.

Y hablando de "temas libres", me complace anunciarles que el Festival Latinoamericano de Instalación de Software Libre (FLISOL) en Monterrey, edición 2009, se llevará a cabo el sábado 25 de abril (sí, claro, de 2009) en la Universidad Regiomontana, y me han invitado a dar una de las pláticas de ese día (les llaman "conferencia", pero siguiendo fiel a mi estilo, voy a "platicar"), mientras se lleva a cabo el installfest, que es algo así como una "fiesta de instalación de Linux" (mi hermana se escandaliza: "¿¡festival!?, ¿¡qué les pasa a ustedes, informáticos!?"), donde instalarán Linux Ubuntu en las computadoras que lleven; por cierto, la instalación es legal y gratuita, y también el registro al evento es gratis. Así que les recomiendo registrarse, asistir, llevar aquella computadora con poca memoria que usaban antes y que ahora sirve para detener la puerta, y además participar en alguno de los talleres o escuchar alguna conferencia (la mía, por ejemplo ;-)) o todas.

Si van, me saludan. Si no van... pues no. :-P

Hasta luego.

:wq!

Criptografía para románticos

noreply@blogger.com (Knaverit) — Sat, 14 Feb 2009 21:12:00 +0000

Sí, también tengo un lado romántico; si no me creen, pregúntenle a mi esposa (no crean que es casualidad el hecho de llamarme Romeo :-D). Lo que pasa es que no uso con frecuencia mi romanticismo, que es diferente. Pero, ¿qué tiene qué ver la criptografía con el romance? Absolutamente todo. Yo mismo usaba la técnica del cifrado César hace muchos años para comunicarme con una novia que tuve: ella me escribía, o yo le escribía, pero siempre usando un sencillo algoritmo de sustitución de letras y una llave compartida previamente (me estoy refiriendo a una llave criptográfica, k=3, no sean mal pensados). La llave no era otra cosa sino un número que representa cuántas letras hay que desplazar. Por ejemplo, si ella quería escribirme: "necesito verte", simplemente cambiaba la 'n' por 'q' (3 letras después), la 'e' por 'h', y así sucesivamente hasta tener: "qhfhvlwr yhuwh", mensaje que se ingeniaba para mandarme por un medio no tan seguro (con alguna amiga). Yo recibía aquél papelito perfumado y procedía a decodificarlo, aplicando la llave con el algoritmo en sentido contrario: la 'q' por 'n' (3 letras antes), la 'h' por 'e', la 'f' por 'c', hasta tener el mensaje. Nuestro sistema funcionó correctamente y, dado que no nos descubrieron, puedo decir que nadie lo rompió nunca a pesar de su sencillez... el rompimiento fue otro. Así es la vida. ;-)

Ahora que me doy cuenta, creo que debí haber escrito todo esto usando algún cifrado, porque ahora que lo lea mi esposa se me va a armar tremendo lío. :-D

Sin embargo, ¿quién usa el cifrado César hoy en día? (En todo caso, les recomiendo usar cifrado Vigenère, que también es sencillo y prácticamente irrompible). Tal vez cifrar los mensajes mantenga fuera de la vista de los padres y otros curiosos las declaraciones de amor entre romeos y julietas, a menos que tengan un papá o mamá criptoanalistas... (hijos: si están leyendo esto y no quieren que me entere de algún mensaje que les intercepte, tendrán que ir investigando sobre criptografía de curva elíptica o, quizá para entonces, criptografía cuántica... o mejor aún, ¡cuéntenmelo todo!, ¿para qué se complican? :-D).

En fin, todo sea por conservar algo de intimidad y guardar secretos, pero siguiendo un principio básico en criptografía: estar de acuerdo. No vaya a pasar como aquella canción de Juan Luis Guerra que dice: "te mando señales de humo como un fiel apache, pero no comprendes el truco y se pierde en el aire". Ya me imagino, el cuate aquél mandando las señales con código morse ("y un código morse transmite el 'te quiero' de un ángel, se pierde en el aire"), y la amada ni en cuenta. ¡Que alguien le enseñe código morse, por favor!.

Aunque es cierto que un mensaje cifrado (encriptado, pues) hace evidente que hay un secreto guardado en el mensaje (es decir, si alguien ve un papel perfumado que dice: "qhfhvlwr yhuwh", va a saber que hay algo secreto y sentirá la curiosidad de saber qué es lo que dice), pero ¿qué tal si el mensaje es digital y contiene una fotografía o una canción en MP3? ¿qué tal si en la fotografía o en la canción va oculto un mensaje, imperceptible a simple vista o a simple oído? Eso ya no sería tan evidente. Esto es posible gracias a la esteganografía y otras técnicas de covert channels, pero de eso hablaré en otra ocasión; hoy no, porque la esteganografía no es tan romántica como la criptografía.

Bueno, los dejo con una frase de amor pseudo-geek, en cifrado César, que dice:

"dpru hv phprulcdu vx gluhfflrq ls, hq oxjdu gh xvdu gqv"

Hasta luego.

:wq!

Nota cultural: Para aquellos que siempre quisieron saber la secuencia que usó el fiel apache de la canción para transmitir "te quiero" en las señales de humo, la representación en Morse es: - . / --.- ..- .. . .-. --- (es cierto, por mis venas corre sangre de telegrafista: feliz día del telegrafista).

La comunicación es un asunto de capas

noreply@blogger.com (Knaverit) — Fri, 23 Jan 2009 19:07:00 +0000

¿Alguna vez has tratado de entender cómo es ese asunto de las capas del modelo OSI o del conjunto de protocolos TCP/IP? Algunos maestros, en lugar de ayudar a comprenderlo sólo lograron confundir a más de cuatro, estoy seguro. Y al final sigue quedando la gran incógnita: ¿qué función tienen las capas en un modelo como OSI o TCP/IP? Esto lo escucho una y otra vez cada vez que doy un curso de redes y en realidad es algo muy simple. La gente encargada de definir el modelo pensó en una manera de representar que dentro de una comunicación intervienen una serie de elementos que, si bien son diferentes entre sí, se interrelacionan de una manera tal que pueden conseguir que una transmisión de datos se lleve a cabo. El concepto de capas es simplemente una forma de representar la individualidad de cada tarea en la comunicación y cómo se relaciona con otras tareas para lograr una colaboración de todo el conjunto.

En esta ocasión, como estoy de buen humor (como casi siempre ;)), les voy a platicar una alegoría para intentar explicar un aspecto fundamental en las comunicaciones entre dos equipos en una red de datos que usa TCP/IP. Después de contar la historia, trataré de aplicarla al concepto de comunicación del que estamos hablando, tengan paciencia.

La capa de Aplicación, en el origen
Yo vivo en Monterrey, México, y tengo un amigo, Guillermo Alegría (la versión mexicana de Bill Joy :D), que vive en la Ciudad de México. Mi amigo me ha pedido ayuda porque quiere aprender UNIX, así que pensé en enviarle unos manuales que tengo por ahí guardados.

La capa de Transporte, en el origen
Como son varios libros y quiero asegurarme de que mi amigo los reciba, he pensado que la mejor manera de enviarlos será uno a la vez, y una vez que tenga la confirmación de que recibió el primer libro, le envío el segundo y así sucesivamente (soy un poco desconfiado, por eso mejor me aseguro de que los va recibiendo, uno a la vez). Para que no se maltraten, envuelvo cada libro en un paquete.

La capa de Internet, en el origen
Por supuesto que para enviar un paquete necesito escribir el nombre y la dirección de Guillermo, y también la mía en caso de que mi amigo ya no viviera en ese domicilio y tuvieran que devolverme el paquete (no puedo darme el lujo de perder un libro de UNIX). Mi amigo vive en la célebre calle Chopo, en el número ocho, y así lo escribo en el paquete.

La capa de Enlace de Datos, en el origen
Llego a la empresa de mensajería, una de confianza. El encargado observa el paquete y me pregunta por qué medio quiero enviarlo: "¿Por avión o por carretera?" -me pregunta. Me interesa que mi amigo comience a estudiar cuanto antes, pero no tanto como para pagar la diferencia de un envío aéreo. "Por carretera" -le respondo.

El medio físico
Y ahí va el libro, viajando por carretera hasta la Ciudad de México. Diez horas de camino. En México encuentran mucho tráfico, como siempre, lo que retrasa el envío dos horas más. Ni hablar, todo sea en aras del saber.

La capa de Enlace de Datos, en el destino
Al fin la camioneta de reparto llega a Chopo 8, se aseguran de estar en el domicilio indicado y tocan el timbre. Mi amigo abre la puerta y se alegra de recibir el envío. A simple vista el paquete parece estar en buenas condiciones, de lo contrario, si llegara abierto por ejemplo, no lo aceptaría y me sería devuelto, o posiblemente sí lo recibiría, haciendo la observación pertinente al que lo entrega.

La capa de Internet, en el destino
Le preguntan a mi amigo: "¿Es usted Guillermo Alegría?", y él responde afirmativamente, por supuesto, y le entregan el paquete.

La capa de Transporte, en el destino
Le dan a firmar un acuse de recibo, porque recuerden que yo quería asegurarme de que recibiera el paquete, así que pedí que por cada paquete que él recibiera, firmara un recibo indicando que efectivamente tenía ya en su poder el paquete, así yo sabría que podría enviar el siguiente libro con mayor confianza. Mi amigo ya no puede esperar, le quita la envoltura al libro y observa que es el volumen 1, lo que quiere decir que seguramente deberá esperar más libros como ese. Si en el siguiente envío yo le mandara el volumen 3, seguramente él me mandaría a avisar que le faltó el volumen 2 y que no puede saltarse del 1 al 3, que necesita el 2. Al menos eso haría yo.

La capa de Aplicación, en el destino
Sentado cómodamente en su sillón, con un refresco y unas frituras, mi amigo Memo (es que así le decimos en México a los que se llaman Guillermo) se dispone a leer el libro de UNIX y se da cuenta de que podrá hacer muchas cosas ahora que aprenda a usarlo. Sólo espero que un día de éstos no me diga que ejecutó "rm -r /", siendo root. ;-)

¿Y qué tiene que ver esto con TCP/IP?
Mucho. TCP/IP es un conjunto de protocolos (reglas de comunicación) que tienen su propia función y que en conjunto pueden llevar a cabo la comunicación entre, al menos, dos dispositivos en una red. La división en capas nos ayuda a entender que en la capa de Aplicación se preparan los datos que serán enviados desde una Aplicación X a una Aplicación Y en otro dispositivo; como los datos que se envían seguramente son muchos, la capa de Transporte puede segmentar dichos datos en segmentos o datagramas que sean más fáciles de enviar, por tener un tamaño más manejable para los dispositivos de red. Como posiblemente sean varios segmentos de datos, se enumeran para que, una vez que lleguen a su destino, el destinatario (el que los recibe) sepa que han llegado todos los datos o si tal vez faltó alguno para pedir que se envíe nuevamente. Ahora bien, ninguna comunicación confiable será completa si no hay un adecuado direccionamiento, o si no se conoce el domicilio o dirección de quien recibirá los datos, y es precisamente la capa de Internet la encargada de identificar en cada paquete de datos la dirección de quien envía y de quien recibirá dichos datos. Una vez que ya se tienen listos los datos, en la capa de Enlace de Datos se prepara una trama (frame) para que los datos puedan ser enviados por algún medio físico, usando un cable, por ejemplo, o a través de ondas por el aire. Como cada medio es diferente y exige diferentes tipos de controles, las tramas se preparan para cada medio en particular, de acuerdo a los estándares.

Cuando los datos llegan al destinatario ocurre la operación contraria, pues las tramas llegan por un medio físico, y cada protocolo de cada capa va tomando la información que requiere de su contraparte que envió los datos. Por ejemplo, la capa de Enlace de Datos se asegura de que la trama realmente vaya dirigida a ese dispositivo físico de la red y pasa el paquete a la capa de Internet para que haga lo mismo; en la capa de Internet se verifica que la dirección de destino sea efectivamente la actual y se pasa a la capa de Transporte para que verifique a su vez que el segmento forma parte de la secuencia esperada y, en muchos casos, preparar una confirmación de haber recibido los datos, para que se envíen más. Al final, los datos son colocados en orden y pasados a la capa de Aplicación, que hará que sean presentados o recibidos por la Aplicación Y de una manera legible, ya sin todo el "empaque" que se colocó en los datos al ser enviados.

Obviamente esta es una explicación muy simplificada de lo que realmente ocurre. No hablé, por ejemplo, del famoso three-way handshake para TCP, por ejemplo, ni de otras características igualmente importantes, pero para eso hay muy buenos libros y otros recursos de consulta. Este es solamente mi sencilla aportación para tratar de explicar algo como a mi me hubiera gustado que me lo explicaran.

Fin de la transmisión.

:wq!

El colmo de un CISSP/CEH: que su blog sea catalogado como "malicious"

noreply@blogger.com (Knaverit) — Wed, 22 Oct 2008 01:08:00 +0000

Después de haber pasado un inicio de semana en injusta ignominia, bloqueado por el Websense desde la red de la empresa donde trabajo, en la dudosa categoría de "Malicious Web Site", me he animado nuevamente a escribir, haciendo a un lado el oprobio y concentrándome en el propósito original de este blog, que es... ahora que lo pienso, no tengo otro propósito mas que escribir un poco de lo que sé y que creo que le pueda ser de interés a alguien.

Pero, ¿por qué "malicious"? Si yo no hago phishing, ni pharming, ni tampoco soy spammer ni cracker. Una cosa es que sepa cómo hacerlo, y otra muy diferente es que lo haga o que enseñe cómo se hace. En eso precisamente radica el Ethical Hacking, en conocer y usar adecuadamente y con responsabilidad las herramientas para encontrar huecos de seguridad y ofrecer alternativas de solución.

Hablando de Ethical Hacking, hace unos días terminé lo que fue mi última intrusión, hasta el momento, en un sistema ajeno con permiso del dueño. Seguramente no sería tan relevante, si no fuera por la manera que al final usé para poder ver información confidencial.

Para darles un poco más de contexto a mis lectores (¡ya son 5!), les diré que el Ethical Hacking, o Pen-Test (prueba de penetración), consiste en llevar a cabo una serie de pruebas controladas, automáticas o manuales, con diversas herramientas de hacking para intentar ganar acceso y comprobar qué tan vulnerable es una red o un sistema. Hay ethical hacking en prácticamente cualquier nivel: de sistemas operativos, redes, redes inalámbricas, aplicaciones web, sistemas criptológicos, bases de datos, etc. Pero lo más importante en cualquier prueba de penetración no es solamente encontrar las vulnerabilidades, sino proporcionar las soluciones, y eso es lo satisfactorio.

Ahí estaba yo, a la mitad de la noche, inspirado por el café, escribiendo un programa en Java... import java.net.*; import java.io.*; etc. Y es que después de dos escaneos sin vulnerabilidades relevantes, la única alternativa que veíamos (mi taza de café y yo) era hacerlo artesanalmente: programando mi propia herramienta. Los scanners me ayudaron en cierta manera para automatizar el proceso de descubrimiento e identificación, pero si quería llegar más lejos (o más adentro, según la perspectiva), tenía que hacerlo a mano, artesanalmente. El Diccionario de la Lengua Española define artesano como "quien hace por su cuenta objetos de uso doméstico imprimiéndoles su sello personal", por lo tanto como yo hago objetos (bueno, hago las clases y luego los objetos con new) y les imprimo mi sello personal, entro en la categoría artesanal. Además, yo siempre he dicho: "programar es un arte". Mi programa, hecho en 100% Java, funcionó y me permitió terminar la penetración en menos de lo que terminaba mi última taza de café.

El caso es que aproveché una vulnerabilidad de la aplicación en el manejo de sesiones. Externamente la aplicación se veía bien, con su forma de acceso por usuario y contraseña, pero al analizar las respuestas del servidor HTTP observé patrones que me ayudaron a formarme una imagen mental de lo que ocurre allá en el servidor. No puedo revelar más detalles de la intrusión, pero para cuando terminé mi café no sólo había encontrado la puerta para entrar, sino que ya tenía evidencia de información confidencial que usuarios de ese sitio habían subido, confiados de que sus documentos estarían seguros, pero el simple hecho de confiar a alguien más nuestra información, la hace potencialmente vulnerable.

Este tipo de ejercicios son muy enriquecedores por el conocimiento que proporcionan (sin mencionar la retribución económica), pero debo aclarar que sólo lo hago por la vía legal; una intrusión sin permiso no está en mis planes, ni tampoco está en mi código de ética.

Ya para concluir, si por alguna razón este sitio vuelve a ser bloqueado por nuestros amigos de Websense y están leyendo estas líneas gracias a una traducción de Google (¿sería buena idea escribir esto en inglés?), lamento informarles que en este sitio no enseño técnicas para hacking, ni tampoco publico exploits, y los únicos consejos que publico son con el ánimo de incrementar la cultura de la seguridad de la información... y compartir una que otra taza de buen Java.

:wq!

CISSP: Certified Information Systems Security Professional, por (ISC)².
CEH: Certified Ethical Hacker, por EC-Council.

El pescador y el granjero son ingenieros: Phishing & Pharming

noreply@blogger.com (Knaverit) — Mon, 22 Sep 2008 15:37:00 +0000

El pescador (Phishing)

El pescador preparó la carnada. Definitivamente la página Web de Bancotorro® que había puesto en aquél servidor lucía perfecta: nadie notaría la diferencia con la original del banco. Por cierto, ¡qué fácil resultó apropiarse del servidor Web!, gracias a ese administrador que hizo el favor involuntario de dejar instaladas las extensiones de FrontPage. La página tiene todo para que parezca la original excepto, claro, el nombre de dominio de la dirección del sitio pero, ¿quién se fija en los nombres de dominio? Además se sacó un diez con ese certificado falso de SSL: así el sitio hasta parece seguro, con el https, el candadito amarillo y todo, pero con una firma digital falsa (a casi nadie le importa, eso es lo bonito de este engaño). El certificado no le costó ni un centavo y el emisor le dio la oportunidad de llenar en línea la solicitud y recibir el certificado a nombre de Bancotorro® directamente en su correo (bueno, ni siquiera es su correo, sino uno falso), para prueba por 60 días, tiempo más que suficiente para una buena pesca.

El pescador se dispuso a lanzar el anzuelo. Esa lista de direcciones de correo que consiguió de un conocido spammer era oro molido: cientos y cientos de direcciones de correo de fanáticos de las cadenas y los powerpoints motivacionales, registrantes incautos de servicios gratuítos que nunca funcionaron, y algunas (muchas) víctimas inocentes cuyo único error fue ser un contacto de mensajería instantánea de alguien que un día sintióse perdedor y quiso ver quién lo había borrado-del-messenger para así terminar de aniquilar su autoestima. "¡Qué bueno que todavía hay almas generosas -pensaba el pescador, mientras sonreía sarcásticamente- que creen que alguien va a donar un centavo para ayudar a los niños enfermos por cada mail que envíen... como si fuera posible saber que lo enviaron!".

El pescador agitó la caña de pescar con maestría y lanzó el anzuelo: en un instante un mensaje de correo, supuestamente del banco, solicitando hacer clic en un hipervínculo para actualizar los datos y evitar la suspensión de la cuenta, fue enviado a cientos de buzones de e-mail. "Si no fuera por los filtros bayesianos -pensó el pescador- la pesca sería mucho mejor". No obstante su trabajo rindió fruto: en pocos minutos el falso sitio Web de Bancotorro®, la carnada, logró capturar algunas decenas de nombres de usuario, contraseñas y claves dinámicas, mientras los redirigía a la página real, para evitar sospechas (de bancotorro.com a bancorroto.com, ¿alguien nota la diferencia? Ah, favor de no dar clic en esos hipervínculos, por favor). De ahí sólo es cuestión de minutos para completar la fechoría, pues la clave dinámica es vigente muy poco tiempo, y si alguien se da cuenta del engaño podría retrasarlo un poco (lo bueno para él es que Bancotorro® no le vuelve a pedir la clave dinámica para las transacciones). La cárcel no lo asusta, pues el servidor-víctima resultó estar en un país de aquéllos en los que la legislación para cibercrímenes no existe (lo que pasó es que, como los legisladores de aquél país no entendían nadita de seguridad informática, prefirieron seguir chateando y subiendo fotos a sus féisbucs, en lugar de aprobar la ley contra cibercrímenes); y para cerrar el ciclo de impunidad, el mensaje-carnada de correo lo estaba enviando ni más ni menos que desde un servidor SMTP que se encontró, desnudito el pobre y con relay habilitado, en la DMZ de una conocida empresa que brinda servicios ni más ni menos que de seguridad informática. Qué irónico.

Fue una buena pesca, no se podía quejar: en pocos minutos logró hacerse de dinero fácil, transfiriendo de una cuenta a otra, vaciando la del ingenuo, llenando la suya propia. Mientras lo hacía, recordó cuando furtivamente instalaba keyloggers en las computadoras de los ciber-cafés, de los hoteles y, por supuesto, de la Universidad donde estudiaba (el laboratorio de cómputo era un paraíso: la anarquía total), y con ellos podía recibir cómodamente en un buzón de correo todo lo que la gente tecleaba. Volvió a sonreir: "de las cosas que se entera uno".

Sin embargo le preocupaba una cosa. Cada vez eran menos los que mordían el anzuelo, con eso de las campañas de los bancos y uno que otro blogger que escribía consejos sobre seguridad informática. La gente ya no es como antes, ahora ponen más atención en darse cuenta a dónde los envía un hipervínculo. Pero eso no le quita el sueño, pues desde que conoció al granjero, alguien con sus mismas inclinaciones delictivas, pero con una técnica que era el complemento perfecto para sus operaciones, cobró nuevos ánimos. Su nuevo socio era su salvación.

El granjero (Pharming)

El granjero disfrutaba de una tranquilidad envidiable. Su trabajo consistía en conseguir que, cuando alguien quisiera entrar, por ejemplo, al sitio de Bancotorro®, fuera redirigido hacia el sitio falso que el pescador había preparado para obtener las credenciales del usuario. Aunque su trabajo suena sencillo, en realidad tiene su complejidad: primero debe encontrar servidores DNS que puedan ser fácilmente engañados (envenenados) e integrados a su granja, de tal manera que cuando alguien pregunte por el sitio de Bancotorro®, el DNS envenenado lo reenvíe hacia el sitio falso. De no haber sido por Kaminsky podría haber perfeccionado la técnica aún más, pero por fortuna para él aún hay muchos que no han instalado parches a sus clientes y servidores DNS.

El granjero hace todo esto con regularidad, pero hay algo que le gusta más todavía: saltarse las trancas y modificar el archivo de hosts de una PC. De esta manera no hay necesidad de usar DNS, pues la misma computadora engañada dirige hacia el sitio falso, con una simple línea agregada al archivo de hosts, y sin tener que cambiar la dirección en la barra de dirección del navegador, haciéndole creer al navegante que está entrando en el sitio correcto. Esto lo disfruta más porque requiere ingenio engañar a un usuario de Internet y convencerlo de ejecutar un programa en su computadora aunque, pensándolo bien, no requiere tanto ingenio: puede aprovecharse del sentimentalismo, y enviarle al inapercibido navegante una tarjeta de felicitación... pero, ¿y si no es su cumpleaños?, ¡no importa! la curiosidad lo hará abrirla de cualquier manera. No necesita más, pues habiendo incrustado el código letal en esa supuesta tarjetita de felicitación habrá logrado su objetivo. "¡Qué bueno que aún hay usuarios que trabajan usando la cuenta de administrador!" -murmuró.

¡Qué par! Juntos, el pescador y el granjero, son imparables. Bueno, tal vez no tanto. Quizá algún día ya no puedan usar las mismas técnicas, o quizá algún día el administrador de seguridad de Bancotorro® se dé cuenta de que la clave dinámica o token debe ser dinámica no sólo para el ingreso, sino también para cada transacción, y se les cierre esa mina, pero por lo pronto están ahorrando y guardando su dinero debajo del colchón (es que no confían en los bancos, y menos en Bancotorro®). Ah, y por cierto, están felices porque ya no son sólamente un pescador y un granjero... ahora les dicen ingenieros... ingenieros sociales.

:wq!

Java para todos

noreply@blogger.com (Knaverit) — Mon, 15 Sep 2008 23:23:00 +0000

La semana pasada estuve en el Instituto Tecnológico Superior de Poza Rica, en Veracruz, por una invitación que me hicieron para participar como jurado en la competencia local de programación de ACM. El lenguaje de programación que usaron para el concurso fue Java y, sobra decirlo, yo estaba como Glassfish en el agua. La competencia fue muy interesante, y me tocó revisar los programas que hicieron los muchachos, estudiantes de Ingeniería en Sistemas Computacionales. La jornada la terminé dándoles una serie de recomendaciones para mejorar su nivel de programación y resolución de problemas; espero sinceramente que hagan un buen papel en la siguiente competencia. Gracias al ITSPR por la invitación.

Una de las grandes cualidades del lenguaje de programación Java es su simplicidad. Una vez entendidos los conceptos de Orientación a Objetos, prácticamente es posible desarrollar cualquier programa, y para cualquier plataforma. Aunque esta simplicidad ha sido duramente criticada por muchos, en mi opinión Java sigue siendo un lenguaje de programación muy poderoso. Hay que admitir que un error muy grande en algunas Universidades es haber quitado de sus planes de estudio las materias relacionadas con análisis de algoritmos y estructuras de datos (con su correspondiente terapia sobre aritmética de apuntadores, claro) que, tradicionalmente se han enseñando en lenguaje C, y reemplazado completamente por materias relacionadas con el lenguaje Java. Yo he sido instructor certificado de Sun Microsystems, Inc., dando cursos de certificación en Java Programming desde el 2000, y mi opinión es que, aunque es importante aprender la sintaxis de los lenguajes de programación, no deben descuidarse los fundamentos. Incluso en la actualidad muy pocos saben hacer los tradicionales diagramas de flujo, mucho menos los diagramas en UML. Por eso insisto en la importancia de la formación de verdaderos programadores que sepan resolver problemas, no sólo tecleadores de código.

Pero Java sigue siendo una excelente opción tanto para el que comienza a programar como para el experimentado que necesita desarrollar aplicaciones robustas, escalables, multiplataforma y con una curva logarítimica de aprendizaje más suave (en razón de tiempo/esfuerzo). Para los que quieren comenzar con Java (no importa la edad), les recomiendo visitar la sección de Young Developers y Tutorials en java.sun.com, donde encontrarán herramientas y otros recursos para comenzar a programar en Java. No se desanimen si leyeron o escucharon a alguien decir que sólo los verdaderos programadores programan en C... no es cierto, en realidad los verdaderos programadores programan en código máquina... ;-)

Y para aquellos interesados en ganarse un dinero extra y mejorar su reputación como programadores, les animo a entrar a concursos y competencias como la JavaCup, que es un concurso que consiste en un torneo de fútbol virtual, basado en eliminatorias, donde cada equipo es una clase Java que implementa la estrategia del mismo, apoyándose en un framework creado para tal efecto. Para participar sólo tienes que implementar tu equipo (una clase Java). Toda competencia es buena: es una alternativa para adquirir buena experiencia, y posiblemente algún premio, y si no ganas, acéptalo con humildad y no hagas escándalo: toma la experiencia e inscríbete al siguiente concurso.

En fin, Java es para todos y está en todas partes: Java está en infinidad de computadoras de dispositivos electrónicos y vehículos (incluyendo el Mars Rover de la NASA, en Marte); gran cantidad de aplicaciones en Internet son interactivas gracias a Java, las transacciones comerciales y muchos servicios de administración de identidades son seguros gracias a tecnologías como JavaCard,y la tecnología multimedios se ha visto enormemente beneficiada por las cualidades gráficas de Java, sin olvidar a los juegos para múltiples jugadores simultáneos en teléfonos celulares... la tecnología Java está en todas partes, Java es para todos.

System.exit(0);

:wq!

En busca de la privacidad... ¿en féisbuc?

noreply@blogger.com (Knaverit) — Wed, 27 Aug 2008 15:35:00 +0000

Oh, bendita privacidad. Todos tenemos algo que no queremos mostrar a los demás, ya sea por seguridad o por el derecho a guardar secretos. Por eso hace dos meses compré mi control de seguridad más caro: una pantalla protectora para mi laptop, para que los de al lado no vean lo que estoy escribiendo, especialmente en las juntas. Una premisa clásica en seguridad de información es que el control (el mecanismo o instrumento utilizado para minimizar un riesgo de seguridad) no debe ser más caro que el activo que está protegiendo... y la verdad el riesgo de que mi vecino en una junta vea que estoy escribiendo en blogger.com no vale más de los 60 dólares que pagué... ni modo, ahora hay que usarlo, ¿quién me manda a andar encargando a alguien que lo compre en lugar de comprarlo yo?. :-D. En fin, todo sea por conseguir un poco de privacidad.

Hace unos días abrí una cuenta de Facebook (féisbuc), y no precisamente por estar de moda, sino más bien por una característica fundamental del hombre (y también de la mujer, por supuesto) llamada curiosidad. Extrañamente la inauguración de mi nueva y reluciente cuenta de féisbuc coincidió con una serie de artículos en periódicos y noticias televisivas en donde se pone en tela de juicio la seguridad de los sitios que sostienen las llamadas redes sociales (social networks), específicamente mencionando a Facebook, hi5 y MySpace. Ahora el tema de la seguridad y de la privacidad repentinamente son del interés común, y esto no habría sido relevante de no haber ocurrido en México recientemente un secuestro que terminó en tragedia, cuyas investigaciones revelaron que la víctima (antes de serlo) había publicado prácticamente sus detalles de vida en al menos uno de los mencionados sitios. Es bien sabido que en esas redes se muestran no sólo los nombres de los amigos de una persona, sino también sus fotografías, la dirección donde vive, las actividades que tendrá el fin de semana, o los lugares a donde va frecuentemente, pero de eso precisamente se alimenta una red social, ¿o no?

Armado con mi fresquecita cuenta de féisbuc y mi incipiente lista de amigos que tuvieron el honor de aceptarme en su red :-P, me di a la tarea de revisar qué es lo que pudiera representar un riesgo por fuga de información. En realidad es más simple de lo que cuentan, aunque hace falta cierta habilidad (no mucha, por cierto) para interpretar lo que ahí se ve; a fin de cuentas es sólo minería de datos (data mining) y la interpretación depende de otros factores. De entrada, si no estás registrado no ves prácticamente nada, aunque el registro es cuestión de unos cuantos clics, con una validación bastante simple. Una vez dentro, lo que sigue es buscar gente: puede usarse la búsqueda del sitio o a través de los enlaces de amigos de tus amigos, y de los amigos de los amigos de tus amigos...

¡Espera mil milisegundos...! (java.lang.Thread.sleep(1000);) ¿eso quiere decir que cualquier persona puede ver la información que alguien publica en esos sitios? No precisamente. Todo depende de cuánta información revele. Es decir, que al final todo se reduce a que el nivel de exposición está en relación directa con el grado de apertura que cada persona tiene y desea mostrar a otros, conocidos y desconocidos, por iniciativa propia o por pura ignorancia; y es importante aclarar que dichos sitios se protegen, con cláusulas que los eximen de cualquier responsabilidad derivada del uso que hagan los suscriptores del servicio. Realmente no es un problema del servicio en sí, sino de la forma en que la gente hace uso de él.

Para concluir mi investigación, preparé una prueba de concepto para tratar de demostrar que el problema de la divulgación de información es pertinente al individuo, y no necesariamente a la infraestructura de la red social. La prueba consistió en crear una cuenta falsa de féisbuc, asociada a una dirección de correo igualmente falsa, junto con un perfil más falso que un billete de 3 pesos. Obviamente no era yo, sino una identidad que yo inventé (y sí que me vi creativo, créanme). Comencé incorporando a la identidad prima (matemáticamente hablando) una apariencia difícil de resistir, con datos ficticios pero creíbles. La prima comenzó la búsqueda: primero sus "compañeros" de la Universidad, luego otros aleatorios, algunos conocidos (míos) y sus amigos (de mis conocidos). En ese mismo día hubo respuestas: varios incautos aceptaron a la prima sin ningún problema (o les pareció conocida, o de plano les gustó). Ahora, usando la cuenta prima puedo ver los perfiles, las fotografías, el domicilio (con Google Maps y todo) y otros datos personales, gracias a que todavía hay gente que cree en la amistad y en la buena voluntad de las personas (hasta tengo ganas de llorar, "pero tan sólo de mi ojo derecho", como dice Juan Luis Guerra), y que haría cualquier cosa con tal de tener una lista extensa de amigos y ser populares, aunque involuntariamente estén exponiendo incluso a sus familias.

¿Qué hacer, entonces? Por supuesto no hay que tomar la postura radical de no usar esos servicios por miedo a que alguien nos investigue, pues sería equivalente a decir que no saldremos a la calle por temor a sufrir un accidente. Lo importante es ser precavidos y no ser tan confiados. Al menos en féisbuc pude configurar mi cuenta (la real) para que nadie pudiera ver mis datos y fotografías, excepto mis contactos, incluso para no aparecer en los resultados de la búsqueda. De sobra está decir que no tendré muchos contactos ni seré popular, pero tampoco es algo que me quite el sueño. No he mencionado que la misma situación es aplicable a los blogs, pero si este blog fuera privado no se estarían enterando de ésto y yo sí quiero que se enteren. Hay que buscar el balance. Por cierto, durante mi recorrido por el féisbuc encontré muchas cuentas (algunas conocidas) con perfiles públicos, es decir, a la vista de todos. Si estás entre mis amigos y conocidos y estás leyendo esto, revisa por favor tus opciones de privacidad en tu féisbuc, y si no también. :-D. Sólo hay que dedicar un poco de tiempo y evitar problemas.

Ya por último, ¿cómo puede alguien estar seguro de que aquél que está solicitándote integrarse a tu red social es realmente alguien que conoces? Es difícil, pero puede usarse un principio de seguridad telefónica básico conocido como call back. Hacer call back (también conocido como dial back, o "devolver la llamada") quiere decir que cuando alguien te llama por teléfono, para asegurarte que realmente es él, cuelgas y le llamas tú al número que conoces de él o ella. Aplicándolo al caso féisbuc, equivaldría a escribirle a tu amigo o amiga (a la dirección previamente conocida, no a aquella que viene en el perfil del solicitante, pues podría ser falsa) y preguntar si realmente hizo la solicitud. En la práctica es más fácil asumir el riesgo, pero ¿cuántas veces realmente alguien se pone a pensar en la posibilidad de que sea un engaño y alguien esté tratando de hacernos daño? Casi siempre puede más la curiosidad que la seguridad personal.

Las redes sociales son, entonces, una de tantas formas de interrelacionarnos, al menos virtualmente, con personas afines y de intereses comunes, compartir información de interés mutuo, como noticias y fotografías, pero que deben ser usadas con responsabilidad, con la responsabilidad que amerita el uso de un servicio de naturaleza informativa y de relaciones interpersonales. Sin embargo, como sabiamente dijo alguien que conozco, pero cuya identidad me reservo por su propia seguridad :-P (cito textualmente): "Debido a que las redes sociales hoy en día ponen en riesgo nuestra integridad fisica, tendremos que volver a las viejas prácticas donde nos vemos en un lugar, platicamos sin teclado, y no podemos subir videos ni usar Ks a nuestro antojo, deformando palabras o poner caritas de msn con signos y letras". Palabras sabias, sin duda.

Ahora ya lo saben, si algún día reciben una solicitud de féisbuc (Facebook, pues) para agregar como amigo o amiga a alguien que no conozcan (o que aparentemente sí conocen), piénsenlo dos veces... podría ser algún malintencionado, ...o podría ser mi prima... mi cuenta prima. :-D

:wq!

Cuida el ambiente... y el ancho de banda

noreply@blogger.com (Knaverit) — Fri, 08 Aug 2008 03:30:00 +0000

Diariamente mis buzones de correo electrónico (e-mail, i-meil) tienen mucha actividad, igual que los de muchos de ustedes. Mensajes que entran y salen, a veces indiscriminadamente; SMTP e IMAP en todo su esplendor. Todos esos bits recorriendo el éter.

No soy ambientalista, aunque de repente trato de seguir algunos de los consejos que considero prácticos, especialmente aquellos de quien he llamado La Conciencia Ecológica de IT, aquí donde trabajo. En últimas fechas me llamó la atención que varias firmas de correos electrónicos que recibía desde hace ya varios meses incluían una leyenda como:

P Cuide el ambiente: por favor no imprima este e-mail a menos que sea realmente necesario.

Curioso como soy, me di a la tarea de googlear el famoso letrerito, y encontré que alguien sugirió el año pasado incluir el mensaje en las firmas de correo electrónico, como una manera de crear consciencia en la comunidad y no se imprimieran innecesariamente los correos electrónicos, pues eso representa, según el mensaje original, un desperdicio. Desde entonces cada vez más y más correos llegan con esa leyenda. Suena bien intencionado, y no lo critico, pero ¿realmente alguien deja de imprimir un correo después de leer ese mensaje?

Como decía, el tema ambientalista no ha estado dentro de mis temas prioritarios (ambientalistas: este es el momento de rasgar las vestiduras), pero creo que mi geek interior me impulsó a estar a la moda, sin renunciar a mi posición de neutralidad ecológica. Así que redacté mi propia firma-creadora-de-consciencia-ambiental-posicionadora:

Í Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;)

(Sí, amigos: reemplacé el arbolito verde y el caminito por un floppy disk azul.)

Los que me conocen saben que soy enemigo de las cadenas, pues llenan de pura basura los buzones de correo electrónico, como en otro tiempo llenaban nuestros buzones postales aquellas cartas que tenías que fotocopiar como 51,966 veces y repartirlas indiscriminadamente entre vecinos, parientes y otros incautos, antes de que te cayera la maldición de no-se-quién, como "constaba" en los testimonios incluidos: "fulanito no lo hizo y al otro día perdió su trabajo"; pero si lo hacías recibirías grandes beneficios, porque "fulanita sí lo hizo y al día siguiente ganó la lotería", seguramente porque mientras repartía las cartas antes de que le cayera un rayo, pasó por el puesto de billetes de lotería y, con lo que le sobró de las fotocopias, compró el cachito ganador. Perdón, me explayé. El caso es que las cadenas son molestas y no sólo llenan los buzones, sino que también llevan consigo las direcciones de correo de todos aquellos seres que tan inocentemente reenviaron el mensaje (o lo recibieron) sin saber que lo que estaban haciendo no era solamente evitar que les cayera un piano encima, sino proveyendo de materia prima a los spammers (si algún spammer está leyendo esto, acuérdese de lo que le ocurrió a Vardan Kushnir. He dicho).

¿Y todo este rollo, por qué es? Ah, pues porque mi mensaje dice: Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;) (el emoticon al final es para que nadie lo vea como una orden, pues ¿quién soy yo para decirle a otros lo que debe o no hacer con su e-mail? :D).

Los servidores de correo electrónico tienen mucho trabajo recibiendo y enviando mensajes, aplicando filtros bayesianos para determinar si un mensaje es probablemente spam, verificando las cuotas de los usuarios para evitar que se excedan, revisando los archivos adjuntos con el antivirus, almacenando los e-mails en los discos, y todo eso cuesta y debe administrarse. Además, el simple hecho de enviar algo por el éter, consume recursos en la red: electrones viajando por el cobre, o fotones por la fibra óptica, o señales de radio por el aire; los routers deben dedicar tiempo y procesamiento para enviar los mensajes eligiendo la mejor ruta, y ¿qué decir de la energía eléctrica que se consume en cada ciclo de CPU para procesar el envío, a cualquier nivel?. Todo un despliegue de tecnología al servicio de alguien que posiblemente pensó: "no vaya a resultar cierto y me abandone mi novia o se muera mi perro. Por si acaso, mejor lo mando las 128 direcciones que me piden".

En fin, si alguien tiene curiosidad y quiere incluir el ahora-famoso mensaje ambientalista, sólo necesita agregar el siguiente código HTML en su firma de correo (si es que soporta HTML):



<font color="#006600" face="Webdings" size="+1">P</font><font color="#006600"> Cuide el ambiente: por favor no imprima este e-mail a menos que sea realmente necesario.</font>

Y si quieren incluir una versión mía, ligeramente modificada, donde recomiendo reutilizar el papel en lugar de prohibir imprimir (y reemplazando irreverentemente el arbolito original):



<font color="#006600" face="Webdings" size="+1">Q</font><font color="#006600"> Si necesita imprimir este e-mail, hágalo... pero reutilice y recicle el papel. ;)</font>

Y ya por último, si se quieren unir a mi causa por la preservación de los bits y el ahorro de espacio en los medios magnéticos y el ahorro de energía al no usar innecesariamente los procesadores de los servidores de correo y otros dispositivos de red que también han sido víctimas del temible "forward", he aquí mi firma (por supuesto, con el floppy):


<font color="#000066" face="Webdings" size="+1">Í</font><font color="#000066"> Cuida el ambiente, el ancho de banda y el espacio en disco: Por favor, no reenvíes este e-mail a menos que sea realmente necesario. ;)</font>

Bueno. Después de escribir todo este asunto pseudo-ambientalista, creo que es hora de ver esas presentaciones de PowerPoint que me llegaron esta mañana. :D

Por favor, reenvíen este mensaje a sus amigos y conocidos. No van a ganar la lotería, ni la chava más guapa de la escuela les va a hacer caso por enviarlo, pero al menos podrían contribuir a reducir el calentamiento global... de los servidores de correo.

:wq!

Del plato a la boca, se cae la sopa: El caso DNS-Kaminsky-Dullien

noreply@blogger.com (Knaverit) — Tue, 29 Jul 2008 01:20:00 +0000

No hace mucho les platicaba acerca del caso Kaminsky y cómo mantuvo en secreto (aunque, eso sí, divulgando a los cuatro vientos que tenía un secreto) una vulnerabilidad encontrada en el protocolo DNS, y comentaba yo acerca de la importancia de no revelar algo que pudiera caer en manos enemigas y ser explotado. En esto estábamos, cuando me entero este fin de semana que alguien se le adelantó a Kaminsky (que ya se veía con los reflectores encima): Thomas Dullien (aka Flake) publicó en su blog lo que él pensaba (por cierto, acertadamente) que podía ser el problema del DNS. Esto no sería relevante si no fuera porque alguien que participó en el proyecto de Kaminsky lo confirmó, con lujo de detalles. Aunque esta información estuvo publicada en Internet poco tiempo (fue quitada después de una disculpa), fue suficiente para que ahora medio mundo conozca los detalles y seguramente ya se están preparando los exploits correspondientes.

Bueno, esto iba a ocurrir de cualquier manera en agosto, cuando Kaminsky lo dijera en el BlackHat, así que los que hicieron la tarea y actualizaron (o parcharon) sus sistemas podrán dormir tranquilos. (?)

Esto deja varias lecciones: Primero, que cualquier persona con el tiempo, conocimiento y motivación suficientes, pudo haber descubierto la falla. Segundo, que no podemos confiar en la Seguridad por Oscuridad, es decir, que el simple hecho de ocultar algo no lo hace seguro. Y tercero, que a veces no conviene esperar tanto a los reflectores, especialmente cuando hay tanta expectativa: bien dicen que del plato a la boca, se cae la sopa.

Hasta luego.

:wq!

Error forense en Numb3rs

noreply@blogger.com (Knaverit) — Wed, 16 Jul 2008 15:15:00 +0000

¿Y la cadena de custodia, 'apá?

Anoche ví el episodio Sacrifice de la primera temporada de Numb3rs, la serie de televisión donde Charlie Eppes, un chavo matemático, ayuda a su hermano Don, agente del FBI, a resolver casos usando ¿qué creen? sí, matemáticas. He visto algunos episodios de la primera temporada y, aunque el concepto es interesante, algunas cosas son realmente difíciles de creer (de acuerdo, es entretenimiento). Cuando llego a ver televisión (algo muy remoto), lo hago para divertirme, no para estudiar matemáticas (esas las estudio a otra hora), y Numb3rs había sido prometedor, pero el episodio que vi anoche casi me causa una conmoción cerebral, por el impacto recibido al ver cómo los principios de investigación forense (al menos en el ámbito de la informática) eran echados a la basura. Les platico, aunque les advierto que revelaré parte de la trama. Bueno, están advertidos.

Como algunos de ustedes saben, me apasiona el tema de la seguridad de información, la criptografía y las investigaciones forenses en crímenes informáticos. Así que, cuando comienza el episodio y me doy cuenta de que la computadora de la víctima formará parte de la investigación, digo: "esto se va a poner interesante", pero, ¡oh, desilusión!, nunca se involucró a un forense de computadoras que conociera el procedimiento, obviamente no se inició la cadena de custodia, y peor aún, se transgredieron varios principios fundamentales del análisis forense que habrían ocasionado que, en caso de que tuvieran que ir a un juicio, la evidencia hubiera resultado inútil.

El episodio trata de la investigación del homicidio de un investigador que trabaja en un proyecto clasificado (confidencial) del gobierno; los archivos de su computadora personal (donde presumiblemente estaba toda su investigación) habían sido borrados. Primero: ¿qué hacía este investigador con información confidencial en su computadora casera? Por lo visto nadie le explicó al investigador el modelo de confidencialidad Bell-LaPadula, lo mismo que aquél militar que fue cesado porque su hija divulgó información clasificada del ejército, misma que encontró en una memoria flash (USB) donde su papá (el ex-militar) había copiado dichos archivos confidenciales... aunque esa es otra historia.

Pero, como dijera Jack El Destripador (Jack The Ripper): "vamos por partes" :-D. Por ejemplo: cuando llegan los supuestos forenses, comienzan a revisar la computadora directamente en la escena del crimen. Un buen forense no hubiera hecho eso; debieron haber comenzado la cadena de custodia del equipo, llevado al laboratorio forense, extraído el disco duro, obtenido una imagen bit a bit, montado la copia en modo read-only en un sistema operativo para analizar (de preferencia el de Linus, no el de Bill :-)) y, ahora sí, comenzar a investigar. Al no haber hecho esto, nuestros amigos investigadores expertos del FBI incurrieron en un error forense, al manipular directamente la computadora involucrada. Otra falla fue el hecho de que Charlie trató de revisar la PC del investigador, ahora occiso, también directamente, sin trabajar sobre una copia. Puras fallas.

Por otra parte, la explicación que Charlie le da a su hermano respecto a la sobreescritura de datos es algo ilustrativa, y cumple con el propósito de poner en contexto a la audiencia. Lo que él explica es un concepto que en seguridad conocemos como zeroization, que consiste en sobreescribir los datos con algún patrón de bits, de modo que se dificulte la recuperación de los datos originales. El asesino sabía que borrar los archivos no era suficiente, pues generalmente son recuperables, pero con zeroization sería mucho más difícil (pero no para nuestro héroe matemático). A lo mejor si se hubiera robado la computadora, el móvil hubiera parecido distinto y la investigación no hubiera requerido a los forenses de cómputo. Caso cerrado. :-D

Ya sé que todo esto al final es ficción y que en la vida real no se hubieran cometido tantos errores en materia forense. Además, pienso que para muchos es mucho más entretenido ver a estos personajes en la investigación que al forense y su laboratorio. Al final, como siempre, encontraron al culpable y todos vivieron felices, listos para el siguiente episodio... excepto Charlie, que se quedó pensando si lo que hacía era bueno o malo, si ayudaba a salvar vidas o las quitaba. Un dilema muy grande para una mente tan brillante. ;-)

:wq!

// Para los que no entendieron el subtítulo, está inspirado en la frase célebre del comercial de un chavito que está platicando con su papá, y le pregunta cuándo va a hereder la camioneta.

La importancia de no 'soltar la sopa': El caso DNS-Kaminsky

noreply@blogger.com (Knaverit) — Wed, 09 Jul 2008 20:44:00 +0000

Hasta este día no había escrito ningún comentario referente a vulnerabilidades o riesgos de seguridad, aún cuando siempre procuro estar pendiente de las actualizaciones y avisos relevantes diariamente. Sin embargo, mientras leía y profundizaba en los detalles de una de las actualizaciones relevantes de Microsoft de esta semana, me llamó enormemente la atención el caso de Dan Kaminsky, un profesional en seguridad informática que descubrió hace pocos meses (y por accidente, dice él) una vulnerabilidad en la implementación del protocolo DNS, que afecta tanto a servidores DNS como a clientes DNS.

Sólo para estar en el mismo contexto y para que nadie se sienta excluído: DNS (Domain Name System) es el servicio que se usa en Internet para evitar tener que memorizar (nosotros los humanos) direcciones IP (como 209.85.173.104) y en lugar de eso, recordar más fácilmente nombres de dominio tales como www.google.com. Sin DNS, Internet no sería lo que es ahora (no sería atractivo para muchísima gente).

Regresando al tema, lo que me llamó la atención de esto fue la forma de proceder de Dan Kaminsky al darse cuenta del problema. El hacker típico sin ética (black hat) habría explotado la vulnerabilidad en algún servidor expuesto (que, tratándose del servicio de DNS, no hubiera representado ninguna dificultad) y casi inmediatamente lo habría difundido en algún foro de hacking (en esos ámbitos, el dudoso prestigio de ser el primero en consumar un ataque es muy bien visto, aunque no sea éticamente correcto o legal). El problema aquí es que, por tratarse de un problema masivo, es decir, que afecta a todos los sistemas DNS, independientemente del fabricante, el atacante podría tener virtualmente control absoluto de prácticamente cualquier sistema de resolución de nombres de dominio (DNS) y direccionar a sitios falsos para robar información o cometer actos fraudulentos. Un gran riesgo.

Pero Kaminsky no lo hizo público. En lugar de anunciar públicamente (y quizá irresponsablemente) la falla, buscó a los principales proveedores involucrados en el desarrollo de servicios DNS (Sun Microsystems, Cisco, Microsoft) y al CERT (Computer Emergency Response Team) de Estados Unidos, y en conjunto comenzaron a trabajar secretamente en la solución, con el propósito de liberar la solución a nivel mundial al mismo tiempo. Esto ocurrió ayer, el día en que los principales proveedores de la industria liberaron simultáneamente los patches para sus respectivos productos. Las palabras clave en esto son "secretamente" y "en conjunto". Si no se hubiera hecho así, a estas alturas tendríamos un caos por todos los que habrían explotado ya la vulnerabilidad sin existir una solución de fondo en todos los sistemas. El mismo Kaminsky invita a seguir investigando el DNS, y a no hacer públicos los hallazgos en los foros o canales de IRC, y yo estoy completamente de acuerdo con él.

Los ataques a los sistemas DNS no son nuevos. Desde hace tiempo han existido los ataques de buffer overflow, DNS cache poisoning, spoofing, entre otros, pero no se había presentado un caso que involucrara de forma masiva a los sistemas en todo el mundo, y que se manejara de forma tan profesional y organizada como se hizo en esta ocasión. Así es como lo veo.

¿Qué tiene que ver esto con un usuario de servicios a través de Internet? Absolutamente todo. DNS interviene en prácticamente cualquier interacción en Internet... imagínense tener que visitar sitios Web usando la dirección IP, como http://209.85.173.104 por ejemplo. ¡Qué complicado! (las campañas de mercadotecnia se verían en apuros). Así que DNS nos ayuda a que escribamos http://www.google.com en el navegador, en lugar de la dirección IP, pues DNS hace la traducción del nombre de dominio en la dirección IP correspondiente. Si este problema se explotara, podríamos ser redirigidos sin darnos cuenta a servidores falsos y ser víctimas de pharming; o los correos electrónicos que enviáramos serían dirigidos a servidores extraños y ser interceptados por alguien más. Si DNS falla, Internet falla. El impacto sería enorme, pero aquí es donde la estrategia de manejarlo en forma coordinada tiene un gran valor.

Aún no hay información detallada acerca de esto, y la implementación presumiblemente se ha hecho pensando en que sea muy difícil la ingeniería inversa de los parches que están siendo liberados, precisamente para dar tiempo de instalar los parches en todos los sistemas que usan DNS, o de mover de BIND8 (que ya está muerto, excepto en Yahoo!) a BIND9. De hecho en este preciso momento ya hay varios tratando de identificar (usando ingeniería inversa) exactamente qué es lo que los parches corrigen, para tratar de explotarlo; esto es algo que no se puede evitar, y es la razón por la que es importante que todos los que tienen servicios que usan DNS instalen los parches cuanto antes. Kaminsky va a dar su versión en la próxima conferencia de Black Hat en Las Vegas, pero los detalles seguirán en secreto, al menos por un buen rato.

La seguridad es asunto de todos, y la seguridad en Internet no es la excepción. Al menos yo quiero que cuando mi familia se conecte a Internet para leer las noticias, comprar un libro, jugar en línea, usar el correo electrónico, hacer un pago bancario o simplemente leer un blog, lo haga con seguridad. ¿Quién no? Qué bueno que Dan Kaminsky no soltó la sopa. ;-)

:wq!

ISO 27001:2005, Primera Reunión de Intercambio de Experiencias en Monterrey

noreply@blogger.com (Knaverit) — Sun, 01 Jun 2008 03:08:00 +0000

"La Seguridad no es un producto; la Seguridad es un proceso".

La frase anterior es el mantra que todos los gurús profesionales en seguridad repiten una y otra vez (¿repetimos?). Esto es una gran realidad, pues en la actualidad muchas empresas no han entendido que la seguridad no es algo que se compre en caja, ni un proyecto que tenga una fecha de inicio y una fecha de conclusión, o algo que sea responsabilidad exclusiva de TI, sino que es un proceso de mejora continua, en el que todo el personal de la compañía debe estar involucrado.

Con esto en mente, ALAPSI Noreste organizó el 29 de mayo la Primera Reunión Cumbre de Intercambio de Experiencias con Sistemas ISO 27001:2005 Certificados, que tuvo como finalidad juntar a representantes de algunas empresas de México que han obtenido la certificación en Sistemas de Gestión de Seguridad de Información ISO27001:2005, para que platicaran sus experiencias en torno a la certificación, los beneficios obtenidos, las recomendaciones para aquellos que estén planeando iniciar el proceso de certificación, los retos que enfrentaron, etc. Entre los panelistas tuvimos a Patricia Molina de Elcoteq, a Carlos Rincón de Laboratorios Armstrong, a Daniel Aldrete de Hispanic Teleservices y a Ricardo Morales de Alestra. Todos ellos coincidieron en algo: la certificación ISO 27001:2005 les trajo beneficios a sus respectivas organizaciones, tales como mayor confianza por parte de sus clientes, estandarización y mejora de sus proceso internos, ahorros significativos, entre otros más.

ISO 27001:2005 es un estándar para la seguridad de información basado en la norma británica BS 7799, y que define lo nececesario para implementar, mantener y mejorar un Sistema de Gestión de Seguridad de Información, de acuerdo al Ciclo de Deming (o Plan, Do, Check, Act). Aunque la seguridad en sí no es un producto ni un proyecto, como ya lo mencioné anteriormente, la implantación de este estándar en una empresa con miras a la certificación sí requiere que se maneje como un proyecto, con su propio presupuesto. En general la implantación de ISO 27001 puede durar entre 6 meses y un año, según el alcance requerido y qué grado de madurez tienen los procesos en la organización. Aunque algunas empresas requieren el apoyo de consultores externos, es importante considerar dos cosas: primero, que tengan la experiencia suficiente en implementaciones anteriores, no que vengan a aprender con la empresa; y segundo, que su participación se limite a guiar al personal estratégico en cómo hacer las cosas, y no a hacer él sólo todo el trabajo desde lo básico (créanme, un consultor puede resultar muy caro). Una vez que el sistema está implementado y se tienen al menos unos 3 meses de evidencia documentada, ya se puede invitar a un organismo certificador (externo a la empresa) para que revise los procesos, la evidencia documental y se cerciore de que se cumple con lo establecido en el estándar. Por lo que escuchamos por parte de los que ya han recorrido este camino, no es fácil, pero vale la pena.

Esta reunión fue organizada por ALAPSI Noreste, que es la Asociación Latinoamericana de Profesionales en Seguridad Informática, de la cuál formo parte. Nuestra misión es crear conciencia y capacitar a organizaciones e individuos en el área de Seguridad de Información, por medio de cursos, seminarios, conferencias, artículos en publicaciones relacionadas con seguridad, etc., y promover prácticas que aseguren la confidencialidad, integridad y disponibilidad de los recursos informáticos de las organizaciones.

En resumen, espero que con eventos como éste cada vez más empresas se sientan comprometidas con la seguridad de la información, y comiencen a establecer las bases necesarias para que sus organizaciones mantengan los niveles de seguridad que se requieren en esta era de la información.

:wq!

Lo nuevo en Sun Tech Days 2008, México

noreply@blogger.com (Knaverit) — Wed, 28 May 2008 00:16:00 +0000

Otro año más y no he podido ir al JavaOne. Ni modo. Pero esta ocasión estuve nuevamente en el Sun Tech Days 2008, en la Ciudad de México, que sigue siendo una buena (y barata) opción para actualizarse en temas de Java y Solaris. El evento lo organiza Sun Microsystems y es algo así como un "world tour". Ahora no escuché a Sang Shin, pero estuve en varias conferencias con Raghavan "Rags" Srinivas (el del sombrero vaquero), por ejemplo, y nuevamente con Fabiola Gallegos. Mi objetivo principal en este viaje fue el de actualizarme en temas como SOA (Service Oriented Architecture), seguridad en Web Services y, por supuesto, en Mobile Applications.

Como un plus, estuve en una demo de Sun SPOT (Small Programmable Object Technology), que es una tecnología (aún experimental) de Sun Labs para la programación de dispositivos inalámbricos, equipados con sensores de luz y temperatura, acelerómetros, y un transmisor de radiofrecuencia de 2.4GHz, entre otras cosas (sin olvidar que corre con una implementación especial de virtual machine llamada Sqwawk, que corre directamente en la flash del dispositivo, hace la función de sistema operativo e implementa Java ME). La sesión se enfocó en demostrar la programación del dispositivo para transmitir la información recolectada por los sensores, o la incorporación de un dispositivo electrónico externo (en ese caso, una brújula electrónica) que transmitió la orientación hacia el basestation, y fue representada gráficamente en una aplicación de escritorio con Swing; fue sencilla, pero bastante ilustrativa. Lo malo es que en México aún no pueden conseguirse los kits de Sun SPOT, porque tienen que cumplirse ciertas regulaciones antes, pero un día de éstos conseguiré mi propio kit para jugar un rato.

Referente a Java ME, las demostraciones de Fabiola en este año se enfocaron a ejemplificar la ejecución de programas Java en dispositivos ejecutando Windows (como Pocket PC) y en BlackBerry. Fue todo un show, porque ejecutar una aplicación de Java ME en una Pocket PC requiere primero la instalación de una JVM específica para esa plataforma, y luego ya la instalación de la aplicación Java, que no es nada sencillo, sin embargo es posible. Para el caso de BlackBerry es más sencillo, pero aún así no es tan directo como en la mayoría de los teléfonos celulares habilitados con Java.

Y para terminar, las sesiones de SOA fueron bastante extensas y muy ricas en contenido. Como lo mencioné, mi principal preocupación era escuchar sobre los temas referentes a seguridad, y no me decepcionaron. Esto es particularmente importante por tratarse de una arquitectura que pretende integrar múltiples servicios a través de Web Services independientes de lenguaje, BPEL para coordinar u orquestar las transacciones que deban hacer uso de múltiples Web Services, y que permite la integración de tecnologías de seguridad que protegen la integridad y confidencialidad de los datos a través de todas las operaciones entre todas las entidades, y no sólo entre dos servidores. Sobre este tema escribiré en otra ocasión más ampliamente.

Bueno, así fue la semana anterior: "100% Pure Java".

:wq!

¿'Networker' o 'Programmer'? ...esa es la cuestión

noreply@blogger.com (Knaverit) — Fri, 18 Apr 2008 04:21:00 +0000

Esta semana di un seminario de Java, enfocado a demostrar cómo utilizar la tecnología Java para comunicar dos programas en una arquitectura cliente-servidor utilizando Sockets de TCP/IP. El tema en sí es interesante, desde mi punto de vista, y más porque tuve que explicar un poco sobre cómo ocurre la comunicación entre dos equipos en una red, por TCP/IP, antes de mostrar (y demostrar) el código Java de los programas cliente y servidor, para lograr que se comunicaran. Fue un seminario interesante, especialmente porque el tema era nuevo para muchos, y eso es lo que lo hace interesante.

Al final alguien me preguntó qué era más difícil aprender: redes o programación. Es una pregunta difícil, pues hablamos de dos áreas que, aunque relacionadas por la tecnología, son muy distintas entre sí. En primer lugar, porque las redes de computadoras se basan en tecnologías de comunicación que requieren varias disciplinas de las ciencias, mientras que la programación requiere una habilidad muy particular para idear la lógica que permita la ejecución correcta de los algoritmos necesarios para lograr algo. En sí el trabajo con redes requiere implementar una serie de principios ya probados y que funcionan prácticamente por sí solos mientras se cumplan las condiciones requeridas, tal es el caso de los protocolos de red, o de las tecnologías de interconexión que ya se han estandarizado. Pero programar es un arte, un arte que precisa imaginación, habilidad para resolver un problema de la manera más simple y eficiente posible y plasmarlo en un código comprensible para una computadora; programar es crear, es inventar. En resumen, son disciplinas muy distintas entre sí.

Semanas atrás un amigo me pedía mi recomendación para que le dijera qué curso le convenía tomar: uno de redes o uno de programación. Mi respuesta fue: "aprende lo que te guste hacer más". Al final decidió tomar el de programación, y espero que le esté yendo bien. Los últimos años he estado dando cursos de capacitación en programación en Java y cursos de redes (networking) con equipos Cisco, específicamente para aquellos que quieren certificarse como CCNA, y son definitivamente mundos distintos.

Yo comencé programando a la edad de 12 años, ya lo había comentado anteriormente, con una computadora Timex Sinclair y una Radio Shack de bolsillo que me dio mi tío Israel. Mi tío me regaló también mi primer libro de programación y con ese libro aprendí (en otra ocasión contaré la anécdota). Años después conocí acerca de las redes para transmisión de datos, de protocolos y tecnologías de redes, pero como dicen por ahí: "nadie puede negar su origen".

¿Entonces qué soy?, ¿networker o programmer? Un poco de todo, creo yo.

:wq!

Conjugando el inexistente verbo "subnetear" (Episodio II)

noreply@blogger.com (Knaverit) — Wed, 13 Feb 2008 01:43:00 +0000

Hay dos razones por las que he decidido dar continuación al tema de la obtención de sub-redes (subnetear, pues, para los que insisten): una es la creciente cantidad de referencias de búsquedas que he visto desde Google hasta este blog, referentes a "subnetear" o "subredes"; y otra es por pedido específico de una lectora que recientemente pidió que ejemplificara el caso para una red de clase A y otro de clase B. Pues bien, en esta segunda parte explicaré el procedimiento con una red de clase B (posiblemente haga una tercera parte con un ejemplo de clase A, dependiendo del interés).

Ok, partamos de un caso concreto: tenemos la red 150.14.0.0/16. Hay que recordar que el sufijo /16 indica que los bits que representan la máscara de sub-red (que para las redes clase B, antes de ser "subneteadas", siempre es 16 o sea, 2 octetos de 8 bits). En una red de esta clase (clase B), la cantidad de hosts está determinada por los 16 bits restantes de la parte de hosts, por lo que 2¹⁶-2=65,534 hosts posibles... ni hablar del desperdicio de direcciones.

Nuestra máscara /16, que en decimal es lo mismo que 255.255.0.0, se representa en binario de la siguiente manera.

11111111.11111111.00000000.00000000
<-------------red*host------------>

Ahora la parte crucial: ¿cómo comenzar a dividir la red? Simple: debemos partir de una necesidad: ¿qué requerimos?, ¿cierta cantidad de redes o cierta cantidad de direcciones de host por red? Tal vez son ambas cosas. En este ejemplo supondremos que el requerimiento es obtener de la dirección dada por lo menos 500 sub-redes con capacidad para 100 hosts cada una. Vamos a aplicar una sencilla regla para determinar cuántos bits necesitamos pedir (recuerden que no es un préstamo, sino un obsequio :-D):

Como necesitamos que haya 500 sub-redes, necesitamos encontrar un número tal que elevando la base 2 a dicho número nos de la cantidad de sub-redes necesaria, o un poco más. Como ya lo mencioné anteriormente, podemos obtener la potencia por aproximación (al "ojo por ciento") o usando logaritmos. Al final puse una breve explicación de ambos procedimientos, para quien tenga interés.

Lo importante es que obtuvimos el número que buscamos: 9 bits. Con 9 bits podemos obtener 512 combinaciones, lo que nos da alegremente la posibilidad de obtener tranquilamente las 500 sub-redes que nos piden. Ahora sólo nos resta verificar que cada sub-red (de las 512) pueda efectivamente incluir al menos 100 hosts. Para esto basta con obtener la cantidad de combinaciones que nos dan los bits restantes. Recuerda que una dirección IP está formada por 32 bits, y para nuestro caso 16 bits ya están siendo usados por la dirección clase B, y 9 bits son los que acabamos de calcular que necesitamos para obtener las 512 sub-redes. Así que, si la aritmética no nos falla, nos quedan 7 bits para obtener direcciones de hosts (sí, mira: 32-16-9=7). Con 7 posiciones podemos obtener 128 combinaciones de "0" y "1" (bits), y aún restándole las 2 direcciones de ley (al total de direcciones de hosts siempre restamos dos, porque una será la dirección de la sub-red y otra será la dirección de broadcast) nos da un número (126) que nos permite cumplir, también tranquilamente, con el requerimiento de 100 direcciones. Con "bolitas y palitos" (literalmente) queda de la siguiente manera:

11111111.11111111.11111111.10000000
<--red original--><-subred->
<--nueva máscara de subred->
11111111.11111111.11111111.10000000

Y esta nueva máscara de sub-red en decimal sería: 255.255.255.128 (él último octeto sólo tiene un bit 1 en la posición más significativa, y es el número 128).

Lo interesante de este caso es obtener las direcciones de sub-red, pues hay que observar que los bits de sub-redes abarcan dos octetos (9 bits). No se asusten, no pondré las 512. Voy a poner sólo las primeras combinaciones de sub-redes para los dos últimos octetos. Así tenemos:

00000000.00000000 (es decir, 0.0)
00000000.10000000 (es decir, 0.128)
00000001.00000000 (es decir, 1.0)
00000001.10000000 (es decir, 1.128)
00000010.00000000 (es decir, 2.0)
00000010.10000000 (es decir, 2.128)

Quiero hacer notar una cosa: el bit menos significativo de la nueva máscara es precisamente el que está en la posición 128 del cuarto octeto (y, por cierto, 128 es el número que resulta de 2⁷, antes de restarle 2). Si lo que queremos es obtener más rápido las direcciones de red (¿quién no quiere?), puede hacerse con incrementos de 128 (el bit menos significativo de la máscara) en el octeto correspondiente. Sólo que hay un detalle: comenzamos con 0 (cero), luego sumamos 128, pero si sumamos 128 a 128 nos da 256, que no puede expresarse con sólo 8 bits (256=100000000, 9 bits). Lo que hacemos es exactamente lo mismo que con las horas y minutos del reloj: después de 59 minutos se incrementa en 1 la hora, y los minutos quedan en cero; por lo tanto, si tenemos 0.128, el siguiente número NO es 0.256, sino 1.0. ¿Está claro?

Ahora sí, poniendo las direcciones completas, quedarían:

150.14.0.0/25
150.14.0.128/25
150.14.1.0/25
150.14.1.128/25
150.14.2.0/25
150.14.2.128/25
etc.

"¡Espera! ¿De dónde salió el '/25'?". Originalmente teníamos 16 bits en la parte de la red, pero como pedimos 9 bits a la parte de hosts, sumando 16 mas 9 nos quedan ni más ni menos que 25 bits, por eso la nueva máscara es /25.

Muy bien, hasta este momento hemos obtenido las combinaciones de sub-redes. Ahora necesitamos obtener las direcciones de host para cada una de las sub-redes obtenidas. Eso es fácil. Hagámoslo primero en binario. Para cada sub-red vamos a calcular su dirección de broadcast:

00000000.01111111 (este es 0.127)
00000000.11111111 (este es 0.255)
00000001.01111111 (este es 1.127)
00000001.11111111 (este es 1.255)
00000010.01111111 (este es 2.127)
00000010.11111111 (este es 2.255)
etc.

No hay que olvidar la regla: "las direcciones de red tienen todos los bits de host en cero (0), y las direcciones de broadcast tienen todos los bits de host en uno (1)".

De esta manera, obtener los rangos de direcciones de host válidas es mucho más sencillo, pues la primera dirección válida será una más que la dirección de red, y la última dirección válida será una menos que la dirección de broadcast. Sencillo, ¿no?

Para la sub-red 150.14.0.0/25
150.14.0.0/25 (dirección de red)
150.14.0.1/25 (primera dirección de host válida)
150.14.0.126/25 (última dirección de host válida)
150.14.0.127/25 (dirección de broadcast)

Para la sub-red 150.14.0.128/25
150.14.0.128/25 (dirección de red)
150.14.0.129/25 (primera dirección de host válida)
150.14.0.254/25 (última dirección de host válida)
150.14.0.255/25 (dirección de broadcast)

Para la sub-red 150.14.1.0/25
150.14.1.0/25 (dirección de red)
150.14.1.1/25 (primera dirección de host válida)
150.14.1.126/25 (última dirección de host válida)
150.14.1.127/25 (dirección de broadcast)

Si observan, la cantidad de direcciones entre la primera y la última válida son exactamente las 128 que dijimos (aunque sólo necesitamos 100, pero no es lo mismo "desperdiciar" 28 que 15,000).

Y con esto hemos terminado de "subnetear" la red de clase B (¡perdón!, la palabra "subnetear" sigue sin existir en español) sin desperdiciar muchas direcciones.

(Ningún bit salió lastimado durante esta división de sub-redes).
:-D

:wq!

Procedimiento usando logaritmos

Me voy a permitir hacer un pequeño recordatorio matemático y pondré el procedimiento para obtener la potencia usando logaritmos:

Sabemos que:
x=bⁿ

y que:
n=log_bx

Si la base (b) fuera 10, obtener n con la calculadora es directo. El problema con una calculadora sería obtener n siendo la base (b) diferente de 10, como en nuestro caso que es 2. Para esto podemos usar la siguiente identidad:

log₂x=(log x)/(log 2)

De tal manera que la fórmula quedaría:
n=(log x)/(log 2)

Sustituyendo:
n=(log x)/(log 2) = (log 500)/(log 2)
n=2.7/0.3
n=9

Porque:
2⁹=512

El resultado indica que necesitamos 9 bits para obtener las sub-redes. Este procedimiento es el más complejo y requiere usar calculadora o tablas de logaritmos, pero sirve por lo menos para impresionar a más de dos. ;-) Esto me recuerda lo que decía mi maestro de Ecuaciones Diferenciales, cuando nos motivaba a comprar el libro de texto. Él decía: "muchachos: compren el libro. Les aseguro que si no aprenden, por lo menos podrán impresionar a las muchachas con el puro título". :-D ¡Cuánta razón tenía!.

Procedimiento por aproximación

Perdón por haber puesto el procedimiento anterior, pero varios se habían quedado con la duda de cómo se resolvía por logaritmos, si es que realmente se podía. La realidad es que muchos de los que regularmente calculan sub-redes no usan ese procedimiento (y muchos ni siquiera lo conocen). Mejor hagámoslo de la manera tradicional, aunque no se vea tan nerd.

Si lo que necesitamos es un número al que podamos elevar (potencia) el 2 (la base) para que nos dé 500 redes, yéndonos por potencias de 2 podemos encontrarlo relativamente rápido:

n=9, pues
2⁹=512 (porque 2*2*2*2*2*2*2*2*2=512)

El "secreto" es ir multiplicando 2*2, llevando la cuenta de cuántos "2" llevas, hasta que encuentres el número que buscas... ;) Este procedimiento es más práctico que el anterior; tal vez no impresiones a nadie (o ¿quién sabe?), pero al menos llegarás rápido al número que necesitas. ;-)

:wq!

Aka Knaverit

noreply@blogger.com (Knaverit) — Mon, 04 Feb 2008 10:02:00 +0000

Hace un tiempo me preguntó un amigo si yo tenía algún nickname o seudónimo con el que me conocieran en la red, o si yo era alguien "importante", de esos que colaboran en muchos foros y responden preguntas, o encuentran vulnerabilidades y hacen alarde de ello, etc. La realidad es que no soy nadie importante en la red (al menos eso creo), sólo alguien que gusta de compartir cosas que sabe (algunas sencillas, otras no tanto), o cosas que considera que podrían interesarle a alguien. Y respecto a encontrar vulnerabilidades, sí he encontrado algunas de vez en cuando, y el código de ética de CEH me obliga a no divulgarlas, sino a reportarlas directamente a los responsables de los sitios para que las solucionen, con mi valor agregado: la recomendación de solución. Eso sí me gusta. Ahorita, por ejemplo, estoy haciendo un white hat hacking que una empresa me pidió hacer para ella misma (y mis planes de fin de semana largo se fueron por la borda). Si no fuera por estas pausas que me doy para escribir de vez en cuando, ya hace rato me hubiera ido a dormir.

Para los que tengan curiosidad, en todas mis entradas de mis blogs firmo como Knaverit, aunque no es nada parecido a los seudónimos que usan los hackers o los crackers. Mi seudónimo se remonta a hace muchos años, cuando dibujaba, y es el nombre que le puse al personaje principal de una historieta que nunca vio la luz, mas que de mi lámpara de mi mesa de dibujo. Mis personajes están por ahí en algún lugar entre mis viejos libros, pero Knaverit siempre fue mi favorito, así que esa es la razón por la que firmo así. De hecho si buscan "knaverit" en Google (o sea, si "googlean" :-D) seguramente me van a encontrar a mi (quiero decir, a mis blogs), y también descubrirán que hace tiempo compré unos limpiadores para la pantalla de mi laptop (no me gusta que pongan los dedos en la pantalla), y alguna referencia a un sitio donde próximamente estaré subiendo mis podcasts: así es, dentro de poco comenzaré a subir algunos de mis entradas de los blogs que escribí en 2007, en formato MP3, leídos por el de la voz (o sea por mi, para que me entiendan). Aún no sé si esta forma de comunicar lo que escribo sea de interés para alguien, pero voy a probar. Incluso se me ocurren dos o tres ideas para aprovechar el podcasting... luego les platico.

Sólo una nota aclaratoria, en caso de que ISC2 me investigue ahora que soy candidato a CISSP: No pertenezco a ninguna agrupación de hacking ni oculto mi identidad con otro nombre; sólo me gusta cómo se oye y, como escritor novel me puedo permitir tener algún seudónimo, ¿no?, . :-D

Así que ya lo saben, me llamo Romeo (para los cuates), pero también soy conocido (aka=also known as) como Knaverit... KnaverIT (léase con la pronunciación conocida de: "my name is Bond, James Bond"). :-D

:wq!

La imperiosa necesidad de la confidencialidad

noreply@blogger.com (Knaverit) — Thu, 13 Dec 2007 06:20:00 +0000

Hace varias semanas atrás terminé de leer el libro "Criptonomicón", de Stephenson. Uno de los grandes temas abordados en él fue sin duda el de la confidencialidad. La necesidad que tienen no sólo los individuos sino también las organizaciones de mantener en secreto su información crucial es lo que ha permitido la evolución de los criptosistemas y otros mecanismos que garanticen -si es que puede existir alguna garantía- que esa información no será conocida por ningún otro que no sea aquél a quien va dirigida.

Sin embargo el derecho a la confidencialidad se ha encontrado en controversia al ser confrontado con la obligación de los gobiernos de garantizar la seguridad. Mucho se ha dicho acerca de las diferentes maneras que tienen los gobiernos de conocer y controlar el flujo de la información. Por ejemplo, pocos han oído acerca de Carnivore*, la herramienta de software usada hasta hace algunos años por el FBI de los Estados Unidos para analizar (con la orden judicial correspondiente) el tráfico de correo electrónico que pasa por un proveedor de servicios de Internet (ISP) y que permite leer los encabezados de los mensajes de correo electrónico en busca de indicios de alguna conspiración o hecho ilegal (cuando digo "hasta hace algunos años" no quiero decir que ya no lo hace, sino que ha optado por otras alternativas de software que logran el mismo fin). Por otra parte, también muy pocos han escuchado acerca de las posibilidades de codificación de mensajes usando, por ejemplo, PGP (Pretty Good Privacy, Privacidad Bastante Buena), que es un programa utilizado para autentificar (estar seguros de que una persona que envía un mensaje es realmente quien dice ser) y, especialmente, dar privacidad por medio de la criptografía ("esconder" un mensaje para que, en caso de ser interceptado o leído por un tercero, no pueda ser entendido) no sólo en transmisiones en vivo (como lo haría un protocolo como SSL, por ejemplo) sino aún en datos almacenados en algún medio. Sin duda, un juego de gato y ratón en el que prevalece el más astuto o, en ocasiones, el más persistente.

La pregunta es, ¿hasta dónde es importante la confidencialidad? Por supuesto que a ninguno le agrada la idea de que alguien más conozca la información que uno considera privada. ¿Cuántos casos no sabemos de gente que ha leído el correo electrónico de otra persona sin su consentimiento, o ha averiguado cuánto dinero gana consiguiendo acceso a algún reporte de estado de cuenta bancario del afectado? Los gobiernos de algunos países consienten la idea de intervenir en las conversaciones (telefónicas o de correo electrónico, por ejemplo) con la justificante de prevenir algún delito. La respuesta, por supuesto, no es trivial. Sin embargo, es innegable el hecho de que todos tenemos derecho a conservar en secreto aquello que consideramos que no deba ser conocido por los demás pues nos haría vulnerables, a menos que ese secreto ponga en riesgo la vida o la integridad de los demás, en cuyo caso deberíamos ser capaces de descifrar dichos mensajes a tiempo y tomar acciones en consecuencia.

La frontera entre ocultar y conocer es muy sutil, y la legislación muy pobre, pero en mi humilde opinión (IMHO) todo este asunto de conocer o no conocer la información ajena, o de ocultar o no nuestra información se debe resumir en una palabra: respeto.

:wq!

* El enlace original a Carnivore ya no existe en el sitio del FBI, por eso incluí la referencia de archive.org, donde es posible encontrar versiones antiguas de páginas web.

¡Felices 100000 años!

noreply@blogger.com (Knaverit) — Thu, 22 Nov 2007 06:17:00 +0000

Pues llegó el día.

Hoy es mi cumpleaños número 100000 en binario (oigan, en hexadecimal es mucho más atractivo: 0x20). Generalmente no soy muy dado a considerar mi cumpleaños como una fecha muy importante (aunque definitivamente lo es), pero en esta ocasión y por tratarse de un número significativo, estoy haciendo una excepción (¿o debo decir "lanzando una excepción"?, throw new java.lang.Exception();... no, porque una excepción es una condición inesperada en un programa, y en mi caso este cumpleaños sí lo estaba esperando).

Y no es sólo porque 32 sea la cantidad de bits que forman una dirección IPv4, o porque 32 es el código ASCII del carácter espacio, o el tamaño que generalmente reservan en memoria las variables de tipo entero en un programa, o la quinta potencia de dos (2^5), o el punto de congelación del agua (en grados Fahrenheit) al nivel del mar, o porque 32 son las piezas que hay al iniciar un juego de ajedrez, o mejor aún, porque en matemáticas el 32 es el noveno número feliz o el tercer número de Leyland... no, no sólo es por eso, también es porque he dado 32 vueltas alrededor del sol.

Realmente no tengo un comentario tan profundo el día de hoy, sólo quería compartir con ustedes este momento; disculpen tanta simpleza, pero no todos los días se cumplen 100000 años. ;-)

:wq!