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!

Error forense en Numb3rs

¿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

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

"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

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

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)

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

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!