La comunicación es un asunto de capas

¿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"

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

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

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?

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

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

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!